I have run into a problem with grub that baffles me.
Grub seems to confuse two drives in my system.

I have an 1TB M2 ssd and three sata drives.
sda is a 2TB spinning disk with 4 partitions.
sdb is a 500GB SSD with a single partition
sdc is a 2TB spinning disk with 4 partitions.

When I first configured the system I was able
to to construct a grub.cfg which allowed me
to to boot into any of the partitions.

Sometime after the initial configuration I
replaced the spinning drive sdc with a different
2TB drive with 4 nearly identical partitions.

I now find I cannot boot into partitions 2,3,4
on sdc. When I do an ls under grub it
seems to show that
sdb=hd1 and sdc=hd2 have been switched. I
see that because the ls shows that hd1 has
four partitions and hd2 has only one partition.

However, when I boot into sdb1 I get into
the correct partition, and similarly for
when I boot into sdc1.

Here is my grub.cfg:

set timeout=10
set vga=791

menuentry 'N1:k4.15.2' {
search --no-floppy --fs-uuid --set=root=UUID bc5617f6-c928-46ea-8a29-46377698cbc3
linux /boot/k4.15.2 load_ramdisk=1 root=UUID=bc5617f6-c928-46ea-8a29-46377698cbc3 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
initrd /boot/initrd.gz
}

menuentry 'N1:k64.8.10' {
search --no-floppy --fs-uuid --set=root=UUID bc5617f6-c928-46ea-8a29-46377698cbc3
linux /boot/k64.8.10 load_ramdisk=1 root=UUID=bc5617f6-c928-46ea-8a29-46377698cbc3 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
initrd /boot/initrd.gz
}

menuentry 'B1:k4.15.2' {
root='(hd1,1)'
linux /boot/k4.15.2 load_ramdisk=1 root=/dev/sdb1 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
initrd /boot/initrd.gz
}

menuentry 'A1:k4.15.2' {
#search --no-floppy --fs-uuid --set=root '(hd0,1)'
root='(hd0,1)'
linux /boot/k4.15.2 load_ramdisk=1 root=/dev/sda1 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
initrd /boot/initrd.gz
}

menuentry 'A2:k4.15.2' {
#search --no-floppy --fs-uuid --set=root '(hd0,2)'
root='(hd0,2)'
linux /boot/k4.15.2 load_ramdisk=1 root=/dev/sda2 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
initrd /boot/initrd.gz
}

menuentry 'A4:k4.15.2' {
#search --no-floppy --fs-uuid --set=root '(hd0,4)'
root='(hd0,4)'
linux /boot/vmlinuz-huge-5.13.11 load_ramdisk=1 root=/dev/sda4 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
initrd /boot/initrd.gz
}

menuentry 'C1:k4.15.2' {
#search --no-floppy --fs-uuid --set=root '(hd2,1)'
root='(hd2,1)'
linux /boot/k4.15.2 load_ramdisk=1 root=/dev/sdc1 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
initrd /boot/initrd.gz
}

#----------------the entries above boot correctly, those below do not

menuentry 'C2:k4.15.2' {
#search --no-floppy --fs-uuid --set=root '(hd2,1)'
root='(hd2,2)'
linux /boot/k4.15.2 load_ramdisk=1 root=/dev/sdc1 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
initrd /boot/initrd.gz
}

menuentry 'C3:k4.15.2' {
#search --no-floppy --fs-uuid --set=root '(hd2,1)'
root='(hd2,3)'
linux /boot/k4.15.2 load_ramdisk=1 root=/dev/sdc1 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
initrd /boot/initrd.gz
}

Attempts to boot into sdc2 or sdc3 result in a "no such partition" error from grub.

Grub does not recognize the partitions for sdc2,sdc3, or sdc4 even when I use
the uuid block ID.

It does not matter if I use grub from Slackware 14.2 or from the latest Slackware current.
I tried partitioning sdc with both gdisk and fdisk with no change in the result.

Apart from grub, linux has no problem with any of the drives in my system.

I spent about 17 hours today trying to resolve this problem. I would
appreciate any suggestions you might have.

Thanks.

On 08/18/2021 11:10 PM, root wrote:
> I have run into a problem with grub that baffles me.
> Grub seems to confuse two drives in my system.
>
> I have an 1TB M2 ssd and three sata drives.
> sda is a 2TB spinning disk with 4 partitions.
> sdb is a 500GB SSD with a single partition
> sdc is a 2TB spinning disk with 4 partitions.
>
> When I first configured the system I was able
> to to construct a grub.cfg which allowed me
> to to boot into any of the partitions.
>
> Sometime after the initial configuration I
> replaced the spinning drive sdc with a different
> 2TB drive with 4 nearly identical partitions.
>
> I now find I cannot boot into partitions 2,3,4
> on sdc. When I do an ls under grub it
> seems to show that
> sdb=hd1 and sdc=hd2 have been switched. I
> see that because the ls shows that hd1 has
> four partitions and hd2 has only one partition.
>
> However, when I boot into sdb1 I get into
> the correct partition, and similarly for
> when I boot into sdc1.
>
> Here is my grub.cfg:
>
> set timeout=10
> set vga=791
>
> menuentry 'N1:k4.15.2' {
> search --no-floppy --fs-uuid --set=root=UUID bc5617f6-c928-46ea-8a29-46377698cbc3
> linux /boot/k4.15.2 load_ramdisk=1 root=UUID=bc5617f6-c928-46ea-8a29-46377698cbc3 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
> initrd /boot/initrd.gz
> }
>
> menuentry 'N1:k64.8.10' {
> search --no-floppy --fs-uuid --set=root=UUID bc5617f6-c928-46ea-8a29-46377698cbc3
> linux /boot/k64.8.10 load_ramdisk=1 root=UUID=bc5617f6-c928-46ea-8a29-46377698cbc3 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
> initrd /boot/initrd.gz
> }
>
>
>
> menuentry 'B1:k4.15.2' {
> root='(hd1,1)'
> linux /boot/k4.15.2 load_ramdisk=1 root=/dev/sdb1 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
> initrd /boot/initrd.gz
> }
>
>
> menuentry 'A1:k4.15.2' {
> #search --no-floppy --fs-uuid --set=root '(hd0,1)'
> root='(hd0,1)'
> linux /boot/k4.15.2 load_ramdisk=1 root=/dev/sda1 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
> initrd /boot/initrd.gz
> }
>
> menuentry 'A2:k4.15.2' {
> #search --no-floppy --fs-uuid --set=root '(hd0,2)'
> root='(hd0,2)'
> linux /boot/k4.15.2 load_ramdisk=1 root=/dev/sda2 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
> initrd /boot/initrd.gz
> }
>
> menuentry 'A4:k4.15.2' {
> #search --no-floppy --fs-uuid --set=root '(hd0,4)'
> root='(hd0,4)'
> linux /boot/vmlinuz-huge-5.13.11 load_ramdisk=1 root=/dev/sda4 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
> initrd /boot/initrd.gz
> }
>
> menuentry 'C1:k4.15.2' {
> #search --no-floppy --fs-uuid --set=root '(hd2,1)'
> root='(hd2,1)'
> linux /boot/k4.15.2 load_ramdisk=1 root=/dev/sdc1 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
> initrd /boot/initrd.gz
> }
>
> #----------------the entries above boot correctly, those below do not
>
>
> menuentry 'C2:k4.15.2' {
> #search --no-floppy --fs-uuid --set=root '(hd2,1)'
> root='(hd2,2)'
> linux /boot/k4.15.2 load_ramdisk=1 root=/dev/sdc1 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
> initrd /boot/initrd.gz
> }
>
>
> menuentry 'C3:k4.15.2' {
> #search --no-floppy --fs-uuid --set=root '(hd2,1)'
> root='(hd2,3)'
> linux /boot/k4.15.2 load_ramdisk=1 root=/dev/sdc1 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
> initrd /boot/initrd.gz
> }
>
> Attempts to boot into sdc2 or sdc3 result in a "no such partition" error from grub.
>
> Grub does not recognize the partitions for sdc2,sdc3, or sdc4 even when I use
> the uuid block ID.
>
> It does not matter if I use grub from Slackware 14.2 or from the latest Slackware current.
> I tried partitioning sdc with both gdisk and fdisk with no change in the result.
>
> Apart from grub, linux has no problem with any of the drives in my system.
>
> I spent about 17 hours today trying to resolve this problem. I would
> appreciate any suggestions you might have.
>
> Thanks.

Edit /etc//fstab to use only UUID and don't use /dev/ on the system with
the problem. 'blkid' as root will give you all drives UUID.

You may need to change grub.cfg to use UUID. I found this but can't test
it, I use legacy-grub.
https://support.huaweicloud.com/intl/en-us/usermanual-ims/ims_01_0324.html
--
Jimmy Johnson

Alien Linux - AMD A8-7600 - at sda11
Registered Linux User #380263

Jimmy Johnson <Jimmy@disposable.invalid> wrote:

Thanks for responding. I tried changing grub.cfg to use block-ID
but that didn't make a difference.

>
> Edit /etc//fstab to use only UUID and don't use /dev/ on the system with
> the problem. 'blkid' as root will give you all drives UUID.
>
> You may need to change grub.cfg to use UUID. I found this but can't test
> it, I use legacy-grub.
>
> https://support.huaweicloud.com/intl/en-us/usermanual-ims/ims_01_0324.html

My blkid output is:
/dev/sdc2: UUID="f030cb95-a735-4522-8c84-2ab2691e9020" TYPE="ext4" PARTUUID="9da03be6-02"

The corresponding entry in my grub.cfg would be:

menuentry 'C2:k4.15.2' {
search --no-floppy --fs-uuid --set=root=UUID f030cb95-a735-4522-8c84-2ab2691e9020
linux /boot/k4.15.2 load_ramdisk=1 root=UUID=f030cb95-a735-4522-8c84-2ab2691e9020 prompt_ramdisk=0 ro printk.time=0 vt.default_utf8=0 gfxpayoad=1024x768x64
initrd /boot/initrd.gz
}

This did not change the problem, I still got the "no such partition" message.

Experiments my son did yesterday it makes a difference whether the drive
was originally partitioned using gdisk or fdisk.

Le 19/08/2021 à 15:58, root a écrit :
>
> search --no-floppy --fs-uuid --set=root=UUID f030cb95-a735-4522-8c84-2ab2691e9020

--set=root=UUID is wrong. Replace with --set=root

Le 19/08/2021 à 08:10, root a écrit :
> Grub seems to confuse two drives in my system.

No, it does't. GRUB gets drive numbers from the firmware (BIOS/UEFI).
Drive number assigned by the firmware are arbitrary, so do not rely on
them. The only constant seems to be that the boot drive in BIOS mode is
always (hd0).

/dev/sd* names have nothing to do with firmware drive numbers, but they
are not reliably persistent. Do not rely on them either.

Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> Le 19/08/2021 ?? 08:10, root a ??crit??:
>> Grub seems to confuse two drives in my system.
>
> No, it does't. GRUB gets drive numbers from the firmware (BIOS/UEFI).
> Drive number assigned by the firmware are arbitrary, so do not rely on
> them. The only constant seems to be that the boot drive in BIOS mode is
> always (hd0).
>
> /dev/sd* names have nothing to do with firmware drive numbers, but they
> are not reliably persistent. Do not rely on them either.

Thanks for responding.

The bios reports drive numbers in the order of what we call
sda,sdb,sdc... I tried to add a drive map to grub but
it did not change the order.

When I get the grub menu, I can type c to get a shell
and do ls to see what the drives are.

The ordering is
hd0 sda
hd1 sdc
hd2 sdb

I can edit an entry and then the boot works.

It comes out this way even if I use the blockID

I know this sounds crazy.

Le 20/08/2021 à 23:03, root a écrit :
>
> The bios reports drive numbers in the order of what we call
> sda,sdb,sdc...

No it doesn't, as shown below. When it does, it is just a coincidence.

> I tried to add a drive map to grub but
> it did not change the order.

Of course not. The BIOS does not care about GRUB settings.
If by "drive map" you mean /boot/grub/device.map, this is just a hint
used by GRUB tools such as grub-mkconfig.

Use UUIDs or LABELs instead of drive numbers or names.

> The ordering is
> hd0 sda
> hd1 sdc
> hd2 sdb

You demonstrate that the BIOS drive order is not in the order of sda,
sdb, sdc... (which is as unreliable as the BIOS drive order anyway)

> It comes out this way even if I use the blockID

What is the blockID ?

Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> Le 20/08/2021 ?? 23:03, root a ??crit??:
>>
>> The bios reports drive numbers in the order of what we call
>> sda,sdb,sdc...
>
> No it doesn't, as shown below. When it does, it is just a coincidence.
>
>> I tried to add a drive map to grub but
>> it did not change the order.
>
> Of course not. The BIOS does not care about GRUB settings.
> If by "drive map" you mean /boot/grub/device.map, this is just a hint
> used by GRUB tools such as grub-mkconfig.
>
> Use UUIDs or LABELs instead of drive numbers or names.
>
>> The ordering is
>> hd0 sda
>> hd1 sdc
>> hd2 sdb
>
> You demonstrate that the BIOS drive order is not in the order of sda,
> sdb, sdc... (which is as unreliable as the BIOS drive order anyway)
>
>> It comes out this way even if I use the blockID
>
> What is the blockID ?

UUID

Le 21/08/2021 à 03:34, root a écrit :
> Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>>
>> You demonstrate that the BIOS drive order is not in the order of sda,
>> sdb, sdc... (which is as unreliable as the BIOS drive order anyway)
>>
>>> It comes out this way even if I use the blockID
>>
>> What is the blockID ?
>
> UUID

Using a UUID won't change drive numbers or names. Its purpose is only to
associate a persistant identifier with a block device regardless of the
variable device number or name.

Th "search" command in your grub.cfg is wrong, as I explained in a
previous reply :

--set=root=UUID is wrong. Replace with --set=root

Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> Le 21/08/2021 ?? 03:34, root a ??crit??:
>> Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>>>
>>> You demonstrate that the BIOS drive order is not in the order of sda,
>>> sdb, sdc... (which is as unreliable as the BIOS drive order anyway)
>>>
>>>> It comes out this way even if I use the blockID
>>>
>>> What is the blockID ?
>>
>> UUID
>
> Using a UUID won't change drive numbers or names. Its purpose is only to
> associate a persistant identifier with a block device regardless of the
> variable device number or name.
>
> Th "search" command in your grub.cfg is wrong, as I explained in a
> previous reply :
>
> --set=root=UUID is wrong. Replace with --set=root

I'm sorry I didn't respond earlier. I will make the change
and report back.

I know you didn't suggest the uuid solution, but I want to
comment that the uuid changes if I re-write the partition,
as in formatting and copying new contents. Most of
these partitions are backups so that wouldn't work.
Even then it didn't change the problem.

I've done some more diagnosis of the problem. I have
entries in grub.cfg to boot into the first partition
on drives sda,sdb, and sdc. In each case I see
that I am in the correct partition after booting.
That means that grub identifies hd0 as sda, hd1 as sdb,
and hd2 as sdc.

However, when I try to boot into sdc2 as hd2,2 it says there
is no such partition and similarly for hd2,3 and hd2,4.

root <NoEMail@home.org> wrote:
> I know you didn't suggest the uuid solution, but I want to comment
> that the uuid changes if I re-write the partition, as in formatting
> and copying new contents. Most of these partitions are backups so
> that wouldn't work. Even then it didn't change the problem.

Correct, although what causes a new UUID to be generated is
initializing a new filesystem.

But, if you want to reuse a UUID, you can (these instructions are for
the ext[234] filesystems). If you've already created them, then aquire
the old UUIDs somehow, then use tune2fs (see "man tune2fs") to assign
the old UUIDs to the newly formatted filesystems.

Or, if you have not yet created them and are manually running the
mkfs.ext[234] command, then use the -U option (see the man page for the
command you use) when you make the filesystem to assign a specific UUID
to the new filesystem. Note you still have to obtain the prior UUID
somehow.

Le 21/08/2021 à 17:27, root a écrit :
>
> I know you didn't suggest the uuid solution, but I want to

I support the UUID solution.

> comment that the uuid changes if I re-write the partition,
> as in formatting and copying new contents. Most of
> these partitions are backups so that wouldn't work.

If you change the filesystem UUID, you need to update grub.cfg in both
places (the search command and the kernel command line), and also
/etc/fstab.

> Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>>
>> --set=root=UUID is wrong. Replace with --set=root

Yes, eliminating the =UUID worked, but it also
worked before. I have left it out and will hereafter.

Thanks.

Rich <rich@example.invalid> wrote:
>
> But, if you want to reuse a UUID, you can (these instructions are for
> the ext[234] filesystems). If you've already created them, then aquire
> the old UUIDs somehow, then use tune2fs (see "man tune2fs") to assign
> the old UUIDs to the newly formatted filesystems.
>
> Or, if you have not yet created them and are manually running the
> mkfs.ext[234] command, then use the -U option (see the man page for the
> command you use) when you make the filesystem to assign a specific UUID
> to the new filesystem. Note you still have to obtain the prior UUID
> somehow.
>

Thanks. Doesn't it seem a little too much trouble? if the (hd..) stuff
works then why not?

root <NoEMail@home.org> wrote:
> Rich <rich@example.invalid> wrote:
>>
>> But, if you want to reuse a UUID, you can (these instructions are for
>> the ext[234] filesystems). If you've already created them, then aquire
>> the old UUIDs somehow, then use tune2fs (see "man tune2fs") to assign
>> the old UUIDs to the newly formatted filesystems.
>>
>> Or, if you have not yet created them and are manually running the
>> mkfs.ext[234] command, then use the -U option (see the man page for the
>> command you use) when you make the filesystem to assign a specific UUID
>> to the new filesystem. Note you still have to obtain the prior UUID
>> somehow.
>
> Thanks. Doesn't it seem a little too much trouble? if the (hd..) stuff
> works then why not?

If nothing changes about your system, the hdX numbers are usually
stable. In which case, you won't see a problem using them.

But, if you upgrade to a new motherboard, or add/subtract cards that
contain disk controllers, it is possible the hdX/sdX assignments to
physical disks will be different after the hardware changes.

The UUID's are in the filesystem, so it does not matter if the hdX or
sdX values move around, the UUID's allow the right filesystems to be
mounted correctly.

Le 21/08/2021 à 20:38, Rich a écrit :
>
> But, if you upgrade to a new motherboard, or add/subtract cards that
> contain disk controllers,

or just connect a USB drive

> it is possible the hdX/sdX assignments to
> physical disks will be different after the hardware changes.