A/B device: "Update DroidBoot" fails (opens /dev/block/by-name/lk, ENOENT) and "Unmount" is a no-op; deleting a ROM entry never frees its space #65

Summary

On an A/B partitioned device, three related problems make it impossible to
maintain or cleanly remove a second OS from within the app:

1. Update DroidBoot crashes because it opens /dev/block/by-name/lk, which
   does not exist on A/B devices — the partition is lk_a / lk_b.
2. Unmount (Settings) does nothing: the abmbootset device-mapper node and
   its mount stay in place.
3. Deleting a ROM entry removes romX.conf but never frees the space that
   was reserved for it; the app afterwards reports the reduced free space as if
   the storage were gone.

This is on a Volla-provided build of the app (0.3.0-m0, versionCode 3001),
which I understand is downstream, but bugs 1 and 2 look generic to A/B handling
and 3 to entry deletion, so filing upstream in case they're shared.

Device

Bug 1 — Update DroidBoot: opens lk without slot suffix

Settings → Update DroidBoot fails immediately. On-screen:

Flashing DroidBoot…
Note: probably cannot write to bootloader
--- Failure ---
java.io.FileNotFoundException: /dev/block/by-name/lk: open failed: ENOENT (No such file or directory)
    at com.topjohnwu.superuser.io.SuFileInputStream.open(SuFileInputStream.java:59)
    at org.andbootmgr.app.UpdateDroidBootFlowKt$Flash$1.invokeSuspend(UpdateDroidBootFlow.kt:71)
Caused by: android.system.ErrnoException: open failed: ENOENT (No such file or directory)

The device has no lk partition — only slotted ones:

$ ls /dev/block/by-name/ | grep '^lk'
lk_a
lk_b
$ getprop ro.boot.slot_suffix
_b

Expected: the bootloader partition path should honour ro.boot.slot_suffix
(lk + suffix), i.e. lk_b here.

Bug 2 — Unmount is a no-op

Settings → Unmount returns to the screen with no error, but nothing is
actually unmounted:

$ grep abm /proc/mounts
/dev/block/mapper/abmbootset /data/misc/abm_tmp/.abm_bootset ext4 rw,seclabel,relatime 0 0
$ ls /dev/mapper/
abmbootset
control

Both remain present after tapping Unmount (and after re-entering Settings).

Bug 3 — Deleting a ROM entry leaves its space allocated and unreachable

Ubuntu Touch was installed with a 55 GiB reservation (partitions ut =
10368708608 B and ut_data = 48700238848 B, created successfully). It boots to
a black screen and hangs, so I chose to remove it.

Entries tab → open "Ubuntu Touch" → Delete. The entry disappears from both
the Entries and Unified tabs (only VollaOS and Install OS remain). But:

• /data free space is unchanged before and after the delete (~36 GiB free of
  230 GiB — should be ~93 GiB).
• The Install OS wizard afterwards reports Available space: 35.8 GiB,
  confirming the reservation was not returned.
• The reserved space lives inside the abmbootset dm container mounted at
  /data/misc/abm_tmp/.abm_bootset, which is unreachable without root — so
  there is no user-facing way to reclaim it once the entry is gone.

Expected: deleting an entry should also release the storage it reserved (or the
UI should offer a way to shrink/free the abmbootset container).

Notes

• The install itself worked: partition layout created, images flashed,
  -- Successful!.
• I could not test clearing the Dtb field as a boot-hang workaround because
  the entry editor treats Dtb as required (field turns red, Update
  disabled when empty).
• Happy to provide logs or test patches.