Created attachment 361848 [details] output of ls -ls /etc/init.d openRC: 0.12.3 (2013-10-23 and previous) fsck does not find LABEL= if it is an LVM volume mountlocal does not find LABEL= for LVM filesystems as a result several "local filesystems failed to mount" examination shows that fsck had no dependency information to make LVM stuff be processed before it runs. It also appears that localmount does not properly use the dependancy info correctly to activate LVMs before trying. Attaching: ls -l /etc/init.d/ rc-update output
Created attachment 361850 [details] output of rc-update
Created attachment 361852 [details] output of 'ls -ls /etc/runlevels/boot'
Created attachment 361854 [details] content of /etc/fstab
(In reply to G.Wolfe Woodbury from comment #0) > examination shows that fsck had no dependency information to make LVM stuff > be processed before it runs. > It also appears that localmount does not properly use the dependancy info > correctly to activate LVMs before trying. The lvm script has "before fsck" in its dependencies, so if they are both in the boot runlevel, lvm will start before fsck. The localmount script has "use lvm" and "after lvm". "use lvm" will start lvm if lvm and localmount are in the same runlevel, and "after lvm" will make sure localmount runs after lvm. In order to be sure that is happening, I need to see a boot log. set rc_logger="YES" in /etc/rc.conf, reboot, and attach a copy of /var/log/rc.log.
Please feel free to reopen when you can provide the requested information. Thanks, William
Here is the requested rc.log output. There is no trace of lvm being used in the boot set. ------------------------------------------------------------------------------- rc boot logging started at Thu Oct 31 09:45:58 2013 * Setting system clock using the hardware clock [UTC] ... [ ok ] * Loading module vboxdrv ... [ ok ] * Loading module vboxnetadp ... [ ok ] * Loading module vboxnetflt ... [ ok ] * Loading module vboxpci ... [ ok ] * Autoloaded 4 module(s) * Remounting root filesystem read/write ... [ ok ] * Remounting filesystems ... [ ok ] * Updating /etc/mtab ... [ ok ] * Activating swap devices ... [ ok ] * Configuring kernel parameters ... [ ok ] * Creating user login records ... [ ok ] * Wiping /tmp directory ... [ ok ] * Setting hostname to onyx ... [ ok ] * Setting terminal encoding [UTF-8] ... [ ok ] * Setting keyboard mode [UTF-8] ... [ ok ] * Loading key mappings [us] ... [ ok ] * Bringing up network interface lo ... [ ok ] * Updating microcode ... [ ok ] * Bringing up interface lo * 127.0.0.1/8 ... [ ok ] * Adding routes * 127.0.0.0/8 via 127.0.0.1 ... [ ok ] * Activating additional swap space ... [ ok ] * setting up tmpfiles.d entries ... [ ok ] * Initializing random number generator ... [ ok ] rc boot logging stopped at Thu Oct 31 09:46:00 2013 rc default logging started at Thu Oct 31 09:46:00 2013 * Bringing up interface eth0 * 10.11.12.102/24 ... [ ok ] * Adding routes * default via 10.11.12.1 ... [ ok ] * Checking your configfile (/etc/syslog-ng/syslog-ng.conf) ... [ ok ] * Starting syslog-ng ... [ ok ] * Starting named ... * Checking named configuration ... [ ok ] [ ok ] * Mounting network filesystems ... [ ok ] * Starting sshd ... [ ok ] * Starting apache2 ... [ ok ] * Setting clock via the NTP client 'ntpdate' ... 31 Oct 09:46:12 ntpdate[1861]: step time server 216.66.0.142 offset 0.032677 sec [ ok ] * Starting ntpd ... [ ok ] * Starting boinc ... [ ok ] * Starting ConsoleKit daemon ... [ ok ] * Starting cupsd ... [ ok ] * Starting DenyHosts daemon ... [ ok ] * Starting rpcbind ... [ ok ] * Starting NFS statd ... [ ok ] * Starting NFS sm-notify ... [ ok ] * Mounting NFS filesystems ... [ ok ] * Starting postfix ... [ ok ] * samba -> start: smbd ... [ ok ] * samba -> start: nmbd ... [ ok ] * Starting vixie-cron ... [ ok ] * Setting up kdm ... [ ok ] * Starting xinetd ... [ ok ] * Starting local [ ok ] rc default logging stopped at Thu Oct 31 09:46:18 2013
(In reply to G.Wolfe Woodbury from comment #6) > Here is the requested rc.log output. > There is no trace of lvm being used in the boot set. There is also no trace of fsck, and there should be, You should at least see "checking local file systems", maybe followed by some errors. This log also indicates no failures when mounting local file systems.
It is interesting that the rc.log does not show fsck running, it can be seen clearly on the boot screen scrolling by. Services run in boot mode are logged before and after the fsck place, but fsck is not logged. I point to the rc-update printout given above. and include the rc.log from my latest reboot (Thu morning 2013-11-07) also including attachments of the /etc/init.d/fsck script
Created attachment 362778 [details] recent rc.log 2013-11-07
Created attachment 362782 [details] current /etc/init.d/fsck script
This problem remains very puzzleing. I have identified part of the problem to the current version of lvm not having any activation pathways for lvmetad for openRC installations! There are inclusions for systemd (lvmetad.service and lvmetad.socket) but nothing in /etc/init.d mentions lvmetad. Attempting to enable use_lvmetad in /etc/lvm/lvm.conf results in copious output of failure to find the socket. It also seems that the script in /etc/init/d/lvm doesn't properly start/detect PVs due to the coding of the conditionals. I am still working on understanding this development.
(In reply to G.Wolfe Woodbury from comment #11) > This problem remains very puzzleing. I have identified part of the problem > to the current version of lvm not having any activation pathways for lvmetad > for openRC installations! There are inclusions for systemd (lvmetad.service > and lvmetad.socket) but nothing in /etc/init.d mentions lvmetad. Attempting > to enable use_lvmetad in /etc/lvm/lvm.conf results in copious output of > failure to find the socket. Do you have a configuration that actually requires lvmetad? LVM should still work fine without lvmetad > It also seems that the script in /etc/init/d/lvm doesn't properly > start/detect PVs due to the coding of the conditionals. I am still working > on understanding this development. Could you clarify which conditions aren't triggering for you?
It doesn't net lvmetad, but the /etc/init.d/lvm script seems to be the problem. It does some very painful and unstable tricks to perform the activations. I have been playing with that script to simplify it but I'm not ready to submit it as a patch. I say unstable because in a fresh installation it works, but adding some packages (not yet identified) seem to upset the balance and cause 'lvm start' to fail. I am also still investigating the rc_logger issues. [Sorry for the long delay in replying. I have had some life issues interfering with my continuing involment with my systems administration avocation in retirement. SysAdmin was my specialty during my work years.]
This bug is now irrelevant. Recent changes to the OpenRC scripts have somehow managed to eliminate this problem and recent installs and upgrades are working properly without this problem occurring. I also note that lvmetad is not the problem, it seems to have been a red herring. I still have concerns mentioned in comment 13 about how the script chooses to build a bash command sequence to run various lvm "subcommands" when the commands could simply be run from the init script directly. I'm still investigating modifications and simplifications to the script. So far I have my full installtion back, and lvm start is working fine. This bug can be closed as RESOLVED with WORKSFORME or a "superceeded" status if one is available.
(In reply to G.Wolfe Woodbury from comment #14) > I still have concerns mentioned in comment 13 about how the script chooses > to build a bash command sequence to run various lvm "subcommands" when the > commands could simply be run from the init script directly. I'm still > investigating modifications and simplifications to the script. In some setups, the commands (symlinks to a multicall binary) don't always exist. They can mostly be implemented with 'lvm $LVM_OPTS $COMMAND $COMMAND_OPTS ...', but there was a historical reason that a script was preferred (I can't recall now, I wrote some of it a long long time ago). > This bug can be closed as RESOLVED with WORKSFORME or a "superceeded" status > if one is available. Closing as obsolete.
