gpgv: BAD signature from

[jradxl]

Hello,
I've been using ArkaneLinux for a few days now, with KDE and some extras I've loaded, and am very impressed.
But today, using my first time with arkdep deploy I get this key error.
I'm not an ARCH guru. But I on a traditional Arch I'd try pacman to refresh the keys...
But on an immutable system I'm not sure how to proceed.
Previously fiddling with pacman I get the message it will unlock the filesystem, and I don't whether it gets locked again.
I did look to see whether arkdep had a command to update the keys.

Hopefully you can advise.
Thanks
John

# arkdep deploy
--> Deploying arkanelinux latest
--> Downloading database
008048b6c421522911f58d997f6e31066ba64a02db from arkanelinux will be deployed.

Proceed with deployment? [Y/n] 
--> Downloading disk image
008048b6c421522911f58d997f6e310 100%[=======================================================>]   1.43G  45.6MB/s    in 32s     
008048b6c421522911f58d997f6e310 100%[=======================================================>]     438  --.-KB/s    in 0s      
--> Checking GPG signature
gpgv: Signature made Tue Aug 20 03:23:14 2024 BST
gpgv:                using RSA key 9367D79152631966FF094C242BA91DC2563B83D1
gpgv: BAD signature from "Dennis ten Hoove <[email protected]>"
<#> gpg check failed

[jradxl]

Woops, sorry as I posted I realized I run as root...

Perhaps you could comment on whether this error is significant:

--> Generating initramfs
dracut[E]: Module 'cifs' depends on module 'network', which can't be installed

Thanks
John

%> sudo arkdep deploy                                                 
[sudo] password for jradley: 
<!> The following hanging images were found in cache
008048b6c421522911f58d997f6e31066ba64a02db.tar.zst
008048b6c421522911f58d997f6e31066ba64a02db.tar.zst.sig
--> Deploying arkanelinux latest
--> Downloading database
008048b6c421522911f58d997f6e31066ba64a02db from arkanelinux will be deployed.

Proceed with deployment? [Y/n] 
--> 008048b6c421522911f58d997f6e31066ba64a02db already in cache, skipping download
--> Checking GPG signature
gpgv: Signature made Tue Aug 20 03:23:14 2024 BST
gpgv:                using RSA key 9367D79152631966FF094C242BA91DC2563B83D1
gpgv: Good signature from "Dennis ten Hoove <[email protected]>"

[jradxl]

Ah, a learning curve....
If I arkdep deploy then I get your Gnome version again...
How do I update my "arkanelinux-kde", derived from your test-arkanelinux-kde?
Thinking,,,,,
Can I keep repeating sudo arkdep-build arkanelinux-kde...
But I won't pick up any changes you have made to test-arkanelinux-kde, which I can see package.json was updated 1 hour ago.
So I need to keep downloading your test-arkanelinux-kde and merge in any changes to my package.json
Have I got this right?

[jradxl]

OK. It's obvious once I thought it through...
I'm going to have to git pull arkdep and append a version of package.json that only contains the packages I want to add.
I guess I can script this.
That's a bit awkward for a package like tailscale where I'm having to relogin every time a build a new image.
So I think I need an overlay for /etc/systemd/system in /arkdep/overlay/etc, but I may need to pass /var/lib/tailscale/tailscaled.state between builds

[dennis1248]

It actually does sound like a bug. It is supposed to load a custom keychain from /arkdep/keys/trusted-keys. I recall when implementing this that it caused me a lot of headache and it took me half a day to figure out on how to get it to work at all. I think the entire GPG bit needs to be re-implemented.

Locking the filesystem automatically again when you Pacman I could add. But I see little value in doing so after the system has already been changed. But it does make sense to do for consistency, then the user can just always assume the filesystem is locked. I will think about this.

Perhaps you could comment on whether this error is significant:

--> Generating initramfs
dracut[E]: Module 'cifs' depends on module 'network', which can't be installed

The error can be ignored. I will add this Dracut module to the ignore list, so it will no longer complain about it in the future.

Ah, a learning curve.... If I arkdep deploy then I get your Gnome version again... How do I update my "arkanelinux-kde", derived from your test-arkanelinux-kde? Thinking,,,,, Can I keep repeating sudo arkdep-build arkanelinux-kde... But I won't pick up any changes you have made to test-arkanelinux-kde, which I can see package.json was updated 1 hour ago. So I need to keep downloading your test-arkanelinux-kde and merge in any changes to my package.json Have I got this right?

That is correct. Arkdep has no way to determine which image variant it is running right now. Someone else asked the same question a few day ago on the Manjaro forums; https://forum.manjaro.org/t/manjaro-immutable-out-now-for-community-testing/166364/70

So what you would need to do is edit /arkdep/config and change repo_default_image to your prefered image variant. Do note that I do not actively update the KDE image, although I did happen to release an update with some fixes for it just yesterday.

To layer changes to images you can either use Flatpaks or containers. Distrobox is installed by default, it can install GUI apps and provide mutable development environments should you require those.

OK. It's obvious once I thought it through... I'm going to have to git pull arkdep and append a version of package.json that only contains the packages I want to add. I guess I can script this. That's a bit awkward for a package like tailscale where I'm having to relogin every time a build a new image. So I think I need an overlay for /etc/systemd/system in /arkdep/overlay/etc, but I may need to pass /var/lib/tailscale/tailscaled.state between builds

What you could do is add these directories to /arkdep/config under the migrate_files list. Alternatively, if it is a lot of data and copying is not idea, you can also add a new subvolumes to /arkdep/shared and mount them at these locations with fstab.

For Systemd services it is best to add their symlinks to /arkdep/overlay manually.

[jradxl]

Thank you for your detailed response
Mention of migrate_files was very helpful

I tried pacman -Q which offered to unlock. Which seems overkill for a query.
I'm now using expac -S -H M '%k\t%n' . Are there other ways to list all installed packages?

Will ask Systemd Services question in new issue

[dennis1248]

The pacman wrapper is indeed a bit rudimentary. This change should prevent it from triggering, but I haven't tested it yet; 1346416

A workaround to make it so that it does not use the wrapper is to call the actual pacman binary directly. sudo /usr/bin/pacman -Qi linux

The wrapper itself lives in /usr/abin/pacman, it is just a bash script which checks if the disk is locked and calls pacman.