~bitfehler/anemos

3 2

[makeimg] debugging patch failure

Details
Message ID
<D1S2IJBOTCGZ.1JP3RODHGWLHF@gnzler.io>
DKIM signature
pass
Download raw message
Hi,

first off thanks for building anemos and makeimg, i've been testing how to
transition away from a k3s stack with flux for gitops to something simpler and
better suited for my basic use-case :)

after about 2 weeks of not looking at/or running my IMGBUILD, I now run into
this:

==> Applying patches
patching file etc/inittab
Hunk #1 FAILED at 13.
1 out of 1 hunk FAILED -- saving rejects to file etc/inittab.rej
==> ERROR: Build failed
==> Cleaning up
==> Running custom cleanup script
+ cleanup
+ umount -R /home/robert/src/infra/anemos/makeimg.hFlXtMVnT
umount: /home/robert/src/infra/anemos/makeimg.hFlXtMVnT: target is busy.
+ test -n 1
+ losetup -d /dev/loop0
+ set +x
rm: cannot remove '/home/robert/src/infra/anemos/makeimg.hFlXtMVnT': Device or resource busy

i assume something has changed with alpine's /etc/inittab and the patch, which i
copied verbatim from your bitfehler-ns [1] example btw, doesn't apply anymore.

while the location of the makeimg chroot seems to still be there and the cleanup
script seems to indicate it's still used by something?, inspecting it after
makeimg exits is not helpful:

$ doas ls -la makeimg.hFlXtMVnT/
total 4
drwxr-xr-x 1 root   root      0 Jun  5 13:49 .
drwxr-xr-x 7 robert robert 3452 Jun  5 13:48 ..

[1]: https://git.sr.ht/~bitfehler/bitfehler-ns/tree/master/item/files/etc/inittab.makeimg.patch
Details
Message ID
<D1S7O1BLL9GK.301MUX4W3IW4K@gnzler.io>
In-Reply-To
<D1S2IJBOTCGZ.1JP3RODHGWLHF@gnzler.io> (view parent)
DKIM signature
pass
Download raw message
On Wed Jun 5, 2024 at 2:04 PM CEST, Robert Günzler <r@gnzler.io> wrote:
> i assume something has changed with alpine's /etc/inittab and the patch, which i
> copied verbatim from your bitfehler-ns [1] example btw, doesn't apply anymore.

i managed to debug this by inserting ls and cat calls at the start of cleanup()
this is the new patch needed to make it work:

--- inittab.orig	2022-09-05 21:53:04.021100286 +0200
+++ inittab	2022-09-05 21:52:46.877847668 +0200
@@ -13,7 +13,7 @@
 tty6::respawn:/sbin/getty 38400 tty6

 # Put a getty on the serial port
-#ttyS0::respawn:/sbin/getty -L 115200 ttyS0 vt100
+ttyS0::respawn:/sbin/getty -L 115200 ttyS0 vt100

 # Stuff to do for the 3-finger salute
 ::ctrlaltdel:/sbin/reboot


> while the location of the makeimg chroot seems to still be there and the cleanup
> script seems to indicate it's still used by something?, inspecting it after
> makeimg exits is not helpful:

i also found that this was due to my buggy cleanup(). i called the default
implementation like this and it worked fine again:

cleanup() {
	# [...] other stuff here

	mi_cleanup_root_raw "${imgroot}"
}
Details
Message ID
<B7271CE6-0C15-4D77-BBE1-1A21FE48DB8D@bitfehler.net>
In-Reply-To
<D1S7O1BLL9GK.301MUX4W3IW4K@gnzler.io> (view parent)
DKIM signature
pass
Download raw message
Edit: sneaky re-send to list w/o html, because phones...

Hey Robert,

thanks for the fixed patch, I indeed haven't deployed my servers in a while. And yes, patches breaking over time is kind of a pain right now. It can be very desirable, as you know exactly when upstream changes. But especially with anemos, the breakage sure shows at an inconvenient time...

I am currently working on better testing facilities for anemos (see the other thread), but after that I intend to do the same for makeimg. Unfortunately, I currently do not have a great idea for what to do for broken patches. I think a general "keep build environment around for debugging" might be useful. But e.g. just dumping a potentially huge file to stdout seems a little silly? I'll think harder about this once I get around to it, but if you have any ideas, feel free to let me know :)

Cheers,
Conrad
Details
Message ID
<ef612dc4-c00b-429d-a21f-1ad66edabd2b@bitfehler.net>
In-Reply-To
<D1S7O1BLL9GK.301MUX4W3IW4K@gnzler.io> (view parent)
DKIM signature
pass
Download raw message
Hey again,

for closure: I just pushed a new version (0.13.0), with two improvement 
for this. First, you can run `makeimg -k` and it will keep the build 
environment around in case of errors. But second, more to the point, I 
improved the handling of failed patches. Your specific problem would now 
result in output like this:

==> Applying patches
patching file etc/nginx/http.d/default.conf
patching file etc/inittab
Hunk #1 FAILED at 13.
1 out of 1 hunk FAILED -- saving rejects to file etc/inittab.rej
==> ERROR: The following hunks failed to apply to etc/inittab:
--- inittab.orig	2022-09-05 21:53:04.021100286 +0200
+++ inittab	2022-09-05 21:52:46.877847668 +0200
@@ -13,7 +13,7 @@
  tty6::respawn:/sbin/getty 38400 tty6

  # Put a getty on the serial port
-#ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100
+ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100

  # Stuff to do for the 3-finger salute
  ::ctrlaltdel:/sbin/reboot
==> ERROR: Content of etc/inittab where hunks failed:
tty6::respawn:/sbin/getty 38400 tty6

# Put a getty on the serial port
#ttyS0::respawn:/sbin/getty -L 115200 ttyS0 vt100

# Stuff to do for the 3-finger salute
::ctrlaltdel:/sbin/reboot
===
==> ERROR: Build failed


It takes a moment to mentally parse the output, but my hope is that this 
should be sufficient in most cases to find & fix the issue, but else 
`-k` should always help.

Thanks for nudging me to finally implement this :)

Cheers,
Conrad
Reply to thread Export thread (mbox)