search

sakaki- / gentoo-on-rpi-64bit

Bootable 64-bit Gentoo image for the Raspberry Pi4B, 3B & 3B+, with Linux 5.4, OpenRC, Xfce4, VC4/V3D, camera and h/w codec support, weekly-autobuild binhost
GNU General Public License v3.0
921 stars 126 forks source link

genup: layman: command not found #61

Closed zd59 closed 5 years ago

zd59 commented 5 years ago

Hello!

I'm new to Gentoo (20+ years Slackware) and yesterday installed this Sakaki arm64 Gentoo to my RPI 3b+. After install, I want to update the system by issue 'genup' The reply was:

pi64 /home/zd # genup
* Checking Portage configuration, please wait...
* Gentoo System Updater v1.0.16
* Updating Portage tree and syncing the eix cache
* (this may take some time)...
 * Syncing all portage overlays
/usr/bin/eix-sync: line 396: layman: command not found
 * layman -S failed
 * Running emerge --sync
>>> Syncing repository 'gentoo' into '/usr/portage'...
 * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
 * Refreshing keys from keyserver ...OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: Server indicated a failure

And the system is very unresponsive despite disabling display compositing.

For advice would be very grateful.

sakaki- commented 5 years ago

The layman error is normal, as the image does not ship with that particular package installed (it does not affect the update). The gpg message suggests a problem possibly on the hkps://hkps.pool.sks-keyservers.net end, or perhaps your network connection went down.

The best thing is probably to reboot the system and try again. Once genup does start to update your system, it will take a number of hours, during which it will be quite unresponsive (due to the load). You can run e.g. htop in a terminal window to see what is running.

zd59 commented 5 years ago

Thank you Sakaki for a fast response.

Tried many times, rebooted but always failed. Passed a few hours between attempts. But ping returns response. This is strange. Any additional advice, maybe logs or genup debug mode to get a reason of failures?

sakaki- commented 5 years ago

Sorry you are having trouble with this. I just downloaded a fresh copy of the image and ran genup, to be sure everything still works, and it went through OK. Please reboot, then try running (as root, or using sudo each time):

emaint sync --repo rpi3
emaint sync --repo sakaki-tools
emaint sync --repo gentoo

What do those three lines return?

zd59 commented 5 years ago

Sorry web interface on that page do not allow me to use Preview, quoting, "insert code" etc. So below is all in pure text. The last command failed, see below.

pi64 ~ # emaint sync --repo rpi3

Syncing repository 'rpi3' into '/usr/local/portage/rpi3'... /usr/bin/git fetch origin Already up to date. === Sync completed for rpi3 q: Updating ebuild cache for /usr/local/portage/rpi3 ... q: Finished 201 entries in 0.061999 seconds

Action: sync for repo: rpi3, returned code = 0

pi64 ~ # emaint sync --repo sakaki-tools

Syncing repository 'sakaki-tools' into '/usr/local/portage/sakaki-tools'... /usr/bin/git fetch origin Already up to date. === Sync completed for sakaki-tools q: Updating ebuild cache for /usr/local/portage/sakaki-tools ... q: Finished 16 entries in 0.009894 seconds

Action: sync for repo: sakaki-tools, returned code = 0

pi64 ~ # emaint sync --repo gentoo

Syncing repository 'gentoo' into '/usr/portage'...

  • Using keys from /usr/share/openpgp-keys/gentoo-release.asc
  • Refreshing keys from keyserver ...OpenPGP keyring refresh failed: gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: Server indicated a failure

OpenPGP keyring refresh failed: gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: Server indicated a failure

OpenPGP keyring refresh failed: gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: Server indicated a failure ... and keep failing

sakaki- commented 5 years ago

Are you behind a restrictive firewall by any chance? Can you successfully web browse to https://hkps.pool.sks-keyservers.net/?

zd59 commented 5 years ago

No, take a look: OpenPGP Public Key Server Commands Welcome to keys2.kfwebs.net, a keyserver for OpenPGP hosted by KF Webs, part of the pool.sks-keyservers.net round-robin.

But a web browser warns me, that connection is not secure: "Could not verify this certificate because the issuer is unknown" - perhaps selfissued. But that coud not be the reason for failure.

sakaki- commented 5 years ago

Please try the following command, as root or using sudo:

gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release --debug-all -vvv --refresh-keys

That should give some idea of why the key fetch is failing.

PS: yes, the bad certificate thing shouldn't be a blocker.

zd59 commented 5 years ago

Thank you again.

The response:

pi64 ~ # gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release --debug-all -vvv --refresh-keys gpg: Note: no default option file '/var/lib/gentoo/gkeys/keyrings/gentoo/release/gpg.conf' gpg: using character set 'utf-8' gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog gpg: DBG: [not enabled in the source] start gpg: keyblock resource '/var/lib/gentoo/gkeys/keyrings/gentoo/release/pubring.kbx': No such file or directory gpg: DBG: [not enabled in the source] keydb_new gpg: DBG: [not enabled in the source] stop gpg: keydb: handles=1 locks=0 parse=0 get=0 gpg: build=0 update=0 insert=0 delete=0 gpg: reset=0 found=0 not=0 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=0 cached=0 good=0 bad=0 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: secmem usage: 0/65536 bytes in 0 blocks pi64 ~ #

sakaki- commented 5 years ago

Sorry, my mistake, that was the wrong gpg location for the way gemato works now. The simplest way to check for the current release would actually be to run, as root, the following (this will attempt to update a different signature, but will use the same key update mechanism):

gpg --homedir /root/.gnupg/ --debug-all -vvv --refresh-keys --keyserver hkps://hkps.pool.sks-keyservers.net

You can drop the --debug-all if it generates too much output. Are any obvious errors reported when you try the above?

zd59 commented 5 years ago

Again, server error:

pi64 ~ # gpg --homedir /root/.gnupg/ --debug-all -vvv --refresh-keys --keyserver hkps://hkps.pool.sks-keyservers.net gpg: reading options from '/root/.gnupg/gpg.conf' gpg: using character set 'utf-8' gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog gpg: DBG: [not enabled in the source] start gpg: DBG: [not enabled in the source] keydb_new gpg: DBG: [not enabled in the source] keydb_search enter gpg: DBG: keydb_search: 1 search descriptions: gpg: DBG: keydb_search 0: FIRST gpg: DBG: keydb_search: searching keybox (resource 0 of 1) gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success gpg: DBG: [not enabled in the source] keydb_search leave (found) gpg: DBG: [not enabled in the source] keydb_get_keybock enter gpg: DBG: parse_packet(iob=1): type=6 length=525 (parse.keydb.c.1242) gpg: DBG: parse_packet(iob=1): type=13 length=51 (parse.keydb.c.1242) gpg: DBG: parse_packet(iob=1): type=2 length=596 (parse.keydb.c.1242) gpg: DBG: parse_packet(iob=1): type=2 length=563 (parse.keydb.c.1242) gpg: DBG: iobuf-1.0: underflow: buffer size: 1746; still buffered: 0 => space for 1746 bytes gpg: DBG: iobuf-1.0: close '?' gpg: DBG: [not enabled in the source] keydb_get_keyblock leave gpg: DBG: [not enabled in the source] keydb_search enter gpg: DBG: keydb_search: 1 search descriptions: gpg: DBG: keydb_search 0: NEXT gpg: DBG: keydb_search: searching keybox (resource 0 of 1) gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => EOF gpg: DBG: [not enabled in the source] keydb_search leave (not found) gpg: DBG: free_packet() type=6 gpg: DBG: free_packet() type=13 gpg: DBG: free_packet() type=2 gpg: DBG: free_packet() type=2 gpg: DBG: chan_3 <- # Home: /root/.gnupg gpg: DBG: chan_3 <- # Config: /root/.gnupg/dirmngr.conf gpg: DBG: chan_3 <- OK Dirmngr 2.2.10 at your service gpg: DBG: connection to the dirmngr established gpg: DBG: chan_3 -> GETINFO version gpg: DBG: chan_3 <- D 2.2.10 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> KEYSERVER --clear hkps://hkps.pool.sks-keyservers.net gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> KEYSERVER gpg: DBG: chan_3 <- S KEYSERVER hkps://hkps.pool.sks-keyservers.net gpg: DBG: chan_3 <- OK gpg: refreshing 1 key from hkps://hkps.pool.sks-keyservers.net gpg: DBG: chan_3 -> KS_GET -- 0x774A2481A39885DE8B56AB4F09F2FF455D90CAF4 gpg: DBG: chan_3 <- ERR 219 Server indicated a failure gpg: keyserver refresh failed: Server indicated a failure gpg: DBG: chan_3 -> BYE gpg: DBG: [not enabled in the source] stop gpg: keydb: handles=1 locks=0 parse=1 get=1 gpg: build=0 update=0 insert=0 delete=0 gpg: reset=0 found=1 not=1 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=0 cached=0 good=0 bad=0 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: secmem usage: 0/65536 bytes in 0 blocks

sakaki- commented 5 years ago

OK, well that works fine for me, on a fresh copy of the image. Try, instead:

gpg --homedir /root/.gnupg/ --debug-all -vvv --refresh-keys --keyserver hkp://hkps.pool.sks-keyservers.net

(i.e. using hkp protocol)

zd59 commented 5 years ago

hkps or hkp - no difference, the exact same error:

gpg: refreshing 1 key from hkp://hkps.pool.sks-keyservers.net gpg: DBG: chan_3 -> KS_GET -- 0x774A2481A39885DE8B56AB4F09F2FF455D90CAF4 gpg: DBG: chan_3 <- ERR 219 Server indicated a failure gpg: keyserver refresh failed: Server indicated a failure gpg: DBG: chan_3 -> BYE

sakaki- commented 5 years ago

It must be something local to your setup. I wonder if perhaps it is your DNS (e.g. https://bbs.archlinux.org/viewtopic.php?id=220996)?

You could try rebooting, then temporarily editing (as root, or using sudo) /etc/resolv.conf, commenting out any existing lines in there and adding instead:

nameserver 8.8.8.8

save, and then issue:

gpg --homedir /root/.gnupg/ --debug-all -vvv --refresh-keys --keyserver hkps://hkps.pool.sks-keyservers.net

again. Any difference this time?

zd59 commented 5 years ago

CONGRATULATE!

Success. I have RPI on my home network behind a router/firewall, Networkmanager from RPI set nameserver to internal IP of a router (default gateway). I'm not a network expert, so how to permanently solve the issue (give an exact nameserver IP to networkmanager? which one, is OK to set it to my ISP server IP?)

Thank you again for your kindness and fast response!

Best regards.

sakaki- commented 5 years ago

Glad to hear it is working ^-^

You can set the nameserver permanently by opening the Applications → Settings → Network Connections tool - click on your network connection name in the list, use the 'gearwheel' icon to open properties, select IPv4 Settings tab, choose the Automatic (DHCP) addresses only in Method: dropdown, then set (e.g.) 8.8.8.8 in the DNS serversfield (you can set your ISP's DNS if you like instead), and press Save. Restart. Hopefully if you look in /etc/resolv.conf now, it will be showing 8.8.8.8 (or whatever you chose) as set by NetworkManager. Check you can still ping etc., and then try running genup again. Leave it alone to run - it will probably take four or so hours to fully update your machine.

zd59 commented 5 years ago

Thanks again.

Will set/try that after back home from work. And probably close the case.

zd59 commented 5 years ago

genup works now. You were right, it is really long process. Upgrading now for over two hours and done 23 jobs from 219..

Gratefully closing the case.

Regards.