Hi, For anyone following this thread, the fix was to add fsck.repair=yes as a kernel boot parameter in /boot/grub/menu.lst.
So: kernel /vmlinuz root=LABEL=VOYAGE_FS console=ttyS0,115200n8 Becomes: kernel /vmlinuz root=LABEL=VOYAGE_FS console=ttyS0,115200n8 fsck.repair=yes Then run: update-grub And presto on startup from a power loss: [/sbin/fsck.ext2 (1) -- /dev/sda1] fsck.ext2 -a -C0 /dev/sda1 Becomes: [/sbin/fsck.ext2 (1) -- /dev/sda1] fsck.ext2 -y -C0 /dev/sda1 Hope this helps someone. Cheers. On 21 September 2017 at 23:52, Erik van Linstee <[email protected]> wrote: > > > On 21-09-17 07:28, Richard Warburton wrote: > > Hi, > > Thanks Erik for posting the fsck.ext2 fix. However, I notice that during > startup fsck runs with: > > [/sbin/fsck.ext2 (1) -- /dev/sda1] fsck.ext2 -a -C0 /dev/sda1 > > > note the -a. I need it to be -y. > > Because on the hard fixes it drops to BusyBox, and on an APU2, that's not > useful. > > At first I thought I wasn't setting the FSCKFIX correctly, but that > doesn't seem to be it. In fact given the order of parameters, I'm not > convinced it's running from checkroot.sh. I hardcoded fix="-y" in > checkroot.sh where the check was, so it wouldn't even matter what FSCKFIX > was set as. > > > You are right, it isn't running from checkroot.sh. fsck is called when the > system is booting from the initramfs. My fix makes sure fsck.ext2 is added > to the initramfs by the initramfs tools, which it wasn't before. > > I have no idea how the system in the initramfs decides to call fsck and > with which parameters. I may try to find out one day, but that does not > help you now. Sorry. > > Erik >
_______________________________________________ Voyage-linux mailing list [email protected] http://list.voyage.hk/mailman/listinfo/voyage-linux
