Closed timrowledge closed 2 weeks ago
hmm....what do you get from losetup -a
and `df' (hopefully you haven't rebooted since doing the burn)?
On 2024-10-06, at 5:58 PM, Benn @.***> wrote:
hmm....what do you get from losetup -a
nothing
and `df' (hopefully you haven't rebooted since doing the burn)?
lots pf room - it's 250gb ssd
Latest info - I tried writing the generated img using rpi imager amd it behaved the same, so I'm triple-checking with a vanilla pi imag to see if that works.
tim Rowledge; @.***; http://www.rowledge.org/tim Klingon Code Warrior:- 9) "A TRUE Klingon warrior does not comment his code!"
Dammit! Right now it looks like an actual dead Pi; first one ever! More tomorrow.
On 2024-10-06, at 5:58 PM, Benn @.***> wrote:
hmm....what do you get from losetup -a and `df' (hopefully you haven't rebooted since doing the burn)?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.
tim Rowledge; @.***; http://www.rowledge.org/tim Useful random insult:- Talks to plants on their own level.
Still wondering about that strange burn command failure. Was the burn command done on the same system that doesn't boot?
On 2024-10-06, at 7:27 PM, Benn @.***> wrote:
Still wondering about that strange burn command failure. Was the burn command done on the same system that doesn't boot?
No, the sdm builld & burn are being done on one of my Pi 5s. In case it helps, it reports
uname -a Linux goldskin 6.6.51+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.51-1+rpt2 (2024-10-01) aarch64 GNU/Linux
I just tried to boot an SD written from this problematic setup and a old Pi 3 got far enough to fall into sometihng I've never even heard of before; 'BusyBox'. Trying to exit that reports
ALERT! PARTUUID=75d6d1b4-02 does not exist
So I guess that number relates to the error message
Set new disk ID 'e0513248' on '/dev/sda' Disk identifier changed from 0x75d6d1b4 to 0xe0513248.
The partition table has been altered. Calling ioctl() to re-read partition table. Re-reading the partition table failed.: Device or resource busy The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or partx(8). Syncing disks.
Disk ID 'e0513248' set successfully with sfdisk ? Device /dev/sda is already mounted
I'll try writing the SD card from the built img file via the mac and see if that has any effect.
tim Rowledge; @.***; http://www.rowledge.org/tim Fractured Idiom:- RIGOR MORRIS - The cat is dead
Another datapoint; I notice that doing the img build leaves a complaint from 'apt'
Start 'apt upgrade' IMG '/home/tim/Documents/SDM-files/2024-07-04-raspios-bookworm-arm64.img' has 276496 1K-blocks (0.3GB, 0.3GiB) free at start of 'apt upgrade' ? apt returned an error; review /etc/sdm/apt.log umount: /mnt/sdm/boot/firmware unmounted umount: /mnt/sdm unmounted
But the 'host' Pi has no problem with an apt upgrade (just for a change!)
I did look at the /etc/sdm/apt.log and the error lines look like
Setting up wayvnc (0.8.0-rc0-1) ... Creating group 'vnc' with GID 992. Creating user 'vnc' (vnc) with UID 992 and GID 992. System has not been booted with systemd as init system (PID 1). Can't operate. Failed to connect to bus: Host is down Created symlink /etc/systemd/system/wayvnc.service.wants/wayvnc-control.service → /lib/systemd/system/wayvnc-control.service. System has not been booted with systemd as init system (PID 1). Can't operate. Failed to connect to bus: Host is down
and
Setting up bluez (5.66-1+rpt1+deb12u1) ... Installing new version of config file /etc/bluetooth/input.conf ... invoke-rc.d: could not determine current runlevel Reloading system message bus config...Failed to open connection to "system" message bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory invoke-rc.d: initscript dbus, action "force-reload" failed. invoke-rc.d: could not determine current runlevel
Processing triggers for initramfs-tools (0.142) ... update-initramfs: Generating /boot/initrd.img-6.1.0-rpi7-rpi-v8 W: Couldn't identify type of root file system for fsck hook update-initramfs: Generating /boot/initrd.img-6.1.0-rpi7-rpi-2712 W: Couldn't identify type of root file system for fsck hook
and ends with
Warning: using insecure memory! Processing triggers for libc-bin (2.36-9+rpt2+deb12u3) ... [Done]
2024-01-22 17:07:34 apt-get -qq --yes autoremove
[Done]
tim Rowledge; @.***; http://www.rowledge.org/tim Last one out, turn off the computer!
The error ? apt returned an error; review /etc/sdm/apt.log
is issued by sdm and customization is halted when apt exits with an error.
Could you provide me with the entire contents of /etc/sdm/apt.log and /etc/sdm/history for this failed run? (redacted as appropriate).
If you'd prefer to not post them here, get my email from the README.
Thanks!
On 2024-10-07, at 11:58 AM, Benn @.***> wrote:
The error ? apt returned an error; review /etc/sdm/apt.log is issued by sdm and customization is halted when apt exits with an error.
Could you provide me with the entire contents of /etc/sdm/apt.log and /etc/sdm/history for this failed run? (redacted as appropriate).
OK-
I added the build & burn scripts in use too.
The built image when written to SD via Raspberry Pi Imager on my iMac does actually work on the aforementioned alternative Pi 3. The original one is still playing dead :-(
tim Rowledge; @.***; http://www.rowledge.org/tim Strange OpCodes: CAO: Compare Apples to Oranges
Uhhh...if you sent it, I did not receive. Outlook.com has much stricter spam checking than previously. Did you zip everything up?
I've had the exact same error and it seems to improve when I format the SSD card first, but I'm not 100% sure yet.
Please make sure that the burn device is dismounted before starting the burn. The check in sdm for this is broken at the moment, will be fixed in the next release later this month.
Alright, thank you
The check for device mounted is corrected in sdm V13.0. Closing this issue due to no activity.
After the fun of the failing update problem I attempted a re-run of an SDM build & burn, reusing my scripts from last time.
The burn seems to fail; the output is - ` ./sdm-burn.sh Pi-Top2
The partition table has been altered. Calling ioctl() to re-read partition table. Re-reading the partition table failed.: Device or resource busy The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or partx(8). Syncing disks.
The symptom on the machine is that it simply sits there with a red led on the Pi. :-(