You are not logged in.
In recent times i've been getting an odd sort of error message during boot. The messge is "file system check failed but did not detect errors". It does not stop the boot process. The screen blanks when Devuan reaches the login prompt so I didn't notice it for several days. After noticing it, I could not find it in dmesg. A grep of files in the /var/log directory could find no log of the error message.
The usual search engines found many occurrence of this error message but each for a different problem.
As far as I can tell, there are no file system errors.
Devuan Chimaera, 64 bit.
Do I actually have an error?
Thank you.
Last edited by durham (2021-09-14 21:56:08)
A dangerous technology is one that is available only to an elite group -- George M. Ewing, Analog, April 1977
Offline
One of the early steps in the boot sequence is to run fsck on the root file system, and that apparently has some difficulty, but doesn't result in stopping the boot-up. There might be log file(s) saved to /var/log/fsck/ with details. Otherwise it would be a good idea to firstly shut down and boot up using a live disk to run fsck manually to see what is happening and possible resolve it. Secondly boot up the machine again and if there's still the note, then you should force a rebuild of your initrd (which apparently have become incomplete in some way).
Offline
Thank you for the reply. I tried everything you said. No errors, but no changes. It is beginning to look like something is off in the init ram fs configs and that will be a pain to sort out.
A dangerous technology is one that is available only to an elite group -- George M. Ewing, Analog, April 1977
Offline
Right, so I finally got around to opening up the init ram disk. I hate looking at other people's sh/bash code. Arg.
Between that and snapping a pic with my phone during boot up (debian/devuan loves to the clear the screen during boot up, as well as on login prompts) I've got an idea of what is going on.
Near as I can tell, the init ram fs calls fsck early on. fsck then whines that it can't see /dev/mapper/azura-dawn. fsck must be running before LVM opens up (activates? makes visible?) the volume. Then the init ram fs quietly and without any further fuss mounts the volume and boot off of it. The problem is not solved, but now it is revealed to be an init ram fs error not a disk error.
The only thing I am missing out on, therefore is the early (still in the init ram fs part of the boot process) file system check.
Since the last few distros I used didn't do disk check in their init ram fs's, nothing is different now.
A dangerous technology is one that is available only to an elite group -- George M. Ewing, Analog, April 1977
Offline
If azura-dawn is your root LVM then, possibly, the initram lacks the lvm2 utilities? But those should have been added by the update-initramfs command, so it's a bit peculiar.
Offline
If azura-dawn is your root LVM then, possibly, the initram lacks the lvm2 utilities? But those should have been added by the update-initramfs command, so it's a bit peculiar.
That's pretty much what I thought, but then the fact that the init ram fs then activates and mounts the lvm volumes (with discards correctly set to passdown, i used lvs to check) means that the lvm software must be the init ram fs (oh and when I looked in the init ram fs, I saw lvm in there).
It begins to look like the fsck call tries to happen before lvm opens everything up.
Agreed: peculiar.
Last edited by durham (2021-09-25 03:54:10)
A dangerous technology is one that is available only to an elite group -- George M. Ewing, Analog, April 1977
Offline