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 . My fstab: /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 > happy. 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