[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#652459: mounting /usr from initramfs



On Tue, 05 Aug 2014 at 09:42:16 +0100, Simon McVittie wrote:
> I was curious how systemd solved this. It's very simple: its equivalent
> of checkfs.sh (systemd-fsck@.service) runs something like
> "/lib/systemd/systemd-fsck /usr", which runs "fsck -M /usr", which
> exits 0 with no effect if /usr is already mounted. Job done.

Meanwhile, its equivalent of checkroot.sh (systemd-fsck-root.service)
assumes that / needs to have fsck run on it if and only if it is
mounted read-only.

That doesn't seem complete. It seems worthwhile to enumerate the situations
we could be in:

M/I: monolithic kernel vs. initramfs
R/U: /usr is on root vs. /usr is its own partition
F/-: initramfs fscks / and /usr (only if I) vs. it does not
W/-: initramfs mounts / and /usr rw (only if I & F) vs. it does not

That's 2**4 = 16 situations, of which M?F? (2**2 = 4) and ??-W (2**2 = 4)
are impossible: the initramfs can't do anything if there isn't one, and
an initramfs that mounts / and /usr rw must fsck them first. That leaves us
with 8:

MR--: monolithic kernel, /usr is part of /, / is mounted ro by the kernel
  + init must fsck / and remount it, most likely rw

IR--: initramfs, /usr is part of /, / is mounted ro by the initramfs
  (this is the situation that works well in initramfs-tools 0.115)
  + init must fsck / and remount it, most likely rw

IRFW: initramfs, /usr is part of /, / is fsck'd and mounted rw by the initramfs
  + init should not change how / is mounted
    - currently, checkroot.sh would redundantly mount ro, fsck, remount rw
      (systemd's current logic, not fscking a rw root, would solve this)

IUFW: initramfs, /usr is separate, / and /usr are fsck'd and mounted rw by
      initramfs
  + init should not change how / or /usr is mounted
    - currently, checkroot.sh would redundantly mount ro, fsck, remount rw
      (systemd's current logic, not fscking a rw root, would solve this)
    - currently, checkfs.sh would try to fsck a mounted /usr
      (fsck -M would solve this)

systemd's logic does not cover a deliberately read-only root:

IRF-: initramfs, /usr is part of /, / is fsck'd and mounted ro by initramfs
  + init should not change how / is mounted
    - currently, checkroot.sh would redundantly fsck /
    - currently, systemd-fsck would redundantly fsck /

IUF-: initramfs, /usr is separate, / and /usr are fsck'd and mounted ro by
      initramfs
  + init should not change how / or /usr is mounted
    - currently, checkroot.sh would redundantly fsck /
    - currently, checkroot.sh would try to fsck a mounted /usr
      (fsck -M would solve this)
    - currently, systemd-fsck would redundantly fsck / (but not /usr)

Do we aim to support those? I don't think they can be distinguished from IR--
except by communicating "root has been fsck'd" from initramfs to init
via a flag-file in /run or something.

There are two more situations that, AIUI, we explicitly will not/do not
want to support, which is the point of this bug:

MU--: monolithic kernel, /usr is separate, / is mounted ro by the kernel
    (we currently try to support this but it is not reliable)

IU--: initramfs, /usr is separate, only / is mounted by the initramfs
    (we currently try to support this but it is not reliable)

That's all 8 possible situations, so I think I've covered everything?

    S


Reply to: