| Summary: | linuxrc in genkernel's initramfs does not properly deal with bind mounts | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Andreas Plesch <andreasplesch> |
| Component: | genkernel | Assignee: | Gentoo Genkernel Maintainers <genkernel> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | bkohler, ryao |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Andreas Plesch
2012-06-01 00:42:46 UTC
Dracut has a similar problem with bind mounts: http://forums.gentoo.org/viewtopic-t-918146-start-0-postdays-0-postorder- asc-highlight-.html According to the post, it can be worked around because dracut uses a "full" fstab style file for the early mounts (/etc/fstab.sys). One can add the /newroot (or /sysroot in dracut) there manually. Perhaps this approach could be adopted for genkernel as well ? I have pushed a fix [1] to branch "bug-418463". Please review and test the change. For testing, this sequence of commands may be helpful: $ git clone git://git.overlays.gentoo.org/proj/genkernel.git $ cd genkernel $ git checkout -t origin/bug-418463 $ sudo GK_SHARE="$PWD" ./genkernel initramfs [1] http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=commitdiff;h=aed52e83827cff73e8f7ba5773ea8e0cd7c3c25b Thanks for the quick response. I tested the proposed patch and it works as expected on my system, eg. the bind mount are mounted now early and udev can use them. I did notice that the mount table as produced with the mount command now lists the mount points with the bind mounts twice: # mount ... /dev/sda1 on /disk/fels/d3 type ext4 (rw,noatime,commit=0) /dev/sda1 on /usr/x86_64-pc-linux-gnu type ext4 (ro,noatime,user_xattr,barrier=1) /dev/sda1 on /usr/lib64 type ext4 (ro,noatime,user_xattr,barrier=1) /dev/sda1 on /usr/lib32 type ext4 (ro,noatime,user_xattr,barrier=1) /dev/sda1 on /usr/libexec type ext4 (ro,noatime,user_xattr,barrier=1) /dev/sda1 on /usr/include type ext4 (ro,noatime,user_xattr,barrier=1) ... /disk/fels/d3/usr/x86_64-pc-linux-gnu on /usr/x86_64-pc-linux-gnu type none (rw,bind,commit=0) /disk/fels/d3/usr/lib64 on /usr/lib64 type none (rw,bind,commit=0) /disk/fels/d3/usr/lib32 on /usr/lib32 type none (rw,bind,commit=0) /disk/fels/d3/usr/libexec on /usr/libexec type none (rw,bind,commit=0) /disk/fels/d3/usr/include on /usr/include type none (rw,bind,commit=0) But this does not seem to have a negative effect sofar. It just produces df output which lists the ssd as mounted multiple times. As this doubled listing is not occuring without the initrd, it probably is related to the remounting at the end of the initrd, and may or may not be genkernel related. Perhaps it is normal. (In reply to comment #3) > Thanks for the quick response. > > I tested the proposed patch and it works as expected on my system, eg. the > bind mount are mounted now early and udev can use them. Nice, thank you. > I did notice that the mount table as produced with the mount command now > lists the mount points with the bind mounts twice: Interesting. I assume that's another bug. I'll need your help to track it down. If you have will and time for that, please open a new dedicated bug for that. +*genkernel-3.4.34 (04 Jun 2012) + + 04 Jun 2012; Sebastian Pipping <sping@gentoo.org> +genkernel-3.4.34.ebuild: + Bump to 3.4.34 + Ok, I filed a new bug: https://bugs.gentoo.org/show_bug.cgi?id=419773 Hm, after rebooting several times with the new initrd, now the bind mounts stay read-only consistently when the main system starts up: # mount ... /dev/sda1 on /usr/lib64 type ext4 (ro,noatime,user_xattr,barrier=1) /dev/sda1 on /usr/lib32 type ext4 (ro,noatime,user_xattr,barrier=1) /dev/sda1 on /usr/libexec type ext4 (ro,noatime,user_xattr,barrier=1) /dev/sda1 on /usr/include type ext4 (ro,noatime,user_xattr,barrier=1) ... /disk/fels/d3/usr/x86_64-pc-linux-gnu on /usr/x86_64-pc-linux-gnu type none (ro,bind) /disk/fels/d3/usr/lib64 on /usr/lib64 type none (ro,bind) /disk/fels/d3/usr/lib32 on /usr/lib32 type none (ro,bind) /disk/fels/d3/usr/libexec on /usr/libexec type none (ro,bind) /disk/fels/d3/usr/include on /usr/include type none (ro,bind) This was not the case initially (see above) but I do not know what could have changed. Unfortunately, this way the system does not work very well, eg. cannot be updated. So perhaps the status of this bug needs to be updated ? (In reply to comment #7) > This was not the case initially (see above) but I do not know what could > have changed. Please check your disk and file system for errors. It was the disk last time an ext4 went read-only on me, just saying. > Unfortunately, this way the system does not work very well, > eg. cannot be updated. > So perhaps the status of this bug needs to be updated ? Re-opening. Especially that "(ro,bind)" is puzzling me. Any help is welcome. I finally checked the ext4 filesystem in question for errors. fsck reported some dtime=0 (or similar) errors but after they were fixed the bind mounts are still read-only. I can easily remount them read-write without problems, so I do not think it is the filesystem. In fact that is what I put into "local" init section, eg. in /etc/local.d/remount_earlymounts.start (on gentoo), and it works well. I went into the debug shell of the initrd to see what happens if I manually recreate the mounting there. After creating the mount points I did $ mount /dev/sda1 /mnt/disk1 $ mount -t none -o bind /mnt/disk1/usr/lib64 /mnt/lib64 The bind mount is read-write at this point. So something must happen after that in the initrd, or early when the main system comes up. fsck reports the ext4 file system on /dev/sda1 as clean. (In reply to comment #8) > (In reply to comment #7) > > This was not the case initially (see above) but I do not know what could > > have changed. > > Please check your disk and file system for errors. It was the disk last > time an ext4 went read-only on me, just saying. > > > > Unfortunately, this way the system does not work very well, > > eg. cannot be updated. > > So perhaps the status of this bug needs to be updated ? > > Re-opening. > > Especially that "(ro,bind)" is puzzling me. Any help is welcome. The first mount is mounted ro. The bind mount likely duplicates that property. Modifying the system fstab to specify rw on the bind mount should solve that. Andreas, would you confirm that doing that works? If it does, this could be considered a documentation issue. |
