question about disk_var.sh

[Toomas Tamm]

> @Thomas L.: Can you remember why
>   https://github.com/faiproject/fai/commit/2887bb7d30d5b4517390fe21d3551c618053ff38 
>   "setup-storage: Generate conditional definitions for disk_var.sh such that
>    variables will only be set if not previously defined by users."
> was implemented? If I parse the history correctly this change has been 
> introduced with FAI 4.0 / setup_storage 1.4
> 
> @All: Who uses that feature and what is the usecase? (Why is it necessary to 
> override the generated variables?)

Here is the relevant dialogue between me (Toomas Tamm) and Michael
Tautschnig (the original author of setup-storage):

<start quotes from mail archive>

Subject: algorithm of setting BOOT_DEVICE

Toomas Tamm:
Date: Wed, 10 Nov 2010 11:51:09 +0200

Is there a human-language description of how the value of BOOT_DEVICE
gets determined in setup-storage? I tried to read the sources
(/usr/share/fai/setup-storage/Fstab.pm) but there are several pieces of
code dealing with assignment of this variable and tracking the
necessary conditions is complicated.

I would also want to know if there is a "standard" way of overriding the
decision of setup-storage (with regard to BOOT_DEVICE) for any
particular class of computers?


Michael Tautschnig:
Date: Wed, 10 Nov 2010 11:10:51 +0100

Unfortunately no, I think I never properly documented this anywhere. It should
be done, though, and probably the setup-storage man page would be the best
place. I'll try to fix this soon, but one of the core problems is that AFAIK the
version in trunk and the experimental one differ in this regard. Which version
would you be interested in?

[...]

Would you mind explaining why you'd need to override this? The reason I'm asking
is that if you have a case possibly relevant to others then we might want to add
this to setup-storage.

Anyway, overriding is utterly simple: Under the assumption that you use grub,
the only point where $BOOT_DEVICE is actually used is
files/boot/grub/menu.lst/postinst - which is part of your config space, if you
based it on the provided simple example. And of course you are free to do
whatever you like in this script...


Toomas Tamm:
Date: Wed, 10 Nov 2010 14:01:36 +0200

I am using experimental.

[...]

For the same reason I was so keen on having "preserve_always:all" not
disturb the partitioning at all: I am installing Debian onto laptops
which have been strangely partitioned by the manufacturers, and further
changed by myself with gparted, and I need to make sure that the grub
ends up at a specific location, which I may want to hand-pick for each
particular machine type.

This way I can be sure that I would not lose access to the recovery
partitions which in many cases are the primary way to revert the machine
to factory-fresh state, should anything go wrong.

[...]

I am using GRUB_PC and I think the proper place to change would be
scripts/GRUB_PC/10-setup . Right?

However, I would suggest a simple addition to provide the override: if
task_partition finds BOOT_DEVICE already assigned (eg by one of the
scripts in "class" directory), it should ignore the value generated by
setup-storage and use the user-provided value instead. Would that be
hard to implement?


Michael Tautschnig:
Date: Fri, 3 Dec 2010 22:46:55 +0100

[...]

As this assignment of values is done in the disk_var.sh file (which is sourced
in task_partition) I'll make setup-storage perform conditional assignments. This
should do the trick. Will be part of the next experimental version, which should
be available in a few hours (once I'm happy with my changes).

<end quote from mail archive>


Now, looking at my current configuration space, I see that I am not
using this feature anyway. My own SVN logs indicate that I created an
alternative solution approximately at the same time as this dialogue
took place. So, from my point of view, the patch could be reverted.

On the other hand, if properly documented, it would allow for neat
overrides of the boot and root device assignments, which could be done
in the class/* scripts.

Toomas Tamm