all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Adding a menu entry on GRUB.
@ 2024-04-11 21:18 William
  2024-04-12 11:04 ` 宋文武
  0 siblings, 1 reply; 7+ messages in thread
From: William @ 2024-04-11 21:18 UTC (permalink / raw)
  To: help-guix

Hello.

I'm currently trying to add a menu entry on GRUB through the Guix
system declaration to boot another GNU+Linux system but I don't have
much clue how to do it with this setup.

The other system currently has three partitions, one for "/boot",
one for "/" and one for "/home", I tried defining a menu entry like
this:

```
(menu-entry
                     (label "GNU/Linux")
                     (device (uuid
                     "d757ca6e-ae43-41b7-bc73-7e80cd270e05" 'ext4)) 
                     (linux "/vmlinuz-linux")
                     (linux-arguments
                     '("root=UUID=da4c92d2-099f-4046-ab1d-1695860f33f0
                     rw net.ifnames=0 quiet")) 
                     (initrd "/intel-ucode.img /amd-ucode.img
                     /initramfs-linux.img"))
```

As you can see, it contains two different UUIDs, this is intended, as
one UUID is for the "/boot" partition, the other one is for the "/"
partition, I copied these values from the grub.cfg menu entry generated
by os-prober during the installation of this system, and they look the
same on the menu entry defined by Guix. 

However, this entry does not work, when I try to boot the system
from the GRUB menu, it says it couldn't find the device by UUID
"d757ca6e-ae43-41b7-bc73-7e80cd270e05", which is the "/boot" partition.

I checked and double checked if they're the right UUIDs and they are,
so the issue seems that GRUB must be aware first that this "/boot"
partition relies on the "/" partition, but on the manual I don't see
exactly how I could define that. 

Is this implemented and possible? When I tried defining a menu entry
for another operating system it did work, but that install was a single
partition.



Both GuixSD and the other operating system are installed on MBR
partitions and use the old "legacy/BIOS" bootstrap method.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Adding a menu entry on GRUB.
  2024-04-11 21:18 Adding a menu entry on GRUB William
@ 2024-04-12 11:04 ` 宋文武
  2024-04-12 15:37   ` William
  0 siblings, 1 reply; 7+ messages in thread
From: 宋文武 @ 2024-04-12 11:04 UTC (permalink / raw)
  To: William; +Cc: help-guix

William <willbilly@fedora.email> writes:

> Hello.
>
> I'm currently trying to add a menu entry on GRUB through the Guix
> system declaration to boot another GNU+Linux system but I don't have
> much clue how to do it with this setup.
>
> The other system currently has three partitions, one for "/boot",
> one for "/" and one for "/home", I tried defining a menu entry like
> this:
>
> ```
> (menu-entry
>                      (label "GNU/Linux")
>                      (device (uuid
>                      "d757ca6e-ae43-41b7-bc73-7e80cd270e05" 'ext4)) 
>                      (linux "/vmlinuz-linux")
>                      (linux-arguments
>                      '("root=UUID=da4c92d2-099f-4046-ab1d-1695860f33f0
>                      rw net.ifnames=0 quiet")) 
>                      (initrd "/intel-ucode.img /amd-ucode.img
>                      /initramfs-linux.img"))
> ```
>
> As you can see, it contains two different UUIDs, this is intended, as
> one UUID is for the "/boot" partition, the other one is for the "/"
> partition, I copied these values from the grub.cfg menu entry generated
> by os-prober during the installation of this system, and they look the
> same on the menu entry defined by Guix.

This looks fine to me.

>
> However, this entry does not work, when I try to boot the system
> from the GRUB menu, it says it couldn't find the device by UUID
> "d757ca6e-ae43-41b7-bc73-7e80cd270e05", which is the "/boot" partition.

The error seems from "search --fs-uuid --set d757ca6e-ae43-41b7-bc73-7e80cd270e05"

You can press 'c' in the GRUB to enter its command line, and then run
'ls -l' to see if it actually find a partition with the correct UUID.
Maybe the UUID reported by os-prober is wrong...


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Adding a menu entry on GRUB.
  2024-04-12 11:04 ` 宋文武
@ 2024-04-12 15:37   ` William
  2024-04-12 20:21     ` Felix Lechner via
  0 siblings, 1 reply; 7+ messages in thread
From: William @ 2024-04-12 15:37 UTC (permalink / raw)
  To: 宋文武; +Cc: help-guix

On Fri, 12 Apr 2024 19:04:31 +0800
宋文武 <iyzsong@envs.net> wrote:


> The error seems from "search --fs-uuid --set
> d757ca6e-ae43-41b7-bc73-7e80cd270e05"
> 
> You can press 'c' in the GRUB to enter its command line, and then run
> 'ls -l' to see if it actually find a partition with the correct UUID.
> Maybe the UUID reported by os-prober is wrong...

Yes, this did shine some light on what the problem might be. GRUB on
Guix reports that the partitions from the SSD that contains the other
distribution have an "unknown filesystem", and therefore it cannot
display any UUID. However, all three partitions do have an ext4
filesystem and UUIDs, I tried listing the partitions on the other
distro's GRUB and indeed it did show them properly there.

What could be causing this behavior?


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Adding a menu entry on GRUB.
  2024-04-12 15:37   ` William
@ 2024-04-12 20:21     ` Felix Lechner via
  2024-04-21 15:48       ` William
  0 siblings, 1 reply; 7+ messages in thread
From: Felix Lechner via @ 2024-04-12 20:21 UTC (permalink / raw)
  To: William, 宋文武; +Cc: help-guix

Hi William,

On Fri, Apr 12 2024, William wrote:

> What could be causing this behavior?

Maybe the GRUB module for that particular file system was not loaded (or
was not found).  Please have a look at the documentation for 'insmod'.

Kind regards
Felix


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Adding a menu entry on GRUB.
  2024-04-12 20:21     ` Felix Lechner via
@ 2024-04-21 15:48       ` William
  2024-04-22  0:53         ` Felix Lechner via
  0 siblings, 1 reply; 7+ messages in thread
From: William @ 2024-04-21 15:48 UTC (permalink / raw)
  To: Felix Lechner; +Cc: help-guix

On Fri, 12 Apr 2024 13:21:52 -0700
Felix Lechner <felix.lechner@lease-up.com> wrote:

> Hi William,
> 
> On Fri, Apr 12 2024, William wrote:
> 
> > What could be causing this behavior?  
> 
> Maybe the GRUB module for that particular file system was not loaded
> (or was not found).  Please have a look at the documentation for
> 'insmod'.
> 
> Kind regards
> Felix

Hello. 

The SSD partition table is MBR, and all three partitions contain an
ext4 filesystem. I don't see how it could be a missing module issue,
and even if it was I'm not sure which module would I have to choose
since Guix is already installed on an MBR partition table with ext4
filesystem and it boots just fine.

This looks like some sort of obscure and bizarre bug, as
everything I'm seeing tells me that the SSD filesystems should be
recognized without any issue by Guix GRUB, but they aren't.

I ran e2fsck, lsblk, blkid and fdisk on a booted system to verify
that everything is fine with these partitions, no sign of anything
unusal...


fdisk:

Disk /dev/nvme0n1: 232,89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: KINGSTON SNV2S250G                      
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xcd98d418

Device         Boot     Start       End   Sectors   Size Id Type
/dev/nvme0n1p1 *         2048   2097151   2095104  1023M 83 Linux
/dev/nvme0n1p2        2097152 197408767 195311616  93,1G 83 Linux
/dev/nvme0n1p3      197408768 488396799 290988032 138,8G 83 Linux




lsblk:

nvme1n1 
├─nvme1n1p1 ext4   1.0 d757ca6e-ae43-41b7-bc73-7e80cd270e05 
├─nvme1n1p2 ext4   1.0 da4c92d2-099f-4046-ab1d-1695860f33f0 
└─nvme1n1p3 ext4   1.0 d4fd6b3f-c46f-4ce0-9ad4-cb0b32f9b23e




blkid:

/dev/nvme1n1: PTUUID="2717697f" PTTYPE="dos"


/dev/nvme1n1p2: UUID="da4c92d2-099f-4046-ab1d-1695860f33f0"
BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="2717697f-02"


/dev/nvme1n1p3: UUID="d4fd6b3f-c46f-4ce0-9ad4-cb0b32f9b23e"
BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="2717697f-03"

/dev/nvme1n1p1: UUID="d757ca6e-ae43-41b7-bc73-7e80cd270e05"
BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="2717697f-01"




e2fsck:

nvme1n1p1
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

         389 inodes used (0.61%, out of 64000)
           2 non-contiguous files (0.5%)
           1 non-contiguous directory (0.3%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 381
       28616 blocks used (11.18%, out of 256000)
           0 bad blocks
           1 large file

         370 regular files
           9 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
           0 symbolic links (0 fast symbolic links)
           0 sockets
------------
         379 files

nvme1n1p2
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

      238335 inodes used (12.00%, out of 1986768)
         266 non-contiguous files (0.1%)
         217 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 209222/63
     3819800 blocks used (48.13%, out of 7936000)
           0 bad blocks
           2 large files

      194070 regular files
       14662 directories
           0 character device files
           0 block device files
           0 fifos
        2320 links
       29593 symbolic links (29042 fast symbolic links)
           0 sockets
------------
      240645 files

nvme1n1p3
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

       40577 inodes used (0.31%, out of 13221888)
         241 non-contiguous files (0.6%)
          47 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 40446/32
     2101091 blocks used (3.98%, out of 52856752)
           0 bad blocks
           1 large file

       36603 regular files
        3715 directories
           0 character device files
           0 block device files
           0 fifos
          12 links
         249 symbolic links (91 fast symbolic links)
           0 sockets
------------
       40579 files


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Adding a menu entry on GRUB.
  2024-04-21 15:48       ` William
@ 2024-04-22  0:53         ` Felix Lechner via
  2024-04-22 19:37           ` William
  0 siblings, 1 reply; 7+ messages in thread
From: Felix Lechner via @ 2024-04-22  0:53 UTC (permalink / raw)
  To: William; +Cc: help-guix

Hi William,

On Sun, Apr 21 2024, William wrote:

> I ran e2fsck, lsblk, blkid and fdisk on a booted system to verify that
> everything is fine with these partitions, no sign of anything
> unusal...

Are you being bitten by a new incompatibility between GRUB and the new
default options? [1] How did you create your file systems?

Kind regards
Felix

[1] https://lists.gnu.org/archive/html/guix-devel/2024-04/msg00207.html


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Adding a menu entry on GRUB.
  2024-04-22  0:53         ` Felix Lechner via
@ 2024-04-22 19:37           ` William
  0 siblings, 0 replies; 7+ messages in thread
From: William @ 2024-04-22 19:37 UTC (permalink / raw)
  To: Felix Lechner; +Cc: help-guix

On Sun, 21 Apr 2024 17:53:51 -0700
Felix Lechner <felix.lechner@lease-up.com> wrote:

> Hi William,
> 
> On Sun, Apr 21 2024, William wrote:
> 
> > I ran e2fsck, lsblk, blkid and fdisk on a booted system to verify
> > that everything is fine with these partitions, no sign of anything
> > unusal...  
> 
> Are you being bitten by a new incompatibility between GRUB and the new
> default options? [1] 
> 
> Kind regards
> Felix
> 
> [1]
> https://lists.gnu.org/archive/html/guix-devel/2024-04/msg00207.html

Hello.


Yes, this definitely looks like the root of the issue, specially since
other GRUBs I tested such as the ones from Debian or Artix are
unaffected by this issue.

> How did you create your file systems?

The filesystems were created automatically through a Calamares GUI
installer, there's a non-zero chance that the installer created a
filesystem with options that are incompatible due to this bug.

Luckily I can wait until GRUB is patched on Guix as this issue can be
circumvented by closing Guix's GRUB from command line and booting with
another GRUB I have in my machine.


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2024-04-22 19:38 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-11 21:18 Adding a menu entry on GRUB William
2024-04-12 11:04 ` 宋文武
2024-04-12 15:37   ` William
2024-04-12 20:21     ` Felix Lechner via
2024-04-21 15:48       ` William
2024-04-22  0:53         ` Felix Lechner via
2024-04-22 19:37           ` William

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.