Installation

Installation

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

Hello guix!

I've just checked the installer, and I would like to propose something.

It seems to me that the current installer effort is primarily frontend
oriented.

I believe, that we could make a powerful extension to guixsd if we could do
an installation from an installation description.

I think this installation description should look like the operating-system
description we
already have.

This could make automated installations working, in an uniform way. I've
seen some efforts
on writing automated install scripts, but this could be a supported,
official way to do this.

We could even store this description, and bring some more state into the
scope of guixsd,
for example partitions could later be queried from the installation
description.

Do you think this can work?
Do you think this is a good idea?

I believe that using this tool, and hacking a bit on booting, and providing
a few services
we might be able to create a really good quality bare-metal provisioning
framework.

This is one of the perspectives, that brought my attention to guix.

[-- Attachment #2: Type: text/html, Size: 1387 bytes --]

Re: Installation

[Ludovic Courtès]

Hi Gábor,

Gábor Boskovits <boskovits@gmail.com> skribis:

> I believe, that we could make a powerful extension to guixsd if we could do
> an installation from an installation description.
>
> I think this installation description should look like the operating-system description we
> already have.

In what way would it defer?  :-)

‘operating-system’ *is* an “installation description.”

Thanks,
Ludo’.

Re: Installation

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Gábor Boskovits <boskovits@gmail.com> skribis:
>
>> I believe, that we could make a powerful extension to guixsd if we could do
>> an installation from an installation description.
>>
>> I think this installation description should look like the operating-system description we
>> already have.
>
> In what way would it defer?  :-)
>
> ‘operating-system’ *is* an “installation description.”

I guess it would differ from what we have currently in that it would
also specify partitioning information, which is not handled by
“operating-system”.

Does it make sense to extend “operating-system” such that disk
partitioning information could be included and (*holds breath*) acted
upon automatically?

Acting on partitioning info is a little scary because it can easily lead
to data loss upon reconfiguration.  Small bugs could lead to very big
problems, so maybe this should not be default behaviour.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Installation

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]

2018-01-17 16:47 GMT+01:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Ludovic Courtès <ludo@gnu.org> writes:
>
> > Gábor Boskovits <boskovits@gmail.com> skribis:
> >
> >> I believe, that we could make a powerful extension to guixsd if we
> could do
> >> an installation from an installation description.
> >>
> >> I think this installation description should look like the
> operating-system description we
> >> already have.
> >
> > In what way would it defer?  :-)
> >
> > ‘operating-system’ *is* an “installation description.”
>
> I guess it would differ from what we have currently in that it would
> also specify partitioning information, which is not handled by
> “operating-system”.
>
> Does it make sense to extend “operating-system” such that disk
> partitioning information could be included and (*holds breath*) acted
> upon automatically?
>
> Acting on partitioning info is a little scary because it can easily lead
> to data loss upon reconfiguration.  Small bugs could lead to very big
> problems, so maybe this should not be default behaviour.
>
>
Yes, partitioning information is one of the primary missing point for me.
I don't think that it should be default behaviour either. Another thing that
could be useful is secret provisioning in some form.

I am thinking of this as a base of a bare-metal provisioning framework.
We could get some ideas, what else the other tools are doing.

I guess I've also read something about guix deploy. What is the current
status of that?

One more thing: lvm really seems not to map well onto the current set of
storage primitives.
I guess that lvm support could be added more cleanly with this kind of
mapping:

Partition -> PV
Mapped device of PVs -> volume group
Partition of volume group -> LV

--
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>

[-- Attachment #2: Type: text/html, Size: 2818 bytes --]

Re: Installation

[Ludovic Courtès]

Hi,

Gábor Boskovits <boskovits@gmail.com> skribis:

> Yes, partitioning information is one of the primary missing point for me.
> I don't think that it should be default behaviour either. Another thing that
> could be useful is secret provisioning in some form.

Makes sense.

> I am thinking of this as a base of a bare-metal provisioning framework.
> We could get some ideas, what else the other tools are doing.

Indeed.

> I guess I've also read something about guix deploy. What is the current
> status of that?

Essentially there’s a ‘wip-deploy’ branch with early code and probably
mailing list discussions about how this should work.

Note however that ‘guix deploy’ is intended primarily to deal with
upgrades of existing GuixSD deployments, I think.  IOW, it’s like ‘guix
system reconfigure’ rather than ‘guix system init’.

Ludo’.

Re: Installation

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Gábor Boskovits <boskovits@gmail.com> skribis:
>>
>>> I believe, that we could make a powerful extension to guixsd if we could do
>>> an installation from an installation description.
>>>
>>> I think this installation description should look like the operating-system description we
>>> already have.
>>
>> In what way would it defer?  :-)
>>
>> ‘operating-system’ *is* an “installation description.”
>
> I guess it would differ from what we have currently in that it would
> also specify partitioning information, which is not handled by
> “operating-system”.
>
> Does it make sense to extend “operating-system” such that disk
> partitioning information could be included and (*holds breath*) acted
> upon automatically?

I suppose only ‘guix system init’ could actually use that information.

Perhaps we could have a separate partitioning description, and users
could optionally run:

  guix system init --partitioning=part.scm config.scm

?

Is it really an improvement over writing a Parted script, which is
something people can already do?

> Acting on partitioning info is a little scary because it can easily lead
> to data loss upon reconfiguration.  Small bugs could lead to very big
> problems, so maybe this should not be default behaviour.

It’s definitely scary.

Ludo’.

Re: Installation

[ng0]

[-- Attachment #1: Type: text/plain, Size: 2320 bytes --]

Ludovic Courtès transcribed 1.5K bytes:
> Ricardo Wurmus <rekado@elephly.net> skribis:
> 
> > Ludovic Courtès <ludo@gnu.org> writes:
> >
> >> Gábor Boskovits <boskovits@gmail.com> skribis:
> >>
> >>> I believe, that we could make a powerful extension to guixsd if we could do
> >>> an installation from an installation description.
> >>>
> >>> I think this installation description should look like the operating-system description we
> >>> already have.
> >>
> >> In what way would it defer?  :-)
> >>
> >> ‘operating-system’ *is* an “installation description.”
> >
> > I guess it would differ from what we have currently in that it would
> > also specify partitioning information, which is not handled by
> > “operating-system”.
> >
> > Does it make sense to extend “operating-system” such that disk
> > partitioning information could be included and (*holds breath*) acted
> > upon automatically?
> 
> I suppose only ‘guix system init’ could actually use that information.
> 
> Perhaps we could have a separate partitioning description, and users
> could optionally run:
> 
>   guix system init --partitioning=part.scm config.scm
> 
> ?
> 
> Is it really an improvement over writing a Parted script, which is
> something people can already do?

My approach is different (making a templating system around Guix that translates
a number of not yet defined language inputs into a file that can be reused by
Guix), but I think we should make use of the guix system abilities and not rely
on the fact that people could already do this with an external tool.

> > Acting on partitioning info is a little scary because it can easily lead
> > to data loss upon reconfiguration.  Small bugs could lead to very big
> > problems, so maybe this should not be default behaviour.
> 
> It’s definitely scary.

Do we have the ability to separate features, like --enable-experimental passed
to configure build Guix with certain features that might break your OS? Otoh
we already presume that people setting up GuixSD today know enough about systems
to recover from failures (which is another undocumented problem/usecase with GuixSD).

> Ludo’.
> 
> 

-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Installation

[Ricardo Wurmus]

ng0 <ng0@n0.is> writes:

> Do we have the ability to separate features, like --enable-experimental passed
> to configure build Guix with certain features that might break your
> OS?

That would be too vague to be useful.

> Otoh
> we already presume that people setting up GuixSD today know enough about systems
> to recover from failures (which is another undocumented problem/usecase with GuixSD).

I don’t think that we do.  There should not be failures that leave the
system broken.  If there are then these are bugs and should be reported.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Installation

[myglc2]

On 01/18/2018 at 16:11 Ricardo Wurmus writes:

> ng0 <ng0@n0.is> writes:
>
>> Do we have the ability to separate features, like --enable-experimental passed
>> to configure build Guix with certain features that might break your
>> OS?
>
> That would be too vague to be useful.
>
>> Otoh
>> we already presume that people setting up GuixSD today know enough about systems
>> to recover from failures (which is another undocumented problem/usecase with GuixSD).
>
> I don’t think that we do.  There should not be failures that leave the
> system broken.  If there are then these are bugs and should be reported.

I agree with Ricardo's assesment and in my experience (running
Guix/Debian and GuixSD on physical intel E3 servers for that last two
years) 'guix system reconfigure" has NEVER left my system broken.

The only times guixSD has become broken are when I physically moved the
boot drive around. Maybe this is fixed. For details see ...

http://lists.gnu.org/archive/html/guix-devel/2018-01/msg00245.html

Re: Installation

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 4452 bytes --]

ludo@gnu.org (Ludovic Courtès) writes:

> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Gábor Boskovits <boskovits@gmail.com> skribis:
>>>
>>>> I believe, that we could make a powerful extension to guixsd if we could do
>>>> an installation from an installation description.
>>>>
>>>> I think this installation description should look like the operating-system description we
>>>> already have.
>>>
>>> In what way would it defer?  :-)
>>>
>>> ‘operating-system’ *is* an “installation description.”
>>
>> I guess it would differ from what we have currently in that it would
>> also specify partitioning information, which is not handled by
>> “operating-system”.
>>
>> Does it make sense to extend “operating-system” such that disk
>> partitioning information could be included and (*holds breath*) acted
>> upon automatically?
>
> I suppose only ‘guix system init’ could actually use that information.
>
> Perhaps we could have a separate partitioning description, and users
> could optionally run:
>
>   guix system init --partitioning=part.scm config.scm
>
> ?
>
> Is it really an improvement over writing a Parted script, which is
> something people can already do?
>
>> Acting on partitioning info is a little scary because it can easily lead
>> to data loss upon reconfiguration.  Small bugs could lead to very big
>> problems, so maybe this should not be default behaviour.
>
> It’s definitely scary.
>
> Ludo’.

Currently, I can only imagine two possible ways this might be used:

1) Somebody wants to frequently change the hard drives, partitions,
and/or file systems in their computer(s).

2) Somebody wants to initialize the hard drives, partitions, and/or file
systems in their computer(s), but doesn't need to update it later.

In the case of (1), who really does this?  I know of no developers or
users who actually need to change these things frequently.  And when
changes to these things ARE necessary, it's usually easier to just blast
everything away and start fresh (restoring what you need from a backup
later), rather than trying to figure out the right way to safely modify
things in place.  Since changing these kinds of things on a system
that's already in use is a rare and dangerous activity, I'm not
convinced that Guix needs to provide support for this use case.

In the case of (2), anybody who frequently needs to provision systems
will probably have a use case for this, so it might make sense to add a
feature for first-time initialization only.  Maybe a company wants to
provision many GuixSD systems for employee laptops.  Maybe somebody
needs to provision many GuixSD servers in a datacenter.  I think that if
somebody really needs to do this sort of provisioning frequently,
they're probably going to implement their own custom workflow to
accomplish the task.

Can Guix add a feature to make their life easier?  Maybe.  For example,
maybe we can fields to the <operating-system> declaration which are only
acted upon by "guix system init".  The intended workflow would be: boot
a GuixSD installation image, then run "guix system init" per the manual
(perhaps via a script, or even a "guix-provisioning-service" started by
Shepherd...!), and Guix will do everything it does today to initialize
the system, but first it will also destructively initialize the hard
drives, partitions, and file systems according to what is contained in
the specified <operating-system> declaration.  THIS could be nice!

Of course, someone who is provisioning systems like this already has the
option of creating custom scripts and tools to initialize the system's
drives, partitions, and file systems, but wouldn't it be nice if Guix
could do this on their behalf, also?  If these details were all defined
in the <operating-system> declaration, then (1) the user wouldn't have
to implement those kinds of tools themselves, and (2) it would reduce the
possibility of writing an <operating-system> declaration that contains
incorrect information about disks, partitions, or file systems because
all that information would be contained in a single file.

I think the key here is that if Guix provides a way to manipulate disks,
partitions, or file systems, it should only be allowed when initializing
a new system - not reconfiguring an existing one.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Installation

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 5238 bytes --]

2018-01-22 5:38 GMT+01:00 Chris Marusich <cmmarusich@gmail.com>:

> ludo@gnu.org (Ludovic Courtès) writes:
>
> > Ricardo Wurmus <rekado@elephly.net> skribis:
> >
> >> Ludovic Courtès <ludo@gnu.org> writes:
> >>
> >>> Gábor Boskovits <boskovits@gmail.com> skribis:
> >>>
> >>>> I believe, that we could make a powerful extension to guixsd if we
> could do
> >>>> an installation from an installation description.
> >>>>
> >>>> I think this installation description should look like the
> operating-system description we
> >>>> already have.
> >>>
> >>> In what way would it defer?  :-)
> >>>
> >>> ‘operating-system’ *is* an “installation description.”
> >>
> >> I guess it would differ from what we have currently in that it would
> >> also specify partitioning information, which is not handled by
> >> “operating-system”.
> >>
> >> Does it make sense to extend “operating-system” such that disk
> >> partitioning information could be included and (*holds breath*) acted
> >> upon automatically?
> >
> > I suppose only ‘guix system init’ could actually use that information.
> >
> > Perhaps we could have a separate partitioning description, and users
> > could optionally run:
> >
> >   guix system init --partitioning=part.scm config.scm
> >
> > ?
> >
> > Is it really an improvement over writing a Parted script, which is
> > something people can already do?
> >
> >> Acting on partitioning info is a little scary because it can easily lead
> >> to data loss upon reconfiguration.  Small bugs could lead to very big
> >> problems, so maybe this should not be default behaviour.
> >
> > It’s definitely scary.
> >
> > Ludo’.
>
> Currently, I can only imagine two possible ways this might be used:
>
> 1) Somebody wants to frequently change the hard drives, partitions,
> and/or file systems in their computer(s).
>
> 2) Somebody wants to initialize the hard drives, partitions, and/or file
> systems in their computer(s), but doesn't need to update it later.
>
> In the case of (1), who really does this?  I know of no developers or
> users who actually need to change these things frequently.  And when
> changes to these things ARE necessary, it's usually easier to just blast
> everything away and start fresh (restoring what you need from a backup
> later), rather than trying to figure out the right way to safely modify
> things in place.  Since changing these kinds of things on a system
> that's already in use is a rare and dangerous activity, I'm not
> convinced that Guix needs to provide support for this use case.
>
> In the case of (2), anybody who frequently needs to provision systems
> will probably have a use case for this, so it might make sense to add a
> feature for first-time initialization only.  Maybe a company wants to
> provision many GuixSD systems for employee laptops.  Maybe somebody
> needs to provision many GuixSD servers in a datacenter.  I think that if
> somebody really needs to do this sort of provisioning frequently,
> they're probably going to implement their own custom workflow to
> accomplish the task.
>
> Can Guix add a feature to make their life easier?  Maybe.  For example,
> maybe we can fields to the <operating-system> declaration which are only
> acted upon by "guix system init".  The intended workflow would be: boot
> a GuixSD installation image, then run "guix system init" per the manual
> (perhaps via a script, or even a "guix-provisioning-service" started by
> Shepherd...!), and Guix will do everything it does today to initialize
> the system, but first it will also destructively initialize the hard
> drives, partitions, and file systems according to what is contained in
> the specified <operating-system> declaration.  THIS could be nice!
>
> Of course, someone who is provisioning systems like this already has the
> option of creating custom scripts and tools to initialize the system's
> drives, partitions, and file systems, but wouldn't it be nice if Guix
> could do this on their behalf, also?  If these details were all defined
> in the <operating-system> declaration, then (1) the user wouldn't have
> to implement those kinds of tools themselves, and (2) it would reduce the
> possibility of writing an <operating-system> declaration that contains
> incorrect information about disks, partitions, or file systems because
> all that information would be contained in a single file.
>
> I think the key here is that if Guix provides a way to manipulate disks,
> partitions, or file systems, it should only be allowed when initializing
> a new system - not reconfiguring an existing one.
>
> I agree with this. And the use case I have in mind is datacenter
infrastructure
provisioning. Usually there is no expilcit need to do this after
initialization.
If manipulation of partitions should be done later, then it can be solved
by the tools we already have. One exception that comes to my mind is
lvm and zfs/btrfs subvolume creation for vms, but that is on the vm
provisioning layer.

I would really like to see guixsd on the infrastructure layer, because the
current
situation is quite problematic.

> --
> Chris
>

[-- Attachment #2: Type: text/html, Size: 6590 bytes --]

Re: Installation

[George myglc2 Clemmer]

On 01/17/2018 at 15:35 Ludovic Courtès writes:

> Hi Gábor,
>
> Gábor Boskovits <boskovits@gmail.com> skribis:
>
>> I believe, that we could make a powerful extension to guixsd if we could do
>> an installation from an installation description.
>>
>> I think this installation description should look like the operating-system description we
>> already have.
>
> In what way would it defer?  :-)
>
> ‘operating-system’ *is* an “installation description.”

War story, FWIW: In the past I have upgraded systems from Guix/Debian
and and from GuixSD to new system disks by simply doing 'guix system
init config.scm'. I found this a lot easier than using an install
disk. The only problem I hit was that removing the original system disk
caused the boot to hang but putting it back into the original slot and
pointing the the BIOS at the new disk booted just fine from the new
disk. The behavior I observed at the time is described in bug#23072:

https://lists.gnu.org/archive/html/bug-guix/2016-03/msg00182.html

IIRC the details are: when running on a system disk (say: /dev/sda) and
installing to new disk (say: /dev/sdb) you must set the bootloader
target to /dev/sdb so the boot loader will be copied to the new system
disk. But, at least on my servers, when I remove the original system
disk, the new disk system becomes /dev/sda, and the bootloader fails.

Presumably this happens when, at boot time, the previously specified
target no longer matches the current deviceID of the actual boot device.
I am actively interested in perfecting my understanging of this topic
because I am about to overhall my server configs, and plan to use the
approach again. So Ludo’, if you see faulty logic above I would love to
hear about it.

TIA - George

Drive identifiers

[Danny Milosavljevic]

> IIRC the details are: when running on a system disk (say: /dev/sda) and
> installing to new disk (say: /dev/sdb) you must set the bootloader
> target to /dev/sdb so the boot loader will be copied to the new system
            ^
            |
            +--- we could change that to enable specifying a model and
                 serial number

> disk.

> But, at least on my servers, when I remove the original system
> disk, the new disk system becomes /dev/sda, and the bootloader fails.

It does?  What error message does it fail with?  Does the grub shell still start?

I thought grub's "search" facility existed to prevent this exact scenario
(since it searches for the actual file / uuid on all drives it should be immune
to drive swapping - within reason).

It would be possible for us to find out the drive's serial number
(which should be somewhat unique and persistent):

$ udevadm info --query=all --name=/dev/sda | grep ID_SERIAL # SSD
E: ID_SERIAL=Samsung_SSD_850_EVO_1TB_S21DNXAGB15171J
E: ID_SERIAL_SHORT=S21DNXAGB15171J

$ udevadm info --query=all --name=/dev/sdb | grep ID_SERIAL # SD card in X200
E: ID_SERIAL=RICOH_R5U880FlashMedia_R5U880-00003-0:0
E: ID_SERIAL_SHORT=R5U880-00003

Maybe we could make the user specify the serial number in the operating-system
bootloader-configuration.  Installing the bootloader to the wrong
drive would be very bad otherwise.  Also, it's not exactly declarative if the
labels sda, sdb etc can move around - and reconfiguring / booting ends up like
a game of musical chairs.

Although if a drive fails and an administrator replaces it by a new drive,
one would have to change the operating-system configuration and reconfigure
(which could potentially download gigabytes of data and take hours).

Not ideal.

Maybe store the original serial number into a file on disk and make Guix
fall back to checking those in a second pass (with a warning).

(Guix could still call the bootloader's installer with the name of the
device file it found out - so it wouldn't be an involved change)

We would still have to check what happens with the hard drive emulators of
CD-ROMs - do these have a unique persistent serial number?

Re: Drive identifiers

[Danny Milosavljevic]

Modification would be:

guix/scripts/system.scm install-bootloader should resolve target, like

  if target doesn't startwith "/dev/"
    compare target with ID_SERIAL using udevinfo, return device name
  else
    as before

gnu/system/vm.scm qemu-image should resolve target likewise before calling
initialize-hard-disk.

I wonder how qemu drive serial numbers work.

https://serverfault.com/questions/318755/qemu-can-i-set-the-serial-number-on-a-virtual-scsi-device

Re: Drive identifiers

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> guix/scripts/system.scm install-bootloader should resolve target, like
>
>   if target doesn't startwith "/dev/"
>     compare target with ID_SERIAL using udevinfo, return device name
>   else
>     as before

Do GRUB, U-Boot, and co. provide a way to refer to drivers by serial
number?  If they do, perhaps we can just pass them the ‘target’ string
and let them do the right thing.

Ludo’.

Re: Drive identifiers

[Danny Milosavljevic]

Hi Ludo,

On Thu, 18 Jan 2018 11:32:11 +0100
ludo@gnu.org (Ludovic Courtès) wrote:

> Do GRUB, U-Boot, and co. provide a way to refer to drivers by serial
> number?

Not that I know of.  udev (and ID_SERIAL) is a relatively (10 years) recent invention.  I don't think there was a generic way to easily (without having a dozen different tools depending on the hardware type) get serial numbers before it.

I also don't think a bootloader would have all the necessary drivers to find that out either.

It would be nice, sure.  But once the bootloader is loaded (by the BIOS or ROM loader), it really doesn't need the whole-drive any more, just the partitions.  And those have UUIDs right inside the partition on disk.

But if bootloaders do after all support drive serial numbers I'd like to hear it :)

Re: Drive identifiers

[Danny Milosavljevic]

Even better:

Using /dev/disk/by-id , I think this already works now with no user-space changes!

  (bootloader (grub-configuration (device "/dev/disk/by-id/ata-Samsung_SSD_850_EVO_1TB_S21DNXAGB15171J")))

Reconfiguring as we speak...

Yep.  Works.

Re: Drive identifiers

[myglc2]

On 01/18/2018 at 10:29 Danny Milosavljevic writes:

>> IIRC the details are: when running on a system disk (say: /dev/sda) and
>> installing to new disk (say: /dev/sdb) you must set the bootloader
>> target to /dev/sdb so the boot loader will be copied to the new system
>             ^
>             |
>             +--- we could change that to enable specifying a model and
>                  serial number
>
>> disk.
>
>> But, at least on my servers, when I remove the original system
>> disk, the new disk system becomes /dev/sda, and the bootloader fails.
>
> It does?  What error message does it fail with?  Does the grub shell
> still start?

I am recounting what I experienced almost 2 years ago, see
bug#23072. The bug is sill open.
[...]
> Maybe we could make the user specify the serial number in the operating-system
> bootloader-configuration.  Installing the bootloader to the wrong
> drive would be very bad otherwise.  Also, it's not exactly declarative if the
> labels sda, sdb etc can move around - and reconfiguring / booting ends up like
> a game of musical chairs.

[...]

I would not recommend doing this because forcing the specification of
serial number would further complicate the system config process for all
users but provide insurance that, at best, would protect only the small
subset of users with multiple drives. IOW, it would force everybody to
buy insurance that single drive guixSD users will never need, and savvy
sysadmins won't want.

WRT multi-drive systems, the most pressing issue involves raided system
drives. (e.g, see my config below). This works great but has a HUGE
vulnerability: When the raid member holding the bootloader fails
(e.g. "/dev/nvme0n1" below) the system is unbootable. On my Debian
systems I easily fix this by duplicating the boot loader to all the raid
members. But this doesn't work on GuixSD because the bootloader is
constantly changing. So the most pressing need, IMO, is to provide a way
to maintain the bootloader on multiple targets (e.g., all the mapped
devices in "/dev/md3" below).

  ;; RAID1 root using 1 NVMe SSD + 2 HDs
  (bootloader (grub-configuration (target "/dev/nvme0n1")
				  (terminal-outputs '(console))
				  (terminal-inputs '(serial console))
				  (serial-speed 115200)				  
				  ))
  (initrd (lambda (file-systems . rest) (apply base-initrd file-systems
					       #:extra-modules '("raid1")
					       rest)))
  (mapped-devices (list (mapped-device
			 (source '("/dev/nvme0n1p1" "/dev/sda1" "/dev/sdb1"))
			 (target "/dev/md3")
			 (type raid-device-mapping))))
  (file-systems (cons (file-system
			(title 'device)
			(device "/dev/md3")
			(mount-point "/")
			(type "ext4")
			(dependencies mapped-devices))
		      %base-file-systems))
  (swap-devices '("/dev/nvme0n1p2" ))

HTH - George

Re: Drive identifiers

[Danny Milosavljevic]

> bug#23072. The bug is sill open.

From the bug report:

>>>   "clocksource: Switched to clocksource tsc"

That's a Linux kernel message - so grub is innocent.  It loaded the Linux kernel.

I recommend mounting the root by UUID, then it will be found.

> I would not recommend doing this because forcing the specification of
> serial number would further complicate the system config process for all
> users but provide insurance that, at best, would protect only the small
> subset of users with multiple drives. IOW, it would force everybody to
> buy insurance that single drive guixSD users will never need, and savvy
> sysadmins won't want.

It would just be an option.
The user could also specify the device by name.

Having a declarative specification with non-persistent
names in it is dangerous.

> WRT multi-drive systems, the most pressing issue involves raided system
> drives. (e.g, see my config below). This works great but has a HUGE
> vulnerability: When the raid member holding the bootloader fails
> So the most pressing need, IMO, is to provide a way
> to maintain the bootloader on multiple targets (e.g., all the mapped
> devices in "/dev/md3" below).

Makes sense.
Please file a bug report about it...

I think installing the bootloader on multiple devices is the easy part.

Does it also require grub.conf on multiple devices or is that part already
RAID-aware then?

Re: Drive identifiers

[myglc2]

On 01/18/2018 at 10:29 Danny Milosavljevic writes:

[...]

> Maybe we could make the user specify the serial number in the operating-system
> bootloader-configuration.  Installing the bootloader to the wrong
> drive would be very bad otherwise.  Also, it's not exactly declarative if the
> labels sda, sdb etc can move around - and reconfiguring / booting ends up like
> a game of musical chairs.
>
> Although if a drive fails and an administrator replaces it by a new drive,
> one would have to change the operating-system configuration and reconfigure
> (which could potentially download gigabytes of data and take hours).
>
> Not ideal.
>
> Maybe store the original serial number into a file on disk and make Guix
> fall back to checking those in a second pass (with a warning).
>
> (Guix could still call the bootloader's installer with the name of the
> device file it found out - so it wouldn't be an involved change)
>
> We would still have to check what happens with the hard drive emulators of
> CD-ROMs - do these have a unique persistent serial number?

Hi Danny,

I commented in a separate post on requiring our users to provide the
drive SN in the config file.  Here I comment on consequences of having
the SN of a HD in a file held by that HD. IMO this is like having the
directory name in a file held by the directory. Both raise the same
issue: the file is no longer relocatable.

In our case, as you point out, this creates a new error
case. Unfortunately we can't possibly know the best way to handle
it. E.G.: If the user has created an image backup of a mission-critical
GuixSD server and if they start it on a second server as a warm-backup
and if they have forgotten to change critical identify files (say
hostname) and if this can cause both servers to become corrupted,
halting on this error might be helpful. But first we should consider how
many "ifs" I used to construct this hypothetical downside. Maybe we are
protecting against very unlikely downsides.  Second: if we halt the user
may well say, "Yep, it's an image BU", override the error, and end up in
the same fix ;-) OTOH, if our user is feverishly trying to start the
image because the primary server failed, halting hurts the user. I
expect that, in practice, the latter case will be much more likely than
the former.

HTH - George

Re: Drive identifiers

[Danny Milosavljevic]

Hi,

On Thu, 18 Jan 2018 19:43:54 -0500
myglc2@gmail.com wrote:
> Here I comment on consequences of having
> the SN of a HD in a file held by that HD. IMO this is like having the
> directory name in a file held by the directory. Both raise the same
> issue: the file is no longer relocatable.
> 
> In our case, as you point out, this creates a new error
> case. Unfortunately we can't possibly know the best way to handle
> it.

Yeah, I thought about it some more and I think the best way to handle it
is to NOT store the SN in a file on disk and to not have a second pass.

If we implement it in a way that "guix system init" and
"guix system reconfigure" only resolve the SN to a device name
and then install to the device by device name it means that
even when doing a drive replacement, grub will still boot from the new drive
(because it just boots from whatever fixed device it was installed to
and doesn't care about the SN).

Once the user reconfigures guix the next time (for something unrelated maybe)
they'll get an error message because a drive with that SN is not found.

What was I thinking with the extra file?

It's better without :)

Re: Drive identifiers

[Ricardo Wurmus]

myglc2@gmail.com writes:

> On 01/18/2018 at 10:29 Danny Milosavljevic writes:
>
> [...]
>
>> Maybe we could make the user specify the serial number in the operating-system
>> bootloader-configuration.  Installing the bootloader to the wrong
>> drive would be very bad otherwise.  Also, it's not exactly declarative if the
>> labels sda, sdb etc can move around - and reconfiguring / booting ends up like
>> a game of musical chairs.
>>
>> Although if a drive fails and an administrator replaces it by a new drive,
>> one would have to change the operating-system configuration and reconfigure
>> (which could potentially download gigabytes of data and take hours).
>>
>> Not ideal.
>>
>> Maybe store the original serial number into a file on disk and make Guix
>> fall back to checking those in a second pass (with a warning).
>>
>> (Guix could still call the bootloader's installer with the name of the
>> device file it found out - so it wouldn't be an involved change)
>>
>> We would still have to check what happens with the hard drive emulators of
>> CD-ROMs - do these have a unique persistent serial number?
>
> Hi Danny,
>
> I commented in a separate post on requiring our users to provide the
> drive SN in the config file.  Here I comment on consequences of having
> the SN of a HD in a file held by that HD. IMO this is like having the
> directory name in a file held by the directory. Both raise the same
> issue: the file is no longer relocatable.
>
> In our case, as you point out, this creates a new error
> case. Unfortunately we can't possibly know the best way to handle
> it. E.G.: If the user has created an image backup of a mission-critical
> GuixSD server and if they start it on a second server as a warm-backup
> and if they have forgotten to change critical identify files (say
> hostname) and if this can cause both servers to become corrupted,
> halting on this error might be helpful.

The configuration is written in Guile, so you could run code before
returning the operating-system configuration value.

I do this in my config, because I’ve been reinstalling my system onto a
newly formatted disk:

--8<---------------cut here---------------start------------->8---
;; Get the UUID of the encrypted disk
(define %uuid
  (let* ((port (open-input-pipe "blkid -s UUID -o value /dev/sda1"))
         (str  (read-line port)))
    (close-pipe port)
    str))
…
(operating-system …
  (mapped-devices (list (mapped-device
                         (source (uuid %uuid))
                         (target "root")
                         (type luks-device-mapping))))
--8<---------------cut here---------------end--------------->8---

People who are worried about changing device identifiers when restoring
from backup could use a similar mechanism to obtain the identifier on
the target at runtime.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Drive identifiers

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> ;; Get the UUID of the encrypted disk
> (define %uuid
>   (let* ((port (open-input-pipe "blkid -s UUID -o value /dev/sda1"))
>          (str  (read-line port)))
>     (close-pipe port)
>     str))
> …
> (operating-system …
>   (mapped-devices (list (mapped-device
>                          (source (uuid %uuid))
>                          (target "root")
>                          (type luks-device-mapping))))

It’s a weird example because the idea of UUIDs is precisely to *not*
record the partition’s /dev name.  :-)

Ludo’.