User talk:Sakaki/Sakaki's EFI Install Guide/Building the Gentoo Base System Minus Kernel

Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:

A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 13:59, 5 November 2024 (UTC)
:: Your reply ~~~~

Package Name Change

Talk status

This discussion is still ongoing.

"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).

I'll have a look into the dependency point you mention, for users not starting from the minimal-install image. --Sakaki (talk) 09:56, 12 February 2018 (UTC)

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)

Run emaint sync --repo sakaki-tools and it should be fixed; I revbumped the buildkernel ebuilds to address this (issue #9). --Sakaki (talk) 15:54, 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...

Talk status

This discussion is still ongoing.

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)

Default Portage Locations Change

Talk status

This discussion is still ongoing.

In the /mnt/gentoo/etc/portage/repos.conf/gentoo.conf file is the use of "location = /usr/portage" intentional? According to /usr/portage the default locations have changed. Should the guide be changed, or is there a reason to use /usr/portage? Thank you! Aries97 (talk) 18:04, 30 September 2019 (UTC)

Package name change: app-portage/efitools

Talk status

This discussion is still ongoing.

Thank you sakaki for this wonderful guide. I followed it in early March 2020 and some package locations had changed: app-crypt/efitools is now app-portage/efitools.

Also, there was an emerge failure with efitools because of a mis-spelling in the code, if you search for "UNKOWN" in the file called "console". I worked around it by CTRL-Z while portage was preparing the package and then editing the source file in an editor. There's probably a better way to do this, though.

Koivunen (talk) 10:29, 14 March 2020 (UTC)