bcowan

this should be fixed with latest ego sync, no need to modify anything

Please refer to man boot.conf add an entry to /etc/boot.conf such as "Windows 7" { type win7 params root=/dev/sda3 params += chainloader=+1 }

PR was merged last night, so this should be fixed with an ego sync hopefully 🙂

I submitted a pull request to fix this, the patch is missing for the ebuild. Drobbins will hopefully fix when he gets some time :)

I only have 3g ram in this old macbook and rust builds fine. You can try just editing the ebuild for the ram check and change it to 2g. This may fail, I 'm not guaranteeing it will build on every system. If it fails there is always rust-bin to fall back on.

That page needs re-worked and is pretty dated. Portage snapshots are no longer valid afaik, everything is taken care of with git and ego sync. Here is a more in depth wiki page, but its a little involved, allot can be ignored. A simplified version of it is needed. https://www.funtoo.org/Funtoo_Linux_Installation_on_RPI

man boot.conf has most all the settings you are looking for. So edit your /etc/boot.conf and place them in there and run ego boot update

rfkill is provided by util-linux in recent versions which is part of @system. There may be an oversight somewhere that lost the dependency on the stand-alone version that is needed if you have sys-apps/util-linux-2.29.2-r1. just my thoughts :)

Now that you have concisely written down the steps you were doing and what you expected vs. what was happening, I do not see this as a bug but expected behavior. Grub-install indeed needs a mounted /boot or passed another writeable directory with the —boot-directory argument. This is done one single time only during your initial install. ( it writes a few files, notably grub.env and device.map ) You should not have to run grub-install again unless you corrupted something or another OS etc overwrites it. You then can run boot-update. It seems you are doing these steps in the wrong order. The install page documents these steps in the correct order. Boot should not need to be mounted for a working startup. The only thing that should need ran again is boot-update when you change kernels etc, never a grub-install. weird that the forum top posted my reply a couple hours ago????

Now that you have concisely written down the steps you were doing and what you expected vs. what was happening, I do not see this as a bug but expected behavior. Grub-install indeed needs a mounted /boot or passed another writeable directory with the —boot-directory argument. This is done one single time only during your initial install. ( it writes a few files, notably grub.env and device.map ) You should not have to run grub-install again unless you corrupted something or another OS etc overwrites it. You then can run boot-update. It seems you are doing these steps in the wrong order. The install page documents these steps in the correct order. Boot should not need to be mounted for a working startup. The only thing that should need ran again is boot-update when you change kernels etc, never a grub-install.

I would use —usepkgonly or -K instead of —usepkg or -k to emerge libtool and binutils from packages you built. Then try binutils-config -l to list and set it again with binutils-config 2 or whatever. I’m still thinking this is a binutils problem breaking compiler/toolchain links.

It should print the name of the kernel it finds after label your kernel- is blank

Your last post shows the output of boot-update not finding a kernel and the second output shows it automounting sda1 as your /boot when not mounted. Also its grub.cfg not grub.conf if that is not just a typo you wrote in the post.

dang, your binutils-config and gcc-config "look" correct. "looks" can be deceiving. Have you changed CFLAGS or anything? maybe have a bad flag. Might want to post a gcc -v and maybe emerge --info so we have allot of the info bases covered :)

This post still confuses me. /boot not being mounted has nothing to do with grub. Grub uses its own abstraction layer to read grub.cfg which points it to a initrd/kernel. This "abstraction layer" never "mounts" anything, grub has no knowledge of mounts. So only your grub.cfg could be wrong, or not written because you didn't manually mount /boot, but pretty sure boot-update automounts /boot so grub-mkconfig can write grub.cfg unless specified to not automount.