Booting from SSD with CentOS 6.9 results in black screen (No Grub, nothing else after BIOS/EFI)
up vote
0
down vote
favorite
I just encountered a weird problem with my system. When I try to boot CentOS 6.9 I get a black screen from the beginning. I can not see the Grub bootloader or anything after selecting the disk to boot from in the BIOS/EFI.
I think I have to give some more insight on this. I have a desktop system with three SSDs. I configured everything so that I was able to install CentOS 7.5 on one SSD, Windows 10 on the other and CentOS 6.9 on the last one. It was a pain in the a** to do this as I had to figure out that I needed to disable all BIOS functionality on the Mainboard and use EFI instead so that all OSs would isntall in EFI-mode. I then used the Grub 2 Bootloader as my "main" booting source and added the entrys for Windows 10 and CentOS 6.9. After much struggle with CentOS I found out that Grub2 is not able to boot CentOS 6.9 directly so I configured a chainloading to the bootloader that was installed with CentOS 6.9. After doing all this, everything worked fine for weeks.
This is my boot entry for CentOS6.9 in Grub2 of Centos7.5:
Insmod ntfs
Insmod chain
Insmod part_gpt
Set root=(hd3,1)
Chainloader /EFI/redhat/grub.efi
And this is the boot entry in the grub of CentOS6.9 that gets chainloaded:
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,1)
# kernel /vmlinuz-version ro root=/dev/mapper/vg_centos6-lv_root
# initrd /initrd-[generic-]version.img
#boot=/dev/sdc1
device (hd3) Linux HD(1,800,64000,83afa265-4819-4822-bfaa-e6bbe2eff70c)
default=0
timeout=5
splashimage=(hd3,1)/grub/splash.xpm.gz
hiddenmenu
title CentOS 6 (2.6.32-696.el6.x86_64)
root (hd3,1)
kernel /vmlinuz-2.6.32-696.el6.x86_64 ro root=/dev/mapper/vg_centos6-lv_root nomodeset rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_centos6/lv_swap rd_LVM_LV=cl/$
initrd /initramfs-2.6.32-696.el6.x86_64.img
But two days ago I wanted to boot CentOS 6.9 again (Was using Windows 10 and CentOS 7.5 mostly) And after I selected the entry for 6.9 in the boot menu, It said it could not find the hd3,1 partition. I checked with ls on the grub console what partitions are availiable and got the following:
no hd3... . I then selected the ssd with centos6.9 installed to go around the chainloading and got the already mentioned black screen. After that I tried to edit the boot entry in Grub2 of Centos 7.5 to hd2,1 as it looks for me like the numbering just got shifted from 3 to 2. Then I get the same black screen. However, when booting into CentOS 7.5 and mounting sdc1, sdc2 and sdc3 all my files form the CentOS 6.9 including the /EFI/redhat/grub.efi and grub.conf are present.
I dont know of anything I changed on the hardware side or grub configuration since the last time I could boot from 6.9. Does anyone have a suggestion how I could continue troubleshooting?
Greetings,
Mango
EDIT:
Ok, I figured out how to "fix" it but I have no idea what caused my issue. My intention that the drive numbers changed were right and I just overlooked one line where I had to change the drive number. After changing every occurence of hd3 to hd2 it works again.
PS: I think I had a thumb drive attached to the device in the past which is now detached. Could that be an issue? that the thumbdrive was recognized as hd2 for so long and now that it is removed hd3 became hd2?
#boot=/dev/sdc1
device (hd2) Linux HD(1,800,64000,83afa265-4819-4822-bfaa-e6bbe2eff70c)
default=0
timeout=5
splashimage=(hd2,1)/grub/splash.xpm.gz
hiddenmenu
title CentOS 6 (2.6.32-696.el6.x86_64)
root (hd2,1)
kernel /vmlinuz-2.6.32-696.el6.x86_64 ro root=/dev/mapper/vg_centos6-lv_root nomodeset rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_centos6/lv_swap rd_LVM_LV=cl/$
initrd /initramfs-2.6.32-696.el6.x86_64.img
centos boot grub
New contributor
add a comment |
up vote
0
down vote
favorite
I just encountered a weird problem with my system. When I try to boot CentOS 6.9 I get a black screen from the beginning. I can not see the Grub bootloader or anything after selecting the disk to boot from in the BIOS/EFI.
I think I have to give some more insight on this. I have a desktop system with three SSDs. I configured everything so that I was able to install CentOS 7.5 on one SSD, Windows 10 on the other and CentOS 6.9 on the last one. It was a pain in the a** to do this as I had to figure out that I needed to disable all BIOS functionality on the Mainboard and use EFI instead so that all OSs would isntall in EFI-mode. I then used the Grub 2 Bootloader as my "main" booting source and added the entrys for Windows 10 and CentOS 6.9. After much struggle with CentOS I found out that Grub2 is not able to boot CentOS 6.9 directly so I configured a chainloading to the bootloader that was installed with CentOS 6.9. After doing all this, everything worked fine for weeks.
This is my boot entry for CentOS6.9 in Grub2 of Centos7.5:
Insmod ntfs
Insmod chain
Insmod part_gpt
Set root=(hd3,1)
Chainloader /EFI/redhat/grub.efi
And this is the boot entry in the grub of CentOS6.9 that gets chainloaded:
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,1)
# kernel /vmlinuz-version ro root=/dev/mapper/vg_centos6-lv_root
# initrd /initrd-[generic-]version.img
#boot=/dev/sdc1
device (hd3) Linux HD(1,800,64000,83afa265-4819-4822-bfaa-e6bbe2eff70c)
default=0
timeout=5
splashimage=(hd3,1)/grub/splash.xpm.gz
hiddenmenu
title CentOS 6 (2.6.32-696.el6.x86_64)
root (hd3,1)
kernel /vmlinuz-2.6.32-696.el6.x86_64 ro root=/dev/mapper/vg_centos6-lv_root nomodeset rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_centos6/lv_swap rd_LVM_LV=cl/$
initrd /initramfs-2.6.32-696.el6.x86_64.img
But two days ago I wanted to boot CentOS 6.9 again (Was using Windows 10 and CentOS 7.5 mostly) And after I selected the entry for 6.9 in the boot menu, It said it could not find the hd3,1 partition. I checked with ls on the grub console what partitions are availiable and got the following:
no hd3... . I then selected the ssd with centos6.9 installed to go around the chainloading and got the already mentioned black screen. After that I tried to edit the boot entry in Grub2 of Centos 7.5 to hd2,1 as it looks for me like the numbering just got shifted from 3 to 2. Then I get the same black screen. However, when booting into CentOS 7.5 and mounting sdc1, sdc2 and sdc3 all my files form the CentOS 6.9 including the /EFI/redhat/grub.efi and grub.conf are present.
I dont know of anything I changed on the hardware side or grub configuration since the last time I could boot from 6.9. Does anyone have a suggestion how I could continue troubleshooting?
Greetings,
Mango
EDIT:
Ok, I figured out how to "fix" it but I have no idea what caused my issue. My intention that the drive numbers changed were right and I just overlooked one line where I had to change the drive number. After changing every occurence of hd3 to hd2 it works again.
PS: I think I had a thumb drive attached to the device in the past which is now detached. Could that be an issue? that the thumbdrive was recognized as hd2 for so long and now that it is removed hd3 became hd2?
#boot=/dev/sdc1
device (hd2) Linux HD(1,800,64000,83afa265-4819-4822-bfaa-e6bbe2eff70c)
default=0
timeout=5
splashimage=(hd2,1)/grub/splash.xpm.gz
hiddenmenu
title CentOS 6 (2.6.32-696.el6.x86_64)
root (hd2,1)
kernel /vmlinuz-2.6.32-696.el6.x86_64 ro root=/dev/mapper/vg_centos6-lv_root nomodeset rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_centos6/lv_swap rd_LVM_LV=cl/$
initrd /initramfs-2.6.32-696.el6.x86_64.img
centos boot grub
New contributor
1
Hello and welcome to this site! If you found a solution to your own question, please don't edit it and change the subject to "SOLVED". Instead, post your solution as an answer.
– Mr Shunz
2 days ago
Yes, the thumbdrive could well have caused it. With a traditional BIOS, USB thumbdrives were something that required optional extension functionality to access at the BIOS level. With UEFI, they can be perfectly good disks. Thedevice (hd2) Linux...
line is supposed to tie the GRUB device name(hd2)
to the appropriate disk by UUID, but your system might have got that wrong at installation time, and in the absence of any matching UUID,(hd2)
simply refers to the 3rd disk of the system, in whatever order the firmware provides the list to GRUB.
– telcoM
2 days ago
In GPT partitioning, there is a unique disk UUID for each disk, and a partition UUID for each partition. Most filesystems also have filesystem-level UUIDs. Does anyone know which of these the RHEL/CentOS 6 UEFI GRUB looks for? You can get the partition and filesystem UUIDs with theblkid
command, but how to get the GPT disk UUID in RHEL/CentOS 6?
– telcoM
2 days ago
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I just encountered a weird problem with my system. When I try to boot CentOS 6.9 I get a black screen from the beginning. I can not see the Grub bootloader or anything after selecting the disk to boot from in the BIOS/EFI.
I think I have to give some more insight on this. I have a desktop system with three SSDs. I configured everything so that I was able to install CentOS 7.5 on one SSD, Windows 10 on the other and CentOS 6.9 on the last one. It was a pain in the a** to do this as I had to figure out that I needed to disable all BIOS functionality on the Mainboard and use EFI instead so that all OSs would isntall in EFI-mode. I then used the Grub 2 Bootloader as my "main" booting source and added the entrys for Windows 10 and CentOS 6.9. After much struggle with CentOS I found out that Grub2 is not able to boot CentOS 6.9 directly so I configured a chainloading to the bootloader that was installed with CentOS 6.9. After doing all this, everything worked fine for weeks.
This is my boot entry for CentOS6.9 in Grub2 of Centos7.5:
Insmod ntfs
Insmod chain
Insmod part_gpt
Set root=(hd3,1)
Chainloader /EFI/redhat/grub.efi
And this is the boot entry in the grub of CentOS6.9 that gets chainloaded:
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,1)
# kernel /vmlinuz-version ro root=/dev/mapper/vg_centos6-lv_root
# initrd /initrd-[generic-]version.img
#boot=/dev/sdc1
device (hd3) Linux HD(1,800,64000,83afa265-4819-4822-bfaa-e6bbe2eff70c)
default=0
timeout=5
splashimage=(hd3,1)/grub/splash.xpm.gz
hiddenmenu
title CentOS 6 (2.6.32-696.el6.x86_64)
root (hd3,1)
kernel /vmlinuz-2.6.32-696.el6.x86_64 ro root=/dev/mapper/vg_centos6-lv_root nomodeset rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_centos6/lv_swap rd_LVM_LV=cl/$
initrd /initramfs-2.6.32-696.el6.x86_64.img
But two days ago I wanted to boot CentOS 6.9 again (Was using Windows 10 and CentOS 7.5 mostly) And after I selected the entry for 6.9 in the boot menu, It said it could not find the hd3,1 partition. I checked with ls on the grub console what partitions are availiable and got the following:
no hd3... . I then selected the ssd with centos6.9 installed to go around the chainloading and got the already mentioned black screen. After that I tried to edit the boot entry in Grub2 of Centos 7.5 to hd2,1 as it looks for me like the numbering just got shifted from 3 to 2. Then I get the same black screen. However, when booting into CentOS 7.5 and mounting sdc1, sdc2 and sdc3 all my files form the CentOS 6.9 including the /EFI/redhat/grub.efi and grub.conf are present.
I dont know of anything I changed on the hardware side or grub configuration since the last time I could boot from 6.9. Does anyone have a suggestion how I could continue troubleshooting?
Greetings,
Mango
EDIT:
Ok, I figured out how to "fix" it but I have no idea what caused my issue. My intention that the drive numbers changed were right and I just overlooked one line where I had to change the drive number. After changing every occurence of hd3 to hd2 it works again.
PS: I think I had a thumb drive attached to the device in the past which is now detached. Could that be an issue? that the thumbdrive was recognized as hd2 for so long and now that it is removed hd3 became hd2?
#boot=/dev/sdc1
device (hd2) Linux HD(1,800,64000,83afa265-4819-4822-bfaa-e6bbe2eff70c)
default=0
timeout=5
splashimage=(hd2,1)/grub/splash.xpm.gz
hiddenmenu
title CentOS 6 (2.6.32-696.el6.x86_64)
root (hd2,1)
kernel /vmlinuz-2.6.32-696.el6.x86_64 ro root=/dev/mapper/vg_centos6-lv_root nomodeset rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_centos6/lv_swap rd_LVM_LV=cl/$
initrd /initramfs-2.6.32-696.el6.x86_64.img
centos boot grub
New contributor
I just encountered a weird problem with my system. When I try to boot CentOS 6.9 I get a black screen from the beginning. I can not see the Grub bootloader or anything after selecting the disk to boot from in the BIOS/EFI.
I think I have to give some more insight on this. I have a desktop system with three SSDs. I configured everything so that I was able to install CentOS 7.5 on one SSD, Windows 10 on the other and CentOS 6.9 on the last one. It was a pain in the a** to do this as I had to figure out that I needed to disable all BIOS functionality on the Mainboard and use EFI instead so that all OSs would isntall in EFI-mode. I then used the Grub 2 Bootloader as my "main" booting source and added the entrys for Windows 10 and CentOS 6.9. After much struggle with CentOS I found out that Grub2 is not able to boot CentOS 6.9 directly so I configured a chainloading to the bootloader that was installed with CentOS 6.9. After doing all this, everything worked fine for weeks.
This is my boot entry for CentOS6.9 in Grub2 of Centos7.5:
Insmod ntfs
Insmod chain
Insmod part_gpt
Set root=(hd3,1)
Chainloader /EFI/redhat/grub.efi
And this is the boot entry in the grub of CentOS6.9 that gets chainloaded:
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,1)
# kernel /vmlinuz-version ro root=/dev/mapper/vg_centos6-lv_root
# initrd /initrd-[generic-]version.img
#boot=/dev/sdc1
device (hd3) Linux HD(1,800,64000,83afa265-4819-4822-bfaa-e6bbe2eff70c)
default=0
timeout=5
splashimage=(hd3,1)/grub/splash.xpm.gz
hiddenmenu
title CentOS 6 (2.6.32-696.el6.x86_64)
root (hd3,1)
kernel /vmlinuz-2.6.32-696.el6.x86_64 ro root=/dev/mapper/vg_centos6-lv_root nomodeset rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_centos6/lv_swap rd_LVM_LV=cl/$
initrd /initramfs-2.6.32-696.el6.x86_64.img
But two days ago I wanted to boot CentOS 6.9 again (Was using Windows 10 and CentOS 7.5 mostly) And after I selected the entry for 6.9 in the boot menu, It said it could not find the hd3,1 partition. I checked with ls on the grub console what partitions are availiable and got the following:
no hd3... . I then selected the ssd with centos6.9 installed to go around the chainloading and got the already mentioned black screen. After that I tried to edit the boot entry in Grub2 of Centos 7.5 to hd2,1 as it looks for me like the numbering just got shifted from 3 to 2. Then I get the same black screen. However, when booting into CentOS 7.5 and mounting sdc1, sdc2 and sdc3 all my files form the CentOS 6.9 including the /EFI/redhat/grub.efi and grub.conf are present.
I dont know of anything I changed on the hardware side or grub configuration since the last time I could boot from 6.9. Does anyone have a suggestion how I could continue troubleshooting?
Greetings,
Mango
EDIT:
Ok, I figured out how to "fix" it but I have no idea what caused my issue. My intention that the drive numbers changed were right and I just overlooked one line where I had to change the drive number. After changing every occurence of hd3 to hd2 it works again.
PS: I think I had a thumb drive attached to the device in the past which is now detached. Could that be an issue? that the thumbdrive was recognized as hd2 for so long and now that it is removed hd3 became hd2?
#boot=/dev/sdc1
device (hd2) Linux HD(1,800,64000,83afa265-4819-4822-bfaa-e6bbe2eff70c)
default=0
timeout=5
splashimage=(hd2,1)/grub/splash.xpm.gz
hiddenmenu
title CentOS 6 (2.6.32-696.el6.x86_64)
root (hd2,1)
kernel /vmlinuz-2.6.32-696.el6.x86_64 ro root=/dev/mapper/vg_centos6-lv_root nomodeset rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_centos6/lv_swap rd_LVM_LV=cl/$
initrd /initramfs-2.6.32-696.el6.x86_64.img
centos boot grub
centos boot grub
New contributor
New contributor
edited 2 days ago
Kusalananda
119k16223364
119k16223364
New contributor
asked 2 days ago
Mangosniper
11
11
New contributor
New contributor
1
Hello and welcome to this site! If you found a solution to your own question, please don't edit it and change the subject to "SOLVED". Instead, post your solution as an answer.
– Mr Shunz
2 days ago
Yes, the thumbdrive could well have caused it. With a traditional BIOS, USB thumbdrives were something that required optional extension functionality to access at the BIOS level. With UEFI, they can be perfectly good disks. Thedevice (hd2) Linux...
line is supposed to tie the GRUB device name(hd2)
to the appropriate disk by UUID, but your system might have got that wrong at installation time, and in the absence of any matching UUID,(hd2)
simply refers to the 3rd disk of the system, in whatever order the firmware provides the list to GRUB.
– telcoM
2 days ago
In GPT partitioning, there is a unique disk UUID for each disk, and a partition UUID for each partition. Most filesystems also have filesystem-level UUIDs. Does anyone know which of these the RHEL/CentOS 6 UEFI GRUB looks for? You can get the partition and filesystem UUIDs with theblkid
command, but how to get the GPT disk UUID in RHEL/CentOS 6?
– telcoM
2 days ago
add a comment |
1
Hello and welcome to this site! If you found a solution to your own question, please don't edit it and change the subject to "SOLVED". Instead, post your solution as an answer.
– Mr Shunz
2 days ago
Yes, the thumbdrive could well have caused it. With a traditional BIOS, USB thumbdrives were something that required optional extension functionality to access at the BIOS level. With UEFI, they can be perfectly good disks. Thedevice (hd2) Linux...
line is supposed to tie the GRUB device name(hd2)
to the appropriate disk by UUID, but your system might have got that wrong at installation time, and in the absence of any matching UUID,(hd2)
simply refers to the 3rd disk of the system, in whatever order the firmware provides the list to GRUB.
– telcoM
2 days ago
In GPT partitioning, there is a unique disk UUID for each disk, and a partition UUID for each partition. Most filesystems also have filesystem-level UUIDs. Does anyone know which of these the RHEL/CentOS 6 UEFI GRUB looks for? You can get the partition and filesystem UUIDs with theblkid
command, but how to get the GPT disk UUID in RHEL/CentOS 6?
– telcoM
2 days ago
1
1
Hello and welcome to this site! If you found a solution to your own question, please don't edit it and change the subject to "SOLVED". Instead, post your solution as an answer.
– Mr Shunz
2 days ago
Hello and welcome to this site! If you found a solution to your own question, please don't edit it and change the subject to "SOLVED". Instead, post your solution as an answer.
– Mr Shunz
2 days ago
Yes, the thumbdrive could well have caused it. With a traditional BIOS, USB thumbdrives were something that required optional extension functionality to access at the BIOS level. With UEFI, they can be perfectly good disks. The
device (hd2) Linux...
line is supposed to tie the GRUB device name (hd2)
to the appropriate disk by UUID, but your system might have got that wrong at installation time, and in the absence of any matching UUID, (hd2)
simply refers to the 3rd disk of the system, in whatever order the firmware provides the list to GRUB.– telcoM
2 days ago
Yes, the thumbdrive could well have caused it. With a traditional BIOS, USB thumbdrives were something that required optional extension functionality to access at the BIOS level. With UEFI, they can be perfectly good disks. The
device (hd2) Linux...
line is supposed to tie the GRUB device name (hd2)
to the appropriate disk by UUID, but your system might have got that wrong at installation time, and in the absence of any matching UUID, (hd2)
simply refers to the 3rd disk of the system, in whatever order the firmware provides the list to GRUB.– telcoM
2 days ago
In GPT partitioning, there is a unique disk UUID for each disk, and a partition UUID for each partition. Most filesystems also have filesystem-level UUIDs. Does anyone know which of these the RHEL/CentOS 6 UEFI GRUB looks for? You can get the partition and filesystem UUIDs with the
blkid
command, but how to get the GPT disk UUID in RHEL/CentOS 6?– telcoM
2 days ago
In GPT partitioning, there is a unique disk UUID for each disk, and a partition UUID for each partition. Most filesystems also have filesystem-level UUIDs. Does anyone know which of these the RHEL/CentOS 6 UEFI GRUB looks for? You can get the partition and filesystem UUIDs with the
blkid
command, but how to get the GPT disk UUID in RHEL/CentOS 6?– telcoM
2 days ago
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Mangosniper is a new contributor. Be nice, and check out our Code of Conduct.
Mangosniper is a new contributor. Be nice, and check out our Code of Conduct.
Mangosniper is a new contributor. Be nice, and check out our Code of Conduct.
Mangosniper is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f486540%2fbooting-from-ssd-with-centos-6-9-results-in-black-screen-no-grub-nothing-else%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Hello and welcome to this site! If you found a solution to your own question, please don't edit it and change the subject to "SOLVED". Instead, post your solution as an answer.
– Mr Shunz
2 days ago
Yes, the thumbdrive could well have caused it. With a traditional BIOS, USB thumbdrives were something that required optional extension functionality to access at the BIOS level. With UEFI, they can be perfectly good disks. The
device (hd2) Linux...
line is supposed to tie the GRUB device name(hd2)
to the appropriate disk by UUID, but your system might have got that wrong at installation time, and in the absence of any matching UUID,(hd2)
simply refers to the 3rd disk of the system, in whatever order the firmware provides the list to GRUB.– telcoM
2 days ago
In GPT partitioning, there is a unique disk UUID for each disk, and a partition UUID for each partition. Most filesystems also have filesystem-level UUIDs. Does anyone know which of these the RHEL/CentOS 6 UEFI GRUB looks for? You can get the partition and filesystem UUIDs with the
blkid
command, but how to get the GPT disk UUID in RHEL/CentOS 6?– telcoM
2 days ago