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:
- 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.
- Unmount (Settings) does nothing: the
abmbootset device-mapper node and
its mount stay in place.
- 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
|
|
| Model |
Volla Phone Quintus |
| Android device / codename |
algiz |
| ABM device config name |
zahedan |
| ROM |
VollaOS 15 — 134-volla-15.0, Android 15, build 2026-06-01 |
| Fingerprint |
volla/algiz/algiz:15/BP1A.250505.005/134-volla-15.0:user/release-keys |
| Partition scheme |
A/B, active slot _b |
| App |
ABM 0.3.0-m0 (versionCode 3001), /system/priv-app/BootloaderManager-new |
| Second OS installed |
Ubuntu Touch (focal), 55 GiB reserved — install reported -- Successful! |
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.
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:
/dev/block/by-name/lk, whichdoes not exist on A/B devices — the partition is
lk_a/lk_b.abmbootsetdevice-mapper node andits mount stay in place.
romX.confbut never frees the space thatwas 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
algizzahedan134-volla-15.0, Android 15, build 2026-06-01volla/algiz/algiz:15/BP1A.250505.005/134-volla-15.0:user/release-keys_b0.3.0-m0(versionCode 3001),/system/priv-app/BootloaderManager-new-- Successful!Bug 1 — Update DroidBoot: opens
lkwithout slot suffixSettings → Update DroidBoot fails immediately. On-screen:
The device has no
lkpartition — only slotted ones:Expected: the bootloader partition path should honour
ro.boot.slot_suffix(
lk+ suffix), i.e.lk_bhere.Bug 2 — Unmount is a no-op
Settings → Unmount returns to the screen with no error, but nothing is
actually unmounted:
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 toa 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
VollaOSandInstall OSremain). But:/datafree space is unchanged before and after the delete (~36 GiB free of230 GiB — should be ~93 GiB).
Available space: 35.8 GiB,confirming the reservation was not returned.
abmbootsetdm container mounted at/data/misc/abm_tmp/.abm_bootset, which is unreachable without root — sothere 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
abmbootsetcontainer).Notes
-- Successful!.Dtbfield as a boot-hang workaround becausethe entry editor treats
Dtbas required (field turns red, Updatedisabled when empty).