I'm sorry if this is going to be a rather unspecific bug report. Today I spent several hours repairing my system which became unusable after my last world update. Pitfalls in the behaviour of dracut played a major role there, so I'm going to report my experiences and indicate places where different behaviour or documentation would have helped me avoid my problem. I'm using / on a dedicated partition, and /usr inside an lvm. I had kept udev to ~171 for a while, and experimented with dracut to mount my /usr, as I didn't use any initramfs before. I got it working, and thought that things were working smoothly for some time now, so I felt ready to unmask more recent udev, and also switch from module-init-tools to kmod. Alas, it appears that dracut didn't mount /usr, and probably hadn't done so since I had deactivated hostonly mode at some point. It took some detective work to figure that out. The following improvements might help avoid such problems: - 50mount-usr.sh continues without so much as an error message if the device node for /usr is not available. As /usr is absolutely necessary once you switch from module-init-tools (in /sbin) to kmod-8 (/usr/bin/kmod), this is asking for trouble. I believe it would be prudent to drop to an emergency_shell instead in that case. - "hostonly" sounds like it would simply install less stuff. What the documentation does not mention is the fact that in hostonly mode, more specific configuration is generated. In my case, /etc/cmdline.d/90lvm.conf containing the rd.lvm.lv for /usr is only generated in hostonly mode. - rd.lvm.{lv|vg} documentation in the dracut.cmdline man page states that with either of these set, only the given LV resp. VG will be activated. This suggests that in the absence of either, all LVM VGs should be detected and activated, which I found not to be the case. It appears that there is no way to request a full lvm scan from dracut.
(In reply to comment #0) > The following improvements might help avoid such problems: > > - 50mount-usr.sh continues without so much as an error message if the device > node for /usr is not available. As /usr is absolutely necessary once you > switch from module-init-tools (in /sbin) to kmod-8 (/usr/bin/kmod), this is > asking for trouble. I believe it would be prudent to drop to an > emergency_shell instead in that case. But it is specified in /etc/fstab or not? > - "hostonly" sounds like it would simply install less stuff. What the > documentation does not mention is the fact that in hostonly mode, more > specific configuration is generated. In my case, /etc/cmdline.d/90lvm.conf > containing the rd.lvm.lv for /usr is only generated in hostonly mode. Right, man page should be updated on that. Thanks. > - rd.lvm.{lv|vg} documentation in the dracut.cmdline man page states that > with either of these set, only the given LV resp. VG will be activated. This > suggests that in the absence of either, all LVM VGs should be detected and > activated, which I found not to be the case. It appears that there is no way > to request a full lvm scan from dracut. Dracut only enables what is needed for rootfs to mount. If this option is set then dracut scans all VGs until it founds rootfs. Later it should disable not used VGs. You have written you have troubles with dracut. Is this bug only about outdated documentation or there are more problems?
(In reply to comment #1) > But it is specified in /etc/fstab or not? It is specified in the system /etc/fstab, and correctly copied to the initramfs /etc/fstab. In other words, this part of the skript works as expected: while read _dev _mp _fs _opts _freq _passno; do … done < "$NEWROOT/etc/fstab" >> /etc/fstab What does not work the way I would have expected is this part: if [ "0" != "${_passno:-0}" ]; then fsck_usr "$_dev" "$_fs" else : fi _ret=$? echo $_ret >/run/initramfs/usr-fsck if [ $_ret -ne 255 ]; then info "Mounting /usr" mount "$NEWROOT/usr" 2>&1 | vinfo fi I have passno != 0, so the first branch of that if is used. fsck_usr calls fsck_single from fs-lib.sh, which has the line [ -e "$_dev" ] || return 255 So due to the request for an file system check, the mount command isn't executed. As a non-zero value there doesn't apear particularly esoteric to me, dracut should be able to deal with such an fstab. The "if [ $_ret -ne 255 ]" part seems like there should be an "else" as well. > > - "hostonly" … > > Right, man page should be updated on that. Thanks. I take it that you are an upstream developer yourself, so there is no need for an upstream bug report about this, right? > > - rd.lvm.{lv|vg} … > > Dracut only enables what is needed for rootfs to mount. If this option is > set then dracut scans all VGs until it founds rootfs. Later it should > disable not used VGs. OK, I misread the script: originally I had believed that the reason the device node for my /usr file system was missing was due to no vgscan at all. Now I realize that the lvm_scan.sh script has [ -z "$LVS" -o -n "$VGS" ]. I had originally read this as an AND (-a) instead of the OR it actually is. So now I agree that the script SHOULD activate all VGs, which should result in the activation of all LVs, and should have made my device node available. Why that didn't happen is a mystery for me at the moment. I will try to reproduce this problem the next time I boot this machine and have a bit of time for such experiments. Will report back whether I could identify the actual problem. > You have written you have troubles with dracut. Is this bug only about > outdated documentation or there are more problems? Now that I have my configuration in place, things appear to work smoothly. The first thing I reported, about the missing error message and emergency shell, is about behaviour not just documentation. And while I originally assumed the last item about documentation and missing functionality, I now have the impression that there is a yet unidentified bug in behaviour as well. I'm still far from happy with the fact that I require an initramfs in the first place, where the root file system should be enough at least to mount /usr. But that development is not caused by dracut, so I won't blame the messenger.
(In reply to comment #2) > [...] > So due to the request for an file system check, the mount command isn't > executed. As a non-zero value there doesn't apear particularly esoteric to > me, dracut should be able to deal with such an fstab. The "if [ $_ret -ne > 255 ]" part seems like there should be an "else" as well. I agree that's strange dracut doesn't fail on /usr mount failure. I'll fix it. > > > - "hostonly" … > > > > Right, man page should be updated on that. Thanks. > > I take it that you are an upstream developer yourself, so there is no need > for an upstream bug report about this, right? I'm not sure about developer, but I contribute a bit to dracut. I'll take care of it. > I'm still far from happy with the fact that I require an initramfs in the > first place, where the root file system should be enough at least to mount > /usr. But that development is not caused by dracut, so I won't blame the > messenger. I'm not happy with that either. :-)
(In reply to comment #2) > I will try to reproduce this problem the next time I boot this machine and > have a bit of time for such experiments. Will report back whether I could > identify the actual problem. OK, here are my findings so far. All of them with hostonly off. 1. With rd.lvm.lv specified on the command line, everything works as it should. 2. Without rd.lvm.lv, ther LV isn't found, hence /usr isn't mounted. 3. Executing the vgscan / vgchange commands manually activates it. Due to 1., I assume that the lvm_scan.sh command is executed, so udev rules shouldn't be part of this problem. Due to 3. I gather that the basic idea in the lvm_scan.sh script is sound. But as I still experience 2., I guess there is some logic error in lvm_scan.sh. Next time I can work on this, I'll try executinhg the whole lvm_scan.sh manually, perhaps with -x. Sadly less doesn't seem to work too well inside dracut, and my scrollback buffer is rather limited as well. Therefore parsing the results will probably become a real pain. One minor thing I noticed along the way: the info and warn functions of dracut-lib.sh pass their arguments to echo using $@ instead of $*, and vwarn passes the lines unquoted. All of these cause some uneccessary word breaking, and the latter might even cause multiple spaces to be collapsed into a single one, breaking alignment. A trivial issue, but the fix is just as trivial.
(In reply to comment #4) > 2. Without rd.lvm.lv, ther LV isn't found, hence /usr isn't mounted. It is expected behaviour for 018. Please try 019.
(In reply to comment #3) > (In reply to comment #2) > > [...] > > So due to the request for an file system check, the mount command isn't > > executed. As a non-zero value there doesn't apear particularly esoteric to > > me, dracut should be able to deal with such an fstab. The "if [ $_ret -ne > > 255 ]" part seems like there should be an "else" as well. > > I agree that's strange dracut doesn't fail on /usr mount failure. I'll fix > it. Fixed in 022. > > > > - "hostonly" … > > > > > > Right, man page should be updated on that. Thanks. > > > > I take it that you are an upstream developer yourself, so there is no need > > for an upstream bug report about this, right? > > I'm not sure about developer, but I contribute a bit to dracut. I'll take > care of it. Fixed in 022.(In reply to comment #5) (In reply to comment #4) > (In reply to comment #2) > > I will try to reproduce this problem the next time I boot this machine and > > have a bit of time for such experiments. Will report back whether I could > > identify the actual problem. > > OK, here are my findings so far. All of them with hostonly off. > 1. With rd.lvm.lv specified on the command line, everything works as it > should. > 2. Without rd.lvm.lv, ther LV isn't found, hence /usr isn't mounted. > 3. Executing the vgscan / vgchange commands manually activates it. Should be fixed in 019. Is that right? > One minor thing I noticed along the way: the info and warn functions of > dracut-lib.sh pass their arguments to echo using $@ instead of $*, and vwarn > passes the lines unquoted. All of these cause some uneccessary word > breaking, and the latter might even cause multiple spaces to be collapsed > into a single one, breaking alignment. A trivial issue, but the fix is just > as trivial. Fixed in 022. As far as I see everything is fixed for this looong bug. :-) Thank you for the report!
