umount hangs with initramfs as root

[Rob Landley]

On Wednesday 22 March 2006 12:30 am, Chuck Meade wrote:
> Hi Rob,
>
> Thanks for the info.
>
> > > Busybox umount hangs when I try to reboot, while running on a root
> > > fs which is an initramfs.  Reboot is configured on my system to
> > > "umount -a -r", and the umount of the initramfs root is hanging.
> >
> > You're using a kernel before 2.6.13, aren't you?
>
> Yes I am working on a few platforms at once, and this particular one is
> still at 2.6.11.6.  The Busybox version running on it is 1.0.0.
> I know they are not very recent, but I was trying to figure out
> if the problem with umounting an initramfs is known/fixed, or known
> to not work regardless of the version, etc.

It's known/fixed in the kernel.  I didn't spend extra bytes to work around it 
in busybox.

> > I forgot: the patch to prevent initramfs from being umounted went in
> > around then.  Before that you could hang your system hard by umounting
> > initramfs. (The kernel would go into an endless loop since the mount list
> > is a circular doubly linked list with initramfs as the start/end point it
> > searches for.)
> >
> > Hmmm...  Didn't test umount -a with an older kernel.
>
> This is what I mean -- am I correct in interpreting what you wrote above,
> that an initramfs simply cannot be umounted?

To clarify: initramfs is rootfs.  You can't unmount rootfs for approximately 
the same reason you can't kill init (PID 1).  It simplifies the kernel's 
internal logic to never have to deal with an empty list, so they make sure 
there's one entry that's always there.

If that entry ever _does_ go away (as bugs in older 2.6 kernels allowed to 
happen), bad things go in inside the kernel.  (If you kill init the kernel 
panics relatively cleanly.  If you umount rootfs it hangs looping inside the 
umount function, looking for the rootfs you just unmounted which is how it 
knows it's hit the end of the circular list...)

> I have used initrd's in the past, and am testing out using initramfs, as
> my embedded rootfs  (not just a transitional rootfs).  It works great until
> I try to reboot, and the umount hangs.  Especially for a small embedded
> target with limited resources, having the initramfs as the "real" rootfs
> has advantages.  This umount problem is not one of them though :)

It has some very nice advantages.  A quick and dirty workaround is to check 
for fstype "rootfs" in umount.c and never umount one of those.

> I don't know if this inability to umount the initramfs is a "feature" or
> a bug.

Inability to umount is is a feature.  The hang when attempting to umount it is 
a bug.  (The attempt should be ignored by the kernel, and is in current 
kernels.  Just like an attempt to send a kill signal to init.)

> Since you say that a patch went in to prevent it, maybe it is 
> desired behavior.  But it does not make it easy to umount for rebooting.
>
> I see that you wrote the Linux Documentation/ file on initramfs.  So
> based on your knowledge of this topic, what do you think is the appropriate
> next step here?  I am thinking that possibilities include:
> 1. changing my busybox reboot sequence to not "umount -a -r", just umount
>    the mounts *under* /
> 2. possibly changing the reboot sequence to switch_root to some other
>    directory first, then umounting initramfs and rebooting
> 3. any other better ideas?

Well, the kernel was patched to include the following code in fs/namespace.c, 
function do_umount(), from 2.6.16:

                if (mnt == current->fs->rootmnt ||
                    flags & (MNT_FORCE | MNT_DETACH))
                        return -EINVAL;

You could try tweaking your kernel source to not have the bug.

Or, if you can rebuild 1.0, you could patch that to never attempt to umount a 
filesystem of type "rootfs".

> My versions are not recent so they do reflect any of your recent mount
> work.

The old stuff is triggering a kernel bug.

> Thanks very much for your thoughts on this,
> Chuck

Rob
-- 
Never bet against the cheap plastic solution.