Missed testing

Missed testing

[Jeremiah]

I know this probably is not a popular premise but we really need to take
the time to actually test our example configurations prior to including
them in our releases.

For example if one were to go to the guixsd website and download the
current release, verify that it was correct, burn onto a DVD and attempt
to install with guix system init /etc/configuration/desktop.scm /mnt
--fallback results in the following error:

/gnu/store/729zbb84cah3wf2fcsy4h17lqxxib5q-configuration-templates/desktop.scm:23:9:
error: you may need these modules in the initrd for /dev/sda1: mptspi

hint: Try adding them to the 'initrd-modules' field of your
'operating-system' declaration, along these lines:

    (operating-system
      ;; ...
      (initrd-modules (append (list "mptspi")
                                %base-initrd-modules)))

If you think this diagnostic is inaccurate, use the '--skip-checks'
option of 'guix system'

So if I copy the code into the file, it stops recognizing users but if I
--skip-checks the system installs but boots to a guile repl

It takes a bit to find ,help works and then ,bournish only to discover
no readline (so have to type everything by hand everytime) and no tab
completion

Which would have been fine if less/more was available or that pipes (|)
worked or if cryptsetup was in the path

so I wouldn't have to type the following line:

/gnu/store/slpv4rzcmf6lfzzjlhm4d3r1pkb2cx00-cryptsetup-static-1.7.5/sbin/cryptsetup

Then I discover /dev/sda1 isn't even exist!!!

There is no documentation on how to mount and boot, let alone how to get
shepherd to prompt for credentials for the luks volume...

If nothing else we either need to include in the documentation how to
mount a luks volume and resume boot or ensure it works everytime.

-Jeremiah

Re: Missed testing

[Ricardo Wurmus]

Jeremiah@pdp10.guru writes:

> For example if one were to go to the guixsd website and download the
> current release, verify that it was correct, burn onto a DVD and attempt
> to install with guix system init /etc/configuration/desktop.scm /mnt
> --fallback results in the following error:
>
> /gnu/store/729zbb84cah3wf2fcsy4h17lqxxib5q-configuration-templates/desktop.scm:23:9:
> error: you may need these modules in the initrd for /dev/sda1: mptspi

This depends on your hardware and the modules that the kernel loaded in
response upon booting.  There is no way to have a static resource as the
example configuration reflect the modules that can be automatically
loaded by the kernel on all hardware configurations out there.

--
Ricardo

Re: Missed testing

[Jeremiah]

> This depends on your hardware and the modules that the kernel loaded in
> response upon booting.  There is no way to have a static resource as the
> example configuration reflect the modules that can be automatically
> loaded by the kernel on all hardware configurations out there.
Ok, that is fine. Now why isn't there commented out code in the example
with comments saying that?

Still not addressed is why users section stops being defined when one
copy and pastes that example text onto the configuration.

Nor the fact that luks boot with that example configuration never
prompts for the luks password and just goes to a very unhappy place and
drops the user in a guile shell to sort things out and we lack
documentation with how to deal with that case.

Users are going to hit edge cases, when we write them; we really don't
want the users to have to read 100,000+ lines of code to try to
figureout how to deal with them.

-Jeremiah

Re: Missed testing

[Danny Milosavljevic]

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

FWIW, I agree that error handling when booting the Guix system leaves a lot to
be desired.

Because of the system rollback feature it's not so bad, but we should advertise
that feature, and that ",bournish" works, before dropping into the repl.

Also, that doesn't help on initial installation which should be made much more
user-friendly.

> Still not addressed is why users section stops being defined when one
> copy and pastes that example text onto the configuration.

That sounds very strange and would be a very bad bug.

> Nor the fact that luks boot with that example configuration never
> prompts for the luks password and just goes to a very unhappy place and
> drops the user in a guile shell to sort things out and we lack
> documentation with how to deal with that case.

I'm using luks home with current guix master and it prompts for my password.

(define dayas-home (mapped-device
                         (source (uuid "531005b3-71a1-4784-aa2a-11f68682c6da"))
                         (target "dayas-home")
                         (type luks-device-mapping)))

(operating-system
  (mapped-devices (list dayas-home))
  (file-systems ...
                       (file-system
                        (device "/dev/mapper/dayas-home")
                        (mount-point "/home")
                        (type "btrfs")
                        (needed-for-boot? #f)
                        (mount? #t)
                        (check? #t)
                        (dependencies (list dayas-home)))))

> Users are going to hit edge cases, when we write them; we really don't
> want the users to have to read 100,000+ lines of code to try to
> figureout how to deal with them.

I agree.  These kind of bug reports are very useful.

I've learned to not step on the mines, but better would be to have nicer
failure modes.

I'll be so happy when the TUI installer is the default way to install Guix.
Installing Guix manually is not fun.

The installer can and should be made to automatically amend the system
config by mptspi etc.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Missed testing

[Jeremiah]

> Also, that doesn't help on initial installation which should be made
> much more user-friendly.

Fault tolerant is far more important than user-friendly because a
reliable system is far easier to make user-friendly than it is to make a
user-friendly system fault tolerant.

> That sounds very strange and would be a very bad bug.

It is a very easy to reproduce bug, simply copy the text and paste it
into the example config above the user field.

> I'm using luks home with current guix master and it prompts for my
> password.

Here is the complete procedure I followed to hit the bug:

# Steps for creating a guix vm image using qemu and guix bootstrap Image
GUIX_VERSION=0.16.0

# Step 0 get, verify and unpack guix bootstrap image
wget "https://alpha.gnu.org/gnu/guix/guixsd-install-$GUIX_VERSION.x86_64-linux.iso.xz"
wget "https://alpha.gnu.org/gnu/guix/guixsd-install-$GUIX_VERSION.x86_64-linux.iso.xz.sig"
gpg --verify "guixsd-install-$GUIX_VERSION.x86_64-linux.iso.xz.sig"
unxz -k "guixsd-usb-install-$GUIX_VERSION.x86_64-linux.xz"

# Step 1 create and starta vm disk image of appropriate format and size
qemu-img create prototype.qcow2 20G -f qcow2

# start qemu
qemu-system-x86_64 -m 1024 -smp 1 -boot menu=on -enable-kvm -drive
file=prototype.qcow2 -drive
file=guixsd-usb-install-$GUIX_VERSION.x86_64-linux

# Step 2 setup disk partitions
# Format virtual drive to have 1 large primary partition and mark it as
# bootable
echo -e "o\nn\np\n1\n\n\na\nw" | fdisk /dev/sda

# Setup encrypted volume
cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 50000 --use-random --verify-passphrase luksFormat /dev/sda1
# or if that takes too long to type:
cryptsetup -v -c aes-xts-plain64 -s 512 -h sha512 -i 50000 --use-random -y luksFormat /dev/sda1
cryptsetup open /dev/sda1 root

# Format drive to allow its use
mkfs.ext4 /dev/mapper/root

# Label the volume for guix
e2label /dev/mapper/root root

# Mount the drive
mount /dev/mapper/root /mnt

# Step 3 setup network for download of packages and source code
# turn on networking
# vmware:: eno16777736
ifconfig ens3 up
dhclient ens3

# Step 4 add tools required to make setup easier
# Set the default storage space for the setup on the drive itself
herd start cow-store /mnt/

# Step 5 replace the uuid with "/dev/sda1" and set bootloader to grub-bootloader
zile /etc/configuration/desktop.scm

# Step 6 Apply the configuration to the disk
guix system init /etc/configuration/desktop.scm /mnt --fallback

Please note the important difference that the entire drive is fully
encrypted (even grub will prompt for password to decrypt /boot)

> The installer can and should be made to automatically amend the system
> config by mptspi etc.
To the examples, that would be fine but I have concerns about guix
silently fixing configuration files.

-Jeremiah