Currently, if dracut fails to mount /usr for any reason, the user is dropped to a shell after the chroot to /. If /usr is on an lvm logical volume, it's impossible to run any lvm2 commands, since /usr/lib/libncursesw.so.5 is not available. This is a critical library for initial booting. If it isn't in the / filesystem, there is no easy way for a user to run commands to fix the system.
Hi, thanks for reporting this bug. As there is no maintainer for this package I added the committers in CC. (Please set the status to 'assigned' if you are working on it)
CC: (none) => fundawang, mageia, mageia
The problem is stated incorrectly. The system should not chroot to / if /usr could not be mounted. You should instead be in a dracut shell which is fully contained. All the tools required to start LVM should be contained in the initramfs itself. As the general aim is to not have a separate /lib at all, I'd say the proposed solution would be a backwards step. In the setups I've seen previously, I found that when /usr was not mounted, the system did not chroot to /.... are you 100% sure this is the case for you?
Yes, I'm sure. What's happening is that there is currently a bug in dracut such that the "lvm2 vgchange -a y" command does not get run on my i586 system. As /usr is on a logical volume, dracut can't find it, and skips trying to mount it, resulting in an emergency shell after the pivot. While obviously the problem causing the lvm2 command to not get run has to be found/fixed, which would make this change unneeded, this library should be in /lib, like the library it's replacing, as it's required by many commands in /bin and /sbin. I haven't had time to track down why dracut isn't running the lvm2 command, but will look into that more later today.
(In reply to comment #3) > Yes, I'm sure. What's happening is that there is currently a bug in dracut > such that the "lvm2 vgchange -a y" command does not get run on my i586 > system. As /usr is on a logical volume, dracut can't find it, and skips > trying to mount it, resulting in an emergency shell after the pivot. > > While obviously the problem causing the lvm2 command to not get run has to > be found/fixed, which would make this change unneeded, this library should > be in /lib, like the library it's replacing, as it's required by many > commands in /bin and /sbin. > > I haven't had time to track down why dracut isn't running the lvm2 command, > but will look into that more later today. @ Dave Did you get around to doing that?
CC: (none) => marja11
There have been various discussions about this on the mailing list. Now a hostonly initrd works for Dave's setup, but the non-hostonly one is still broken. The reasons are known - it relates to when the initqueue is run and how it doesn't know to wait for the devices on lvm to be ready properly when they are not holding the / partition. i.e. anything that is in /usr tree will not be waited for and thus /usr will not be mounted. Anyway, the problem is known and the fix will be eventually forthcoming.
As /lib and /usr/lib have not been merged yet, I still think all libraries used by programs in /bin and /sbin should be in /lib, not /usr/lib. The dracut/lvm bug report is Bug 4537.
(In reply to comment #6) > As /lib and /usr/lib have not been merged yet, I still think all libraries > used by programs in /bin and /sbin should be in /lib, not /usr/lib. I disagree. As stated earlier the bug report is incorrectly titled and the problem case was incorrectly posed. All the necessary tools and libs are *copied* to the initrd and it is the initrd's job to do the mounting therefore the location of any library is totally irrelevant. Besides if dracut fails to mount /usr, you will not be put into an emergency shell without /usr mounted. If dracut ever gives you an emergency shell, it will be before the pivot root and any lvm command line tools you run will be run from the initrd context. However, all that said we are apparently still going to support mkinitrd in mga2 (something I'd still prefer not to do) and thus in a non-systemd, non-dracut case I have to concede that this will cause problems. I think it was Thomas who specifically wanted to keep mkinitrd, so I'll see if he still feels this way and whether we should make this change. Also it seems this issue itself was introduced by Barry Jackson due to a change to readline: http://svnweb.mageia.org/packages/cauldron/readline/current/SPECS/readline.spec?r1=177891&r2=179770 The log message doesn't say why, so perhaps he can comment on the reasoning?
CC: (none) => tmb, zen25000
(In reply to comment #7) > Also it seems this issue itself was introduced by Barry Jackson due to a change > to readline: > http://svnweb.mageia.org/packages/cauldron/readline/current/SPECS/readline.spec?r1=177891&r2=179770 > > > The log message doesn't say why, so perhaps he can comment on the reasoning? Yes sorry about the lack of comment - lesson learned. This was discussed in https://bugs.mageia.org/show_bug.cgi?id=2156 which I found myself involved with after trying to make what should have been a simple permissions change to fix https://bugs.mageia.org/show_bug.cgi?id=3053.
Sorry I somewhat forgot about this, but I've now moved the lib to / to support this. All the best.
Status: NEW => RESOLVEDResolution: (none) => FIXED