Hello there, G´day!

When using an offline repository, it gets to "lb chroot_archives chroot remove", tries to "apt update" and fails with the following:

Hello again guys!

I noticed that creating a copy of "offline_repo.key.chroot" and naming it "offline_repo.key.binary" will allow the build to complete, the problem is that the "offline_repo.key.binary" will end up on the final image..

ll config/archives/offline_repo.key.*
-rw-r--r-- 1 root root 1.7K Mar  3 19:34 config/archives/offline_repo.key.chroot
-rw-r--r-- 1 root root 1.7K Mar  3 19:34 config/archives/offline_repo.key.binary

Another way is to comment out one line of "/lib/live/build/chroot_archives", which will allow the build to complete without having an aditional file on the final image..

--- /lib/live/build/chroot_archives    2025-03-03 21:16:45.392029253 +1100
+++ /lib/live/build/chroot_archives2    2025-03-03 21:37:52.979999668 +1100
@@ -472,7 +472,7 @@
         done
 
         # Updating indices
-        Apt chroot update
+        #Apt chroot update
 
         # Unmount local repository - after apt update or it will fail due to missing files
         Chroot_try_unbind_path chroot "${LB_PARENT_MIRROR_CHROOT}"

KR,
Raph

Hello Raph,

Changing the extension to '.binary' makes the key present in the final
squashfs file, and the key will not be available during the construction
of the live system.
See the recently added section in the manual [1].

You'll need something like the following (see [2]):

# Register the GPG key
cp offline_repo.key config/archives/offline_repo.gpg.key.chroot

# Register the repository
cat << EOF > config/archives/offline_repo.list.chroot
deb [signed-by=/etc/apt/trusted.gpg.d/offline_repo.gpg.key.chroot.gpg]
http://localhost testing main
EOF

# You might need
'signed-by=/etc/apt/trusted.gpg.d/offline_repo.gpg.key.chroot.asc' if
key is ASCII-armored

# Select the package(s) from the repository
echo "my_package" > config/package-lists/offline_repo.list.chroot

While I was refactoring the repository-related code recently, I ran this
test [2] to ensure that I would not have broken existing features.

What can help to troubleshoot, is to use 'lb config --interactive'
during a non-production build. It allows you to see what will be present
in the image, before it will be sealed.
You can run any command at that time, and use 'exit 0' to continue the
generation of the iso, or use 'exit 1' to abort.

With kind regards,
Roland

[1]
https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-package-installation.en.html#433
[2]
https://salsa.debian.org/live-team/live-build/-/blob/master/test/test_external_deb_sources.sh?ref_type=heads