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, so at
certain moment I thought that original issue was due to attempt to
really mount another partition to /etc (e.g. for easier backups). Later
an entry for /tmp was added to fstab on mounted partition, perhaps new
version of fstab even propagated to initramfs. However after reboot
there was no an entry for /etc in the /etc/fstab file residing on the
root partition, so init had no change to mount /etc with another fstab
(with the entry for /etc). It is literally bootstrap problem.
Fortunately Default User posted complete fstab, so it was possible to
rule out such hypothesis.
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 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
