Problems with 2023-05-03-raspios-bullseye built

julled commented 10 months ago

I try to build a custom image with custom stages after stage2, but stage2 has problems with some packages and also applying some patches as seen below. Has there been some changes in upstream content that the packages and the patch doesnt work anymore?

.....
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/u/usb-modeswitch/usb-modeswitch_2.6.1-1_armhf.deb  Unable to connect to raspbian.raspberrypi.org:http:
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/v/v4l-utils/v4l-utils_1.20.0-2_armhf.deb  Unable to connect to raspbian.raspberrypi.org:http:
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/x/xauth/xauth_1.1-1_armhf.deb  Unable to connect to raspbian.raspberrypi.org:http:
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/z/zip/zip_3.0-12_armhf.deb  Unable to connect to raspbian.raspberrypi.org:http:
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
[11:47:13] End /data/tmp/pi-gen40/stage2/01-sys-tweaks/00-packages
[11:47:13] Begin /data/tmp/pi-gen40/stage2/01-sys-tweaks/00-patches
Converting meta-data to version 2
Applying patch /data/tmp/pi-gen40/stage2/01-sys-tweaks/00-patches/01-useradd.diff
patching file rootfs/etc/default/useradd
Hunk #1 succeeded at 5 with fuzz 1.

Applying patch /data/tmp/pi-gen40/stage2/01-sys-tweaks/00-patches/02-swap.diff
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: jessie-stage2/rootfs/etc/dphys-swapfile
|===================================================================
|--- jessie-stage2.orig/rootfs/etc/dphys-swapfile
|+++ jessie-stage2/rootfs/etc/dphys-swapfile
--------------------------
No file to patch.  Skipping patch.
1 out of 1 hunk ignored
Patch /data/tmp/pi-gen40/stage2/01-sys-tweaks/00-patches/02-swap.diff does not apply (enforce with -f)
[11:47:13] End /data/tmp/pi-gen40/stage2/01-sys-tweaks/00-patches

XECDesign commented 10 months ago

Our nightly images are still building and I'm not seeing the same output as above.

Setting up libc-devtools (2.31-13+rpt2+rpi1+deb11u7) ...
Setting up libblockdev-crypto2:arm64 (2.25-2) ...
Setting up ssh (1:8.4p1-5+deb11u2) ...
Setting up raspinfo (20230123-1) ...
Setting up libpng-dev:arm64 (1.6.37-3) ...
Setting up libfreetype-dev:arm64 (2.10.4+dfsg-1+deb11u1) ...
Setting up libfreetype6-dev:arm64 (2.10.4+dfsg-1+deb11u1) ...
Processing triggers for mailcap (3.69) ...
Processing triggers for initramfs-tools (0.140) ...
Processing triggers for libc-bin (2.31-13+rpt2+rpi1+deb11u7) ...
Processing triggers for udev (247.3-7+deb11u4) ...
Processing triggers for dbus (1.12.28-0+deb11u1) ...
[06:18:10] End /root/pi-gen/stage2/01-sys-tweaks/00-packages
[06:18:10] Begin /root/pi-gen/stage2/01-sys-tweaks/00-patches
Converting meta-data to version 2
Applying patch /root/pi-gen/stage2/01-sys-tweaks/00-patches/01-useradd.diff
patching file rootfs/etc/default/useradd
ESC[35mHunk #1 succeeded at 5 with fuzz 1ESC[00m.

Applying patch /root/pi-gen/stage2/01-sys-tweaks/00-patches/02-swap.diff
patching file rootfs/etc/dphys-swapfile

Applying patch /root/pi-gen/stage2/01-sys-tweaks/00-patches/04-inputrc.diff
patching file rootfs/etc/inputrc

Applying patch /root/pi-gen/stage2/01-sys-tweaks/00-patches/05-path.diff
patching file rootfs/etc/login.defs
patching file rootfs/etc/profile
ESC[35mHunk #1 succeeded at 4 with fuzz 1ESC[00m.

Applying patch /root/pi-gen/stage2/01-sys-tweaks/00-patches/07-resize-init.diff
patching file rootfs/boot/cmdline.txt

Now at patch /root/pi-gen/stage2/01-sys-tweaks/00-patches/07-resize-init.diff
[06:18:11] End /root/pi-gen/stage2/01-sys-tweaks/00-patches

julled commented 10 months ago

Those are the nightly builds for that specific tag?

XECDesign commented 10 months ago

It builds the legacy image from the bullseye branch, which is only two unrelated commits ahead of that tag.

I've just let a build run from that tag and it still completed without issues.

Off the top of my head, I can't think of anything that might cause the issue you're seeing, but the errors fetching archive above that can't be a good sign.

julled commented 10 months ago

thanks @XECDesign for trying this out! I think i clearly have a problem on my side. Is there a way to access the logs of the nigthly builds? or is it a private server?

I think i went into the trouble as i realized that when trying to delete old builds / the work folder in a non-dockerized build, the machine get nonfunctional as some system ressources are mounted into the work folder. Is there a way to safely delete the folders without deleting some system ressources? i think this relates to #244

XECDesign commented 10 months ago

The logs are on an internal server. Have you checked what's going on with those .deb fetch failures? Are you able to wget those files directly?

You'd need to umount everything mounted anywhere under the work/ directory. Also check losetup -l and detach any images that may be bound to a loopback device.

Otherwise you end up running rm -rf on /sys, /proc and /dev, which puts your system in a state it really won't be happy with.

julled commented 10 months ago

The logs are on an internal server. Have you checked what's going on with those .deb fetch failures? Are you able to wget those files directly?

I checked the respecive folders on http://raspbian.raspberrypi.org/raspbian/pool/main/ and there were indeed the specific files not available.

But what i saw was that there were new built apt packages, but i think my builder tried to get the old version of those files. I saw that e.g. at libopenblas-dev, where i received the error just after that new package was released: http://raspbian.raspberrypi.org/raspbian/pool/main/o/openblas/

Maybe i was just unlucky with my built and i was just trying to built while those new files where pushed.

A recent new complete built now works.

You'd need to umount everything mounted anywhere under the work/ directory. Also check losetup -l and detach any images that may be bound to a loopback device.

Otherwise you end up running rm -rf on /sys, /proc and /dev, which puts your system in a state it really won't be happy with.

Thanks for those hints, maybe a small section in the readme could host those infos for others aswell?

XECDesign commented 10 months ago

A recent new complete built now works.

Oh good. Yeah, maybe you caught it at a time raspbian mirrors were out of sync.

Thanks for those hints, maybe a small section in the readme could host those infos for others aswell?

Definitely. An exit trap to do the appropriate cleanup would be even better. But I don't think I'll get around to it any time soon.

julled commented 10 months ago

Definitely. An exit trap to do the appropriate cleanup would be even better. But I don't think I'll get around to it any time soon.

Yes ,a exit trap sounds even better to clean things up!

RPi-Distro / pi-gen

Problems with 2023-05-03-raspios-bullseye built #712