Re: /etc/fstab question (problem)?
On Fri 21 Apr 2023 at 15:46:30 (-0700), David Christensen wrote:
> On 4/21/23 08:12, Max Nikulin wrote:
> > On 20/04/2023 04:03, David Christensen wrote:
> > > * What if root attempts to remove everything under /etc, in
> > > anticipation of mounting a file system at /etc, when one or
> > > more programs have one or more open temporary files?
With one exception, I've not seen root (whichever process that
refers to) doing anything like that in anticipation of mounting
a filesystem, so I wondered where that realisation came from.
The exception (which I haven't actually observed) is run-init
tearing down the initramfs before the true root is mounted.
> > I used initramfs and initrd as synonyms because of file names
> > /boot/initrd* and update-initramfs command. Even though /tmp entry
> > should not be necessary during early init, I believe, it is safer
> > to run "update-initrams -u" just to avoid surprise due to changes
> > in fstab several days or weeks later when kernel update will
> > arrive. It would be much harder to associate boot failure with
> > fstab restored from backup instead of "broken" kernel package.
The OP obviously has a problem with /etc/fstab, in that they reported
modifications having been made by an unknown agent. An important hint
in determining what might have been responsible is to know the
modification timestamp of the altered file, and whether any other
files were modified within a short period bracketing that time.
The OP's backup methods might not be up to that task if they're
losing the metadata, but it's worth checking: the backups might
also be stored elsewhere, with dates in their names, etc.
AFAICT running update-initramfs has no effect as its /etc/fstab will
remain empty. The booting kernel uses the root filesystem's fstab,
located by the root= on the kernel command line. Upgrading the kernel
will run update-initramfs, but not for any effect on the contained
/etc/fstab.
In fact, it's difficult to see any advantage in adding entries to
the /etc/fstab in the initramfs. You would lose one of the important
properties of the kernel/initrd pair which is that you can run it
on a different machine with different root filesystems (selected
by root=…) without having to modify them. (Cast your mind back to days
of yore, when we had to run rdev to modify bytes at a certain kernel
offset to change the root filesystem it would boot.)
> I am unaware of any single document that would allow us to
> definitively answer the question "what does initrd.img depend upon?".
> If anyone knows of such, please provide a citation.
/usr/sbin/mkinitramfs and the configuration parameters that it reads
from /etc/initramfs/, I guess. (I assume you're not wanting to read
about how the kernel turns compressed cpio archives into a cached
filesystem.)
> I find it strange that we run a tool named "update-initramfs" to
> update a file named "initrd.img-*". Should not the tool be named
> "update-initrd"?
No, the initrd ought to be called initramfs. I think the changeover
from ram disk to ram filesystem was during 2.6 kernel versions.
I assume the name just stuck.
> I would like to imagine that running update-initramfs(8) is always
> safe, but I seem to be running into a lot of WTF's on Linux and/or
> Debian again.
It should always be safe, but be aware that initrds have got quite
large nowadays, particularly with MODULES=most, so people with /boot
on its own partition have to keep an eye on free space.
> As for the Linux initial ramdisk, and ignoring system configuration
> settings in memory:
>
> * The Linux initial ram[fs] is a cache used by the boot process. If
> system configuration settings in a file on primary storage are
> created/ updated/ deleted, if initrd.img depends upon those settings,
> and if the initrd.img is not updated, then the system configuration
> settings exist in two places and those settings are out-of-sync [1,2].
> When the system is rebooted, the resulting system configuration will
> be a mixture of settings from primary storage files and from
> initrd.img.
That's why you see update-initramfs being run any time the relevant
parts of the configuration change, avoiding that situation.
> * AIUI the BSD's do not have an initial ramdisk. If system
> configuration settings in a file on primary storage are created/
> updated/ deleted, then the system configuration settings exist in only
> one place. When the system is rebooted, the resulting system
> configuration will be unambiguous.
Yes, I remember building custom kernels years ago, where you had to
build in all the modules that might ever be necessary to find and
mount the root filesystem. And all that code ran in kernel space.
The benefit of an initramfs is that you don't need any filesystem
drivers built into the kernel (you would need one were you to use
a ram /disk/), and most of the code, which can be complex and
extensive, runs in user space. Think decryption, RAID, networked
file systems etc.
> As for systemd:
>
> * AIUI systemd is a system management database comprised of text and
> binary files.
Is that right? I know systemd uses binary files for its logging
(though it can and does write traditional text ones too). But can
you point out some binary configuration files that systemd uses.
> systemd may hook into initrd.img.
Hmm, I got the impression that systemd, /sbin/init, PID1, started just
as run-init finished tearing down all remnants of the initramfs, and
mounted the real root filesystem.
Looking for the string systemd in my own initrd.img, I have the binary:
-rwxr-xr-x 1 678392 Apr 27 2020 main/usr/lib/systemd/systemd-udevd
which looks like a slimmed down version of /bin/udevadm. It's
difficult to imagine initramfs not containing udev. IDK whether
non-systemd users have their own, special version of udev to avoid
having a systemd hook into initrd.img.
Then I see main/usr/lib/modprobe.d/systemd.conf containing two lines:
options bonding max_bonds=0
options dummy numdummies=0
which is something to do with preventing bonding if/when some kernel
module is loaded during the initramfs phase.
Lastly, I see main/usr/lib/systemd/network/99-default.link containing:
[Link]
NamePolicy=keep kernel database onboard slot path
MACAddressPolicy=persistent
which is the backstop for udev's handling of network interfaces.
> I assume systemd has
> a non-trivial schema with referential integrity requirements. The
> text files must have a syntax and the binary files must have a file
> structure. There must be an API to perform operations on all or part
> of the database.
Sorry, which operations on what database?
> My interactions with systemd have been limited to
> running systemd CLI programs. If and when the systemd database and/or
> initrd.img components are damaged and/or out-of-sync such that boot
> fails, I have no idea how to fix that.
Sorry, you've lost me; I thought it was the kernel that booted a linux
system, not systemd.
> * AIUI FreeBSD is configured via text files. I can edit them, check
> them into a version control system, run them through shell pipelines,
> etc.. If and when the system configuration is damaged such that boot
> fails, I know how to boot live media, mount filesystems, and work on
> those files.
Funny—that's rather like what we sysadmins do on linux, apart from
being rather vague when compared with the specific details we are
dissecting here.
> [1] https://en.wikipedia.org/wiki/Don't_repeat_yourself
When an ocean liner leaves port, it doesn't use its main engines:
tugs tow it out of the harbour using their engines. The ship's master
wouldn't be able to navigate the liner into the main channel, but a
pilot handles that with ease, before disappearing over the side into
a pilot boat. Once at sea, the liner needs neither tugs nor pilot.
Cheers,
David.
Reply to: