Handling rootfs on a bind-mount

[Daniel Drake]

Hi,

OLPC runs / as a bind-mount, because the "real" partition
(/dev/mmcblk0p2) holding our root fs can actually hold different
versions of the software (usually with a huge amount of shared data
via hard links). We use this to implement a completely safe atomic
system upgrade path, where a symlink points to either the old or the
new version of the system.

To boot,  in the initramfs with the main partition mounted as /sysroot,  we do

mkdir /vsysroot
mount --bind /sysroot/versions/run/6 /vsysroot
umount /sysroot
NEWROOT=/vsysroot

dracut then does switch_root to /vsysroot.

We are facing an issue with udisks2 under Fedora 17, which under this
configuration exposes /dev/mmcblk0p2 as a removable disk that should
be automounted. So we end up with a strange mount visible in the UI
(Sugar/GNOME), which we'd like to get rid of.

I see that udev tags can be used to make udisks ignore this. I could
write a udev helper and some rules to apply such tags. But I'm
wondering if it is worth touching upon solving this in a more generic
way?

I think the first reason behind this behaviour is because of the
following in udisks_mount_monitor_get_mountinfo()

      /* ignore mounts where only a subtree of a filesystem is mounted */
      if (g_strcmp0 (encoded_root, "/") != 0)
        continue;

This matches our root mount - / is a subtree of a real mount (which is
no longer visible).


Wondering if I could find a way to influence the hints outside of a
udev rule, I ran into update_hints() in udiskslinuxblock.c which seems
to treat all mmcblk* devices as removable. This isn't really correct.
The OLPC XO-1.5 has a SD card (mmcblk0) which can only be accessed by
disassembling the laptop and removing the CPU heatsink - we regard it
as non-removable. And the OLPC XO-1.75 has eMMC storage as mmcblk0
which is soldered onto the motherboard like any other component -
that's definitely non-removable.


Could these behaviour points be adapted in the interest of finding a
real solution here, or is this regarded as a corner case which I
should use the well-documented udev override for?

Thanks,
Daniel