On the road to the next release: testing the installer

On the road to the next release: testing the installer

[Tanguy LE CARROUR]

Hello Guix,

In order to test the latest installer, I went to the "latest download"
page [1] and clicked on "x86_64-linux" under "GNU Guix System on Linux"
and ended up on an error page [2]:

"""
{"error":"Could not find the requested build product."}
"""

[1]: https://guix.gnu.org/en/download/latest/
[2]: https://ci.guix.gnu.org/download/1907

If I follow the link "Build details: x86_64-linux" I end up on Cuirass
where the build output [3] is available for download.

[3]: https://ci.guix.gnu.org/download/1907

When I click, unsurprisingly, I get the same error message.

Is it the ISO that has to be tested? How can I download it?

Regards.

-- 
Tanguy

Re: On the road to the next release: testing the installer

[Tanguy LE CARROUR]

Quoting Tanguy LE CARROUR (2024-02-06 08:31:39)
> In order to test the latest installer, I went to the "latest download"
> page [1] and clicked on "x86_64-linux" under "GNU Guix System on Linux"
> and ended up on an error page [2]:
> […]
> Is it the ISO that has to be tested? How can I download it?

I guess that part of the answer to my question is "build it yourself" [1], right?!

[1]: https://guix.gnu.org/en/manual/devel/en/html_node/Building-the-Installation-Image.html

Regards.

-- 
Tanguy

Re: On the road to the next release: testing the installer

[Tanguy LE CARROUR]

Hi Guix,

Here is the report of my first attempt at reinstalling Guix System
in a reeeeally long time!


Quoting Tanguy LE CARROUR (2024-02-06 13:52:31)
> Quoting Tanguy LE CARROUR (2024-02-06 08:31:39)
> > In order to test the latest installer, I went to the "latest download"
> > page [1] and clicked on "x86_64-linux" under "GNU Guix System on Linux"
> > and ended up on an error page [2]:
> > […]
> > Is it the ISO that has to be tested? How can I download it?
> 
> I guess that part of the answer to my question is "build it yourself" [1], right?!
> 
> [1]: https://guix.gnu.org/en/manual/devel/en/html_node/Building-the-Installation-Image.html

As I was reinstalling my computer at work and I was in a bit of a hurry,
I had created 2 USB stick installers:
- 1 that I built myself from the latest master; and
- 1 that I downloaded from the website for the previous release.

I went for the full disk encryption everything on one partition!
I selected no Window Manager as I’m a happy Sway user and it’s not in
the list.

The installer completed successfully and I rebooted.

Grub asked me right away my passphrase and… it did not work! 😱
After several attempts, I figured out that the keyboard layout
was apparently set to `qwerty` even though I had selected `bépo AFNOR`
during the configuration. When I eventually typed my passphrase
in `querty` Grub started and boot my system and… I had to type the
passphrase a second time, but, fortunately this time in `bépo`!
I checked the `config.scm` and the layout was properly set in the
bootloader declaration.

I then reconfigured my `guix home` and logged back and… the script
that runs on first login failed for `XDG_RUNTIME_DIR` was not set!
I checked and `/run/user/1000` was not even present.

I was already 1 hour in and running late on something I had to do for a client
so… I decided to re-install with the installer from the previous release!
So much for testing the latest installer! 😞

I ran into the same keyboard layout with Grub, so I guess it’s a bug
that is not specific to the new installer.
I than reconfigured my system and my home and… *voilà*, I was back… home!
So, the `XDG_RUNTIME_DIR` error might be related to the current installer!?

I’ll definitively give it another try, but in less… stressful circumstances.
I’ll dedicate a spare disk and use my Thinkpad as I can easily swap the disk
without having to unscrew everything.
If this setup is as convenient as I think it should be, than I can
dedicate some time more often to testing the installer.

That’s all for me for today!

Regards,

-- 
Tanguy

Re: On the road to the next release: testing the installer

[Josselin Poiret]

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

Hi Tanguy,

Tanguy LE CARROUR <tanguy@bioneland.org> writes:

> Grub asked me right away my passphrase and… it did not work! 😱
> After several attempts, I figured out that the keyboard layout
> was apparently set to `qwerty` even though I had selected `bépo AFNOR`
> during the configuration. When I eventually typed my passphrase
> in `querty` Grub started and boot my system and… I had to type the
> passphrase a second time, but, fortunately this time in `bépo`!
> I checked the `config.scm` and the layout was properly set in the
> bootloader declaration.

We don't try to embed the required keymap in the GRUB image and load it
early on.  It shouldn't be too hard, but would require a bit of
refactoring.

> I then reconfigured my `guix home` and logged back and… the script
> that runs on first login failed for `XDG_RUNTIME_DIR` was not set!
> I checked and `/run/user/1000` was not even present.

This is usually a symptom of elogind's PAM module not running/working.
Did you use %desktop-services as a base for services?

Best,
-- 
Josselin Poiret

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

Re: On the road to the next release: testing the installer

[Romain]

Hi,

On February 10, 2024 11:35:56 AM GMT+01:00, Josselin Poiret <dev@jpoiret.xyz> wrote:
>Hi Tanguy,
>
>Tanguy LE CARROUR <tanguy@bioneland.org> writes:
>
>> Grub asked me right away my passphrase and… it did not work! 😱
>> After several attempts, I figured out that the keyboard layout
>> was apparently set to `qwerty` even though I had selected `bépo AFNOR`
>> during the configuration. When I eventually typed my passphrase
>> in `querty` Grub started and boot my system and… I had to type the
>> passphrase a second time, but, fortunately this time in `bépo`!
>> I checked the `config.scm` and the layout was properly set in the
>> bootloader declaration.
>
>We don't try to embed the required keymap in the GRUB image and load it
>early on.  It shouldn't be too hard, but would require a bit of
>refactoring.
>

I started looking at this issue as I am also using full encryption with Guix system.
If someone familiar with the grub-bootloader module would give me a few pointers, I'd be happy to work on fixing it. AFAIR, I couldn't figure out how to access to the grub configuration in the code installing the grub image on disk.

-- 
Romain

Re: On the road to the next release: testing the installer

[Josselin Poiret]

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

Hi Romain,

Romain <romain@rgarbage.fr> writes:

> Hi,
>
> On February 10, 2024 11:35:56 AM GMT+01:00, Josselin Poiret <dev@jpoiret.xyz> wrote:
>>We don't try to embed the required keymap in the GRUB image and load it
>>early on.  It shouldn't be too hard, but would require a bit of
>>refactoring.
>>
>
> I started looking at this issue as I am also using full encryption with Guix system.
> If someone familiar with the grub-bootloader module would give me a few pointers, I'd be happy to work on fixing it. AFAIR, I couldn't figure out how to access to the grub configuration in the code installing the grub image on disk.

The grub configuration is generated by make-grub-configuration in
gnu/bootloader/grub.scm.  The idea would be to add the generated
keyboard layout to the initial grub image, and make sure that
keyboard-layout-config appears first in the generated config.

Best,
-- 
Josselin Poiret

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

Keyboard layout in GRUB (Was: On the road to the next release: testing the installer)

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

[unable to locate Romain's original message]

Hi Josselin,

On Sat, Feb 10 2024, Josselin Poiret wrote:

> The idea would be to ... make sure that keyboard-layout-config appears
> first in the generated config.

I do not suffer from the issue described here but rewrote the bootloader
code locally for more flexibility (and may be able to contribute
it). Could we simply move the reference to keyboard-layout-config here
up by a few lines?  [1]

On a side note, should issues like this be discussed in bugs on
Debbugs/Mumi?

Kind regards
Felix

[1] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/bootloader/grub.scm#n515

Re: Keyboard layout in GRUB (Was: On the road to the next release: testing the installer)

[Josselin Poiret]

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

Hi Felix,

Felix Lechner <felix.lechner@lease-up.com> writes:

> I do not suffer from the issue described here but rewrote the bootloader
> code locally for more flexibility (and may be able to contribute
> it). Could we simply move the reference to keyboard-layout-config here
> up by a few lines?  [1]

We could move it up and that would solve it for people not using
encrypted /boot I believe.  However, for people using encrypted /boot,
the keymap would never be loaded instead of loaded after unlocking the
volume.  The solution for that is to embed the keymap in the GRUB image,
so that it can always be found.

I believe we don't use grub-mkimage directly for the efi case for now,
which is the command we want to use to be able to include arbitrary
files in the image, hence my comment about the code needing some
refactoring.

Best,
-- 
Josselin Poiret

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

Re: Keyboard layout in GRUB (Was: On the road to the next release: testing the installer)

[Romain]

Hello,

On February 12, 2024 11:29:37 AM GMT+01:00, Josselin Poiret <dev@jpoiret.xyz> wrote:
>Hi Felix,
>
>Felix Lechner <felix.lechner@lease-up.com> writes:
>
>> I do not suffer from the issue described here but rewrote the bootloader
>> code locally for more flexibility (and may be able to contribute
>> it). Could we simply move the reference to keyboard-layout-config here
>> up by a few lines?  [1]
>
>We could move it up and that would solve it for people not using
>encrypted /boot I believe.  

IIRC, grub doesn't take the keymap into account unless the `at_keyboard` module is loaded. It is not the case at the moment.
Also there seems to be an incompatibility between this module and some laptop keyboards (for example I have a Thinkpad X220 with libreboot/seabios payload and the keyboard stopped working after loading this module).

>I believe we don't use grub-mkimage directly for the efi case for now,
>which is the command we want to use to be able to include arbitrary
>files in the image, hence my comment about the code needing some
>refactoring.

Even in the BIOS case, as far as I understood the code, the grub image installer function doesn't have access to `bootloader-configuration` data. I think that passing it down to this function would require some changes in the way the bootloader is installed. But I might have overseen something, that I why I was hoping for someone knowledgeable to jump in the discussion :)

-- 
Romain

Re: Keyboard layout in GRUB (Was: On the road to the next release: testing the installer)

[Josselin Poiret]

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

Hi Romain,

Romain <romain@rgarbage.fr> writes:

> IIRC, grub doesn't take the keymap into account unless the `at_keyboard` module is loaded. It is not the case at the moment.
> Also there seems to be an incompatibility between this module and some laptop keyboards (for example I have a Thinkpad X220 with libreboot/seabios payload and the keyboard stopped working after loading this module).
> [...]
> Even in the BIOS case, as far as I understood the code, the grub image installer function doesn't have access to `bootloader-configuration` data. I think that passing it down to this function would require some changes in the way the bootloader is installed. But I might have overseen something, that I why I was hoping for someone knowledgeable to jump in the discussion :)

No, you're right, that's the kind of refactoring I was thinking about.
It's not conceptually hard but kind of annoying to do.  Same for the
at_keyboard module, although I'm wondering how the current situation
works for you then.

Best,
-- 
Josselin Poiret

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

Re: Keyboard layout in GRUB (Was: On the road to the next release: testing the installer)

[Romain]

Hi Josselin,

On February 13, 2024 10:35:42 AM GMT+01:00, Josselin Poiret <dev@jpoiret.xyz> wrote:
> Same for the
>at_keyboard module, although I'm wondering how the current situation
>works for you then.

As for now, the `at_keyboard` module is not loaded, only the default `console` module, with which I don't have any issue, apart from not having a localized keyboard layout.

Anyway, after grub unlocking the encrypted disk, the LUKS passphrase is then prompted from the initrd, which is properly localized.

BTW, I think that a nice feature for people using non-encrypted /boot would be to copy the kernel/unitrd files to /boot and generate the corresponding grub.cfg. This is a common behaviour in other distros (including NixOS).

Have a nice day,
Romain

Re: On the road to the next release: testing the installer

[Tanguy LE CARROUR]

Hi Romain,


Quoting Romain (2024-02-10 13:35:14)
> On February 10, 2024 11:35:56 AM GMT+01:00, Josselin Poiret <dev@jpoiret.xyz> wrote:
> >Tanguy LE CARROUR <tanguy@bioneland.org> writes:
> >
> >> Grub asked me right away my passphrase and… it did not work! 😱
> >> […]
> >
> >We don't try to embed the required keymap in the GRUB image and load it
> >early on.  It shouldn't be too hard, but would require a bit of
> >refactoring.
> 
> I started looking at this issue as I am also using full encryption with Guix system.
> If someone familiar with the grub-bootloader module would give me a few pointers, I'd be happy to work on fixing it. AFAIR, I couldn't figure out how to access to the grub configuration in the code installing the grub image on disk.

Totally out of my comfort zone, I’m afraid! 😅

But it would definitively make sense to fix that as it could scare new
comers away.


-- 
Tanguy

Re: On the road to the next release: testing the installer

[Vivien Kraus]

Le vendredi 09 février 2024 à 12:24 +0100, Tanguy LE CARROUR a écrit :
> Grub asked me right away my passphrase and… it did not work! 😱
> After several attempts, I figured out that the keyboard layout
> was apparently set to `qwerty` even though I had selected `bépo
> AFNOR`
> during the configuration. When I eventually typed my passphrase
> in `querty` Grub started and boot my system and… I had to type the
> passphrase a second time, but, fortunately this time in `bépo`!
> I checked the `config.scm` and the layout was properly set in the
> bootloader declaration.
This is unfortunate, but a known workaround is to boot and log in, then
run cryptsetup luksAddKey <the device>, then enter your passphrase (to
unlock the drive), then switch your keyboard layout to qwerty, then hit
the exact same keys, and confirm by hitting the exact same keys. So
now, you can unlock the drive with either your passphrase in a bépo
layout or your passphrase in a qwerty layout.

Re: On the road to the next release: testing the installer

[Tomas Volf]

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

On 2024-02-10 11:43:33 +0100, Vivien Kraus wrote:
> Le vendredi 09 février 2024 à 12:24 +0100, Tanguy LE CARROUR a écrit :
> > Grub asked me right away my passphrase and… it did not work! 😱
> > After several attempts, I figured out that the keyboard layout
> > was apparently set to `qwerty` even though I had selected `bépo
> > AFNOR`
> > during the configuration. When I eventually typed my passphrase
> > in `querty` Grub started and boot my system and… I had to type the
> > passphrase a second time, but, fortunately this time in `bépo`!
> > I checked the `config.scm` and the layout was properly set in the
> > bootloader declaration.
> This is unfortunate, but a known workaround is to boot and log in, then
> run cryptsetup luksAddKey <the device>, then enter your passphrase (to
> unlock the drive), then switch your keyboard layout to qwerty, then hit
> the exact same keys, and confirm by hitting the exact same keys. So
> now, you can unlock the drive with either your passphrase in a bépo
> layout or your passphrase in a qwerty layout.
>

It would probably make sense to have the second (qwerty) password in the first
key slot, to make the unlocking faster.

Or, just use the key file unlock and enter password just once (albeit it would
be the qwerty one).

Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

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

Re: On the road to the next release: testing the installer

[Tanguy LE CARROUR]

Hi Vivien,

Quoting Vivien Kraus (2024-02-10 11:43:33)
> Le vendredi 09 février 2024 à 12:24 +0100, Tanguy LE CARROUR a écrit :
> > Grub asked me right away my passphrase and… it did not work! 😱
> > After several attempts, I figured out that the keyboard layout
> > was apparently set to `qwerty` even though I had selected `bépo
> > AFNOR`
> > during the configuration. When I eventually typed my passphrase
> > in `querty` Grub started and boot my system and… I had to type the
> > passphrase a second time, but, fortunately this time in `bépo`!
> > I checked the `config.scm` and the layout was properly set in the
> > bootloader declaration.
> This is unfortunate, but a known workaround is to boot and log in, then
> run cryptsetup luksAddKey <the device>, then enter your passphrase (to
> unlock the drive), then switch your keyboard layout to qwerty, then hit
> the exact same keys, and confirm by hitting the exact same keys. So
> now, you can unlock the drive with either your passphrase in a bépo
> layout or your passphrase in a qwerty layout.

Thanks! Actually, someone suggested exactly the same thing during
the last Guix@Paris. The other options were:

- have a second Qwerty keyboard around when booting; and
- do some voodoo magic with the boot partition.

I’ll definitively give a try to the `luksAddKey` on Monday.

Regards.

-- 
Tanguy

Cuirass 1.2.0-2.7bcd3d0 (and manual): latest install image not available for download (wrong URL?)

[Giovanni Biscuolo]

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

Hello Tanguy,

IMO there is a bug in the CI UI

Tanguy LE CARROUR <tanguy@bioneland.org> writes:

> In order to test the latest installer, I went to the "latest download"
> page [1] and clicked on "x86_64-linux" under "GNU Guix System on Linux"
> and ended up on an error page [2]:
>
> """
> {"error":"Could not find the requested build product."}
> """
>
> [1]: https://guix.gnu.org/en/download/latest/

the exact URL is this one:

https://ci.guix.gnu.org/search/latest/ISO-9660?query=spec:images+status:success+system:x86_64-linux+image.iso

Looking at this results:
https://ci.guix.gnu.org/search?query=spec:images+status:success+system:x86_64-linux+image.iso

there are plenty of images succesfully built.

Unfortunately the "Build outputs" URL available in the datails page are
broken so there is no way to download them via ci.guix.gnu.org (AFAIU)

> [2]: https://ci.guix.gnu.org/download/1907

I also tested:

- https://ci.guix.gnu.org/build/3395955/details pointing to
  https://ci.guix.gnu.org/download/1927

- https://ci.guix.gnu.org/build/3267415/details pointing to
  https://ci.guix.gnu.org/download/1894

and the result is the same:

--8<---------------cut here---------------start------------->8---

{"error":"Could not find the requested build product."}

--8<---------------cut here---------------end--------------->8---

[...]

> Is it the ISO that has to be tested? How can I download it?

Unfortunately also the latest (devel) manual

https://guix.gnu.org/en/manual/devel/en/html_node/USB-Stick-and-DVD-Installation.html

now is pointing to an invalid url:

https://ftp.gnu.org/gnu/guix/guix-system-install-f29f80c.x86_64-linux.iso

I'm almost sure not so log ago it was pointing to a valid file.

Are the two issues linked of do I need to file a separate bug for the
manual?

Sorry I don't know how to help to fix it.

Best regards, Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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