AB dies when changing labels on some partitions.

[Allan]

When trying to change name/label for some partitions, AB dies
with a 'LOAD ERROR' printed on top of existing layout.

This seem to happen for:

Data partitions
other non-bootable partitions (especially some Linux)
unformatted partitions.

Seems to have started with 1.1.0

[Ben Rietbroek]

Please be aware that a "label" that AB is able to edit
can vary between the 8-char BPB labels or 32-char LVM-labels.

Editing "labels" is also not something AB should be doing anyway...

In all fairness, AB should actually not be 'so intelligent'
as it is. Labels for disks or partitions or file-systems should
be modified with their respectative tools. Not AB.

Label editing and "bling-bling" like 'Cooper Bars' are among the
things I want to remove from future versions.

Since AB is bound to 32kB code-space, it is my opinion to let go of
some stuff like the '90-ties anti-virus and the FX-bling-bling.

What is your opinion ?

[Allan]

Replying to rousseau:

Please be aware that a "label" that AB is able to edit
can vary between the 8-char BPB labels or 32-char LVM-labels.

Editing "labels" is also not something AB should be doing anyway...

1.0.6 provided this feature, and it worked.

In all fairness, AB should actually not be 'so intelligent'
as it is. Labels for disks or partitions or file-systems should
be modified with their respectative tools. Not AB.

Well, problems seems among others to be for linux and swap and unformatted
partitions. Not sure what respective tools there are for LVM labels there.

Label editing and "bling-bling" like 'Cooper Bars' are among the
things I want to remove from future versions.

Since AB is bound to 32kB code-space, it is my opinion to let go of
some stuff like the '90-ties anti-virus and the FX-bling-bling.

What is your opinion ?

Well I agree, that eCS needs a bootmanager that is simple and works, and shows
correct driveletters (for OS/2 and eCS partitions) (Even BM never did that).

BUT it seems wrong to 'downgrade' Air-Boot to this; or rather, it seems wrong to
use the name 'Air-boot' for this. Create a new fork, with a new name for that
project (EB - eComStation Bootmanager).

I like the simple interface of BM; and I like the idea, that a bm can be configured
from within itself at boottime (no requirement to boot an OS + conf app) like AB.

So, let EB show almost like BM, with driveletters and LVM labels for all it can,
and partition labels for others, and none for partitions where it makes no sense.

The problems about labels for non bootable partitions seems to be, that AB for
standard shows all (new) partitions as bootable - and thereby in the boot menu
where others only shows what have been defined as bootable. Thats why we gets
these odd partitions with odd labels in out face.
EB might think of another scheme.

Oh, and bling bling and sounds really don't belong in EB, I agree - but AB is AB
(and it can be turned off)

[Ben Rietbroek]

Replying to yoda:

Replying to rousseau:

Please be aware that a "label" that AB is able to edit
can vary between the 8-char BPB labels or 32-char LVM-labels.

Editing "labels" is also not something AB should be doing anyway...

1.0.6 provided this feature, and it worked.

In all fairness, AB should actually not be 'so intelligent'
as it is. Labels for disks or partitions or file-systems should
be modified with their respectative tools. Not AB.

Well, problems seems among others to be for linux and swap and unformatted
partitions. Not sure what respective tools there are for LVM labels there.

So you are saying this worked for you with v1.0.6 and got broken with v1.0.7 or later ?

Label editing and "bling-bling" like 'Cooper Bars' are among the
things I want to remove from future versions.

Since AB is bound to 32kB code-space, it is my opinion to let go of
some stuff like the '90-ties anti-virus and the FX-bling-bling.

What is your opinion ?

Well I agree, that eCS needs a bootmanager that is simple and works, and shows
correct driveletters (for OS/2 and eCS partitions) (Even BM never did that).

BUT it seems wrong to 'downgrade' Air-Boot to this; or rather, it seems wrong to
use the name 'Air-boot' for this.

I agree.

Create a new fork, with a new name for that
project (EB - eComStation Bootmanager).

The v1.x line will end when a major rewrite is ready (v2).
That would maybe a good oppertunity to change the name I guess.
You name proposal seems natural, but would wronly imply it's for booting eCS only.
On the other hand, if ever eCS EFI booting will become possible, it will be part of
the EFI boot-chain and only needs to focus on booting eCS.
So I basically agree with a change of name but like to get more opinions from others.

I like the simple interface of BM; and I like the idea, that a bm can be configured
from within itself at boottime (no requirement to boot an OS + conf app) like AB.

So, let EB show almost like BM, with driveletters and LVM labels for all it can,
and partition labels for others, and none for partitions where it makes no sense.

Something like that...

The problems about labels for non bootable partitions seems to be, that AB for
standard shows all (new) partitions as bootable - and thereby in the boot menu
where others only shows what have been defined as bootable.

Excactly, that is the first action a user needs to take after a fresh AB install.

Thats why we gets
these odd partitions with odd labels in out face.

Then they installed without reading the manual which clearly states why data partitions
are shown on a fresh install. AB cannot figure out which partition is bootable and which is not.
It has no access on the file-system level. That's why the user has to filter them.
This is a one time effort at fresh AB install or when a data partition is added.

EB might think of another scheme.

It could be an idea to present the user with these filtering options when AB gets installed
for the first time. Then at next boot data partitions will not be shown because the user
pre-filtered them when installing AB for the first time. This requires some more modifications
because at installation time the AB internal partition table is not generated yet.

One could also argue that editing a label of a non-boot partition makes no sense
since it will not appear in the boot-menu once the user has correctly configured AB.
Maybe it's an idea to disable editing of a label when it is not marked bootable...

Oh, and bling bling and sounds really don't belong in EB, I agree - but AB is AB
(and it can be turned off)

Yes, but removing something like FX will free some 1400 precious track0 space.
But I agree that such a removal should not be done while the software is named AiR-BOOT.

This issue needs some more consensus of which way to go.
Renaming seems a good idea.

Addendum:
AB v1.0.6 presented the user with the SETUP screen after a fresh install.
So the user was kinda 'forced' to first filter before the Main Menu got displayed.
I changed that because since eCS v2.1, the user can install AB from the eCS installation
and blocking on the SETUP would interfere with unattended installation.

In retrospect I realize this was a quick and dirty hack.
The solution would be to reintroduce the SETUP screen on a fresh AB install,
but now after the unattended phases 1 and 2 of eCS installation have completed.

Additionally, when the user has done the first time filtering without having seen any
Boot Menu yet, label editing of data partitions will implicitly be disabled.
So in effect, the possibility of editing a label will be tied to the 'B' marker.