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.
