Re: /etc/fstab question (problem)?
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?
David, you were wrote /etc instead of /tmp in several messages,
I apologize for the errors. :-(
I will strive to do more proofreading before posting.
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.
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.
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"?
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.
I am glad to read that the issue is solved, I see no problem with using
of live image (it is wise to always have it available).
I think, in this case live image (unlike reboot) was not strictly
necessary and may reduce down time if it is critical. I think, the
following is safe enough (not verified, may contain typos or even errors):
- backup /etc/fstab and current initrd
- have a look into grub.cfg and grub manual to be able to boot using
backup file
- restore /etc/fstab from backup
- Do not run "systemctl daemon-reload", since till shutdown systemd
should work accordingly to content of old fstab version
- update-initramfs -u
- reboot. It is required after adding /tmp to fstab to make new fstab
active and after update-initramfs to verify that new fstab does cause
boot issue. Single reboot should be enough, however another one before
update-initramfs is possible.
- mount --bind / /mnt
- remove files from /mnt/tmp/ remained from the previous boot. Otherwise
some large file hidden by mounted /tmp may reduce free space available
on the / partition
- umount /mnt
- remove initrd backup
As for the Linux initial ramdisk, and ignoring system configuration
settings in memory:
* The Linux initial ramdisk 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.
* 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.
As for systemd:
* AIUI systemd is a system management database comprised of text and
binary files. systemd may hook into initrd.img. 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. 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.
* 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.
David
[1] https://en.wikipedia.org/wiki/Don't_repeat_yourself
[2] https://www.martinfowler.com/bliki/TwoHardThings.html
Reply to: