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
_______________________________________________
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel
