CentOSThis forum is for the discussion of CentOS Linux. Note: This forum does not have any official participation.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
gdisk /dev/sda
Found valid GPT with protective MBR; using GPT.
Command (? for help): v
this will be message if this is the problem
Code:
Warning: The 0xEE protective partition in the MBR is marked as active. This is technically a violation of the GPT specification, and can cause some EFIs to ignore the disk, but it is required to boot from a GPT disk on some BIOS-based computers. You can clear this flag by creating a fresh protective MBR using
the 'n' option on the experts' menu.
Last edited by colorpurple21859; 09-25-2019 at 09:15 AM.
You cleared the BIOS settings, and your CentOS system couldn't boot. That means the problem is related to a BIOS setting, and fixing this would instantly have made the system bootable again.
The most likely cause of your boot problems is that the legacy/EFI BIOS settings are incorrect. Booting with rescue media and messing with grub settings while still having the wrong BIOS settings is likely to result in a system that's unbootable in either mode.
First, make sure you know with certainty whether the system was installed in EFI or legacy mode. Fortunately, this should be really easy to ascertain: EFI requires a GPT partitioned disk, while legacy mode (sort-of) needs MBR. Boot from a USB stick, and fdisk -l /dev/sda (or /dev/your_boot_device_here) will tell you if you're using GPT or MBR. Look for "disklabel type"; MBR is reported as "dos".
Once you've established the type of partitioning being used, make sure to set your BIOS settings accordingly. Remember, simply enabling "legacy" support is no guarantee the system won't try EFI first. You need to also check the boot order. Disabling legacy support does guarantee the system will boot using EFI, though. Oh, and remember the Secure Boot setting; it probably needs to be disabled.
Only when all this is done does it make sense to use rescue media and try reinstalling grub.
You cleared the BIOS settings, and your CentOS system couldn't boot. That means the problem is related to a BIOS setting, and fixing this would instantly have made the system bootable again.
The most likely cause of your boot problems is that the legacy/EFI BIOS settings are incorrect. Booting with rescue media and messing with grub settings while still having the wrong BIOS settings is likely to result in a system that's unbootable in either mode.
First, make sure you know with certainty whether the system was installed in EFI or legacy mode. Fortunately, this should be really easy to ascertain: EFI requires a GPT partitioned disk, while legacy mode (sort-of) needs MBR. Boot from a USB stick, and fdisk -l /dev/sda (or /dev/your_boot_device_here) will tell you if you're using GPT or MBR. Look for "disklabel type"; MBR is reported as "dos".
Once you've established the type of partitioning being used, make sure to set your BIOS settings accordingly. Remember, simply enabling "legacy" support is no guarantee the system won't try EFI first. You need to also check the boot order. Disabling legacy support does guarantee the system will boot using EFI, though. Oh, and remember the Secure Boot setting; it probably needs to be disabled.
Only when all this is done does it make sense to use rescue media and try reinstalling grub.
That's exactly what I thought. So here are some notes:
Code:
Disk label type: dos
Device Boot Id System
/dev/sda1 * 0 Empty
/dev/sda2 ef EFI (FAT-12/16/32)
For SATA Mode Selection, I have IDE, AHCI and RAID (doesn't count). I'm choosing IDE, which says "for better compatibility" as opposed to "AHCI: Supports new features that improve performance". "SATA Controllers" are enabled.
The CSM (Compatibility Support Module) is where things get confusing. PXE OpROM, Stoage OpROM, and Video OpROM Policies, I've set all to Legacy only. Two other options are Do not launch and UEFI only. So all those are set to Legacy Only.
At this point, nothing has changed. Secure Boot State is Disabled. I can't even choose it. Secure Boot (one lower on the Security tab) is Disabled.
This is what I've been running with so far, then thought it was a grub thing. Is there a way I can test all this, or do we move onto grub now?
That's exactly what I thought. So here are some notes:
Code:
Disk label type: dos
Device Boot Id System
/dev/sda1 * 0 Empty
/dev/sda2 ef EFI (FAT-12/16/32)
So it seems your system was actually installed in EFI mode, even though MBR was used. Make sure to disable all "Legacy" support and leave the Secure Boot setting as disabled.
Quote:
Originally Posted by BeeRich
For SATA Mode Selection, I have IDE, AHCI and RAID (doesn't count). I'm choosing IDE, which says "for better compatibility" as opposed to "AHCI: Supports new features that improve performance".
That's probably wrong. The "compatibility" they're talking about has to do with older operating systems that don't know about AHCI. CentOS7 certainly does support AHCI.
So it seems your system was actually installed in EFI mode, even though MBR was used. Make sure to disable all "Legacy" support and leave the Secure Boot setting as disabled.
That's probably wrong. The "compatibility" they're talking about has to do with older operating systems that don't know about AHCI. CentOS7 certainly does support AHCI.
So should I choose Do not launch or UEFI only? I can turn this whole section off (CSM Disabled). So there's 4 choices there.
Upon choosing UEFI only, no drives show up at all (there are 2 I use actually, one as storage). Same happens with Do not launch for the first two choices (third has Legacy or EUFI). Turning off CSM, no drives are available either. So it seems Legacy only is the only option.
Note: I'm not taking into account that there are no boot files on the drives, because of the grub2 stuff before.
Note: I'm not taking into account that there are no boot files on the drives, because of the grub2 stuff before.
That's probably quite significant.
The EFI boot mechanism (in the BIOS) expects to find boot images on the EFI System Partition (ESP), a mandatory partition formatted with one of the FAT filesystems. If these files are missing, the system simply cannot boot.
I'd leave the BIOS settings in "UEFI Only" mode and try to fix grub using rescue media.
The EFI boot mechanism (in the BIOS) expects to find boot images on the EFI System Partition (ESP), a mandatory partition formatted with one of the FAT filesystems. If these files are missing, the system simply cannot boot.
I'd leave the BIOS settings in "UEFI Only" mode and try to fix grub using rescue media.
Well at this point, I don't know what to say. I set it to UEFI Only, and it's reporting no Linux partitions are there. I can't do a thing in the shell.
So I don't even have an operating system now. /boot/efi doesn't exist. No clue how I got there. Any last advice before I shoot myself in the head?
Well at this point, I don't know what to say. I set it to UEFI Only, and it's reporting no Linux partitions are there. I can't do a thing in the shell.
What is reporting "no Linux partitions"? Which shell?
According to your first post, your root partition resides inside LVM along with the swap partiton and a separate partition for /home (/dev/sda3 being the only physical volume), while /dev/sda2 is your boot partition.
What is reporting "no Linux partitions"? Which shell?
According to your first post, your root partition resides inside LVM along with the swap partiton and a separate partition for /home (/dev/sda3 being the only physical volume), while /dev/sda2 is your boot partition.
The rescue anaconda shell. I can't even chroot /mnt/sysimage/ because implementing the rescue shows there are no Linux partitions, and everything falls apart. No bash, no sh, nothing. I've tried two USB drives with different versions of CentOS7 and same thing.
I'm afraid I'm not familiar with this particular rescue environment. I have very limited experience with CentOS and RHEL.
Is the drive/controller detected at all? Does ls /dev/sd* show /dev/sda and its partitions?
And if so, is the partition still intact? fdisk -l should display three partitions: The EFI partition, the /boot partition, and an LVM partition containing / (root), /home and swap. Again, according to your first post.
And how about LVM, does lvdisplay show three logical volumes?
I'm afraid I'm not familiar with this particular rescue environment. I have very limited experience with CentOS and RHEL.
Is the drive/controller detected at all? Does ls /dev/sd* show /dev/sda and its partitions?
And if so, is the partition still intact? fdisk -l should display three partitions: The EFI partition, the /boot partition, and an LVM partition containing / (root), /home and swap. Again, according to your first post.
And how about LVM, does lvdisplay show three logical volumes?
/dev/sda does show up, as does its partitions. Other partitions do not, for /dev/sdb.
fdisk -l only shows previous partitions. EFI is on /dev/sda2, and Boot is marked on /dev/sda1. There is no /home nor swap.
I'm past the point of breaking. I have a poor brand of SSD in there. I'm going to rebuild.
Any advice on rebuilding? I don't want legacy. I'm assuming the UEFI only is the good choice. I have two new SSDs coming so I can RAID 5.
What about /dev/sda3? Is should show up as an LVM partition.
UEFI vs. legacy is a matter of personal preference. I see no advantages to using UEFI (and a few disadvantages), so I always go with Legacy.
However, I'd highly recommend using GPT instead of MBR. It has superior multi-partition support compared to MBR, and supports partitions larger than 2 Tb and drives larger than 4 Tb.
Why did you reset the bios to begin with? Maybe that will lend some insight into what is happening.
post the output of
Code:
parted -l
and
Code:
ls /sys/firmware/efi
Code:
I can't even chroot /mnt/sysimage/
did you activate the lvm on partition 3 and mount cento-root on /mnt/sysimage and sda1 on /mnt/sysimage/boot after mounting your root file system?
Because I needed to get into the BIOS to change the Restart after power outage setting. It was set to Fastboot, and the only way out of that is to reset the CMOS, which killed my ability to boot, for some reason. And as luck would have it, I'm the very first person to do this ever.
I can't paste any feedback. I'm on a completely different machine, and that box is on rescue anaconda. Not sure what you're looking for, but it (parted -l) says /des/sda is a 16 GB Lexar JumpDrive, partition msdos.
Then a Linux device-mapper (linear), at /dev/mapper/live-base, partition table: loop.
Then another with (snapshot) instead of (linear)
ls /sys/firmware/efi:
Code:
config_table
efivars
fw_platform_size
fw_vendor
runtime
runtime-map
systab
vars
Like I said, I can't chroot /mnt/sysimage because:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
