3

I use Linux overlay fs as root filesystem to keep the real root partition read-only and write changes to another fs (e.g., tmpfs or another partition).

However, when the root filesystem is finally in place (after 'pivot root'), the original mounts (let's say at /dev/sda at /mnt/root-write-protected) is hidden in the initial root (eg. init ramdisk), but still actively mounted. However, it is not visible from inside the root filesystem anymore, nor can the original device be mounted again in a writeable fashion, as mount says:

mount: /dev/sda is already mounted

despite no entry is listed by mount or cat /etc/mtab.

How can I access (e.g., read from, remount) this hidden mount?

5
  • Off topic, How are you doing this "I use Linux overlay fs as root filesystem to keep the real root partition read-only and write changes to another fs (e.g., tmpfs ..." ?
    – Anwar
    Jul 6, 2019 at 17:46
  • For Debian like Distros (like Ubuntu) there is a package overlayroot, that installs all scripts needed. Also there are older scripts lurking in the internet, that can be installed to the initrd to write-protect the root partition. If you try to do it manually, it's quite involved as you have to do it in early boot (when the kernel mounts the root partition) and therefore you need to do scripting in the initrd.
    – dronus
    Jul 10, 2019 at 13:11
  • I installed the package but couldn't find helpful scripts. All scripts was for accessing files under an overlay mounted fs
    – Anwar
    Jul 12, 2019 at 6:45
  • After installing the package, you have to set up some configurations eg. edit /etc/overlayroot.conf. There is some documentation inside.
    – dronus
    Jul 13, 2019 at 9:52
  • This is even more confusing with dm devices, by the way. They appear not used (as reported by dmsetup info--open count 0 reported) when they are in fact used as a layer in a overlay fs! Ventoy+Ubuntu persistent (via casper) creates something like that. (I think the issue is that dmsetup info is only able to see/report simple mounts, but not uses in an overlay.) Jan 21 at 0:15

2 Answers 2

1

Before the pivot-root happens, mount --bind the filesystem into a place that you'll be able to reach.

For example:

  1. Mount sda2 on /mnt/root-write-protected.
  2. Mount overlayfs on /mnt/new-root.
  3. Added step: Bind /mnt/root-write-protected on /mnt/new-root/raw-disk.
  4. Pivot into /mnt/new-root.
  5. Now you have sda2 accessible at /raw-disk.
2
  • 1
    So this means once the mount is buried by pivot_root is it can't be recovered in anyway while still blocking a remount of the underlying device? So I need to interfere with early startup before pivot_root ?
    – dronus
    Sep 26, 2018 at 23:03
  • I now found a solution that works without changing the delicate initrd setup before pivot_root.
    – dronus
    Aug 6, 2020 at 20:38
0

As the original mount is "buried" by pivot_root or change_root, it cannot be remounted as a writable device. However, it is possible to use the volume as a source file for a loop device. This can be mounted as usual and used for write access. The system should be rebooted after changes to this device, as the overlay is inconsistent with the actual disk data.

Like:

sudo mkdir /mnt/hidden_root
sudo losetup -f /dev/sda2 # change to your overlayed root volume 
sudo mount /dev/loop0 /mnt/hidden_root  # change loop0 if already used before
# ...  do changes to /mnt/hidden_root here ...
sudo reboot 

After reboot, changes are applied to live root.

Also make sure never loop-mount a device that is already read/write mounted. The two filesystems (at least in case of ext3/4) will almost immediately start to battle over their shared metadata on disk against each other, destroying the FS.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .