I used to bind mount my /usr from another volume, as my root volume is almost full. However, with KUbuntu 22.04.1 LTS, I.e., systemd ver 249.11, I found it impossible now.

Here is how I did it before in /etc/fstab:

LABEL=bigvol    /bigvol         auto defaults,noatime,nodiratime,barrier=1,ro  0 2
/bigvol/d-sys/2023-02/usr  /usr auto bind,ro       0 0

I.e., with 0 2, the /bigvol volume is mounted on boot up, and with 0 0, the /usr volume is not mounted until later.

It's been working like that for over 10 years, but with systemd ver 249.11+ under linux-image-5.15.0-60, it starts to bind mount the /usr volume before any other volumes has been mounted, even when the root volume is temporarily mounted as /root instead of as /.


So I tried the suggested

/bigvol/d-sys/2023-02/usr /usr auto bind,ro,x-systemd.requires-mounts-for=/bigvol 0 0

And it is not working, stopped at the same place when the root volume is temporarily mounted as /root instead of as /.

But Freddy's answer looks so convincing that I tried something else -- using the exact same syntact to bind mount something else (comment out this /usr bind mount but added another bind mount directory /var/cache/apt/archives). And, it, works!

So it seems that

  1. systemd knows that the /usr volume is very special and should be mounted before anything else.
  2. but it fails to see that my /usr volume is only a bind mount should be mounted after anything else.
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.1 LTS
Release:        22.04
Codename:       jammy

$ apt-cache policy linux-image-5.15.0-60-generic
  Installed: 5.15.0-60.66
  Candidate: 5.15.0-60.66
  Version table:
 *** 5.15.0-60.66 500
        500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages
        500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        100 /var/lib/dpkg/status

$ apt-cache policy systemd
  Installed: 249.11-0ubuntu3.6
  Candidate: 249.11-0ubuntu3.6
  Version table:
 *** 249.11-0ubuntu3.6 500
        500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     249.11-0ubuntu3 500
        500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages

  • 1
    I have the very same issue with gentoo and OpenRC. Bind mount works for /home, /var ... , but not for /usr. During boot I see the mount of the root. Then the failure of the bind mount e.g.: Failed: 'mount -t bind -o bind /newroot/media/foobar/usr /newroot/usr So it tries to do the bind mount before the partition mount. But the partition mount is clearly there in /etc/fstab before the bind.
    – aminator
    Apr 19, 2023 at 11:13

2 Answers 2


You can add x-systemd.requires-mounts-for=/bigvol to the mount options of your bind mount to mount it after /bigvol.

From systemd.mount — Mount unit configuration:


Configures a RequiresMountsFor= dependency between the created mount unit and other mount units. The argument must be an absolute path. This option may be specified more than once. See RequiresMountsFor= in systemd.unit(5) for details.

From systemd.unit — Unit configuration:


Takes a space-separated list of absolute paths. Automatically adds dependencies of type Requires= and After= for all mount units required to access the specified path.

Mount points marked with noauto are not mounted automatically through local-fs.target, but are still honored for the purposes of this option, i.e. they will be pulled in by this unit.

LABEL=bigvol               /bigvol  auto defaults,noatime,nodiratime,barrier=1,ro       0 2
/bigvol/d-sys/2023-02/usr  /usr     auto bind,ro,x-systemd.requires-mounts-for=/bigvol  0 0
  • 1
    It is not quite working, please see my updated OP. thx!
    – xpt
    Feb 17, 2023 at 21:25

This is from / on an Ubuntu 20.04 system:

:/$ ls -la | grep -- '->'
lrwxrwxrwx   1 root root    7 Sep 28  2020 bin -> usr/bin
lrwxrwxrwx   1 root root    7 Sep 28  2020 lib -> usr/lib
lrwxrwxrwx   1 root root    9 Sep 28  2020 lib32 -> usr/lib32
lrwxrwxrwx   1 root root    9 Sep 28  2020 lib64 -> usr/lib64
lrwxrwxrwx   1 root root   10 Sep 28  2020 libx32 -> usr/libx32
lrwxrwxrwx   1 root root    8 Sep 28  2020 sbin -> usr/sbin

Assuming Ubuntu 22.04 is similar, trying to remove /usr from the root partition means no /bin, no /lib, no /lib32, no /lib64, no /libx32, and no /sbin are available when the kernel first boots.

Given that pid 1 is /sbin/init, that means there's no init process on the root partition to get everything started.

It's no surprise it doesn't work.

It seems the days of assuming you don't need one large root partition are over.

  • Note that "It's been working like that for over 10 years". I was not "trying to remove /usr from the root partition", but bind mount a bigger version over it, which were identical at the very beginning, And note also that if I do not do the bind mount, it boots up just fine.
    – xpt
    Feb 18, 2023 at 4:13
  • @xpt That's amazing, given that Ubuntu 22.04 was released in April 2022. Feb 18, 2023 at 4:50
  • 22.04.1 could be much later, I didn't look though, but definitely not April 2022. Oh, if you were saying about "It's been working like that for over 10 years", then it's actually much longer than that -- I've been using Linux for over 20 years.
    – xpt
    Feb 18, 2023 at 14:23

You must log in to answer this question.

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