> @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
