Re: Installer: GUIX_IMAGE as /dev/sda on some hardware?

2019-05-28 Thread Ludovic Courtès
Hello!

Giovanni Biscuolo  skribis:

> But wait! There's the /dev/disk/by-id/ tree, I did not notice it until
> now! :-)
>
> That's the solution:
>
>
>   (bootloader
> (bootloader-configuration
>   (bootloader grub-bootloader)
>   (target "/dev/disk/by-id/scsi-3600508b1001c75a3bebb04b23d19e249")
>   (keyboard-layout keyboard-layout)))
>
> I did not test this but it smells like running, if Guix devels agree I
> think Installer should adopt /dev/disk/by-id by default, sorry I'm not
> able to propose a patch for this

Ideally, we’d use an actual UUID object (or a string?) here rather than
this Linux/udev-specific idiom.  So it would look like:

  (bootloader-configuration
;; …
(target (uuid …)))

Would that work?

I believe using Guile-Parted we could map it back to a /dev name.

WDYT?

Ludo’.



Re: Installer: GUIX_IMAGE as /dev/sda on some hardware?

2019-05-26 Thread Tobias Geerinckx-Rice
[Part two, having made my train connection with 8 seconds to 
spare.]


Giovanni Biscuolo wrote:
But wait! There's the /dev/disk/by-id/ tree, I did not notice it 
until

now! :-)


Yes!  That's what I meant!  Thank you.  I'll be sure to use the 
udev terminology for this in future, it's confusing enough as it 
is.


Thanks,

T G-R


signature.asc
Description: PGP signature


Re: Installer: GUIX_IMAGE as /dev/sda on some hardware?

2019-05-26 Thread Tobias Geerinckx-Rice

Giovanni,

Giovanni Biscuolo wrote:

/dev/xdyN names have never been safe to use in this way


I'm not talking about partitions ;-)


Neither was I.  Force o' habit.  May your partitions never be in 
random order.



According my faulty memory (I cannot reproduce it now)
/dev/sd is what the Installer writes in the 
bootloader

section of config.scm:

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


  (bootloader
(bootloader-configuration
  (bootloader grub-bootloader)
  (target "/dev/sda")
  (keyboard-layout keyboard-layout)))



I didn't realise that our *installer* did this…  It shouldn't. 
Thanks for noting this.


So it's pure coincidence that grub-install on /dev/sda succeedes 
on the

whole set of machines users are installing via USB media? :-O


‘Pure coincidence’ is too loaded.  It almost always works!  But 
your original question already illustrates how ‘almost always 
works’ leads to false inductions of ‘should work’.


The odds may be hugely in your favour, but why gamble at all?

you've discovered, they aren't to be relied on, and you should 
use 
labels or UUIDs instead.


Labels and UUIDs are for volumes, not for the whole disk ;-)


…?  I must not be using the right terminology, but each drive has 
a ‘unique identifier’, and a human-readable label (if that human 
likes numbers, a lot) that isn't unique.


‘ID’ & ‘name’, then, fine, whatever we call it, my point remains 
:-P


Kind regards,

T G-R


signature.asc
Description: PGP signature


Re: Installer: GUIX_IMAGE as /dev/sda on some hardware?

2019-05-25 Thread Tobias Geerinckx-Rice

Giovanni Biscuolo wrote:

This is **very** important when installing grub, in fact grub
installation failed when instantiating my config.scm on the HP 
ProLiant

simply because it was on /dev/sda pointing to the USB media;


/dev/xdyN names have never been safe to use in this way, though. 
I guess they're fine (at your own risk…) as short identifiers 
during a single CLI session, but not across reboots.  It just 
often *happens* to work on most machines, which as we all know, is 
the most dangerous kind of working.


3. how is the USB media "relocated" to the last /dev/sd? device 
by the

installer?


It's… not?  Dev nodes & names are doled out by the kernel.  As 
you've discovered, they aren't to be relied on, and you should use 
labels or UUIDs instead.


Even if we'd pretend differently in the installer, for example 
through artificially delayed probing for usb_storage devices, 
things would still break when that lie would be exposed by adding 
a new SATA drive, or when using a different (rescue) distro, or…



1. has anyone observed a similar issue?

2. what could have caused it?


I used to own a system that scanned drives in a different order 
depending on whether or not a USB keyboard was attached.  It was 
intended as a headless system; great fun debugging that!  

I once corrupted a drive (luckily part of a RAID-1 array, but it 
was still stupid of me) because the rescue CD scanned drives in a 
different order than the distro I was used to.


My first SATA motherboard enumerated drives differently between 
cold and warm boots — but only sometimes.  I think it had 
something to do with spin-up times.


I could go on.  I often do.  Sorry.

Hoping to have scared you into using UUIDs,

T G-R


signature.asc
Description: PGP signature


Installer: GUIX_IMAGE as /dev/sda on some hardware?

2019-05-25 Thread Giovanni Biscuolo
Hello Guix!

I cannot reproduce this anymore since the machine I used is no more
under my physical control and is in production... anyway

I'm sure on a HP ProLiant DL380p Gen8 the installer image (1.0.0
version) [1] listed the USB media as /dev/sda while I've always observed
(and reproducing now on a testing machine) that it's listed as **the
last** /dev/sd? device in the list

This is **very** important when installing grub, in fact grub
installation failed when instantiating my config.scm on the HP ProLiant
simply because it was on /dev/sda pointing to the USB media; I had to
manually install grub on /dev/sdb to complete the install

A couple of questions:

1. has anyone observed a similar issue?

2. what could have caused it?

3. how is the USB media "relocated" to the last /dev/sd? device by the
installer?

Happy hacking! Gio'.


[1] the only custom thing I made was adding "vga=791" and removing
"quiet" from the kernel arguments

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature