Good afternoon,
I found out the rather hard way what caused those boot failure problems that were the subject of a threat starting last month. After my weekly "dnf upgrade" last Thursday, I checked my root e-mail, and found the hard drive had 8 bad sectors, then 16 bad sectors. A smartctl short test showed several parameters "pre-fail", and the others "old-age". I obtained a new drive. My Cray Research friend gave me a USB stick with "Clonezilla-Live-Version" on it. That duplicated the old hard drive onto the new one, but apparently not 100%. After the old drive was removed and the new drive installed, I could not boot. The system was being put into a grub shell(?). (It displayed the "grub> " prompt.) After beating out heads against the wall (or the phone), my Cray research friend gave me another USB stick with "Boot-Repair-Disk" on it. That rebuilt a grub file, but not correctly. But at least I got a grub menu when booting, and I was able to edit the shell that the grub menu entry would run. I had to take the "efi" off the commands "linuxefi" and "initrdefi". That allows me to boot up Fedora. But the menu is missing an entry for windows, and I still have to edit that script every time.
I want the grub menu to offer the three most recent patches of Fedora, the most recent Fedora rescue shell, and windows-7, in that order. (This is a dual-boot system.) And I want the shells launched by the menu entries to be correct. How do I get that accomplished - the correct Fedora-25 way? If it matters, the motherboard uses UEFI bios.
Thank-you in advance. Bill.
On Tue, 27 Jun 2017 12:12:29 -0600 William mattison.computer@yahoo.com wrote:
I want the grub menu to offer the three most recent patches of Fedora, the most recent Fedora rescue shell, and windows-7, in that order. (This is a dual-boot system.) And I want the shells launched by the menu entries to be correct. How do I get that accomplished - the correct Fedora-25 way? If it matters, the motherboard uses UEFI bios.
I'm not sure if it matters as I don't use EFI. But, there is a program called grub2-mkconfig that can be used to regenerate the grub.cfg file in /boot/grub2, and it might work in /boot/efi. It is in the package grub2-tools.
cd into the directory /boot/efi and type the command grub2-mkconfig -o grub.cfg as root. That should leave you with a valid grub menu.
But, I think you might have to fix the /etc/fstab file also before you do the above. If you cloned the drive, it will still be using the block ids for the previous drive in the /etc/fstab.
Use the command blkid to find the UUIDs of the partitions on the new drive. And edit /etc/fstab so they are correct for the / and /boot partition of your new drive.
Then run the grub2-mkconfig command, and the next boot should give you the menu you want.
Again, this would work for grub2 boot, but I'm not sure about efi boot.
On 06/27/2017 01:05 PM, stan wrote:
But, I think you might have to fix the /etc/fstab file also before you do the above. If you cloned the drive, it will still be using the block ids for the previous drive in the /etc/fstab.
This is why fstab uses the UUID by default, and you should too. Cloning the drive doesn't change those.
On Tue, 27 Jun 2017 13:16:49 -0700 Joe Zeff joe@zeff.us wrote:
On 06/27/2017 01:05 PM, stan wrote:
But, I think you might have to fix the /etc/fstab file also before you do the above. If you cloned the drive, it will still be using the block ids for the previous drive in the /etc/fstab.
This is why fstab uses the UUID by default, and you should too. Cloning the drive doesn't change those.
Thanks for the correction. That implies that it is possible to have duplicate UUIDs on a system if a drive and its duplicate are mounted, though, doesn't it? What does the system do at boot in that case? First come, first serve?
It also means that the only thing William has to do is run the grub-mkconfig command, which is easier for him.
As a matter of note, I always use the UUID in fstab, and also create unique labels for each partition. When I want to duplicate a drive, I usually use rsync (sometimes cp) with both drives mounted, and partitions already created on the receiving drive, so the UUIDs, and labels, will differ on the two drives even though the content might be identical.
I just looked at blkid output, and I noticed that there are now PARTUUID and PARTLABEL for drives. Even when each partition already has a UUID and a label. Perhaps this is to deal with the cloning issue, so there are unique identifiers even for cloned drives?
(replying to all three messages)
When I boot, the bios display says it is UEFI. Am I mis-understanding what that means? Am I mis-using the term?
My /boot directory has only two sub-directories: "grub" and "grub2", no sub-directory "efi".
Each of the two sub-directories has a file called "grub.cfg". The two files are identical, except for permissions.
In /etc/fstab, the UUIDs are already correct, based on output by both the blkid command and the lsblk command (which blkid's man page says I really should use instead).
I tried the grub2-mkconfig command in both sub-directories. Then I rebooted. The new menu has Fedora, other Fedora options, Windows 7 (on /dev/sda1), and Windows 7 (on /dev/sda2). Each option appears to boot up correctly, though I did not attempt to actually log in to a windows account.
Why are there two menu entries for windows? On this system, sda1 is the master boot record, sda2 is the windows partition.
After signing in to Fedora, I get a crash message saying vmlinuz crashed. I couldn't catch the whole message. Yet the system does seem to work. What's going on?
thanks, Bill.
On Wed, 28 Jun 2017 01:35:18 -0000 "William Mattison" mattison.computer@yahoo.com wrote:
(replying to all three messages)
When I boot, the bios display says it is UEFI. Am I mis-understanding what that means? Am I mis-using the term?
Your system supports efi, but it seems you aren't using it.
My /boot directory has only two sub-directories: "grub" and "grub2", no sub-directory "efi".
Not sure why this is. The fact that you have a grub directory implies to me that you have been upgrading this system for a while. I don't have a grub directory in /boot, since it is legacy and deprecated.
Each of the two sub-directories has a file called "grub.cfg". The two files are identical, except for permissions.
In /etc/fstab, the UUIDs are already correct, based on output by both the blkid command and the lsblk command (which blkid's man page says I really should use instead).
Confirming Joe's comment.
I tried the grub2-mkconfig command in both sub-directories. Then I rebooted. The new menu has Fedora, other Fedora options, Windows 7 (on /dev/sda1), and Windows 7 (on /dev/sda2). Each option appears to boot up correctly, though I did not attempt to actually log in to a windows account.
It appears to have worked.
Why are there two menu entries for windows? On this system, sda1 is the master boot record, sda2 is the windows partition.
I don't think the MBR is given a partition assignment. I don't run windows, so I'm unfamiliar with how it is organized, but I seem to recall reading that it can have a backup partition, so one of them might be that.
After signing in to Fedora, I get a crash message saying vmlinuz crashed. I couldn't catch the whole message. Yet the system does seem to work. What's going on?
Try reinstalling the latest kernel, or booting an older kernel. Are there any other messages that would indicate the problem in journalctl -b? It seems that the kernel is having a problem, but it is not fatal. Something misconfigured?
On 28/6/17 11:52 am, stan wrote:
On Wed, 28 Jun 2017 01:35:18 -0000 "William Mattison" mattison.computer@yahoo.com wrote:
(replying to all three messages)
When I boot, the bios display says it is UEFI. Am I mis-understanding what that means? Am I mis-using the term?
Your system supports efi, but it seems you aren't using it.
Just as a slightly off topic question regarding /boot, in /boot I have an efi sub-directory. Why is this when I am booting Fedora 27, Ubuntu 17.10 and Windows 10 with the bios configured as legacy mode and Ubuntu doesn't have an efi directory in /boot, nor have I installed Fedora 27 as efi?
My /boot directory has only two sub-directories: "grub" and "grub2", no sub-directory "efi".
Not sure why this is. The fact that you have a grub directory implies to me that you have been upgrading this system for a while. I don't have a grub directory in /boot, since it is legacy and deprecated.
Each of the two sub-directories has a file called "grub.cfg". The two files are identical, except for permissions.
In /etc/fstab, the UUIDs are already correct, based on output by both the blkid command and the lsblk command (which blkid's man page says I really should use instead).
Confirming Joe's comment.
I tried the grub2-mkconfig command in both sub-directories. Then I rebooted. The new menu has Fedora, other Fedora options, Windows 7 (on /dev/sda1), and Windows 7 (on /dev/sda2). Each option appears to boot up correctly, though I did not attempt to actually log in to a windows account.
It appears to have worked.
Why are there two menu entries for windows? On this system, sda1 is the master boot record, sda2 is the windows partition.
I am tri-booting Fedora 27, Ubuntu 17.10 and Windows 10 via grub2. I use grub2-mkconfig to get the menu boot list via /boot/grub2/grub.cfg and then grub2-install /dev/sda to get the menu into the mbr (you don't issue the grub2-install command on an efi system as I understand it). This gives me an entry in the menu for the Fedora 27 current kernel, a Fedora 27 Advanced sub-menu, a single entry for Windows 10, an entry for the Ubuntu current kernel and an Ubuntu Advanced sub-menu. Windows has a system partition and the normal windows partition, but the grub invoked processes that auto detect the available operating systems ignore the Windows System partition, so if you are getting entries for Windows on sda and sda2, then presumably the operating system detector has actually found two windows partitions on /dev/sda.
regards,
Steve
I don't think the MBR is given a partition assignment. I don't run windows, so I'm unfamiliar with how it is organized, but I seem to recall reading that it can have a backup partition, so one of them might be that.
After signing in to Fedora, I get a crash message saying vmlinuz crashed. I couldn't catch the whole message. Yet the system does seem to work. What's going on?
Try reinstalling the latest kernel, or booting an older kernel. Are there any other messages that would indicate the problem in journalctl -b? It seems that the kernel is having a problem, but it is not fatal. Something misconfigured? _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 02/08/2018 01:44 PM, Stephen Morris wrote:
Just as a slightly off topic question regarding /boot, in /boot I have an efi sub-directory. Why is this when I am booting Fedora 27, Ubuntu 17.10 and Windows 10 with the bios configured as legacy mode and Ubuntu doesn't have an efi directory in /boot, nor have I installed Fedora 27 as efi?
That's a good question. I have that as well on a laptop that doesn't even support EFI. That directory isn't owned by anything either. This laptop has been through a lot of Fedora releases though, so maybe that directory was created by a previous release.
On 02/08/2018 10:13 PM, Samuel Sieb wrote:
On 02/08/2018 01:44 PM, Stephen Morris wrote:
Just as a slightly off topic question regarding /boot, in /boot I have an efi sub-directory. Why is this when I am booting Fedora 27, Ubuntu 17.10 and Windows 10 with the bios configured as legacy mode and Ubuntu doesn't have an efi directory in /boot, nor have I installed Fedora 27 as efi?
That's a good question. I have that as well on a laptop that doesn't even support EFI. That directory isn't owned by anything either. This laptop has been through a lot of Fedora releases though, so maybe that directory was created by a previous release.
IIRC, /boot/efi/* is created by the initial anaconda install sequence and is in place in case you use UEFI at some point in the future. Since it's only about 15MB in size, it's pretty innocuous and I wouldn't worry about it. Ubuntu's install mechanism isn't the same and it probably doesn't create that directory unless it notices you are in UEFI boot mode at the time of install.
Which is better? I sorta like Fedora...it's there in case you need it and it really doesn't take up much space. Your browser cache probably sucks up more disk than /boot/efi does. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Have you noticed that "human readable" configuration file - - directives are beginning to resemble COBOL code? - ----------------------------------------------------------------------
On 02/09/2018 09:40 AM, Rick Stevens wrote:
IIRC, /boot/efi/* is created by the initial anaconda install sequence and is in place in case you use UEFI at some point in the future. Since it's only about 15MB in size, it's pretty innocuous and I wouldn't worry about it. Ubuntu's install mechanism isn't the same and it probably doesn't create that directory unless it notices you are in UEFI boot mode at the time of install.
What's in yours? Are any of the files owned? Mine is just an empty directory tree to /boot/efi/EFI/fedora/. I just checked further and that directory is owned by grub-common, but not the parent directories.
On 10/2/18 5:46 pm, Samuel Sieb wrote:
On 02/09/2018 09:40 AM, Rick Stevens wrote:
IIRC, /boot/efi/* is created by the initial anaconda install sequence and is in place in case you use UEFI at some point in the future. Since it's only about 15MB in size, it's pretty innocuous and I wouldn't worry about it. Ubuntu's install mechanism isn't the same and it probably doesn't create that directory unless it notices you are in UEFI boot mode at the time of install.
What's in yours? Are any of the files owned? Mine is just an empty directory tree to /boot/efi/EFI/fedora/. I just checked further and that directory is owned by grub-common, but not the parent directories.
I've just checked my efi directory, and /boot/efi is owned by 'root', as are directories /boot/efi/EFI and /boot/efi/System and file /boot/efi/mach_kernel. Drilling a little bit further directories /boot/efi/EFI/BOOT and /boot/efi/EFI/fedora are also owned by root, as is directory /boot/efi/System/Library, so I'm assuming everything is.
I'm not concerned so much by the space that structure is using, but more just querying why it is there, and, if I happen to delete that structure will that cause any problems, or, if I do delete it is something going to put it back?
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 02/10/2018 04:27 PM, Stephen Morris wrote:
On 10/2/18 5:46 pm, Samuel Sieb wrote:
On 02/09/2018 09:40 AM, Rick Stevens wrote:
IIRC, /boot/efi/* is created by the initial anaconda install sequence and is in place in case you use UEFI at some point in the future. Since it's only about 15MB in size, it's pretty innocuous and I wouldn't worry about it. Ubuntu's install mechanism isn't the same and it probably doesn't create that directory unless it notices you are in UEFI boot mode at the time of install.
What's in yours? Are any of the files owned? Mine is just an empty directory tree to /boot/efi/EFI/fedora/. I just checked further and that directory is owned by grub-common, but not the parent directories.
I've just checked my efi directory, and /boot/efi is owned by 'root', as are directories /boot/efi/EFI and /boot/efi/System and file /boot/efi/mach_kernel. Drilling a little bit further directories /boot/efi/EFI/BOOT and /boot/efi/EFI/fedora are also owned by root, as is directory /boot/efi/System/Library, so I'm assuming everything is.
Sorry for not being more clear. I mean owned in the rpm way. If you do "rpm -qf /path/to/file" it will tell you which package put the file (or directory) there.
I'm not concerned so much by the space that structure is using, but more just querying why it is there, and, if I happen to delete that structure will that cause any problems, or, if I do delete it is something going to put it back?
If you don't have an EFI system, then deleting those files shouldn't make any difference. But I'm curious, since you actually have files in there, can you check what package owns them as described above?
On 11/2/18 7:00 pm, Samuel Sieb wrote:
On 02/10/2018 04:27 PM, Stephen Morris wrote:
On 10/2/18 5:46 pm, Samuel Sieb wrote:
On 02/09/2018 09:40 AM, Rick Stevens wrote:
IIRC, /boot/efi/* is created by the initial anaconda install sequence and is in place in case you use UEFI at some point in the future. Since it's only about 15MB in size, it's pretty innocuous and I wouldn't worry about it. Ubuntu's install mechanism isn't the same and it probably doesn't create that directory unless it notices you are in UEFI boot mode at the time of install.
What's in yours? Are any of the files owned? Mine is just an empty directory tree to /boot/efi/EFI/fedora/. I just checked further and that directory is owned by grub-common, but not the parent directories.
I've just checked my efi directory, and /boot/efi is owned by 'root', as are directories /boot/efi/EFI and /boot/efi/System and file /boot/efi/mach_kernel. Drilling a little bit further directories /boot/efi/EFI/BOOT and /boot/efi/EFI/fedora are also owned by root, as is directory /boot/efi/System/Library, so I'm assuming everything is.
Sorry for not being more clear. I mean owned in the rpm way. If you do "rpm -qf /path/to/file" it will tell you which package put the file (or directory) there.
I'm not concerned so much by the space that structure is using, but more just querying why it is there, and, if I happen to delete that structure will that cause any problems, or, if I do delete it is something going to put it back?
If you don't have an EFI system, then deleting those files shouldn't make any difference. But I'm curious, since you actually have files in there, can you check what package owns them as described above?
I've issued the command rpm -qf /boot/efi and it tells me it was owned by fwupdate-efi-10-1.fc27.x86_64.
I've also issue the command rpm -qf /boot/efi/EFI/fedora/grubenv and that is owned by grub2-efi-x64-2.02-19.fc27.x86_64.
The command rpm -qf /boot/efi/mach_kernel tells me it is owned by mactel-boot-0.9-16.fc27.x86_64.
rpm -qf /boot/efi/EFI/fedora/grubx64.efi says it is owned by grub2-efi-x64-2.02-19.fc27.x86_64.
rpm -qf /boot/efi/EFI/fedora/shim.efi says it is owned by shim-x64-13-0.7.x86_64.
I haven't issued the command against the other .efi files in the fedora sudirectory, but from their names I would assume they are owned by multiple different packages. The thing that sticks out with these .efi files in the fedora directory is that fwupia32.efi and fwupx64.efi are executable by owner which is root, but grubx64.efi is world executable, and, those 3 files are the only ones of the 8 .efi files present that are executable.
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 12/2/18 7:58 am, Stephen Morris wrote:
On 11/2/18 7:00 pm, Samuel Sieb wrote:
On 02/10/2018 04:27 PM, Stephen Morris wrote:
On 10/2/18 5:46 pm, Samuel Sieb wrote:
On 02/09/2018 09:40 AM, Rick Stevens wrote:
IIRC, /boot/efi/* is created by the initial anaconda install sequence and is in place in case you use UEFI at some point in the future. Since it's only about 15MB in size, it's pretty innocuous and I wouldn't worry about it. Ubuntu's install mechanism isn't the same and it probably doesn't create that directory unless it notices you are in UEFI boot mode at the time of install.
What's in yours? Are any of the files owned? Mine is just an empty directory tree to /boot/efi/EFI/fedora/. I just checked further and that directory is owned by grub-common, but not the parent directories.
I've just checked my efi directory, and /boot/efi is owned by 'root', as are directories /boot/efi/EFI and /boot/efi/System and file /boot/efi/mach_kernel. Drilling a little bit further directories /boot/efi/EFI/BOOT and /boot/efi/EFI/fedora are also owned by root, as is directory /boot/efi/System/Library, so I'm assuming everything is.
Sorry for not being more clear. I mean owned in the rpm way. If you do "rpm -qf /path/to/file" it will tell you which package put the file (or directory) there.
I'm not concerned so much by the space that structure is using, but more just querying why it is there, and, if I happen to delete that structure will that cause any problems, or, if I do delete it is something going to put it back?
If you don't have an EFI system, then deleting those files shouldn't make any difference. But I'm curious, since you actually have files in there, can you check what package owns them as described above?
I've issued the command rpm -qf /boot/efi and it tells me it was owned by fwupdate-efi-10-1.fc27.x86_64.
I've also issue the command rpm -qf /boot/efi/EFI/fedora/grubenv and that is owned by grub2-efi-x64-2.02-19.fc27.x86_64.
The command rpm -qf /boot/efi/mach_kernel tells me it is owned by mactel-boot-0.9-16.fc27.x86_64.
rpm -qf /boot/efi/EFI/fedora/grubx64.efi says it is owned by grub2-efi-x64-2.02-19.fc27.x86_64.
rpm -qf /boot/efi/EFI/fedora/shim.efi says it is owned by shim-x64-13-0.7.x86_64.
I haven't issued the command against the other .efi files in the fedora sudirectory, but from their names I would assume they are owned by multiple different packages. The thing that sticks out with these .efi files in the fedora directory is that fwupia32.efi and fwupx64.efi are executable by owner which is root, but grubx64.efi is world executable, and, those 3 files are the only ones of the 8 .efi files present that are executable.
Just further to this, I have checked my boot order in the bios and it is set to SSD, CDROM, UEFI: Builtin efi shell.
If at boot time I display the boot menu it shows this as SSD, HARD DISK 1, HARD DISK 2, CDROM 1, CDROM 2, UEFI: Builtin efi shell, with SSD being the default boot device.
Also in the bios Security section I have Secure Boot explicitly disabled, and the bios also says that Secure Boot can only be used if the system is in 'User Mode'.
regards,
Steve
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 02/11/2018 01:19 PM, Stephen Morris wrote:
Just further to this, I have checked my boot order in the bios and it is set to SSD, CDROM, UEFI: Builtin efi shell.
If at boot time I display the boot menu it shows this as SSD, HARD DISK 1, HARD DISK 2, CDROM 1, CDROM 2, UEFI: Builtin efi shell, with SSD being the default boot device.
So you do have an EFI system. You're just booting it by default as CSM. Better not to remove those packages then. :-)
Also in the bios Security section I have Secure Boot explicitly disabled, and the bios also says that Secure Boot can only be used if the system is in 'User Mode'.
Why are you mentioning this? Secure Boot is optional for EFI. You can still boot in EFI mode whether secure boot is enabled or not. But you can't use secure boot if you boot in CSM mode.
On 12/2/18 12:48 pm, Samuel Sieb wrote:
On 02/11/2018 01:19 PM, Stephen Morris wrote:
Just further to this, I have checked my boot order in the bios and it is set to SSD, CDROM, UEFI: Builtin efi shell.
If at boot time I display the boot menu it shows this as SSD, HARD DISK 1, HARD DISK 2, CDROM 1, CDROM 2, UEFI: Builtin efi shell, with SSD being the default boot device.
So you do have an EFI system. You're just booting it by default as CSM. Better not to remove those packages then. :-)
Also in the bios Security section I have Secure Boot explicitly disabled, and the bios also says that Secure Boot can only be used if the system is in 'User Mode'.
Why are you mentioning this? Secure Boot is optional for EFI. You can still boot in EFI mode whether secure boot is enabled or not. But you can't use secure boot if you boot in CSM mode.
I was mentioning this because I thought Secure Boot was EFI (especially when enabling Secure Boot provides me with an option to load default keys if I want to). Also unlike my previous motherboard where the Bios provided me with options to run the system in Legacy Mode, UEFI mode or UEFI first then Legacy, and provide a drag and drop method for boot ordering between Legacy or UEFI devices, the motherboard I am using now does not provide any indication that UEFI is available and whether or not I want to use it, other than the Shell boot order option (which is nothing more than a shell that has to be exited from to actually boot to the grub menu) and the Secure Boot option which I have never seen on any previous motherboard I've had. Hence my assumption, which may be completely wrong, was that whether I was booting UEFI or not was determine by whether I had Secure Boot enabled or not. I was also assuming that as F27 is a double upgrade from F26 that was installed and run in non-UEFI mode (I don't have any efi partitions for any of the 3 operating systems I'm running on this machine) it is running in Legacy mode.
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 02/11/2018 12:58 PM, Stephen Morris wrote:
I've issued the command rpm -qf /boot/efi and it tells me it was owned by fwupdate-efi-10-1.fc27.x86_64.
I've also issue the command rpm -qf /boot/efi/EFI/fedora/grubenv and that is owned by grub2-efi-x64-2.02-19.fc27.x86_64.
The command rpm -qf /boot/efi/mach_kernel tells me it is owned by mactel-boot-0.9-16.fc27.x86_64.
rpm -qf /boot/efi/EFI/fedora/grubx64.efi says it is owned by grub2-efi-x64-2.02-19.fc27.x86_64.
rpm -qf /boot/efi/EFI/fedora/shim.efi says it is owned by shim-x64-13-0.7.x86_64.
Ok, I wonder what pulled all those things in. Those are all the efi boot packages including the mac one! Feel free to remove those packages since they would only be useful on an EFI system.
I haven't issued the command against the other .efi files in the fedora sudirectory, but from their names I would assume they are owned by multiple different packages. The thing that sticks out with these .efi files in the fedora directory is that fwupia32.efi and fwupx64.efi are executable by owner which is root, but grubx64.efi is world executable, and, those 3 files are the only ones of the 8 .efi files present that are executable.
Normally those permission settings are irrelevant because those files should be on the efi partition which is fat32 and doesn't support that.
You might have a look at your partition layout: fdisk -l /dev/sda Also, your UEFI motherboard could be booting in legacy BIOS mode.
A couple of months back, I had to re-arrange a borked Debian install. This is a 4 TB Western Digital Black drive on a UEFI motherboard: [0:root@TUX ~]$ fdisk -l /dev/sda Disk /dev/sda: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors 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: gpt Disk identifier: 170B3F1A-BFD5-4785-B5E8-803B2B036244
Device Start End Sectors Size Type /dev/sda1 2048 6143 4096 2M BIOS boot /dev/sda2 6144 67115007 67108864 32G Linux swap /dev/sda3 67115008 68114432 999425 488M Microsoft basic data /dev/sda4 68116480 7812083341 7743966862 3.6T Linux RAID /dev/sda5 7812083712 7814037134 1953423 953.8M Linux filesystem
I don't remember why I had to define /dev/sda3. I think Debian insisted on it. If the disk doesn't use EFI, you need the 'BIOS boot' partition. It only has to be 1 MB (maybe less) but this was my first time doing this and I wanted to be sure I didn't have to re-arrange partitions again. Lots of copying files and waiting, waiting, waiting. Breaking mirrors and re-syncing them. Lots of fun.
If you are using it as an EFI disk, you need a different partition other than the 'BIOS boot' but don't rememer what it is.
HTH, Bill
On 6/27/2017 9:35 PM, William Mattison wrote:
(replying to all three messages)
When I boot, the bios display says it is UEFI. Am I mis-understanding what that means? Am I mis-using the term?
My /boot directory has only two sub-directories: "grub" and "grub2", no sub-directory "efi".
Each of the two sub-directories has a file called "grub.cfg". The two files are identical, except for permissions.
In /etc/fstab, the UUIDs are already correct, based on output by both the blkid command and the lsblk command (which blkid's man page says I really should use instead).
I tried the grub2-mkconfig command in both sub-directories. Then I rebooted. The new menu has Fedora, other Fedora options, Windows 7 (on /dev/sda1), and Windows 7 (on /dev/sda2). Each option appears to boot up correctly, though I did not attempt to actually log in to a windows account.
Why are there two menu entries for windows? On this system, sda1 is the master boot record, sda2 is the windows partition.
After signing in to Fedora, I get a crash message saying vmlinuz crashed. I couldn't catch the whole message. Yet the system does seem to work. What's going on?
thanks, Bill. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Good evening,
I believe Stan is correct. I built this system 4+ years ago. At that time, it was my understanding that to get a windows-7 and Fedora dual-boot system, I had to install windows-7 first. I think that at that time, windows-7 did not support UEFI. Though I did not explicitly make it so, the windows-7 install made this a non-UEFI (old BIOS?) system. My sense is that that in turn forced the Fedora install to use the old BIOS. I don't recall having any choice in that. My sense is that for me to now try to convert this home system to UEFI would mean a total re-install of both Fedora and windows-7. (Am I correct?) Remembering how much trouble I had with this 4+ years ago, and being a home user, not a sys-admin, I fear such a conversion would take days, and wouldn't really gain me anything.
Questions: When doing my windows patches and scans today, windows automatically downloaded and installed a new device driver for the new hard drive. Do I need to do that in Fedora? Did Fedora automatically do that already? How do I check?
I saw no indication of vmlinuz crashes in the "journalctl -b" output. I also haven't seen any more vmlinuz crash messages. I'll keep watching. I'll be doing the weekly "dnf upgrade" tomorrow; maybe that will fix any problems that do exist.
What log file shows me all attempts to sign in to this system regardless whether they're local or remote, and regardless whether they were successful or not? And where is that log file?
Bill, here's my fdisk output: --------------- -bash.1[~]: fdisk -l /dev/sda Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0xfde8da65
Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT /dev/sda2 206848 1859026943 1858820096 886.4G 7 HPFS/NTFS/exFAT /dev/sda3 1859026944 1860050943 1024000 500M 83 Linux /dev/sda4 1860050944 3907029167 2046978224 976.1G 5 Extended /dev/sda5 1860052992 1876436991 16384000 7.8G 82 Linux swap / Solaris /dev/sda6 1876439040 1981296639 104857600 50G 83 Linux /dev/sda7 1981298688 3907028991 1925730304 918.3G 83 Linux -bash.2[~]: --------------- sda2 is the windows partition, sda6 is the Linux partition, sda7 is Linux "/home".
thanks, Bill.
Allegedly, on or about 29 June 2017, William Mattison sent:
Questions: When doing my windows patches and scans today, windows automatically downloaded and installed a new device driver for the new hard drive. Do I need to do that in Fedora? Did Fedora automatically do that already? How do I check?
Most likely, that would be for resolving some problem with the prior Windows driver for that device. Much less likely, it could be to deal with a problem with the hard drive itself, that someone modified the Windows driver to workaround.
I'm far more inclined to believe that it's the first reason. Different systems release patches all the time, just because one OS finds a problem with their own code doesn't mean that a different one will have the same problem. Unless, the other one made their code by copying ideas from someone else's bad code.
William Mattison:
Questions: When doing my windows patches and scans today, windows automatically downloaded and installed a new device driver for the new hard drive. Do I need to do that in Fedora? Did Fedora automatically do that already? How do I check?
Tim:
Most likely, that would be for resolving some problem with the prior Windows driver for that device. Much less likely, it could be to deal with a problem with the hard drive itself, that someone modified the Windows driver to workaround.
I'm far more inclined to believe that it's the first reason. Different systems release patches all the time, just because one OS finds a problem with their own code doesn't mean that a different one will have the same problem. Unless, the other one made their code by copying ideas from someone else's bad code.
Supplementary: If the updated driver was for a specific drive (it's named for a brand/model by name), I might believe it was the second issue. But it's much more likely to be a driver for the hard drive interface on the computer motherboard.
Most internal hard drive drivers are for the interface, related to the chipset involved (SiS, NVidia, et cetera - yes NVidia make more than graphics chips). And external hard drives drivers (such as USB ones), are probable more for the external interface (the enclosure), rather than the actual disc drive.
On Thu, 29 Jun 2017 03:33:05 -0000 "William Mattison" mattison.computer@yahoo.com wrote:
Good evening,
I believe Stan is correct. I built this system 4+ years ago. At that time, it was my understanding that to get a windows-7 and Fedora dual-boot system, I had to install windows-7 first. I think that at that time, windows-7 did not support UEFI. Though I did not explicitly make it so, the windows-7 install made this a non-UEFI (old BIOS?) system. My sense is that that in turn forced the Fedora install to use the old BIOS. I don't recall having any choice in that. My sense is that for me to now try to convert this home system to UEFI would mean a total re-install of both Fedora and windows-7. (Am I correct?) Remembering how much trouble I had with this 4+ years ago, and being a home user, not a sys-admin, I fear such a conversion would take days, and wouldn't really gain me anything.
I agree. I don't know the procedure to switch over, though EFI requires a larger reserved area at the start of the hard drive, so you would at least have to change the layout of your drive. I think that EFI is more secure if you are using a mobile device, but for a home user of a desktop it probably provides little benefit.
Questions: When doing my windows patches and scans today, windows automatically downloaded and installed a new device driver for the new hard drive. Do I need to do that in Fedora? Did Fedora automatically do that already? How do I check?
I think Tim has the right of it in his answer. Every time you update your kernel in Fedora, you update your drivers with any changes that have been made to them. It's possible that the vendor has proprietary enhancements in the windows driver specific to the drive. Those might or might not be in the linux driver, depending on whether they have been reverse engineered. They won't affect standard SATA functionality, they will probably be for windows specific reporting for performance statistics via vendor supplied windows software.
I saw no indication of vmlinuz crashes in the "journalctl -b" output. I also haven't seen any more vmlinuz crash messages. I'll keep watching. I'll be doing the weekly "dnf upgrade" tomorrow; maybe that will fix any problems that do exist.
What log file shows me all attempts to sign in to this system regardless whether they're local or remote, and regardless whether they were successful or not? And where is that log file?
Do a journalctl -r and then search for the phrase LOGIN ON /LOGIN ON
The journal files are all under /var/log/journal, but they are not human readable.
On 06/28/2017 08:33 PM, William Mattison wrote:
I believe Stan is correct. I built this system 4+ years ago. At that time, it was my understanding that to get a windows-7 and Fedora dual-boot system, I had to install windows-7 first. I think that at that time, windows-7 did not support UEFI. Though I did not explicitly make it so, the windows-7 install made this a non-UEFI (old BIOS?) system. My sense is that that in turn forced the Fedora install to use the old BIOS. I don't recall having any choice in that. My sense is that for me to now try to convert this home system to UEFI would mean a total re-install of both Fedora and windows-7. (Am I correct?) Remembering how much trouble I had with this 4+ years ago, and being a home user, not a sys-admin, I fear such a conversion would take days, and wouldn't really gain me anything.
If it's working now, then no, there's unlikely to be any benefit, but a lot of work to change it over, especially for windows.
Questions: When doing my windows patches and scans today, windows automatically downloaded and installed a new device driver for the new hard drive. Do I need to do that in Fedora? Did Fedora automatically do that already? How do I check?
That could just be the Windows message for "something changed". The new hard drive is a different brand or different model, so Windows was just updating it's internal records.
Good afternoon,
I found the login attempts in the journalctl output, though it isn't easy. I'll open a new thread to address what this is really about.
Before the hard drive replacement, the grub menu showed the three most recent Fedora patches, then something like "Advanced options for Fedora>", then a Windows (or DOS) option. The menu entries for each of the three most recent Fedora patches looked like this: Fedora (4.11.5-200.fc25.x86_64) 25 (Twenty Five) but with different numbers. Now there is only one Fedora option, and it merely says "Fedora". I did my weekly "dnf upgrade" earlier this afternoon, and it did update the kernel. But the grub menu did not visibly change. I would like it the way it was before the hard drive replacement: three Fedora entries formatted like the one I showed a few lines above here. How do I get it to be that way?
After the grub menu disappears but before the three small whitish rectangles appear, some boot logging shows up in a very large font. Before doing the "grub2-mkconfig", that logging showed up in a much smaller font. The same is true of logging that shows up after the three small rectangles disappear, but before the login GUI shows up. How do I get the font for the boot logging to be a small font?
thank-you in advance, Bill.
On Thu, 29 Jun 2017 21:56:05 -0000 "William Mattison" mattison.computer@yahoo.com wrote:
Good afternoon,
I found the login attempts in the journalctl output, though it isn't easy. I'll open a new thread to address what this is really about.
Before the hard drive replacement, the grub menu showed the three most recent Fedora patches, then something like "Advanced options for Fedora", then a Windows (or DOS) option.
[snip]
How do I get it to be that way?
Add the entry GRUB_DISABLE_SUBMENU=y to the /etc/default/grub file.
PS those are kernels, not patches; each line represents a different kernel that you can boot with.
After the grub menu disappears but before the three small whitish rectangles appear, some boot logging shows up in a very large font. Before doing the "grub2-mkconfig", that logging showed up in a much smaller font. The same is true of logging that shows up after the three small rectangles disappear, but before the login GUI shows up. How do I get the font for the boot logging to be a small font?
Try adding the entry GRUB_GFXPAYLOAD_LINUX=text to the /etc/default/grub file. You might have to play with this a little. To examine the possibilities look in the documentation for grub2 options about GFX using pinfo grub2
Add the entry GRUB_DISABLE_SUBMENU=y to the /etc/default/grub file.
That made no difference. Then I did "grub2-mkconfig". Still no difference.
Try adding the entry GRUB_GFXPAYLOAD_LINUX=text to the /etc/default/grub file. You might have to play with this a little. To examine the possibilities look in the documentation for grub2 options about GFX using pinfo grub2
I couldn't find anything about GFX, GRUB_GFXPAYLOAD_LINUX, or GFXPAYLOAD in the pinfo output. I found some documentation in the GNU GRUB web site. Based on that, I tried "auto" on the right side of the '='. No difference, even after re-running grub2-mkconfig. It's not the text in the grub menu or the grub shell that I'm trying to change. It's the text of the boot logging that shows up after the grub menu goes away (times out), or after I hit the enter key to select "Fedora" for booting. Is that what GRUB_GFXPAYLOAD_LINUX controls? The GNU documentation gave no examples (that I saw) of what to put on the right side of the '='. What goes there?
thanks, Bill.
On Fri, 30 Jun 2017 04:29:12 -0000 "William Mattison" mattison.computer@yahoo.com wrote:
Add the entry GRUB_DISABLE_SUBMENU=y to the /etc/default/grub file.
That made no difference. Then I did "grub2-mkconfig". Still no difference.
Try GRUB_DISABLE_SUBMENU=true The documentation could be out of date. That's what's in my /etc/default/grub file, and I commented it out in order to get the style of grub.cfg *with* submenus, and that worked. You do have to regenerate the grub.cfg file in order for these settings to take effect, and you have to do it in the /boot/grub2 directory with the -o command, grub2-mkconfig -o grub.cfg You probably did it this way, but it isn't clear to me from your description, so I thought I'd say it again.
Try adding the entry GRUB_GFXPAYLOAD_LINUX=text to the /etc/default/grub file. You might have to play with this a little. To examine the possibilities look in the documentation for grub2 options about GFX using pinfo grub2
I couldn't find anything about GFX, GRUB_GFXPAYLOAD_LINUX, or GFXPAYLOAD in the pinfo output. I found some documentation in the GNU GRUB web site. Based on that, I tried "auto" on the right side of the '='. No difference, even after re-running grub2-mkconfig. It's not the text in the grub menu or the grub shell that I'm trying to change. It's the text of the boot logging that shows up after the grub menu goes away (times out), or after I hit the enter key to select "Fedora" for booting. Is that what GRUB_GFXPAYLOAD_LINUX controls? The GNU documentation gave no examples (that I saw) of what to put on the right side of the '='. What goes there?
All of these settings are under Configuration -> Simple Configuration from the main menu for pinfo grub2. If I understand what you are saying correctly, yes, that is what GFXPAYLOAD controls.
If you changed those in the /etc/default/grub file, and ran the above command again, and it didn't change the boot messages, then that isn't the setting you need. Try, order matters, GRUB_GFXMODE=1920x1080,1600x900,1280x720,1024x576,auto GRUB_GFXPAYLOAD_LINUX=keep The early boot is problematic because the video modes available to grub2 are restricted, so you might not be able to get what you want there.
Good evening,
I did what was advised. Still no change. But I think there is a more fundamental problem here. The grub on my system came from"Boot-Repair-Disk", on a live-usb stick, not from any dnf install from a Fedora repository. So if Fedora's grub is customized or specialized in some way, I don't have that.
This shows that the grub.cfg file is getting updated by grub2-mkconfig: bash.8[grub2]: ls -l /etc/default/grub -------------------- -rw-r--r--. 1 root root 463 Jun 30 18:34 /etc/default/grub bash.9[grub2]: ls -l grub.cfg -rw-------. 1 root root 14507 Jun 30 18:37 grub.cfg bash.10[grub2]: -------------------- The title at the top og GRUB's script-editing window reads "GNU GRUB version 2.02~beta3-5".
The grub.cfg file has these lines for the first grub menu entry: -------------------- ### BEGIN /etc/grub.d/10_linux ### menuentry 'Fedora (4.11.6-201.fc25.x86_64) 25 (Twenty Five)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.11.6-201.fc25.x86_64-advanced-45e553d2-fa0c-4eae-95f6-7bf9086ab74c' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd0,msdos3' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3 --hint='hd0,msdos3' c6db3d91-f891-48a2-ae61-28ad5cc9c3a6 else search --no-floppy --fs-uuid --set=root c6db3d91-f891-48a2-ae61-28ad5cc9c3a6 fi linux16 /vmlinuz-4.11.6-201.fc25.x86_64 root=UUID=45e553d2-fa0c-4eae-95f6-7bf9086ab74c ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 vconsole.keymap=us rhgb quiet nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off modprobe.blacklist=nouveau initrd16 /initramfs-4.11.6-201.fc25.x86_64.img } --------------------
But when I reboot, the grub menu shows up, the first entry simply says "Fedora". When "Fedora" is highlighted, and I hit the 'e' key, a script editing window appears. In that script, the numbers for vmlinuz and initramfs are 4.11.5, not 4.11.6.
And I do have version4.11.6 of the kernel, though it's version 4.11.5 that's being booted: -------------------- bash.11[grub2]: dnf list kernel Last metadata expiration check: 3:20:59 ago on Fri Jun 30 16:16:09 2017. Installed Packages kernel.x86_64 4.11.4-200.fc25 @updates kernel.x86_64 4.11.5-200.fc25 @updates kernel.x86_64 4.11.6-201.fc25 @updates Available Packages kernel.x86_64 4.11.7-200.fc25 updates bash.12[grub2]: uname -a Linux coyote 4.11.5-200.fc25.x86_64 #1 SMP Wed Jun 14 17:17:29 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux bash.13[grub2]: --------------------
From all the above, my sense is that something more fundamental is wrong. What, I don't know.
Earlier today, as suggested by this list's guidelines, I created a Fedora People account so I could have a place to post things (logs, files, screen captures, etc.) for members of this list to view. But when I do the ssh command to connect, all I get is "permission denied". I was hoping to put a few files out there for you to examine for better clues. I'm guessing that that will now have to wait until after the Independence Day holiday.
thanks, Bill.
On 06/30/2017 06:50 PM, William Mattison wrote:
I did what was advised. Still no change. But I think there is a more fundamental problem here. The grub on my system came from"Boot-Repair-Disk", on a live-usb stick, not from any dnf install from a Fedora repository. So if Fedora's grub is customized or specialized in some way, I don't have that.
You might have found the problem there. Try running "grub2-install /dev/sda" and see if that makes a difference.
That solved the more important part of the problem. The grub menu has an entry for the correct, current kernel, and it boots the correct current kernel. Thank-you, Sam.
On May 19, I started a thread called "ACPI errors (was: f24 boot fails; need help)". The error messages that I reported there showed up during the boot process as well as in the journalctl log. For a while in June, they showed up during the boot process in a small font. Now they show up in a big font. That's an example of what I'm wanting to display in a small font. This would allow more of the line (and more lines) to fit on the screen. Since they showed up in a small font for a while last month, it must be possible. Here's my /etc/default/grub file: --------------- GRUB_TIMEOUT=10 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 vconsole.keymap=us rhgb quiet nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off modprobe.blacklist=nouveau" #GRUB_DISABLE_RECOVERY="true" GRUB_THEME="/boot/grub2/themes/system/theme.txt" GRUB_DISABLE_SUBMENU=true GRUB_GFXMODE=1920x1080,1600x900,1280x720,1024x576,auto GRUB_GFXPAYLOAD_LINUX=keep --------------- Any ideas?
thanks, Bill.
On 07/02/2017 07:43 PM, William Mattison wrote:
On May 19, I started a thread called "ACPI errors (was: f24 boot fails; need help)". The error messages that I reported there showed up during the boot process as well as in the journalctl log. For a while in June, they showed up during the boot process in a small font. Now they show up in a big font. That's an example of what I'm wanting to display in a small font. This would allow more of the line (and more lines) to fit on the screen. Since they showed up in a small font for a while last month, it must be possible. Here's my /etc/default/grub file:
GRUB_TIMEOUT=10 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 vconsole.keymap=us rhgb quiet nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off modprobe.blacklist=nouveau" #GRUB_DISABLE_RECOVERY="true" GRUB_THEME="/boot/grub2/themes/system/theme.txt" GRUB_DISABLE_SUBMENU=true GRUB_GFXMODE=1920x1080,1600x900,1280x720,1024x576,auto GRUB_GFXPAYLOAD_LINUX=keep
Any ideas?
Is that what you had in the file before? I expect that those settings will force the kernel to use real text mode with the standard 80x25 characters when booting instead of switching to a graphical console where it can use a smaller font. Why do you have the "video=vesa:off" parameter? Is the grub font different now than it was before as well?
Which is best: 1. completely remove the "video=vesa:off" from the GRUB_CMDLINE_LINUX line, or 2. change the "off" to "on" in that line? I would not be surprised if it could make it significant difference.
The font used in the grub menu and the grub shell has been a good size all along, and has not changed. The only changes I made to the grub file are those that you advised. Everything else in that file, including that "video=vesa:off", is either "factory settings", or put there last month by "Boot-Repair-Disk", or put there by the quasi-weekly "dnf upgrade" run, or put there by the quasi-semi-annual upgrade from f[n] to f[n+1].
thanks, Bill.
On 07/03/2017 09:58 AM, William Mattison wrote:
Which is best:
- completely remove the "video=vesa:off" from the GRUB_CMDLINE_LINUX line,
or 2. change the "off" to "on" in that line?
Just remove it. Are you using the proprietary NVidia driver? Is that why you have all the blacklisting?
On 7/7/17 2:25 pm, Samuel Sieb wrote:
On 07/03/2017 09:58 AM, William Mattison wrote:
Which is best:
- completely remove the "video=vesa:off" from the GRUB_CMDLINE_LINUX
line, or 2. change the "off" to "on" in that line?
Just remove it. Are you using the proprietary NVidia driver? Is that why you have all the blacklisting?
I am running the nvidia proprietary driver as provided from the negativo17 repositories rather than rpmfusion, and the installation of that driver does insert the nouveau blacklisting options (I think this is a work-around to having to remove the nouveau driver from the initramfs file as the two can't co-exist), but I also have gfxpayload=vga=1600x1200x32 manually specified as well to control the resolution that grub is using when it displays its menu.
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 3/7/17 12:43 pm, William Mattison wrote:
That solved the more important part of the problem. The grub menu has an entry for the correct, current kernel, and it boots the correct current kernel. Thank-you, Sam.
Just some info on this. The original format of your grub menu, being one line per kernel, was probably coming from grubby. When kernel installs are done, the install process runs grubby by default to build grub.cfg and update the mbr (in a non-efi system) and grubby builds grub.cfg with a line per kernel. I don't like that format so after every kernel install I manually run grub2-mkconfig and grub2-install to get the menu with a single line for the current kernel and and Advanced sub-menu for the other kernels. This implements the same structure for Ubuntu with I boot into as well as Windows 10.
regards,
Steve
On May 19, I started a thread called "ACPI errors (was: f24 boot fails; need help)". The error messages that I reported there showed up during the boot process as well as in the journalctl log. For a while in June, they showed up during the boot process in a small font. Now they show up in a big font. That's an example of what I'm wanting to display in a small font. This would allow more of the line (and more lines) to fit on the screen. Since they showed up in a small font for a while last month, it must be possible. Here's my /etc/default/grub file:
GRUB_TIMEOUT=10 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 vconsole.keymap=us rhgb quiet nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off modprobe.blacklist=nouveau" #GRUB_DISABLE_RECOVERY="true" GRUB_THEME="/boot/grub2/themes/system/theme.txt" GRUB_DISABLE_SUBMENU=true GRUB_GFXMODE=1920x1080,1600x900,1280x720,1024x576,auto GRUB_GFXPAYLOAD_LINUX=keep
Any ideas?
thanks, Bill. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Hi.
On Sun, 11 Feb 2018 12:07:50 +1100 Stephen Morris wrote:
Just some info on this. The original format of your grub menu, being one line per kernel, was probably coming from grubby. When kernel installs are done, the install process runs grubby by default to build grub.cfg and update the mbr (in a non-efi system) and grubby builds grub.cfg with a line per kernel. I don't like that format so after every kernel install I manually run grub2-mkconfig and grub2-install to get the menu with a single line for the current kernel and and Advanced sub-menu for the other kernels.
You can make that automatic by adding a script in
/etc/kernel/postinst.d/
to call grub2-mkconfig -o ...
grub2-install is not needed I think.
On 11/2/18 5:46 pm, Francis.Montagnac@inria.fr wrote:
Hi.
On Sun, 11 Feb 2018 12:07:50 +1100 Stephen Morris wrote:
Just some info on this. The original format of your grub menu, being one line per kernel, was probably coming from grubby. When kernel installs are done, the install process runs grubby by default to build grub.cfg and update the mbr (in a non-efi system) and grubby builds grub.cfg with a line per kernel. I don't like that format so after every kernel install I manually run grub2-mkconfig and grub2-install to get the menu with a single line for the current kernel and and Advanced sub-menu for the other kernels.
You can make that automatic by adding a script in
/etc/kernel/postinst.d/
to call grub2-mkconfig -o ...
grub2-install is not needed I think.
Thanks Francis, I'll check that out. Grub2-install is still required to update the mbr on non-efi (legacy) systems.
regards,
Steve
On 02/11/2018 01:23 PM, Stephen Morris wrote:
On 11/2/18 5:46 pm, Francis.Montagnac@inria.fr wrote:
grub2-install is not needed I think.
Thanks Francis, I'll check that out. Grub2-install is still required to update the mbr on non-efi (legacy) systems.
That's true, but it very rarely needs the boot sector loader updated. Also, I don't know what grub2-install would do to a GPT formatted disk.
On Sun, Feb 11, 2018 at 8:50 PM, Samuel Sieb samuel@sieb.net wrote:
On 02/11/2018 01:23 PM, Stephen Morris wrote:
On 11/2/18 5:46 pm, Francis.Montagnac@inria.fr wrote:
grub2-install is not needed I think.
Thanks Francis, I'll check that out. Grub2-install is still required to update the mbr on non-efi (legacy) systems.
That's true, but it very rarely needs the boot sector loader updated. Also, I don't know what grub2-install would do to a GPT formatted disk.
You can specify "TARGET" with "--target=". From the man page:
--target=TARGET
install GRUB for TARGET platform [default=i386-pc]; available targets: arm-efi ... arm64-efi ... i386-efi ... ia64-efi ... x86_64-efi ...
On 12/2/18 9:12 pm, Tom H wrote:
On Sun, Feb 11, 2018 at 8:50 PM, Samuel Sieb samuel@sieb.net wrote:
On 02/11/2018 01:23 PM, Stephen Morris wrote:
On 11/2/18 5:46 pm, Francis.Montagnac@inria.fr wrote:
grub2-install is not needed I think.
Thanks Francis, I'll check that out. Grub2-install is still required to update the mbr on non-efi (legacy) systems.
That's true, but it very rarely needs the boot sector loader updated. Also, I don't know what grub2-install would do to a GPT formatted disk.
You can specify "TARGET" with "--target=". From the man page:
--target=TARGET
install GRUB for TARGET platform [default=i386-pc]; available targets: arm-efi ... arm64-efi ... i386-efi ... ia64-efi ... x86_64-efi ...
Thanks Tom. My statement was from having seen other threads on this list saying to not run grub2-install on an efi system because it wasn't needed.
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On Mon, Feb 12, 2018 at 4:28 PM, Stephen Morris samorris@netspace.net.au wrote:
On 12/2/18 9:12 pm, Tom H wrote:
On Sun, Feb 11, 2018 at 8:50 PM, Samuel Sieb samuel@sieb.net wrote:
Also, I don't know what grub2-install would do to a GPT formatted disk.
You can specify "TARGET" with "--target=". From the man page:
--target=TARGET
install GRUB for TARGET platform [default=i386-pc]; available targets: arm-efi ... arm64-efi ... i386-efi ... ia64-efi ... x86_64-efi ...
Thanks Tom. My statement was from having seen other threads on this list saying to not run grub2-install on an efi system because it wasn't needed.
You're welcome.
Chris M has said that grub2-install shouldn't be used on an EFI system. Maybe it does the wrong thing when you don't specify "--target=...-efi" because the default is "--target=i386-pc".
On 14/2/18 8:18 pm, Tom H wrote:
On Mon, Feb 12, 2018 at 4:28 PM, Stephen Morris samorris@netspace.net.au wrote:
On 12/2/18 9:12 pm, Tom H wrote:
On Sun, Feb 11, 2018 at 8:50 PM, Samuel Sieb samuel@sieb.net wrote:
Also, I don't know what grub2-install would do to a GPT formatted disk.
You can specify "TARGET" with "--target=". From the man page:
--target=TARGET
install GRUB for TARGET platform [default=i386-pc]; available targets: arm-efi ... arm64-efi ... i386-efi ... ia64-efi ... x86_64-efi ...
Thanks Tom. My statement was from having seen other threads on this list saying to not run grub2-install on an efi system because it wasn't needed.
You're welcome.
Chris M has said that grub2-install shouldn't be used on an EFI system. Maybe it does the wrong thing when you don't specify "--target=...-efi" because the default is "--target=i386-pc".
It could be. As I understand it the default functionality updates the mbr on the specified device, and from what I've read in other threads, I thought they said that to get the grub menu displayed at boot you don't update the mbr on an efi system any more, all that is necessary is to just run grub2-mkconfig.
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On Wed, Feb 14, 2018 at 4:51 PM, Stephen Morris samorris@netspace.net.au wrote:
On 14/2/18 8:18 pm, Tom H wrote:
On Mon, Feb 12, 2018 at 4:28 PM, Stephen Morris samorris@netspace.net.au wrote:
Thanks Tom. My statement was from having seen other threads on this list saying to not run grub2-install on an efi system because it wasn't needed.
You're welcome.
Chris M has said that grub2-install shouldn't be used on an EFI system. Maybe it does the wrong thing when you don't specify "--target=...-efi" because the default is "--target=i386-pc".
It could be. As I understand it the default functionality updates the mbr on the specified device, and from what I've read in other threads, I thought they said that to get the grub menu displayed at boot you don't update the mbr on an efi system any more, all that is necessary is to just run grub2-mkconfig.
I'd be surprised if "grub-install" defaults to "--target=i386-pc" on EFI if you don't include "--target=x86_64-efi" n the command. Maybe; but I'd expect grub to detect that it's running on an EFI system...
I think that I now remember Chris M's objection. It's that the EFI executable that "grub-install" drops onto the ESP isn't signed, which is problematic on SB systems. Ubuntu's "grub-install" has a "--uefi-secure-boot" option to install a signed EFI executable (I _assume_ that "/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed" is copied to the ESP) but Fedora's grub doesn't have either of these so Chris must be right for the SB case.
On 20/2/18 3:51 am, Tom H wrote:
On Wed, Feb 14, 2018 at 4:51 PM, Stephen Morris samorris@netspace.net.au wrote:
On 14/2/18 8:18 pm, Tom H wrote:
On Mon, Feb 12, 2018 at 4:28 PM, Stephen Morris samorris@netspace.net.au wrote:
Thanks Tom. My statement was from having seen other threads on this list saying to not run grub2-install on an efi system because it wasn't needed.
You're welcome.
Chris M has said that grub2-install shouldn't be used on an EFI system. Maybe it does the wrong thing when you don't specify "--target=...-efi" because the default is "--target=i386-pc".
It could be. As I understand it the default functionality updates the mbr on the specified device, and from what I've read in other threads, I thought they said that to get the grub menu displayed at boot you don't update the mbr on an efi system any more, all that is necessary is to just run grub2-mkconfig.
I'd be surprised if "grub-install" defaults to "--target=i386-pc" on EFI if you don't include "--target=x86_64-efi" n the command. Maybe; but I'd expect grub to detect that it's running on an EFI system...
I suspect grub is detecting which architecture is in use. In my /boot/efi/EFI/BOOT the only .efi entries in there other than fallback.efi are x86_64 versions. Also in /boot/efi/EFI/fedora fwupdate has made what I assume are its 32-bit and 64-bit .efi files executable and grubx64.efi is also executable. Also /boot/efi/EFI/fedora/grubenv seems to have its only line, being a saved_entry line, updated every time the machine is booted to reflect the version of the kernel last booted from. This surprises me, as I have never installed Win 10, Fedora 27 or Ubuntu 17.10 in efi format, hence as far as I am aware I'm not using efi even though the motherboard I am using now doesn't appear to have any means to explicitly turn efi off, other than the SecureBoot option, which my previous motherboard that did have the capability of explicitly disabling efi didn't have, also I have SecureBoot disabled in the bios.
I think that I now remember Chris M's objection. It's that the EFI executable that "grub-install" drops onto the ESP isn't signed, which is problematic on SB systems. Ubuntu's "grub-install" has a "--uefi-secure-boot" option to install a signed EFI executable (I _assume_ that "/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed" is copied to the ESP) but Fedora's grub doesn't have either of these so Chris must be right for the SB case.
I thought that with SB all your drivers etc had to be signed to be able to boot from a SecureBoot system, and as such Fedora were using Microsoft certificates, whereas Ubuntu was going down the path of self signing. Given what you said around the /usrlib/grub/x86_64-efi-signed directory, which doesn't exist on my system, and if I understood you correctly doesn't exist in fedora anyway, where are fedora's certificates, and, if I enable SecureBoot in my bios do I have to also load the default certificates that the bios offers?
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 02/19/2018 12:13 PM, Stephen Morris wrote:
I thought that with SB all your drivers etc had to be signed to be able to boot from a SecureBoot system, and as such Fedora were using Microsoft certificates, whereas Ubuntu was going down the path of self signing. Given what you said around the /usrlib/grub/x86_64-efi-signed directory, which doesn't exist on my system, and if I understood you correctly doesn't exist in fedora anyway, where are fedora's certificates, and, if I enable SecureBoot in my bios do I have to also load the default certificates that the bios offers?
Each OS has to get their bootloader to be signed by Microsoft's certificate for the BIOS to accept it. It is usually possible to add your own certificate to the BIOS store, but that is a somewhat convoluted process that most users would not want to try going through. Fedora's signed bootloader shim is in the shim-x64 package and the EFI grub executables are in the grub2-efi-x64 package.
On 20/2/18 7:43 pm, Samuel Sieb wrote:
On 02/19/2018 12:13 PM, Stephen Morris wrote:
I thought that with SB all your drivers etc had to be signed to be able to boot from a SecureBoot system, and as such Fedora were using Microsoft certificates, whereas Ubuntu was going down the path of self signing. Given what you said around the /usrlib/grub/x86_64-efi-signed directory, which doesn't exist on my system, and if I understood you correctly doesn't exist in fedora anyway, where are fedora's certificates, and, if I enable SecureBoot in my bios do I have to also load the default certificates that the bios offers?
Each OS has to get their bootloader to be signed by Microsoft's certificate for the BIOS to accept it. It is usually possible to add your own certificate to the BIOS store, but that is a somewhat convoluted process that most users would not want to try going through. Fedora's signed bootloader shim is in the shim-x64 package and the EFI grub executables are in the grub2-efi-x64 package.
Those packages are installed on my system even though, as far as I'm aware I have never had efi active, and I have never used a motherboard that had SecureBoot enabled. I did not explicitly install those packages and my assumption is they were installed with the F27 upgrade, but I can verify whether they were installed in F26 or not.
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Allegedly, on or about 21 February 2018, Stephen Morris sent:
Those packages are installed on my system even though, as far as I'm aware I have never had efi active, and I have never used a motherboard that had SecureBoot enabled. I did not explicitly install those packages and my assumption is they were installed with the F27 upgrade, but I can verify whether they were installed in F26 or not.
On my Fedora 26 installation, which was a 64-bit fresh install on a blank drive, without using any secure boot options, I have these:
~]$ tree /boot/efi/ /boot/efi/ ├── EFI │ ├── BOOT │ │ ├── BOOTX64.EFI │ │ └── fallback.efi │ └── fedora │ ├── BOOT.CSV │ ├── fonts │ │ └── unicode.pf2 │ ├── gcdx64.efi │ ├── grubenv │ ├── grubx64.efi │ ├── MokManager.efi │ ├── shim.efi │ └── shim-fedora.efi ├── mach_kernel └── System └── Library └── CoreServices
And these:
~]$ tree /usr/lib/grub/ /usr/lib/grub/ └── i386-pc ├── acpi.mod ├── acpi.module ├── adler32.mod ├── adler32.module ├── affs.mod ├── affs.module ├── afs.mod ├── afs.module ├── ahci.mod ├── ahci.module ├── all_video.mod ├── all_video.module ├── aout.mod ├── aout.module ├── archelp.mod ├── archelp.module ├── ata.mod ├── ata.module ├── at_keyboard.mod ├── at_keyboard.module ├── backtrace.mod ├── backtrace.module ├── bfs.mod ├── bfs.module ├── biosdisk.mod ├── biosdisk.module ├── bitmap.mod ├── bitmap.module ├── bitmap_scale.mod ├── bitmap_scale.module ├── blocklist.mod ├── blocklist.module ├── blscfg.mod ├── blscfg.module ├── boot_hybrid.image ├── boot_hybrid.img ├── boot.image ├── boot.img ├── boot.mod ├── boot.module ├── bsd.mod ├── bsd.module ├── bswap_test.mod ├── bswap_test.module ├── btrfs.mod ├── btrfs.module ├── bufio.mod ├── bufio.module ├── cat.mod ├── cat.module ├── cbfs.mod ├── cbfs.module ├── cbls.mod ├── cbls.module ├── cbmemc.mod ├── cbmemc.module ├── cbtable.mod ├── cbtable.module ├── cbtime.mod ├── cbtime.module ├── cdboot.image ├── cdboot.img ├── chain.mod ├── chain.module ├── cmdline_cat_test.mod ├── cmdline_cat_test.module ├── cmosdump.mod ├── cmosdump.module ├── cmostest.mod ├── cmostest.module ├── cmp.mod ├── cmp.module ├── cmp_test.mod ├── cmp_test.module ├── command.lst ├── configfile.mod ├── configfile.module ├── config.h ├── cpio_be.mod ├── cpio_be.module ├── cpio.mod ├── cpio.module ├── cpuid.mod ├── cpuid.module ├── crc64.mod ├── crc64.module ├── cryptodisk.mod ├── cryptodisk.module ├── crypto.lst ├── crypto.mod ├── crypto.module ├── cs5536.mod ├── cs5536.module ├── ctz_test.mod ├── ctz_test.module ├── datehook.mod ├── datehook.module ├── date.mod ├── date.module ├── datetime.mod ├── datetime.module ├── diskboot.image ├── diskboot.img ├── diskfilter.mod ├── diskfilter.module ├── disk.mod ├── disk.module ├── div.mod ├── div.module ├── div_test.mod ├── div_test.module ├── dm_nv.mod ├── dm_nv.module ├── drivemap.mod ├── drivemap.module ├── echo.mod ├── echo.module ├── efiemu32.o ├── efiemu64.o ├── efiemu.mod ├── efiemu.module ├── ehci.mod ├── ehci.module ├── elf.mod ├── elf.module ├── eval.mod ├── eval.module ├── exfat.mod ├── exfat.module ├── exfctest.mod ├── exfctest.module ├── ext2.mod ├── ext2.module ├── extcmd.mod ├── extcmd.module ├── fat.mod ├── fat.module ├── file.mod ├── file.module ├── font.mod ├── font.module ├── freedos.mod ├── freedos.module ├── fshelp.mod ├── fshelp.module ├── fs.lst ├── functional_test.mod ├── functional_test.module ├── gcry_arcfour.mod ├── gcry_arcfour.module ├── gcry_blowfish.mod ├── gcry_blowfish.module ├── gcry_camellia.mod ├── gcry_camellia.module ├── gcry_cast5.mod ├── gcry_cast5.module ├── gcry_crc.mod ├── gcry_crc.module ├── gcry_des.mod ├── gcry_des.module ├── gcry_dsa.mod ├── gcry_dsa.module ├── gcry_idea.mod ├── gcry_idea.module ├── gcry_md4.mod ├── gcry_md4.module ├── gcry_md5.mod ├── gcry_md5.module ├── gcry_rfc2268.mod ├── gcry_rfc2268.module ├── gcry_rijndael.mod ├── gcry_rijndael.module ├── gcry_rmd160.mod ├── gcry_rmd160.module ├── gcry_rsa.mod ├── gcry_rsa.module ├── gcry_seed.mod ├── gcry_seed.module ├── gcry_serpent.mod ├── gcry_serpent.module ├── gcry_sha1.mod ├── gcry_sha1.module ├── gcry_sha256.mod ├── gcry_sha256.module ├── gcry_sha512.mod ├── gcry_sha512.module ├── gcry_tiger.mod ├── gcry_tiger.module ├── gcry_twofish.mod ├── gcry_twofish.module ├── gcry_whirlpool.mod ├── gcry_whirlpool.module ├── gdb_grub ├── gdb.mod ├── gdb.module ├── geli.mod ├── geli.module ├── gettext.mod ├── gettext.module ├── gfxmenu.mod ├── gfxmenu.module ├── gfxterm_background.mod ├── gfxterm_background.module ├── gfxterm_menu.mod ├── gfxterm_menu.module ├── gfxterm.mod ├── gfxterm.module ├── gmodule.pl ├── gptsync.mod ├── gptsync.module ├── gzio.mod ├── gzio.module ├── halt.mod ├── halt.module ├── hashsum.mod ├── hashsum.module ├── hdparm.mod ├── hdparm.module ├── hello.mod ├── hello.module ├── help.mod ├── help.module ├── hexdump.mod ├── hexdump.module ├── hfs.mod ├── hfs.module ├── hfspluscomp.mod ├── hfspluscomp.module ├── hfsplus.mod ├── hfsplus.module ├── http.mod ├── http.module ├── iorw.mod ├── iorw.module ├── iso9660.mod ├── iso9660.module ├── jfs.mod ├── jfs.module ├── jpeg.mod ├── jpeg.module ├── kernel.exec ├── kernel.img ├── keylayouts.mod ├── keylayouts.module ├── keystatus.mod ├── keystatus.module ├── ldm.mod ├── ldm.module ├── legacycfg.mod ├── legacycfg.module ├── legacy_password_test.mod ├── legacy_password_test.module ├── linux16.mod ├── linux16.module ├── linux.mod ├── linux.module ├── lnxboot.image ├── lnxboot.img ├── loadenv.mod ├── loadenv.module ├── loopback.mod ├── loopback.module ├── lsacpi.mod ├── lsacpi.module ├── lsapm.mod ├── lsapm.module ├── lsmmap.mod ├── lsmmap.module ├── ls.mod ├── ls.module ├── lspci.mod ├── lspci.module ├── luks.mod ├── luks.module ├── lvm.mod ├── lvm.module ├── lzma_decompress.image ├── lzma_decompress.img ├── lzopio.mod ├── lzopio.module ├── macbless.mod ├── macbless.module ├── macho.mod ├── macho.module ├── mda_text.mod ├── mda_text.module ├── mdraid09_be.mod ├── mdraid09_be.module ├── mdraid09.mod ├── mdraid09.module ├── mdraid1x.mod ├── mdraid1x.module ├── memdisk.mod ├── memdisk.module ├── memrw.mod ├── memrw.module ├── minicmd.mod ├── minicmd.module ├── minix2_be.mod ├── minix2_be.module ├── minix2.mod ├── minix2.module ├── minix3_be.mod ├── minix3_be.module ├── minix3.mod ├── minix3.module ├── minix_be.mod ├── minix_be.module ├── minix.mod ├── minix.module ├── mmap.mod ├── mmap.module ├── moddep.lst ├── modinfo.sh ├── morse.mod ├── morse.module ├── mpi.mod ├── mpi.module ├── msdospart.mod ├── msdospart.module ├── mul_test.mod ├── mul_test.module ├── multiboot2.mod ├── multiboot2.module ├── multiboot.mod ├── multiboot.module ├── nativedisk.mod ├── nativedisk.module ├── net.mod ├── net.module ├── newc.mod ├── newc.module ├── nilfs2.mod ├── nilfs2.module ├── normal.mod ├── normal.module ├── ntfscomp.mod ├── ntfscomp.module ├── ntfs.mod ├── ntfs.module ├── ntldr.mod ├── ntldr.module ├── odc.mod ├── odc.module ├── offsetio.mod ├── offsetio.module ├── ohci.mod ├── ohci.module ├── part_acorn.mod ├── part_acorn.module ├── part_amiga.mod ├── part_amiga.module ├── part_apple.mod ├── part_apple.module ├── part_bsd.mod ├── part_bsd.module ├── part_dfly.mod ├── part_dfly.module ├── part_dvh.mod ├── part_dvh.module ├── part_gpt.mod ├── part_gpt.module ├── partmap.lst ├── part_msdos.mod ├── part_msdos.module ├── part_plan.mod ├── part_plan.module ├── part_sun.mod ├── part_sun.module ├── part_sunpc.mod ├── part_sunpc.module ├── parttool.lst ├── parttool.mod ├── parttool.module ├── password.mod ├── password.module ├── password_pbkdf2.mod ├── password_pbkdf2.module ├── pata.mod ├── pata.module ├── pbkdf2.mod ├── pbkdf2.module ├── pbkdf2_test.mod ├── pbkdf2_test.module ├── pcidump.mod ├── pcidump.module ├── pci.mod ├── pci.module ├── plan9.mod ├── plan9.module ├── play.mod ├── play.module ├── png.mod ├── png.module ├── priority_queue.mod ├── priority_queue.module ├── probe.mod ├── probe.module ├── procfs.mod ├── procfs.module ├── progress.mod ├── progress.module ├── pxeboot.image ├── pxeboot.img ├── pxechain.mod ├── pxechain.module ├── pxe.mod ├── pxe.module ├── raid5rec.mod ├── raid5rec.module ├── raid6rec.mod ├── raid6rec.module ├── random.mod ├── random.module ├── read.mod ├── read.module ├── reboot.mod ├── reboot.module ├── regexp.mod ├── regexp.module ├── reiserfs.mod ├── reiserfs.module ├── relocator.mod ├── relocator.module ├── romfs.mod ├── romfs.module ├── scsi.mod ├── scsi.module ├── search_fs_file.mod ├── search_fs_file.module ├── search_fs_uuid.mod ├── search_fs_uuid.module ├── search_label.mod ├── search_label.module ├── search.mod ├── search.module ├── sendkey.mod ├── sendkey.module ├── serial.mod ├── serial.module ├── setjmp.mod ├── setjmp.module ├── setjmp_test.mod ├── setjmp_test.module ├── setpci.mod ├── setpci.module ├── sfs.mod ├── sfs.module ├── shift_test.mod ├── shift_test.module ├── signature_test.mod ├── signature_test.module ├── sleep.mod ├── sleep.module ├── sleep_test.mod ├── sleep_test.module ├── spkmodem.mod ├── spkmodem.module ├── squash4.mod ├── squash4.module ├── syslinuxcfg.mod ├── syslinuxcfg.module ├── tar.mod ├── tar.module ├── terminal.lst ├── terminal.mod ├── terminal.module ├── terminfo.mod ├── terminfo.module ├── test_blockarg.mod ├── test_blockarg.module ├── testload.mod ├── testload.module ├── test.mod ├── test.module ├── testspeed.mod ├── testspeed.module ├── tftp.mod ├── tftp.module ├── tga.mod ├── tga.module ├── time.mod ├── time.module ├── trig.mod ├── trig.module ├── tr.mod ├── tr.module ├── truecrypt.mod ├── truecrypt.module ├── true.mod ├── true.module ├── udf.mod ├── udf.module ├── ufs1_be.mod ├── ufs1_be.module ├── ufs1.mod ├── ufs1.module ├── ufs2.mod ├── ufs2.module ├── uhci.mod ├── uhci.module ├── usb_keyboard.mod ├── usb_keyboard.module ├── usb.mod ├── usb.module ├── usbms.mod ├── usbms.module ├── usbserial_common.mod ├── usbserial_common.module ├── usbserial_ftdi.mod ├── usbserial_ftdi.module ├── usbserial_pl2303.mod ├── usbserial_pl2303.module ├── usbserial_usbdebug.mod ├── usbserial_usbdebug.module ├── usbtest.mod ├── usbtest.module ├── vbe.mod ├── vbe.module ├── verify.mod ├── verify.module ├── vga.mod ├── vga.module ├── vga_text.mod ├── vga_text.module ├── video_bochs.mod ├── video_bochs.module ├── video_cirrus.mod ├── video_cirrus.module ├── video_colors.mod ├── video_colors.module ├── video_fb.mod ├── video_fb.module ├── videoinfo.mod ├── videoinfo.module ├── video.lst ├── video.mod ├── video.module ├── videotest_checksum.mod ├── videotest_checksum.module ├── videotest.mod ├── videotest.module ├── xfs.mod ├── xfs.module ├── xnu.mod ├── xnu.module ├── xnu_uuid.mod ├── xnu_uuid.module ├── xnu_uuid_test.mod ├── xnu_uuid_test.module ├── xzio.mod ├── xzio.module ├── zfscrypt.mod ├── zfscrypt.module ├── zfsinfo.mod ├── zfsinfo.module ├── zfs.mod └── zfs.module
On Mon, Feb 19, 2018 at 3:13 PM, Stephen Morris samorris@netspace.net.au wrote:
I thought that with SB all your drivers etc had to be signed to be able to boot from a SecureBoot system, and as such Fedora were using Microsoft certificates, whereas Ubuntu was going down the path of self signing. Given what you said around the /usrlib/grub/x86_64-efi-signed directory, which doesn't exist on my system, and if I understood you correctly doesn't exist in fedora anyway, where are fedora's certificates, and, if I enable SecureBoot in my bios do I have to also load the default certificates that the bios offers?
Ubuntu's using an MS sig. The difference between Fedora and Ubuntu is that the latter doesn't require that kernel modules be signed.
The "/usr/lib/grub/x86_64-efi-signed/" is an Ubuntu directory. So the signed grub EFI executable is in "/boot/efi/EFI/ubuntu/" and "/usr/lib/grub/x86_64-efi-signed/". Fedora only ships the grub EFI executable in "/boot/efi/EFI/fedora/". So, if you run "grub-install" it's recreated and unsigned (I assume!).
AFAIK, "shim" is signed by MS (and is validated by an MS-supplied and -signed "thingy" in the firmware) and it embeds the Fedora sig with which grub, the kernel, and the kernel modules are signed and validated.
On 02/20/2018 03:41 AM, Tom H wrote:
Ubuntu's using an MS sig. The difference between Fedora and Ubuntu is that the latter doesn't require that kernel modules be signed.
If that's true, then I think they're in violation of the secure boot rules. And even if not, it makes secure boot ineffective anyway.
AFAIK, "shim" is signed by MS (and is validated by an MS-supplied and -signed "thingy" in the firmware) and it embeds the Fedora sig with which grub, the kernel, and the kernel modules are signed and validated.
Correct.
On Wed, Feb 21, 2018 at 12:54 AM, Samuel Sieb samuel@sieb.net wrote:
On 02/20/2018 03:41 AM, Tom H wrote:
Ubuntu's using an MS sig. The difference between Fedora and Ubuntu is that the latter doesn't require that kernel modules be signed.
If that's true, then I think they're in violation of the secure boot rules. And even if not, it makes secure boot ineffective anyway.
It's a matter of opinion. If MS, as the SB enforcer, thought that Ubuntu was violating SB, it'd have blacklisted its sig from being validated and chainloaded by the MS firmware sig.
On 02/14/2018 01:51 PM, Stephen Morris wrote:
It could be. As I understand it the default functionality updates the mbr on the specified device, and from what I've read in other threads, I thought they said that to get the grub menu displayed at boot you don't update the mbr on an efi system any more, all that is necessary is to just run grub2-mkconfig.
EFI systems have a special partition that contains as many bootloaders as you want. It solves the problem of who gets to control the MBR bootloader location.
On 20/2/18 7:33 pm, Samuel Sieb wrote:
On 02/14/2018 01:51 PM, Stephen Morris wrote:
It could be. As I understand it the default functionality updates the mbr on the specified device, and from what I've read in other threads, I thought they said that to get the grub menu displayed at boot you don't update the mbr on an efi system any more, all that is necessary is to just run grub2-mkconfig.
EFI systems have a special partition that contains as many bootloaders as you want. It solves the problem of who gets to control the MBR bootloader location.
Are they the .efi files that are in /boot/efi/EFI/BOOT on a system that doesn't have the separate partition?
Just on the separate partition front, if I boot between Win 10, Fedora 27 and Ubuntu 17.10 on the one machine, do I need 3 separate partitions or can the 3 operating system share the one partition if I decide to activate efi on my machine?
regards.
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 02/20/2018 01:24 PM, Stephen Morris wrote:
On 20/2/18 7:33 pm, Samuel Sieb wrote:
EFI systems have a special partition that contains as many bootloaders as you want. It solves the problem of who gets to control the MBR bootloader location.
Are they the .efi files that are in /boot/efi/EFI/BOOT on a system that doesn't have the separate partition?
If the files are not on the right partition, then EFI won't boot from them.
Just on the separate partition front, if I boot between Win 10, Fedora 27 and Ubuntu 17.10 on the one machine, do I need 3 separate partitions or can the 3 operating system share the one partition if I decide to activate efi on my machine?
Yes, the point is that there is one partition for all the operating systems to put their bootloaders in.
On 12/2/18 12:50 pm, Samuel Sieb wrote:
On 02/11/2018 01:23 PM, Stephen Morris wrote:
On 11/2/18 5:46 pm, Francis.Montagnac@inria.fr wrote:
grub2-install is not needed I think.
Thanks Francis, I'll check that out. Grub2-install is still required to update the mbr on non-efi (legacy) systems.
That's true, but it very rarely needs the boot sector loader updated. Also, I don't know what grub2-install would do to a GPT formatted disk.
Wouldn't grub2-install be used to install the boot sectors to the /boot partition? This question is coming from the days when I formatted an entire hard disk as GPT and tried to install an older Fedora system on it and had the install fail with the message that Fedora could not be booted from a GPT environment.
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 02/12/2018 01:32 PM, Stephen Morris wrote:
Wouldn't grub2-install be used to install the boot sectors to the /boot partition? This question is coming from the days when I formatted an entire hard disk as GPT and tried to install an older Fedora system on it and had the install fail with the message that Fedora could not be booted from a GPT environment.
There are no boot sectors with EFI. The necessary files that go in the EFI partition at /boot/efi are in the grub2-efi-x64 and shim-x64 packages.
On 20/2/18 7:39 pm, Samuel Sieb wrote:
On 02/12/2018 01:32 PM, Stephen Morris wrote:
Wouldn't grub2-install be used to install the boot sectors to the /boot partition? This question is coming from the days when I formatted an entire hard disk as GPT and tried to install an older Fedora system on it and had the install fail with the message that Fedora could not be booted from a GPT environment.
There are no boot sectors with EFI. The necessary files that go in the EFI partition at /boot/efi are in the grub2-efi-x64 and shim-x64 packages.
This question was not so much aimed at efi, but rather is it still the case that /boot cannot be placed in a GPT partition?
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 02/20/2018 01:27 PM, Stephen Morris wrote:
On 20/2/18 7:39 pm, Samuel Sieb wrote:
On 02/12/2018 01:32 PM, Stephen Morris wrote:
Wouldn't grub2-install be used to install the boot sectors to the /boot partition? This question is coming from the days when I formatted an entire hard disk as GPT and tried to install an older Fedora system on it and had the install fail with the message that Fedora could not be booted from a GPT environment.
There are no boot sectors with EFI. The necessary files that go in the EFI partition at /boot/efi are in the grub2-efi-x64 and shim-x64 packages.
This question was not so much aimed at efi, but rather is it still the case that /boot cannot be placed in a GPT partition?
I don't understand the question. There are no boot sectors in the /boot partition. The boot sector is the MBR on a non-GPT drive. Linux understands GPT partitions just as well as the old style, so if you really want to, you can put /boot on its own GPT partition. On an EFI system, the kernel and initramfs are still in /boot which is not part of the EFI boot partition.
On 21/2/18 5:02 pm, Samuel Sieb wrote:
On 02/20/2018 01:27 PM, Stephen Morris wrote:
On 20/2/18 7:39 pm, Samuel Sieb wrote:
On 02/12/2018 01:32 PM, Stephen Morris wrote:
Wouldn't grub2-install be used to install the boot sectors to the /boot partition? This question is coming from the days when I formatted an entire hard disk as GPT and tried to install an older Fedora system on it and had the install fail with the message that Fedora could not be booted from a GPT environment.
There are no boot sectors with EFI. The necessary files that go in the EFI partition at /boot/efi are in the grub2-efi-x64 and shim-x64 packages.
This question was not so much aimed at efi, but rather is it still the case that /boot cannot be placed in a GPT partition?
I don't understand the question. There are no boot sectors in the /boot partition. The boot sector is the MBR on a non-GPT drive. Linux understands GPT partitions just as well as the old style, so if you really want to, you can put /boot on its own GPT partition. On an EFI system, the kernel and initramfs are still in /boot which is not part of the EFI boot partition.
My question around the time I was installing, I think F26 from scratch the first time on my 2 TB hard disk that now has both Fedora and Ubuntu on it. As a trial I made the entire hard disk GPT. I then ran the install process for Fedora from a live disk, I can't remember exactly where in the install process this happened, but the install aborted with the message that Fedora cannot be booted from a GPT disk. Not understanding the message I did searches for the message on the net and all the hits I found said the same thing, that Fedora cannot be booted from GPT.
Hence I'm asking with the current Fedora version is it still the case that Fedora cannot be booted from GPT?
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 02/21/2018 12:35 PM, Stephen Morris wrote:
My question around the time I was installing, I think F26 from scratch the first time on my 2 TB hard disk that now has both Fedora and Ubuntu on it. As a trial I made the entire hard disk GPT. I then ran the install process for Fedora from a live disk, I can't remember exactly where in the install process this happened, but the install aborted with the message that Fedora cannot be booted from a GPT disk. Not understanding the message I did searches for the message on the net and all the hits I found said the same thing, that Fedora cannot be booted from GPT.
Hence I'm asking with the current Fedora version is it still the case that Fedora cannot be booted from GPT?
I'm curious about the exact error message because Fedora has been able to boot from GPT for several versions. You do need to match an EFI boot with a GPT partition or a BIOS boot with an MSDOS partition otherwise there are complications.
On 22/2/18 7:43 am, Samuel Sieb wrote:
On 02/21/2018 12:35 PM, Stephen Morris wrote:
My question around the time I was installing, I think F26 from scratch the first time on my 2 TB hard disk that now has both Fedora and Ubuntu on it. As a trial I made the entire hard disk GPT. I then ran the install process for Fedora from a live disk, I can't remember exactly where in the install process this happened, but the install aborted with the message that Fedora cannot be booted from a GPT disk. Not understanding the message I did searches for the message on the net and all the hits I found said the same thing, that Fedora cannot be booted from GPT.
Hence I'm asking with the current Fedora version is it still the case that Fedora cannot be booted from GPT?
I'm curious about the exact error message because Fedora has been able to boot from GPT for several versions. You do need to match an EFI boot with a GPT partition or a BIOS boot with an MSDOS partition otherwise there are complications.
At the time that I was doing this, GPT was being specified as designed for hard disks bigger than 3TB (I think this was the size) and even though I only had a 2TB hard disk I thought I would try it out, and I had efi disabled in the motherboard bios. I may be remember this incorrectly, but I think I got through to the process to set up the partitions on the GPT disk, and as I run with a separate /boot partition I went to create that and that is when it said the Fedora could not be booted from a GPT device. I can't replicate this as I don't have an environment that I can wipe to try GPT out again.
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Good evening,
Neither changing nor removing the "video=" part of the /etc/default/grub file had any effect. But the bigness of the font in the real-time boot log display is a cosmetic issue. The grub menu is now as it should be, and the system boots correctly. That was the real issue. So I consider this issue solved.
I thank everyone who tried to help. This home user could not have done it without you.
Bill.