For sometime now I've kept my /boot parition mounted readonly. I feel it's safer, and more useful than keeping it unmounted. When readonly you can see what's there, and you can't accidentally format it (guess what I did once!), neither of which you can do when unmounted. But why is another discussion. As genkernel can't currently handle a readonly /boot, I made it, and will attach a patch. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 32388 [details, diff] genkernel support for readonly /boot
Hm; could you move that function over to gen_funcs.sh and use ``cut -d\ '' instead of awk? Patch looks good otherwise, thanks!
Created attachment 32390 [details, diff] updated patch, as requested Is there likely to be a mechinism to trap kill signals, and 'cleanup' (a la bootstrap.sh)? If not, I may add something simple, to put /boot back as readonly, in case the build doesn't get to do it at the end.
Well; the only trapping code that is there is the callback cancellation code so trapping shouldn't be an issue. Ideally; you'd want to set a cleanup trap just after a successful mount, if any, and let that stay until the callback section where the trap is set for callback trapping rather than cancelling. After that, if a cleanup trap was set it should be restored again. Oh; and you want grep '^/boot' since grep '/boot' would pick up /mnt/boot and so forth...
OK, I'll look at doing some cleanup stuff later. Probably a safeish assumtion that most people would fix the problem, then try again anyway. As for the "^/boot" v "/boot" thing, has that been fixed since sys-kernel/genkernel-3.0.2a? The /boot check before mine doesn't do it :) Cheers
Just a thought : Why even bother to have genkernel mount /boot if it's read-only. As genkernel is now, it doesn't use any information from /boot and with the --no-install option and the patch from bug 57836 there is no reason to mount /boot.
Martin: I've merged this in with yours from bug #57836, so it won't be [re]mounted RW if --no-install is specified... The patch should be in Portage with genkernel-3.0.2e; please reopen this bug if you have any issues with it. Thanks!
