os/v3/puppy: 1bit-install step 7 reads the wrong Boot#### id from efibootmgr, so BootNext points at the BootManagerMenuApp

1bit-install step 7 creates the firmware entry correctly and then points BootNext and the front of
BootOrder at the wrong id: it takes the first Boot#### line of efibootmgr's output, which is an
entry that already existed, not the one it just created.

new=$(efibootmgr -c -d "$dev" -p 1 -L "1bit OS" -l '\EFI\BOOT\BOOTX64.EFI' 2>> "$LOG" |
      sed -n 's/^Boot\([0-9A-Fa-f]\{4\}\).*/\1/p' | head -1)

efibootmgr -c prints the whole (updated) list, so head -1 is Boot0000* BootManagerMenuApp, not the
new Boot0004* 1bit OS. Measured on the cycle-13 image in QEMU
(~/wt/puppy-out-c13/1bit-os-puppy.img, sha256 dcc619ff…), after 1bit-install /dev/vda --yes:

== 7/7 firmware boot entry (#709)
   Boot0000 = 1bit OS on /dev/vda, first in BootOrder, BootNext

and the firmware state it actually wrote:

BootNext: 0000
BootOrder: 0000,0004,0001,0002,0003
Boot0000* BootManagerMenuApp   FvVol(7cb8bdc9-…)/FvFile(eec25bdc-…)
Boot0004* 1bit OS              HD(1,GPT,161c120b-19a6-4032-9ab4-53c4e5c8bec3,0x800,0x100000)/\EFI\BOOT\BOOTX64.EFI

So the machine's first boot after an install lands in the UEFI boot-manager menu (which waits for input
and, headless, waits forever) instead of booting 1bit OS, and the install's own log line names the wrong
entry.

Fix: parse the id from the created entry, not from the top of the list — e.g. keep efibootmgr -c's output
and match the label with the device path this disk's ESP has (sed -n 's/^Boot$[0-9A-Fa-f]\{4\}$\* 1bit OS.*/\1/p'), or read the entry back after creation with efibootmgr -v | grep -F "$(blkid -s PARTUUID -o value "$esp")". Then efibootmgr -n / -o on that id.

Found while verifying docs/install.md (lane pi-rlk, ~/briefs/TDOCS-INSTALL.md); full transcript in
~/wt/rlk-vm/results.txt. Independent of #865 — with either defect alone the installed disk does not boot
the way the installer says it will.

docs: install 1bit OS (stick, disk, USB) and connect a client to Lemo…

Triaged at origin/main 692cfa25c. Confirmed on PR #828's branch head 5a310e89 (the file is on that branch only), and it is worse than a wrong log line: the guard cannot fire, and the code then uses the wrong id for both BootOrder and BootNext.

1bit-install.sh:183-185
  new=$(efibootmgr -c -d "$dev" -p 1 -L "1bit OS" -l '\EFI\BOOT\BOOTX64.EFI' 2>> "$LOG" |
        sed -n 's/^Boot\([0-9A-Fa-f]\{4\}\).*/\1/p' | head -1)
  [ -n "$new" ] || fail "efibootmgr could not create the 1bit OS entry (its output is in $LOG)"
1bit-install.sh:186-189
  order=$(efibootmgr 2> /dev/null | sed -n 's/^BootOrder: //p' | head -1)
  rest=$(printf '%s' "$order" | tr ',' '\n' | grep -v "^$new$" | tr '\n' ',' | sed 's/,$//')
  efibootmgr -o "$new${rest:+,$rest}" ... ; efibootmgr -n "$new" ...

Three consequences of that one head -1:

[ -n "$new" ] is unreachable as a failure. efibootmgr -c prints the whole updated list, so head -1 returns some Boot#### whenever the tool exists — a creation that failed still passes the guard with an existing id. The one place the installer cannot report a firmware problem is the step named (#709).
BootOrder is built from the same wrong id, and grep -v "^$new$" removes the pre-existing entry from rest while leaving the real 1bit OS entry in the tail — exactly the BootOrder: 0000,0004,0001,0002,0003 in the report. The new entry is present but fifth.
efibootmgr -n "$new" then makes the first boot after an install land in BootManagerMenuApp, which waits for input: headless, that is an appliance that hangs with a black screen, and the installer printed Boot$new = 1bit OS on $dev.

This is a second, independent cause of "#709 does not boot", and one readback covers both

#709 was reopened because the firmware entry was not registered; the c20 boot's entry is registered and the machine boots the wrong one. Same symptom, opposite mechanism. So #709's acceptance — "efibootmgr -v + BootOrder naming the entry after one install" — is the gate for both, and it should be one row that also checks BootNext resolves to the 1bit OS label, not just that some Boot#### exists. Do not close #709 on the entry existing; that is precisely what this bug produced.

Fix shape

Do not parse the list; read the entry back by identity after creating it, and verify against the ESP's PARTUUID rather than the label alone (a second install on another disk would collide on -L "1bit OS"):

esp_pu=$(blkid -s PARTUUID -o value "${dev}1")   # or $ESP_MOUNT's device
efibootmgr -v | sed -n "s/^Boot\([0-9A-Fa-f]\{4\}\)\* 1bit OS.*${esp_pu}.*/\1/p" | head -1

efibootmgr -v prints the device path (HD(1,GPT,161c120b-…,0x800,0x100000)/\EFI\BOOT\BOOTX64.EFI), which is stable; the unqualified -L label is not. Keep the readback as the assertion ([ -n "$new" ] then means something), and print the id with the label in the log line so the transcript shows which entry it pinned.

Next action: the same PR as #865 (both are in 1bit-install.sh, both close on #828 or a stack of it), plus the readback row shared with #709. Owner pi-os3; bucket A.

os/v3/puppy install-probe: the installed-disk leg names the issue it …

Closing note (issue keeper): closed by `#889 → 7690a8c32` — the id is now found by the two things that identify it, and the guard can finally fire

#889's title carries (closes #866); merged 11:52:22Z, closed two seconds later — during my pass, so this note comes after the fact. Verified at 7690a8c32 in os/v3/puppy/1bit-install.sh (bash -n clean):

head -1 of efibootmgr -c's whole list is gone; the entry is found again by the 1bit OS label and this disk's ESP PARTUUID (:188 blkid -s PARTUUID -o value "${dev}1", matched against the HD(1,GPT,<partuuid>,…) that efibootmgr -v prints).
the [ -n "$new" ] branch is no longer unreachable — a missing GUID now fails with the list in the log (:203-206) instead of building BootOrder from a pre-existing id.
the label-only fallback runs only when the firmware prints no HD(…,GPT,…) anywhere, and takes the last label match, which is the entry just appended (:196-199).

Not claimed: the row's acceptance is a readback after a real install — efibootmgr -v + BootNext naming the 1bit OS entry, matched on the PARTUUID rather than the label. Nobody has run it yet; it is shared with #709, and on the board it is #709's gate rather than a re-open of this one.

os/v3/puppy install-probe: the installed-disk leg names the issue it …

docs: the appliance boots as 1bit-os, and installer #866 is fixed

os/v3/puppy: init resolves pupsfs=UUID=…, so an installed disk boots (c…

docs/install: both installed-disk fixes are in main, and a dd-only st…

docs: 1bit OS is the Puppy Linux appliance, and os/mini is a CI/VM ta…

Navigation Menu

Repository navigation

os/v3/puppy: 1bit-install step 7 reads the wrong Boot#### id from efibootmgr, so BootNext points at the BootManagerMenuApp #866

This is a second, independent cause of "#709 does not boot", and one readback covers both

Fix shape

Closing note (issue keeper): closed by `#889 → 7690a8c32` — the id is now found by the two things that identify it, and the guard can finally fire

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

os/v3/puppy: 1bit-install step 7 reads the wrong Boot#### id from efibootmgr, so BootNext points at the BootManagerMenuApp #866

Description

Activity

bong-water-water-bong commented on Nov 3, 2026

This is a second, independent cause of "#709 does not boot", and one readback covers both

Fix shape

bong-water-water-bong commented on Nov 3, 2026

Closing note (issue keeper): closed by #889 → 7690a8c32 — the id is now found by the two things that identify it, and the guard can finally fire

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Closing note (issue keeper): closed by `#889 → 7690a8c32` — the id is now found by the two things that identify it, and the guard can finally fire