Closed julled closed 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
Those are the nightly builds for that specific tag?
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.
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
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.
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?
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.
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!
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?