During boot process, /etc/init.d/checkfs is owned by sys-apps/baselayout-1.12.13 , and runs /sbin/fsck owned by sys-apps/util-linux-2.16.2 .
/dev/sdc1 /mnt/gPXE vfat defaults,noauto 0 2
/dev/sdc1 /mnt/doublehp ext4 loop,offset=10000000 0 2
boot messages (can not do copy paste because console goes up too fast): sdc1 does not seem to be ext2 ... operational error.
I am 100% sure that fsck tried to fsck.ext the begin of disk, the VFAT part.
fsck -A should be more clever. fstab contains all elements required to make it properly.
If fsck can not be patched, init.d/checkfs could parse fstab lines that have an offset, and for these ones, do an apropriate losetup; then fsck *must* be happy.
More and more people are using offset; amongst other things, new virtualisation tools guide us to use raw image disk, and thus, use more and more partitions inside files ... thus offset.
I tried to find out but I can't readily tell whether the problem is in fsck or in fsck.ext4, so I am changing the Summary accordingly.
(In reply to comment #0)
> During boot process, /etc/init.d/checkfs is owned by
> sys-apps/baselayout-1.12.13 , and runs /sbin/fsck owned by
> sys-apps/util-linux-2.16.2 .
> If fsck can not be patched, init.d/checkfs could parse fstab lines that have an
> offset, and for these ones, do an apropriate losetup; then fsck *must* be
I'd be willing to think along these lines for baselayout-2 but not -1 which is now outdated. There the script is /etc/init.d/fsck.
However, the correct fix is in /sbin/fsck because the -A option is supposed to walk through fstab.
dont bother with openrc changes until we hash out the direction upstream