[jaunty] bug when umounting the root partition

[billbear]

umounting the root partition should give errors, but 9.04 returns no error, although umounting is unsuccessful.
and other strange things happens after that.
I found the bug because this script is an endless loop in 9.04 when $part happens to be the root partition:

      while mount | grep "^$part " > /dev/null; do
      umount $part || { echo "Failed to umount $part"; exit 1; }
      done

Details:

billbear@billbear-laptop:~$ sudo -i
[sudo] password for billbear:
root@billbear-laptop:~#
root@billbear-laptop:~# mount
/dev/sda5 on / type ext4 (rw,relatime,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,nosuid,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
lrm on /lib/modules/2.6.28-11-generic/volatile type tmpfs (rw,mode=755)
/dev/sda1 on /boot type ext4 (rw,relatime)
/dev/sda6 on /home type ext4 (rw,relatime)
/dev/sda7 on /tmp type ext4 (rw,relatime)
/dev/sda8 on /usr type ext4 (rw,relatime)
/dev/sda9 on /var type ext4 (rw,relatime)
securityfs on /sys/kernel/security type securityfs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/billbear/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=billbear)
root@billbear-laptop:~#
root@billbear-laptop:~# mount /dev/sda5 /mnt # mounting the root partition elsewhere is possible
root@billbear-laptop:~# ls /mnt
bin boot cdrom dev etc home initrd.img lib lost+found media mnt opt proc root sbin selinux srv sys tmp usr var vmlinuz
root@billbear-laptop:~# mount | grep sda5 # successfully mounted
/dev/sda5 on / type ext4 (rw,relatime,errors=remount-ro)
/dev/sda5 on /mnt type ext4 (rw)
root@billbear-laptop:~#
root@billbear-laptop:~# umount /dev/sda5 # umount only the last mount ponit of root on /mnt
root@billbear-laptop:~# mount | grep sda5 # successfully umounted
/dev/sda5 on / type ext4 (rw,relatime,errors=remount-ro)
root@billbear-laptop:~#
root@billbear-laptop:~#
root@billbear-laptop:~# umount /dev/sda6 # refuse to umount /home.
umount: /home: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))

root@billbear-laptop:~# ##################################################### The above are expected behaviors, below comes the bug #################

root@billbear-laptop:~# umount /dev/sda5 # but umounting the root partition gives no error
root@billbear-laptop:~# echo $?
0
root@billbear-laptop:~# mount | grep sda5 # although it cannot really be umounted. (it is still there)
/dev/sda5 on / type ext4 (rw,relatime,errors=remount-ro)

root@billbear-laptop:~# ######## after the "successful umount" of root, things go strange:

root@billbear-laptop:~# mount /dev/sda5 /mnt # this time the root partition can no longer be mounted elsewhere
mount: /dev/sda5 already mounted or /mnt busy
mount: according to mtab, /dev/sda5 is mounted on /
root@billbear-laptop:~# mount /dev/sda6 /mnt # home partition can still be mounted elsewhere, it seems ok but
root@billbear-laptop:~# ls /mnt
billbear lost+found
root@billbear-laptop:~# mount | grep sda6 # the home partition mounted on /mnt does not appear in the mount list
/dev/sda6 on /home type ext4 (rw,relatime)
root@billbear-laptop:~# ls /mnt # although it is obviously there
billbear lost+found
root@billbear-laptop:~# umount /dev/sda6 # this command can no longer umount home partition on /mnt
umount: /home: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))
root@billbear-laptop:~# umount /mnt # this command can still umount home partition on /mnt
root@billbear-laptop:~# ls /mnt # successfully umounted
root@billbear-laptop:~# mkdir /mnt/1 # now the file system becomes read-only.
mkdir: cannot create directory `/mnt/1': Read-only file system
root@billbear-laptop:~# mkdir /1
mkdir: cannot create directory `/1': Read-only file system

[billbear (ninth-9)]

ok i reinvestigated this problem and found that this happens only when i have separate /home /usr /var /tmp partitions.

This is not a 9.04 problem, 8.04 also behaves like this.

Maybe this is not a bug, although i don't like this behavior.

I think when booting ubuntu, "kernel /boot/vmlinuz... root=..." mounts root partition read-only, and then fstab mount root partition again, and when i have separate /home /usr /var /tmp partitions it's possible to umount root partition that is mounted in fstab, then root partition becomes read-only again.

I really wish that ubuntu told me "root is busy"!

[Tamas Papp (tompos)]

I run into this bug yesterday. It was really annoying.

Accidently I typed 'umount /'. Then I reboototed the box and logon to it again by ssh. Unfortunately I didn't check, that is was still not rebooted, because apache was working (it's a server): I thought, it was just up again.

Later my client called me, that postfix was not working due to some operation not permitted and other strange failures.

I checked the logs, and ttys were killed, mysql were stopped (not really, because the web pages still were using it successfully), when I run 'reboot', but that's all.

It's absolutely a bug, please fix it. Even if it's possible, in 8.04 too.

Thank you.

[Fabio Marconi (fabiomarconi)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.
Is this bug reproducible with the latest Lucid packages ?
Thanks in advance.

[Fabio Marconi (fabiomarconi)]

 Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage .

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://help.ubuntu.com/community/ReportingBugs.

[Fabio Marconi (fabiomarconi)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!