Open kmic5 opened 8 months ago
I just tried this and it tripped on
Copying executable tmp/sbin/start-stop-daemon
cp: cannot stat 'tmp/sbin/start-stop-daemon': No such file or directory
As far as I can tell, this is because dpkg
1.21.22 (in regular Debian bookworm) has this file in /sbin/
, but Raspberry Pi's bookworm distro uses 1.22.6~bpo12+rpt2
, which has it in /usr/sbin
. I am about to try patching build.sh
to use the new path and I'll let you know how that goes, but I'm not in a position to make a PR right now, sorry.
Well, changing that path allows build.sh
to proceed just fine. Unfortunately the resulting image triggers a kernel panic almost immediately upon boot (Kernel panic - not syncing: VFS: Unable to mount root fs on unkown-block(0,0)
). I wonder if it's related to some /boot/
config location changes in Bookworm.
No, it was the 20 byte initramfs that did that. I was missing cpio
in my build environment. I've remedied that and the installer is running.
Would you prefer me to file separate issues on Bookworm-related issues, or keep them here in this PR, by the way?
You can keep them here if you want. Thanks for your effort!
Well, I built the installer, and it ran through almost the entire process on my ancient RPi 2B without issue :confetti_ball:
Unfortunately it fell over at installing packages into the new system:
Building dependency tree...
Reading state information...
Package aptitude is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
Package raspi-copies-and-fills is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
Package nano is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
Package vim is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Unable to locate package firmware-atheros
E: Unable to locate package firmware-brcm80211
E: Unable to locate package firmware-libertas
E: Unable to locate package firmware-misc-nonfree
E: Unable to locate package firmware-realtek
E: Package 'aptitude' has no installation candidate
E: Unable to locate package avahi-daemon
E: Unable to locate package curl
E: Unable to locate package hdparm
E: Unable to locate package htop
E: Unable to locate package iptables-persistent
E: Unable to locate package micro
E: Package 'nano' has no installation candidate
E: Unable to locate package ncdu
E: Unable to locate package netfilter-persistent
E: Unable to locate package tmux
E: Package 'vim' has no installation candidate
E: Unable to locate package raspberrypi-bootloader
E: Unable to locate package raspberrypi-kernel
E: Unable to locate package raspberrypi-sys-mods
E: Unable to locate package libraspberrypi-bin
E: Package 'raspi-copies-and-fills' has no installation candidate
ERROR: 100, FAILED !
Error: The installation could not be completed!
I am a bit baffled by this, because /rootfs/etc/apt/sources.list
contains:
deb http://mirror.aarnet.edu.au/pub/raspbian/raspbian bookworm main contrib non-free firmware
...and /rootfs/etc/apt/sources.list.d/raspberrypi.org.list
contains:
deb http://archive.raspberrypi.org/debian bookworm main
The first mirror definitely contains eg. aptitude. I don't see any errors relating to eg. signing keys or index downloads, so I don't understand why it isn't found.
I just tried this and it tripped on
Copying executable tmp/sbin/start-stop-daemon cp: cannot stat 'tmp/sbin/start-stop-daemon': No such file or directory
As far as I can tell, this is because
dpkg
1.21.22 (in regular Debian bookworm) has this file in/sbin/
, but Raspberry Pi's bookworm distro uses1.22.6~bpo12+rpt2
, which has it in/usr/sbin
. [...]
Can confirm this issue occurs today. It was not present when the PR was submitted. To make the build script (build.sh
) more resilient, perhaps function cp_executable
could be changed to accept a list of paths to search for the source file.
Longer-term, it would help if update.sh
had a way to pin packages to a desired repo. Would require non-trivial changes.
Well, I built the installer, and it ran through almost the entire process on my ancient RPi 2B without issue 🎊
Thanks for trying this out, hope you get it working. I actually have bookworm (built with this PR) running on a 2B without issue since early March.
Unfortunately it fell over at installing packages into the new system:
Building dependency tree... Reading state information... Package aptitude is not available, but is referred to by another package. [...]
[...] The first mirror definitely contains eg. aptitude. I don't see any errors relating to eg. signing keys or index downloads, so I don't understand why it isn't found.
The installer may have failed to update the package lists somehow. Your log indicates success: Updating package lists... OK
so it may take some prodding to discover the underlying issue.
I did not test installing aptitude, but installed vim without issue. If you are able to bring up a shell on the target, you can try inspecting /rootfs
to check the state of things.
If you are able to bring up a shell on the target, you can try inspecting /rootfs to check the state of things.
I can (I have a monitor and keyboard connected), but there was not much to look at. The install log contains only what I posted there, and I can't find any other incriminating details. However, it looks like this corresponds to L2267 in scripts/opt/raspberrypi-ua-netinst/install.sh
, so I can try entering those commands manually and seeing what happens.
I'm getting a lot of "temporary failure in name resolution" errors, which is weird because a minute later nslookup
will work on the same host:
# chroot /rootfs /usr/bin/apt-get update
Ign:1 http://mirror.aarnet.edu.au/pub/raspbian/raspbian bookworm InRelease
Ign:2 http://archive.raspberrypi.org/debian bookworm InRelease
Ign:1 http://mirror.aarnet.edu.au/pub/raspbian/raspbian bookworm InRelease
Ign:2 http://archive.raspberrypi.org/debian bookworm InRelease
Ign:1 http://mirror.aarnet.edu.au/pub/raspbian/raspbian bookworm InRelease
Ign:2 http://archive.raspberrypi.org/debian bookworm InRelease
Err:1 http://mirror.aarnet.edu.au/pub/raspbian/raspbian bookworm InRelease
Temporary failure resolving 'mirror.aarnet.edu.au'
Err:2 http://archive.raspberrypi.org/debian bookworm InRelease
Temporary failure resolving 'archive.raspberrypi.org'
Reading package lists...
W: Failed to fetch http://mirror.aarnet.edu.au/pub/raspbian/raspbian/dists/bookworm/InRelease Temporary failure resolving 'mirror.aarnet.edu.au'
W: Failed to fetch http://archive.raspberrypi.org/debian/dists/bookworm/InRelease Temporary failure resolving 'archive.raspberrypi.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.
There's no nslookup
in /rootfs
, but:
# nslookup mirror.aarnet.edu.au
Server: 192.168.1.1
Address: 192.168.1.1:53
Non-authoritative answer:
Name: mirror.aarnet.edu.au
Address: 202.158.214.106
Non-authoritative answer:
Name: mirror.aarnet.edu.au
Address: 2001:388:30bc:cafe::beef
I suspect it's a DNS/systemd misconfiguration I've encountered before. Let me try again without use_systemd_services=1
to see what happens.
Yes, setting use_systemd_services=0
allowed the whole thing to work. I now have Bookworm running on my RPi 2B+, thank you!
My totally unverified hunch is that this is a variant of systemd's #4621/Ubuntu's issue #1624320, but I have not dug into it. I'd suggest that you look at how you configure DNS in the installer for use_systemd_services=1
, but I am absolutely not volunteering because I hate debugging DNS.
I applied the patches from this conversation onto the "devel" branch and patched "build.sh".
This was the commands I used to build the image:
bash update.sh
bash build.sh
sudo bash buildroot.sh
Building went fine. I burned the image onto the sdcard.
On the sdcard I created this config file "raspberrypi-ua-netinst/config/installer-config.txt":
# To customize the raspberrypi-unattended-installer:
#
# Place your settings in this file as described in the README.md or in the advanced documentation.
# Package
packages=preload,zram-config,zram-tools,apt-file,trash-cli,htop
firmware_packages=1
mirror=https://mirror.netcologne.de/raspbian/raspbian/
release=bookworm
arch=arm64
use_systemd_services=0
# SSH
root_ssh_pubkey=
root_ssh_pwlogin=0
# User
username=pi
userpw=raspbian
usergroups=pi
userperms_admin=1
rootpw=
# Network
hostname=nextcloudpi
ip_addr=192.168.178.28
ip_netmask=255.255.255.0
ip_gateway=192.168.178.1
ip_nameservers=192.168.178.1
# Localization
timezone=Europe/Berlin
keyboard_layout=de
locales=de_DE.UTF-8
system_default_locale=de_DE.UTF-8
# Graphics / GPU
gpu_mem=16
# Advanced
quiet_boot=1
disable_raspberries=1
disable_splash=1
cleanup=1
installer_telnet=none
timeserver=fritz.box
Booting worked fine without "SOS"-code.
But it doesn't continue from there. It seems like the installer script is not run.
Connecting a display to your pi may help to see where it's stalling. Or if you comment out installer_telnet=none
in the config, and the installer script gets far enough to bring up networking, you may be able to remotely view the log.
Another thing to try is a different mirror, or comment out the mirror=...
line to have a suitable mirror chosen automatically.
Have just been working through this PR trying to build on a Pi 4 and thought I'd add some feedback/new bugs...
update.sh
expects the last entry in Release files to be SHA256 - but some now have SHA512, so verification fails. A fix is to explicitly extract the SHA256 hashes before grepping for the filename to be verified - something like this works:
diff --git a/update.sh b/update.sh
index 2ee3cb6..aefccf0 100755
--- a/update.sh
+++ b/update.sh
@@ -203,7 +203,7 @@ download_package_list() {
# Verify the checksum of the Packages file, assuming that the last checksums in the Release file are SHA256 sums
echo -n "Verifying ${package_section} package list... "
- if [ "$(grep "${package_section}/binary-armhf/Packages${extension}" "${1}_Release" | tail -n1 | awk '{print $1}')" = "$(sha256sum "tmp${extension}" | awk '{print $1}')" ]; then
+ if [ "$(awk -v file="${package_section}/binary-armhf/Packages${extension}" '/^SHA256:/ {found=1; next} /^SHA/ && found {found=0} found && $3 == file {print $1}' ${1}_Release)" = "$(sha256sum "tmp${extension}" | awk '{print $1}')" ]; then
echo "OK"
else
echo -e "ERROR\nThe checksum of file '${package_section}/binary-armhf/Packages${extension}' doesn't match!"
I also had to update the build.sh
path for start-stop-daemon
to /usr/bin
as mentioned previously.
However when it boots it fails almost immediately with failed to execute init (error -2)
.
I've had a look at initramfs.gz
and it looks fine - it contains init
which is a symlink to bin/busybox
.
Replacing /init
with bash-static
and I can get enough of a shell to see that executing busybox
gives the error: cannot execute: required file not found
. However the busybox binary is present and executable - implying a missing dependency. /lib
seems to have the core libs (ld-linux etc) and ldconfig -v
doesn't show any obvious errors.
Any hints on how to debug this further?
Have just been working through this PR trying to build on a Pi 4 and thought I'd add some feedback/new bugs...
update.sh
expects the last entry in Release files to be SHA256 - but some now have SHA512, so verification fails. A fix is [...]
Thanks for testing this PR and sharing a fix for the checksum issue.
However when it boots it fails almost immediately with
failed to execute init (error -2)
. [...] Any hints on how to debug this further?
Maybe try the installer on different storage media.
Does file
and readelf -a
output anything abnormal for the busybox binary? If you have a Pi test environment, you can try to chroot
into the initramfs and see if busybox
fails to execute there as well.
Thanks for the suggestions...
Maybe try the installer on different storage media.
I've tried this on different SD cards, and have rebuilt the image a couple of times and still get the same issue.
Does
file
andreadelf -a
output anything abnormal for the busybox binary? If you have a Pi test environment, you can try tochroot
into the initramfs and see ifbusybox
fails to execute there as well.
Nothing obviously 'wrong' with busybox - it has the same md5sum as the one installed from busybox_1.35.0-4_armhf.deb on a manually built working bookworm install, and is executable. When I strace busybox on the manual install it opens 3 libs - libc.so.6
, libresolv.so.2
and ld-linux-armhf.so.3
- all of which look to be available on the netinst boot.
file:
busybox: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=679761041ecc026e956eb0ebedee4a6d8d70b0ae, for GNU/Linux 3.2.0, stripped
readelf:
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x19930
Start of program headers: 52 (bytes into file)
Start of section headers: 852684 (bytes into file)
Flags: 0x5000400, Version5 EABI, hard-float ABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 9
Size of section headers: 40 (bytes)
Number of section headers: 28
Section header string table index: 27
I've also tried changing config.txt to have arm_64bit=0
in case it was a 32/64-bit issue, but that makes no difference.
Data corruption appears to be ruled out, at least with the busybox binary, assuming the SD cards you tried are otherwise fine.
May help to check block devices with lsblk
and mounts with mount
if you can get a bash-static
shell on the target again. You can also try to manually invoke the installer: /opt/raspberrypi-ua-netinst/install.sh
Were you able to chroot
to the netinst build and run busybox from there? Not sure if this is a dependency issue, but it may help to check the libs you mentioned: ldd /path/to/lib1 /path/to/lib2 ...
Something else I just discovered (because I was using a RPi 4): commit b651d0d clobbered the alternate Raspbian/Debian GPG processing uses the target system's filesystem for the raspbian GPG key, so the installer fails at finding the raspbian GPG key for arm64.
Hopefully this fixes #229 !