This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at https://wiki.gentoo.org
Talk:Sakaki's EFI Install Guide/Building the Gentoo Base System Minus Kernel
Package Name Change
"emerge --verbose --oneshot app-portage/cpuinfo2cpuflags"
This package has changed to app-portage/cpuid2cpuflags
This command is still correct
" Now, run the tool and note its output (yours may well differ from the below, which is taken from the Panasonic CF-AX3):
(chroot) livecd / #cpuinfo2cpuflags-x86 "
Using the Live DVD (without SSH), August 2016, there were already dependency conflicts for installing git-repository functionality. Might it be worthwhile to setup a systemd profile and perform bootstrap or deep profile update before this step Preparing to Run Parallel emerges? As a relatively new gentoo user, I thought this dependency conflict interrupted the otherwise smooth flow of your guide. --Findle (talk) 17:28, 14 August 2016 (UTC)
- A very(!) belated thanks for this note (email client was sending notifications about certain talk page changes to spam, fixed now ><). The guide has been updated to reflect this point; also the fact that now the program name has now also changed, to match that of the package (cpuid2cpuflags).
Another name change. app-crypt/sbsigntool just got renamed to app-crypt/sbsigntools, and now sys-kernel/buildkernel-1.0.30::sakaki-tools can't find it. Tatterdemalian (talk) 15:47, 14 July 2018 (UTC)
- Thanks again for the quick responses! Had the repo masked in the meantime. I really need to bookmark the github page. Tatterdemalian (talk) 00:45, 15 July 2018 (UTC)
Engineering team updated the URL...
Just a little FYI that per the engineering team the URL you provided in "Installing an Up-to-Date Portage Tree" is no longer up-to-date. On a side note - maybe the most explicit documentation online I found about getting a Linux to securely boot on UEFI. Trying to reproduce the feats on Hyper-V Generation 2 system for learning purpose.
livecd ~ #gpg --keyserver pool.sks-keyservers.net --recv-key 96D8BF6D
should now read
livecd ~ #gpg --keyserver subkeys.pgp.net --recv-key 96D8BF6D
- Thanks! Per the gpg manpage "[m]ost keyservers synchronize with each other, so there is generally no need to send keys to more than one server" (and it is similar situation when receiving); keys when imported must be cross-checked of course, since they may be received across an unauthenticated channel. I've found the pool.sks-keyservers.net name the most reliable, which is why it's that way in the guide. --Sakaki (talk) 09:56, 12 February 2018 (UTC)
Git Repositories Compromised
Sakaki, the following warning was posted to the Gentoo forum a few days ago: https://forums.gentoo.org/viewtopic-t-1083234.html?sid=32e5b4df8f28a459648841c175ac3da5
Is the sakaki-tools repository affected by this? --Tatterdemalian (talk) 20:43, 2 July 2018 (UTC)
- No, sakaki-tools is unaffected, as it is under my personal control (although that reminds me, I should migrate to using verified commits by default on this repo). Also, if you have followed the advice in the guide and use the emerge-webrsync method to update your main Portage tree (with the webrsync-gpg FEATURE set) you will only have been working from signed snapshots, which, according to the release engineering team, are unaffected by the breach. sys-apps/portage itself also has the rsync-verify USE flag to check incremental rsync tree updates via app-portage/gemato, but at the time of writing this flag was not turned on by default for stable amd64 Portage, afaik. --Sakaki (talk) 08:55, 3 July 2018 (UTC)
- Okay, thanks for the quick reply! Unfortunately, I think I was using your guide before webrsync-gpg was even a feature, so I have to go back and retrofit my Gentoo install for it. --Tatterdemalian (talk) 16:30, 3 July 2018 (UTC)