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.
]]>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.
]]>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.
]]>