Unbootable images with GuixSD on... "GuixSD"

Guix,

[I lost most hours of sleep to this. I might ramble more than usual.]

The default label for images was recently changed[1] to "GuixSD".

While I think it's a fine label, that's also a problem: I've been using

it for years for my root partitions. And when one broke last night, I

couldn't use the GuixSD installer to rescue it.

The installer's now expects exactly one "GuixSD" partition when booting

— at least on UEFI. If the GRUB finds two, the GRUB will randomly

choose. In my case, the GRUB chose a frozen system.

(With a black screen that made debugging hell, but that's probably an

unrelated effect of the roughness of our UEFI support.)

The real problem here is that we're using a label as a UUID.

From gnu/build/vm.scm:

;; Create a tiny configuration file telling the embedded grub

;; where to load the real thing.

(call-with-output-file grub-config

(lambda (port)

(format port

"insmod part_msdos~@

search --set=root --label GuixSD~@

configfile /boot/grub/grub.cfg~%")))

I'm not the first to think so, as noted in gnu/system/vm.scm:

(define root-label

;; Volume name of the root file system. Since we don't know which

device

;; will hold it, we use the volume name to find it (using the UUID would

;; be even better, but somewhat less convenient.)

(normalize-label "GuixSD"))

I like that understatement. I'm not sure how to go about creating a

reproducible almost-UUID based on the store hash and passing it to all

the right places in a reasonably non-horrible manner either, random

hacker. And it would mean even more work and testing after all the

heroic effort on the new installer image + UEFI support by Danny,

Marius, and others.

Until it does happen, I suggest we change the name to "GuixSD-image"[2].

Still fragile, but not the PR fail that ‘don't call your GuixSD file

system GuixSD or it will break GuixSD’ would be.

Zzz,

T G-R

[1]:

[2]: Or whatever. I remember someone (Danny?) calling "-image" an

implementation detail. I think it's a description of the end result.

---

Or GuixSD-bikeshed or whatever.

gnu/build/vm.scm | 7 +++++--

gnu/system/install.scm | 2 +-

gnu/system/vm.scm | 2 +-

3 files changed, 7 insertions(+), 4 deletions(-)

Hi T G-R,

On Mon, 17 Jul 2017 16:40:56 +0200

Tobias Geerinckx-Rice <me@tobias.gr> wrote:

Sorry!

I agree. Unfortunately Guix UUIDs are difficult to use consistently or I would have changed it over to begin with.

Yeah, having the UUID actually be derived from the store hash would be good.

I think for now having a random UUID be generated would be fine too.

I think for the time being that's a good workaround. But I think we should get the UUIDs for booting working.

The actual reason I had to change it is because of the dashes (which are not valid in ECMA-6 IRV).

"GuixSD_installer" ? Well anyway, just pick one, doesn't matter much which, except that the characters have to be out of [A-Za-z0-9_] (will be uppercased for ISO-9660) because of ECMA-119 Appendix A (ECMA-6 IRV).

Yeah, that was me. I don't understand how an actual operating system on a drive is an image. Maybe I'm old-fashioned, dunno, but I think an image is something that is made up by light rays on a screen, not the real object. In the case of computing an image is a backup file of a drive, not what is on the drive to begin with.

Also, even if it were an image, the image shouldn't say "<foo> image" in the image itself. A mirror which doesn't add anything to your image when you look into it, either :)

Dash is invalid. Otherwise OK!

Danny,

On 17/07/17 19:20, Danny Milosavljevic wrote:

Good to know (I consider you an expert on file system label esoterica,

mainly so I don't have to be). Thanks!

Kind regards,

T G-R

On 17/07/17 19:17, Danny Milosavljevic wrote:> Hi T G-R,

I agree completely. I've become so used to dd'ing ISOs to USB drives

that I've come to think *only* in terms of fake discs, but you're right.

I chose ‘image’ reluctantly, because my first ideas (‘installer’, ‘vm’)

were even less relevant: this label's used for all disc images. Oh well.

We could choose the worst and ugliest label possible: that'd compel

someone to fix this!

(No. "GuixSD_image" it is.)

Thanks,

T G-R

Done with commit 0862b95433cacf91e44248097caa09119fc532a6.

Kind regards,

T G-R

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Can we do ‘string-map’ to replace dash with underscore, just like we did

‘normalize-label’?

Ludo’.

Hello,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

What about generating a UUID in a deterministic yet somewhat unique

fashion along these lines (untested):

We cannot use the store file name’s hash, unfortunately, because the

UUID has to be given on the “host side.”

Thoughts?

Ludo’.

Ludo',

On 18/07/17 12:09, Ludovic Courtès wrote:

That would have been a better approach. :-)

Kind regards,

T G-R

Hi T G-R,

Hi Ludo,

On Tue, 18 Jul 2017 14:30:10 +0200

Tobias Geerinckx-Rice <me@tobias.gr> wrote:

Yes.

I disagree that that would be better. Every map is a source of error and also makes it difficult to follow what is going on (i.e. difficult to maintain).

Best is only to use the common intersection of all the valid charsets and not map anything to anything else.

We can map it and it's OK but it's not good in the long run. I've learnt that the hard way over many years.

But since we do string-upcase already, it doesn't matter anymore. Better hope we don't break it by accident one day (or right away), though.

Ludo',

On 18/07/17 13:49, Ludovic Courtès wrote:

Not great, but I can't think of a better way. :-)

Why not throw SIZE into this mix as well?

When building without ‘--image-size’ (the default nowadays), it's a

function of the exact size of the entire graph and reasonably sensitive

to most kinds of input changes.

That is unfortunate, but a best-effort heuristic will do.

Kind regards,

T G-R

Heya,

Tobias Geerinckx-Rice <me@tobias.gr> skribis:

Yup.

Because it can be the symbol 'guess or a number, so that makes things

needlessly complicated IMO.

The actual size is not known until the derivation is built; we don’t

have access to that information here.

Yeah, still better than a hard-coded label I guess.

Ludo’.

Ludo',

On 18/07/17 20:59, Ludovic Courtès wrote:

Of course. Thanks for your patience. I got completely lost in the

gexp/ungexps of expression->derivation-in-linux-vm. Stupid.

Kind regards,

T G-R

Hi Ludo,

I think it's a good interim solution.

On Tue, 18 Jul 2017 13:49:01 +0200

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

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

^^^^^^^^^^^^^^^^^^^^^^^^^^ hmm... isn't that constant?

Hi!

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Based on your feedback I’ve come up with the two attached patches. I’ve

checked at the REPL that ‘operating-system-uuid’ gives reasonable

results for different ‘operating-system’ configs, and deterministic

results for a given config (OSes that are not ‘eq?’ but that are equal.)

On ext4 “guix system disk-image” produces an image that works like a

charm.

With iso9660, it works… by chance, because GRUB’s “search --fs-uuid”

fails. Guess why? Because it compares UUIDs as strings, and we format

it as a DCE UUID instead of an ISO UUID. Sounds familiar no? :-)

So that’s where we are. Thoughts on how to address it?

Cheers,

Ludo’.

Hi Ludo,

Yeah :)

https://www.gnu.org/software/grub/manual/grub.html#Making-a-GRUB-bootable-CD_002dROMsays:

So... just leave the entire "search" instruction off if it's created by grub-mkrescue ? That's how one could interpret thir "root device" sentence...

Heya,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Oooh, interesting, that comes in handy. :-)

Now, how can we pass the information to ‘grub-configuration-file’ so

that it doesn’t emit that “search” command?

It seems that the bootloader API doesn’t leave room to pass

bootloader-specific options.

Thoughts?

Ludo’.

Hi Ludo,

On Thu, 20 Jul 2017 22:32:29 +0200

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

I can't believe I'm suggesting this (we've come full circle now) but we could add a new bootloader in gnu/bootloader/grub.scm,

(define* grub-hybrid-bootloader ; or grub-mkrescue-bootloader, maybe less misleading.

(bootloader

(inherit grub-efi-bootloader)

(configuration-file-generator grub-configuration-file-without-search-emission) ; this here could parametrize grub-configuration-file somehow or maybe we could refactor grub-configuration-file instead.

; Note: name is still 'grub-efi, so the public boot parameters API doesn't change.

(package grub-hybrid))) ; probably; or grub-efi if you just want a quick test with EFI only.

... and use it in iso9660-image or gnu/system/install.scm .

Hi Ludo,

I've gone ahead and pushed bug# 27705 to master. That means that there's now a new bootloader "grub-mkrescue-bootloader" in gnu/bootloaders/grub.scm . So you can just override its "configuration-file-generator" by one that doesn't emit the "search" command (remainder should be fine as-is).

I wonder what would happen (to Grub) if someone did guix system reconfigure in a system booted from the ISO9660 image, though. I think it would be better to not install any bootloader in the case of mkrescue and guix system reconfigure. We might want to do a follow-up commit that adds a dummy installer to the "installer" field of grub-mkrescue-bootloader. WDYT?