Make network/disk boot toggle preseedable in d-i

[bugproxy]

---Problem Description---
The Ubuntu installer alters the boot order for PowerVM LPARs, which affects automated testing (using network installation). e.g, if the original boot order is network then disk in SMS, after 14.10 installation, the boot order is disk. That means automatic installation will fail, as the network won't be used to boot at all.

I already work around this on other distributions that have made the same decision by restoring the original boot order, but it seems that the Ubuntu installer's limited environment contains none of the necessary tools (nvram, nvsetenv or bootlist), so it's not possible currently.

This is mostly an request for information to Canonical on:

1) if this was intentional
2) if it's possible via preseed to not rewrite the boot order
3) if some or all of the above mentioned tools can be present in the installer

---uname output---
Linux ltcbrazos2-lp03 3.16.0-23-generic #31-Ubuntu SMP Tue Oct 21 17:55:08 UTC 2014 ppc64le GNU/Linux

Machine Type = IBM,9119-MME

---Steps to Reproduce---
 Attempt to install over the network via boot order in SMS. After successful installation, on the disk is in the boot order.

Drop to a shell in the installer and attempt to run any of the commands.

Install method: Cobbler (DHCP/HTTP)

Install disk info: N/A

Install ISO Information: 14.10 from cdimage

[Steve Langasek (vorlon)]

The behavior is certainly intentional. The expectation is that, once you finish installing Ubuntu, you want to boot Ubuntu.

I don't know whether this is something preseedable. Adam, could you look into this?

[Adam Conrad (adconrad)]

I'm not sure if it's preseedable, but probably not. I'll look into that. But you could work around it with a late command that executes nvsetenv and friends in the target.

[Adam Conrad (adconrad)]

Setting to wishlist because the late command workaround should do the trick. If you find that's not the case, give me a poke and we'll see about improving the situation.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2015-01-22 18:22 EDT-------
(In reply to comment #5)
> I'm not sure if it's preseedable, but probably not. I'll look into that.
> But you could work around it with a late command that executes nvsetenv and
> friends in the target.
>
> Setting to wishlist because the late command workaround should do the trick.
> If you find that's not the case, give me a poke and we'll see about
> improving the situation.

Yes agreed, but those commands are not present in the installer :) Instead, I have to separately store and wget a tool (in our case 'nvram') in a late command and use that to restore the boot order. These tools (or some version of them, as mentioned in the original bug: nvram, nvsetenv, bootlist) are typically available to Linux installers on Power.

-Nish

[Adam Conrad (adconrad)]

My point was that the late_command can run in the target, where the tools are available and installed, there's no reason to have the tools also in the installer environment to make this workaround go.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2015-02-23 19:11 EDT-------
(In reply to comment #7)
> My point was that the late_command can run in the target, where the tools
> are available and installed, there's no reason to have the tools also in the
> installer environment to make this workaround go.

Tomo, can you verify if you run the late command in the chroot, that we don't need to install nvram?

-Nish

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2015-02-23 19:21 EDT-------
(In reply to comment #8)
> (In reply to comment #7)
> > My point was that the late_command can run in the target, where the tools
> > are available and installed, there's no reason to have the tools also in the
> > installer environment to make this workaround go.
>
> Tomo, can you verify if you run the late command in the chroot, that we
> don't need to install nvram?

Ah now I recall!

So the issue is multifold.

We need to save off the bootorder information from before the installer runs in a preseed_early script. No tools exist at that point (nvram, etc.). So that's one problem (we manually wget it there).

Then, once install is done, we need to fix-up the boot-order. Yes, we could do this from the chroot, but then we don't have access to the data saved off in the preseed_early script. We could run a non-chroot'd command to just cp it up to the chroot and then use the system-installed nvram in the chroot. Instead, we chose to just fix the boot order outside the chroot (which again lacks the nvram command).

So, to recap:

1) We need access to the boot-order manipulation/reading tools in the preseed_early script.

2) We can either manipulate that preseed_early data in a chroot/non-chroot preseed_late script, but it's a moot point -- either we do it in the chroot using the installed tools, or we do it in a non-chroot using the tools that are required by 1).

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-03-10 02:00 EDT-------
(In reply to comment #15)
> Hello, Andrea:
> Is there any information about this defect from Canonical?
>
> * It was mirrored about December 2014.
> * Nish provided a possible fix recommendation to them about Feb 2015.
>
> Apparently without the suggested update from Canonical, we can not
> do any more work to resolve this issue from our side. With the changes
> in place in the bootloader, we might reassign this one to Josh or Anshuman.

Hi Canonical,

Do we have any updates on this bugzilla ?

Thank you.