#40386 Reading F2FS UUIDs and labels is not supported

Message #5 received at submit@debbugs.gnu.org (full text, mbox, reply):

From: raingloom <raingloom@riseup.net>

To: bug-guix@gnu.org

Subject: guix system init can't find file system by UUID, workaround results in broken boot

Date: Thu, 2 Apr 2020 08:40:54 +0200

[Message part 1 (text/plain, inline)]

Trying to install Guix System onto an SSD using an UltraBay dock.
Config is the attached file (with slight variations in the obvious
places)

`readlink /dev/disk/by-uuid/643a215d-a30e-473b-826e-5c35de29e38f` gives
me /dev/sdb1

Yet using (uuid "643a215d-a30e-473b-826e-5c35de29e38f") results in:

```
sudo -E guix system init --no-bootloader
Configs/Guix/desktop-parametric.scm /mnt
 :( /home/raingloom/Configs/Guix/desktop-parametric.scm:50:26: error:
file system with UUID '643a215d-a30e-473b-826e-5c35de29e38f' not found
```

Switching the UUID to uppercase as in the example (thankfully) doesn't
change anything, not even the error message.

I tried using a label, same result.

I ended up using the /dev/disk/by-uuid and /dev/disk/by-id paths for
the root file system and the bootloader respectively, and that resulted
in a succesful system init, but upon trying to boot the SSD with the
other machine, I got thrown into a rescue shell, because it couldn't
find the root using that path.

**(Quick aside: there really should be a guide for using that rescue
shell. I can get around in a /bin/sh one, but this is nearly unusable.
At least autocompletion should be supported.)**

I tried modifying the --root kernel parameter from Grub, so that it
would point to /dev/sda1 directly (which is the device's name on the
other machine), but I was thrown into the rescue shell again, with the
same backtrace (with the old path replaced with /dev/sda1 of course).

Sooo, I have no idea what to do. Any tips on debugging this?

Or on reconfiguring a Guix System install that is on an external file
system? On Arch I'd just arch-chroot into it and fix it from there, but
I don't know of anything similar for Guix.

[desktop-parametric.scm (text/x-scheme, attachment)]

Message #8 received at 40386@debbugs.gnu.org (full text, mbox, reply):

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

To: raingloom <raingloom@riseup.net>

Cc: 40386@debbugs.gnu.org

Subject: Re: bug#40386: guix system init can't find file system by UUID, workaround results in broken boot

Date: Thu, 02 Apr 2020 13:00:39 +0200

Hi,

raingloom <raingloom@riseup.net> skribis:

> Trying to install Guix System onto an SSD using an UltraBay dock.
> Config is the attached file (with slight variations in the obvious
> places)
>
> `readlink /dev/disk/by-uuid/643a215d-a30e-473b-826e-5c35de29e38f` gives
> me /dev/sdb1
>
> Yet using (uuid "643a215d-a30e-473b-826e-5c35de29e38f") results in:
>
> ```
> sudo -E guix system init --no-bootloader
> Configs/Guix/desktop-parametric.scm /mnt
>  :( /home/raingloom/Configs/Guix/desktop-parametric.scm:50:26: error:
> file system with UUID '643a215d-a30e-473b-826e-5c35de29e38f' not found
> ```
>
> Switching the UUID to uppercase as in the example (thankfully) doesn't
> change anything, not even the error message.
>
> I tried using a label, same result.

What file system is on /dev/sdb1?

The code responsible for that is in (gnu build file-systems).  It
currently recognizes only some file system types: ISO9660, ext2/3/4,
Btrfs, FAT32, FAT16, and JFS.

Can you try:

  sudo guix repl
  ,use(gnu build file-systems)
  (find-partition-by-uuid (uuid "643a215d-a30e-473b-826e-5c35de29e38f"))

?

> I ended up using the /dev/disk/by-uuid and /dev/disk/by-id paths for
> the root file system and the bootloader respectively, and that resulted
> in a succesful system init, but upon trying to boot the SSD with the
> other machine, I got thrown into a rescue shell, because it couldn't
> find the root using that path.

Yes, because /dev/disk is not accessible early on.  That’s why the
manual recommends using ‘uuid’ or ‘file-system-label’.

> **(Quick aside: there really should be a guide for using that rescue
> shell. I can get around in a /bin/sh one, but this is nearly unusable.
> At least autocompletion should be supported.)**

Yes, that reminds me someone reported a serious Bournish bug on IRC.

Thanks,
Ludo’.

Message #13 received at 40386@debbugs.gnu.org (full text, mbox, reply):

From: raingloom <raingloom@riseup.net>

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

Cc: 40386@debbugs.gnu.org

Subject: F2FS support Was: bug#40386: guix system init can't find file system by UUID, workaround results in broken boot

Date: Mon, 6 Apr 2020 08:49:39 +0200

On Thu, 02 Apr 2020 13:00:39 +0200
Ludovic Courtès <ludo@gnu.org> wrote:

> Hi,
> 
> raingloom <raingloom@riseup.net> skribis:
> 
> > Trying to install Guix System onto an SSD using an UltraBay dock.
> > Config is the attached file (with slight variations in the obvious
> > places)
> >
> > `readlink /dev/disk/by-uuid/643a215d-a30e-473b-826e-5c35de29e38f`
> > gives me /dev/sdb1
> >
> > Yet using (uuid "643a215d-a30e-473b-826e-5c35de29e38f") results in:
> >
> > ```
> > sudo -E guix system init --no-bootloader
> > Configs/Guix/desktop-parametric.scm /mnt
> >  :( /home/raingloom/Configs/Guix/desktop-parametric.scm:50:26:
> > error: file system with UUID '643a215d-a30e-473b-826e-5c35de29e38f'
> > not found ```
> >
> > Switching the UUID to uppercase as in the example (thankfully)
> > doesn't change anything, not even the error message.
> >
> > I tried using a label, same result.  
> 
> What file system is on /dev/sdb1?
> 
> The code responsible for that is in (gnu build file-systems).  It
> currently recognizes only some file system types: ISO9660, ext2/3/4,
> Btrfs, FAT32, FAT16, and JFS.
> 
> Can you try:
> 
>   sudo guix repl
>   ,use(gnu build file-systems)
>   (find-partition-by-uuid (uuid
> "643a215d-a30e-473b-826e-5c35de29e38f"))
> 
> ?
> 
> > I ended up using the /dev/disk/by-uuid and /dev/disk/by-id paths for
> > the root file system and the bootloader respectively, and that
> > resulted in a succesful system init, but upon trying to boot the
> > SSD with the other machine, I got thrown into a rescue shell,
> > because it couldn't find the root using that path.  
> 
> Yes, because /dev/disk is not accessible early on.  That’s why the
> manual recommends using ‘uuid’ or ‘file-system-label’.
> 
> > **(Quick aside: there really should be a guide for using that rescue
> > shell. I can get around in a /bin/sh one, but this is nearly
> > unusable. At least autocompletion should be supported.)**  
> 
> Yes, that reminds me someone reported a serious Bournish bug on IRC.
> 
> Thanks,
> Ludo’.

It looks like the issue is that F2FS isn't supported, but I'm working
on adding support. UUID reading works, but labels still seem to be
buggy, and I'm still debugging some initrd issues, but I think I'm
close.

Message #16 received at 40386@debbugs.gnu.org (full text, mbox, reply):

From: raingloom <raingloom@riseup.net>

To: 40386@debbugs.gnu.org

Subject: guix system init can't find file system by UUID, workaround results in broken boot

Date: Thu, 21 May 2020 07:09:52 +0200

This can be closed, now that we have F2FS support.

Although maybe the error message could be better for file systems that
are not supported. Right now the use has no way to distinguish whether
`guix system` failed to find their device because they mistyped the
UUID or because it doesn't even support their file system of choice at
all.

Send a report that this bug log contains spam.