Like I said /dev/sda3 never gets checked. This is not serious. The harddrive
is new, or was new when I did this all new installation of Gentoo.
I needed more space and I needed a virgin harddrive to partition it GPT.
But now rootfs needs to be checked.

So any suggestions on the fstab or any idea on why fsck does not kick in?

Last edited by transsib on Tue Apr 12, 2016 11:39 am; edited 1 time in total

You would need to 'mount -o remount,rw' if changing the bootloader/bootmanager, but that would be once in a blue moon, if ever

I am glad I asked you about this. The "blue moon" won't come hopefully
I've had a hard time setting this up during the Xmas break. I was almost paranoid about those efivars which is why they're still in there.
I also have some residual stuff on the boot/efi partition I could delete now from failed attempts at getting the new Gentoo system to boot
which I don't dare touch for fear of breaking my hard work. May be I should ask for help here too.

Thanks a lot for your advice; I take it and the above goes into my personal tricks file I have for important system procedures.

I was almost paranoid about those efivars which is why they're still in there.

transsib ... given the frequency of use I've opted to not use efivarfs at all, which works fine as long as you use =sys-boot/efibootmgr-0.5.4-r1. I see absolutely no point in a tmpfs filesystem that exist simply to expose NVRAM and which I'm likely to need to access once. The whole thing smells of over-engineering, and the fact that efiboomgr-6.x nolonger works with efivars alone (which just seems dumb), doesn't illicit much in the way of confidence.

transsib wrote:

I also have some residual stuff on the boot/efi partition I could delete now from failed attempts at getting the new Gentoo system to boot which I don't dare touch for fear of breaking my hard work. May be I should ask for help here too.

If you look at the output of 'efibootmgr -v' you will see what paths/executables have an entry, you should be able to work out from this what's needed in /boot/efi. If you happen to also keep efi stub kernels there then obviously these are needed by your bootloader/bootmanager.

transsib wrote:

Thanks a lot for your advice; I take it and the above goes into my personal tricks file I have for important system procedures. Thank you again.

transsib ... in which case, unless 'devfs' has radically changed since the =sys-apps/openrc-0.12.4 version above then shm should be mounted without an entry in fstab.

I have some vague recollection of a shutdown/reboot issue relating to udev, so perhaps yours is similar, unforunately I can't find the thread on a brief search (and as I don't use {e,}udev I generally skim such posts).

0.12.4 doesn't exist any more and 0.19.1 is stable.
I could just wait until the bug works itself out, somehow
Thanks for the link to the openrc thread. I never waisted a thought
on openrc since this install exists because no problem turned up until
I removed the shm line from fstab.

0.12.4 doesn't exist any more and 0.19.1 is stable. I could just wait until the bug works itself out, somehow :wink: Thanks for the link to the openrc thread. I never waisted a thought on openrc since this install exists because no problem turned up until I removed the shm line from fstab.

transsib ... I'm maintaining 0.12.4 in a local overlay (with such things you can always find it in the attic.) As for 'stable', I take stable to mean "has been thoroughly tested, and won't arbitrarily break your install on updating", that is not something that is true of openrc currently ("stable", or otherwise), and I won't allow such developers to break my install willy-nilly (and no amount of argumentation on the direction being taken will convince me otherwise).

As for 'stable', I take stable to mean "has been thoroughly tested, and won't arbitrarily break your install on updating", that is not something that is true of openrc currently ("stable", or otherwise), and I won't allow such developers to break my install willy-nilly (and no amount of argumentation on the direction being taken will convince me otherwise).

best ... khay

If it ain't broke, don't fix it! Checked equery and found, like NeddySeagoon, I'm staying at 0.17 I believe SteveL stopped even sooner.

As for 'stable', I take stable to mean "has been thoroughly tested, and won't arbitrarily break your install on updating", that is not something that is true of openrc currently ("stable", or otherwise), and I won't allow such developers to break my install willy-nilly (and no amount of argumentation on the direction being taken will convince me otherwise).

best ... khay

If it ain't broke, don't fix it! Checked equery and found, like NeddySeagoon, I'm staying at 0.17 I believe SteveL stopped even sooner.