Installer and luks support.

Installer and luks support.

[Mathieu Othacehe]

Hi Guix,

I added support for disk encryption on the wip-newt-installer
branch. The user can select the guided partitioning scheme "Guided -
entire disk with encryption" or enable encryption partition by partition
in the manual partitioning mode.

I discovered an issue that also exist in other partitioning modes, and I
don't know how to deal with it. The last step of the installer consists
in:

* Mount partitions on /mnt (depending on the result of partitioning
  step).
* Write the system configuration to /mnt/etc/config.scm
* Start cow-store service
* Run guix system init /mnt/etc/config.scm /mnt
* Unmount /mnt
* Close luks mappings ---> fail, device is busy.

It fails because at this step, the overlayfs created by cow-store is
still present. To be able to close luks, I have to:

mkdir /remove-store-overlay
mount --move /gnu/store /remove-store-overlay
herd stop cow-store
herd stop guix-daemon
kill -9 <all processes spawned after starting cow-store>
umount /remove-store-overlay

Doing so, everything is cleaned-up, and it is possible to restart the
installer and run it again (in case the previous install failed or so).

Does anyone have a better idea on how to clean-up the overlayfs of
cow-store so that everything can be closed properly?

Thanks,

Mathieu

Re: Installer and luks support.

[Ludovic Courtès]

Hello,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

> I discovered an issue that also exist in other partitioning modes, and I
> don't know how to deal with it. The last step of the installer consists
> in:
>
> * Mount partitions on /mnt (depending on the result of partitioning
>   step).
> * Write the system configuration to /mnt/etc/config.scm
> * Start cow-store service
> * Run guix system init /mnt/etc/config.scm /mnt
> * Unmount /mnt
> * Close luks mappings ---> fail, device is busy.
>
> It fails because at this step, the overlayfs created by cow-store is
> still present. To be able to close luks, I have to:
>
> mkdir /remove-store-overlay
> mount --move /gnu/store /remove-store-overlay
> herd stop cow-store
> herd stop guix-daemon
> kill -9 <all processes spawned after starting cow-store>
> umount /remove-store-overlay
>
> Doing so, everything is cleaned-up, and it is possible to restart the
> installer and run it again (in case the previous install failed or so).
>
> Does anyone have a better idea on how to clean-up the overlayfs of
> cow-store so that everything can be closed properly?

I suppose that if you run “halt” or “reboot”, everything is terminated
properly, right?  I’m not sure if you should worry beyond that; in
general, it’s reasonable to assume that people will reboot when the
installation is over, no?

Not really answering the question, but rather trying to see if we can
sidestep it altogether.  ;-)

Ludo’.

Re: Installer and luks support.

[Mathieu Othacehe]

Hey Ludo,

> I suppose that if you run “halt” or “reboot”, everything is terminated
> properly, right?  I’m not sure if you should worry beyond that; in
> general, it’s reasonable to assume that people will reboot when the
> installation is over, no?

Yes it is. My concern is when the guix system init command fails because
let's say the network went down, in that case forcing the user to reboot
and restart the install process seems painful, don't you think?

Thanks,

Mathieu

Re: Installer and luks support.

[Gábor Boskovits]

Hello Mathieu,

Mathieu Othacehe <m.othacehe@gmail.com> ezt írta (időpont: 2018. dec.
9., V, 2:15):
>
>
> Hey Ludo,
>
> > I suppose that if you run “halt” or “reboot”, everything is terminated
> > properly, right?  I’m not sure if you should worry beyond that; in
> > general, it’s reasonable to assume that people will reboot when the
> > installation is over, no?
>
> Yes it is. My concern is when the guix system init command fails because
> let's say the network went down, in that case forcing the user to reboot
> and restart the install process seems painful, don't you think?

Can't we offer here the option to retry the failed step? i.e. guix system init
in this case? I mean we have everything set up to simply retry. Does
that make sense?

>
> Thanks,
>
> Mathieu
>

g_bor

Re: Installer and luks support.

[Mathieu Othacehe]

Hi Gábor,

> Can't we offer here the option to retry the failed step? i.e. guix system init
> in this case? I mean we have everything set up to simply retry. Does
> that make sense?

Yes that could be a viable option. We could allow the user to launch
again the install command, but we cannot allow him to go back to the
installer menu and resume the process wherever.

Or, we could keep the menu active but remove some critical steps such as
"partitioning" that require umounting/closing.

What do you think?

Thanks,

Mathieu

Re: Installer and luks support.

[Gábor Boskovits]

Mathieu Othacehe <m.othacehe@gmail.com> ezt írta (időpont: 2018. dec.
9., V, 12:15):
>
>
> Hi Gábor,
>
> > Can't we offer here the option to retry the failed step? i.e. guix system init
> > in this case? I mean we have everything set up to simply retry. Does
> > that make sense?
>
> Yes that could be a viable option. We could allow the user to launch
> again the install command, but we cannot allow him to go back to the
> installer menu and resume the process wherever.
>

I believe this might be a good choice first. This seems also easier to do.

> Or, we could keep the menu active but remove some critical steps such as
> "partitioning" that require umounting/closing.
>

On the long run it would be nicer to get the dependencies and the resources
figured out, so the we can go back to whatever step we want. I mean if a step
needs a resource available, for example the mount then we can make it available
when entering that step. And when for example we repartiton the drive, then all
later steps depends on that, so we need to redo all the later steps. WDYT?

> What do you think?
>
> Thanks,
>
> Mathieu

Re: Installer and luks support.

[Ludovic Courtès]

Hi!

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>> I suppose that if you run “halt” or “reboot”, everything is terminated
>> properly, right?  I’m not sure if you should worry beyond that; in
>> general, it’s reasonable to assume that people will reboot when the
>> installation is over, no?
>
> Yes it is. My concern is when the guix system init command fails because
> let's say the network went down, in that case forcing the user to reboot
> and restart the install process seems painful, don't you think?

Good point.  Perhaps a simple hack would be to detect that /mnt is
already an overlayfs mount and in that case skip the “herd start
cow-store /mnt” step?  Would that be enough?

Ludo’.

Re: Installer and luks support.

[Mathieu Othacehe]

Hi,

> Good point.  Perhaps a simple hack would be to detect that /mnt is
> already an overlayfs mount and in that case skip the “herd start
> cow-store /mnt” step?  Would that be enough?

Nope sadly, it won't work because keeping the overlayfs prevent
from closing the luks mapping which will conflict with an eventual
different partitioning.

So unless I'm wrong, that leaves two options:

1. Find a way to close/umount everything but that sounds complex.
2. Like evoked with Gábor, allow the user to resume the installer but
remove the partitioning step and the other steps that will conflict with
this intermediate, wobbly state.

Uppon consideration, I'm not fond of option 2. The ideal would really
be to find a way to umount the overlay, close the luks mapping and allow
the user to resume the installer from anywhere.

Mathieu