While using initramfs root with new baselayout, shutdown of the system can't be performed cleanly. When stopping localmount root partition is remounted ro together with /lib/rcscripts/init.d directory, which is not mounted separately in case of root initramfs. This avoid shutdown process to continue normally with complains about inability to write to /lib/rcscripts/init.d. Temporary workaround I'm using at the moment: add "mount -o remount,rw /" (which is safe in case of root initramfs) at the end of localmount script (before the last "return 0"). Reproducible: Always Steps to Reproduce: 1.Create initramfs 2.Boot with initramfs as root 3.Shoutdown
Could you post your mount output when system is fully running please?
As you requested: /dev/rd/0 on / type tmpfs (rw,size=128m) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec) udev on /dev type tmpfs (rw,nosuid) devpts on /dev/pts type devpts (rw,nosuid,noexec) /dev/md/1 on /boot type ext2 (ro,noatime) /dev/mapper/vg-usr on /usr type ext3 (rw,noatime) /dev/mapper/vg-var on /var type ext3 (rw,noatime) /dev/mapper/vg-tmp on /tmp type ext2 (rw,noatime) /dev/mapper/vg-src on /usr/src type ext3 (rw,noatime) /dev/mapper/vg-opt on /opt type ext3 (rw,noatime) /dev/mapper/vg-games on /usr/share/games type ext3 (rw,noatime) /dev/mapper/vg-media on /mnt/media type xfs (rw,nodev,noatime,logbufs=8,ihashsize=0) /dev/mapper/vg-home on /home type ext3 (rw,noatime) /dev/mapper/vg-portage on /mnt/portage type reiserfs (rw,noatime,data=writeback) /dev/mapper/vg-data on /mnt/data type reiserfs (rw,noatime,data=writeback) shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev) usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,devmode=0664,devgid=85) nfsd on /proc/fs/nfsd type nfsd (rw,noexec,nosuid,nodev) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) bsd:/mnt/games on /mnt/bsd/games type nfs (rw,hard,intr,nfsvers=3,addr=192.168.1.1) bsd:/mnt/software on /mnt/bsd/software type nfs (rw,hard,intr,nfsvers=3,addr=192.168.1.1) bsd:/mnt/music on /mnt/bsd/music type nfs (rw,hard,intr,nfsvers=3,addr=192.168.1.1) bsd:/mnt/misc on /mnt/bsd/misc type nfs (rw,hard,intr,nfsvers=3,addr=192.168.1.1) bsd:/mnt/torrents on /mnt/bsd/torrents type nfs (rw,hard,intr,nfsvers=3,addr=192.168.1.1) bsd:/mnt/dreambox on /mnt/bsd/dreambox type nfs (rw,hard,intr,nfsvers=3,addr=192.168.1.1) bsd:/mnt/pictures on /mnt/bsd/pictures type nfs (rw,hard,intr,nfsvers=3,addr=192.168.1.1) bsd:/mnt/movies on /mnt/bsd/movies type nfs (rw,hard,intr,nfsvers=3,addr=192.168.1.1) bsd:/mnt/movies.tst on /mnt/bsd/movies.tst type nfs (rw,hard,intr,nfsvers=3,addr=192.168.1.1) bsd:/mnt/diskless on /mnt/bsd/diskless type nfs (rw,hard,intr,nfsvers=3,addr=192.168.1.1) bsd:/mnt/backup on /mnt/bsd/backup type nfs (rw,hard,intr,nfsvers=3,addr=192.168.1.1) bsd:/mnt/portage/distfiles on /mnt/portage/distfiles type nfs (rw,hard,intr,nfsvers=3,addr=192.168.1.1) bsd:/mnt/portage/tree/local/layman on /mnt/portage/overlays/layman type nfs (rw,hard,intr,nfsvers=3,addr=192.168.1.1) none on /sys/fs/fuse/connections type fusectl (rw)
a similar thing came up on the embedded list ... we should not fsck or remount ro filesystems that are ram based (so tmpfs and ramfs) ... this would make running out of initramfs trivial ...
If root isn't ram based, then init.d mounted as a separate tmpfs. Should it be mounted separately anyway? It could solve the problem as well, IMO.
Could you attach the output of /lib/rcscripts/bin/mountinfo also please? localmount avoids touching /, so it should not matter the device or fstype in use. It's halt.sh that should handle / - and /lib/rcscripts/init.d for that matter too. If you could capture and log the actual text shown on the screen where this happens I'd like it too.
Output of mountinfo: /var /usr/src /usr/share/games /usr /tmp /sys/fs/fuse/connections /sys /proc/sys/fs/binfmt_misc /proc/fs/nfsd /proc/bus/usb /proc /opt /mnt/portage/overlays/layman /mnt/portage/distfiles /mnt/portage /mnt/media /mnt/data /mnt/bsd/torrents /mnt/bsd/software /mnt/bsd/pictures /mnt/bsd/music /mnt/bsd/movies.tst /mnt/bsd/movies /mnt/bsd/misc /mnt/bsd/games /mnt/bsd/dreambox /mnt/bsd/diskless /mnt/bsd/backup /home /dev/shm /dev/pts /dev /boot / "localmount avoids touching /, so it should not matter the device or fstype in use. It's halt.sh that should handle / - and /lib/rcscripts/init.d for that matter too." - then how come that / is ro after localmount stopped? As for the actual error reported, unfortunately I can say exactly what was it, but that is something about inability to delete symlink in /lib/rcscripts/init.d/stopping, obviously because it's ro together with root.
Created attachment 132526 [details, diff] Don't unmount anything in /sys/* either This may fix it as it appears you have special stuff mounted in /sys also
Thank you for the patch I'll try later today, but honestly it will not solve the problem. Sorry for repeating again, but in my opinion the problem occurs, because ${RC_SVCDIR} is not mounted separately from root during boot process in case of initramfs root. ${RC_SVCDIR} explicitly included as "no_umounts", but in out case ${RC_SVCDIR} is not mounted.
(In reply to comment #8) > Thank you for the patch I'll try later today, but honestly it will not solve > the problem. Sorry for repeating again, but in my opinion the problem occurs, > because ${RC_SVCDIR} is not mounted separately from root during boot process in > case of initramfs root. ${RC_SVCDIR} explicitly included as "no_umounts", but > in out case ${RC_SVCDIR} is not mounted. That should not affect the handling of / in any way. Notice that / is in the "no_umounts" list as well. Also, it is not a requirement that ${RC_SVCDIR} is a mounted, just that it is writeable. So we really need to find out what is going on deeper in rc-mount.sh and why this only affects initramfs users. When localmount stops, it shows what mount points it will try to unmount. Is either / or ${RC_SVCDIR} (/lib/rcscripts/init.d) listed?
Unfortunately I'm not behind my computer, so I can't tell what exactly it's trying to umount, but that was the first thing I took a look when the problem appears and I'm almost sure root (/) isn't there. One thing is clear: local mount makes / ro when stops. One more thing, could this make / ro (below is a quote from localmount)? # Try to unmount all tmpfs filesystems not in use, else a deadlock may # occure, bug #13599. # As $RC_SVCDIR may also be tmpfs we cd to it to lock it cd "${RC_SVCDIR}" umount -a -t tmpfs 2>/dev/null Sorry, forget to tell, but probably you mentioned already out of posted output of mount command: my root actually tmpfs, but not in pure initramfs. I'm using vanilla kernel with two patches: 1) Unpack the early userspace onto tmpfs 2) USB HID Mouse Interrupt Polling Interval I'll take a look at rc-mount.sh as well.
I don't suppose baselayout-2.0.0_rc5 has fixed this?
Unfortunately, the situation is the same: "Unable to remove ... ro filesystem".
Could you describe the steps needed to get an initramfs root so I can try to replicate this please? You could try commenting this line out, but I don't think that will fix. umount -a -t tmpfs 2>/dev/null
(In reply to comment #13) > Could you describe the steps needed to get an initramfs root so I can try to > replicate this please? I don't think it's tmpfs specific and I think it hapends with unpatched kernel as well. Anyway, I attached the patch used for unpacking early userspace into tmpfs instead of standard initramfs. In order to create initramfs image I used just standard Gentoo root without /usr /opt /usr/src /tmp and /var. You have to create one additional file - /init for initramfs. Probably just making symlink /init -> /sbin/init will be fine (untested), but Im using simple script below (all strings except the first and the last one could be omitted: #!/bin/sh /bin/mount -o remount,size=128m / > /dev/null /sbin/mdadm --auto-detect > /dev/null #Now transfer the init to the original init application (got this from the livecd-ng) exec /sbin/init </dev/console >/dev/console 2>&1 The last step is cteating compressed initramfs image: cd /path/to/new/root && find . | cpio -o -H newc | gzip -9 > /path/to/initramfs.cgz The corresponding lilo section is below: image = /boot/bzImage-2.6.23.1.x86_64 root = /dev/ram0 label = 23.1-r-64 append = "vdso=0 quiet" initrd = /boot/initramfs-2.6.23.1.x86_64.cgz vga = 0x31A > > You could try commenting this line out, but I don't think that will fix. > umount -a -t tmpfs 2>/dev/null > As I can remember that was the first thing I tried at the beginning ;-) ... it doesn't help.
Created attachment 134173 [details, diff] unpacking early userspace onto tmpfs
just enable the initial ram filesystem option under general setup and then set the path for initramfs srouce files that path will be packed up automatically as the initramfs root ... make sure you have a script at /init and that will be executed automatically
(In reply to comment #16) > just enable the initial ram filesystem option under general setup and then set > the path for initramfs srouce files > > that path will be packed up automatically as the initramfs root ... make sure > you have a script at /init and that will be executed automatically > Nevertheless, we're talking about initramfs on tmpfs, but not on standard ramfs.
for all intents and purposes, ramfs and tmpfs are exactly the same besides, i dont think you can do initramfs on tmpfs
(In reply to comment #18) > for all intents and purposes, ramfs and tmpfs are exactly the same ...not really, e.g. you can restrict size of tmpfs, but not ramfs... > > besides, i dont think you can do initramfs on tmpfs > on vanlla kernel you can't, that's why I attached the kernel patch.
which is why i said "for all intents and purposes" mount options on size restriction and such are irrelevant for our discussion here with baselayout
(In reply to comment #20) > which is why i said "for all intents and purposes" > > mount options on size restriction and such are irrelevant for our discussion > here with baselayout > I agree... didn't read your message careful.
Created attachment 134628 [details, diff] Ensure mtab is updated correctly when no root entry Using a simple init that just echos text to the console, remounts / and then execs /sbin/init I cannot replicate this. At the end of localmount / and /lib/rc/init.d/ are still mounted rw. This patch is the only thing I've made so that we correctly update /etc/mtab when there is no root entry in /. Aside from that I have no errors during boot or shutdown. I'll try your kernel patches now and see if that makes any difference.
Created attachment 134634 [details, diff] Ensure that mtab matches /proc/mounts, but punt a tmpfs root OK, the issue is having / as tmpfs. The bug is either with `mount -at tmpfs` or the patch. Either way, we can work around it by excluding / from mtab when the fstype is tmpfs. This patch allows a clean boot/shutdown on a normal kernel, initramfs / kernel and initramfs+tmpfs / kernel.
I'll try the patch later today.
(In reply to comment #23) > Created an attachment (id=134634) [edit] > Ensure that mtab matches /proc/mounts, but punt a tmpfs root > > OK, the issue is having / as tmpfs. > The bug is either with `mount -at tmpfs` or the patch. Either way, we can work > around it by excluding / from mtab when the fstype is tmpfs. > > This patch allows a clean boot/shutdown on a normal kernel, initramfs / kernel > and initramfs+tmpfs / kernel. > Indeed, the issue is only with / as tmpfs, otherwise it's not affected by issuing `umount -at tmpfs`. Your path looks like a "smart patch" and it solves the problem simply because after "grep -v "^[^ ]* / tmpfs" /proc/mounts > /etc/mtab" we have "rootfs / rootfs ..." instead of "/dev/ram0 / tmpfs...".
This is correct as the kernel never things / is "in use" when it's tmpfs with your patch, hence the actual issue. The bug is really with the tmpfs patch. Anyway, it's in our svn repo and will be in rc6, so fixed.
