'isomarkboot' from 'aboot-0.7a' dismally fails at least on some CD images. Below is a copy of my letter from July 23rd to aboot maintainer (dhd) with a fix. This was supposed to be incorporated in the next aboot release. I do not know when this will happen. Michal michal David, there is a problem with 'isomarkboot' from aboot-0.7 and 0.7a. With 0.6b things were all right. When I tried to use it on some iso images then, depending on a compiler and/or compilation options I was getting either an infinite loop or SIGSEV. From attempts to print some values and to track things in gdb it was soon rather obvious that a stack is destroyed. After lots of teeth gnashing, tons of lost hair and time I tracked that eventually to isolib.c. It turns out that this code: char retname[de->name_len[0] + 1]; dlen = get_rock_ridge_filename(de, retname, dir); in a loop of iso_find_entry() is responsible (not always, things go haywire from time to time). The following trivial patch makes 'isomarkboot' to behave. --- aboot-0.7a/lib/isolib.c~ Tue May 2 21:58:23 2000 +++ aboot-0.7a/lib/isolib.c Sun Jul 23 18:30:18 2000 @@ -547,7 +547,8 @@ } { - char retname[de->name_len[0] + 1]; + /* char retname[de->name_len[0] + 1]; */ + char retname[256]; dlen = get_rock_ridge_filename(de, retname, dir); if (dlen) { strcpy(de->name, retname); I see with it this: # tools/isomarkboot /dev/loop0 boot/bootlx iso: Max size:321573 Log zone size:2048 iso: First datazone:35 Root inode number 71680 tools/isomarkboot: boot/bootlx is at offset 632492032 and is 82432 bytes long 'de->name_len[0]' is one byte so 'retname[256]' is wide enough always but even if one would like to risk this dynamic allocation then 'de->name_len[0]' should be cast to (unsigned int) in any case.
will be in next rawhide.