After many years of maintaing dual boot setups (Fedora/Windows) my harddisk layout got a bit confusing: Linux and Windows partition were scattered on mainly two harddisks (all gpt). I was able to free a third harddisk (ssd) and copied the linux partitions boot, root and home over to the new disk, where they now reside as /dev/sda1, /dev/sda2 and /dev/sda3. I left the efi-partition on the disk /dev/sdc together with Windows 11. As in /etc/fstab all partitions are identified by their UUID, I didn't feel a need to adjust that file. Trying to boot brought me to the grub command line prompt. After some trial and error, the appropriate sequence of grub commands (set root=..., linux ..., initrd ...) made the system boot into a fully working Fedora 39 installation. From there I tried to repair GRUB2, following the guidelines at https://fedoraproject.org/wiki/GRUB_2?rd=Grub2#Updating_GRUB_2_configuration... namely those three steps:
# rm /boot/efi/EFI/fedora/grub.cfg # rm /boot/grub2/grub.cfg # dnf reinstall shim-* grub2-efi-* grub2-common
But rebooting still gets me to the dreaded grub>. So what am I missing? BTW, I did NOT use the grub2-install command which shoud not be used on UEFI systems.
On Wed, Apr 17, 2024 at 10:48 AM Klaus-Peter Schrage via users users@lists.fedoraproject.org wrote:
But rebooting still gets me to the dreaded grub>. So what am I missing? BTW, I did NOT use the grub2-install command which shoud not be used on UEFI systems.
I recently had similar problems. These are the things to check: o use blkid to get the current UUID(s) o check /etc/kernel/cmdline if it exists - make sure the UUID (if used) is correct for the new root disk o check /boot/efi/EFI/fedora/grub.cfg for correct UUID(s) - as far as I am aware you would have to edit the file to fix o check /boot/grub2/grub.cfg for correct UUID(s) - you should be able to update if needed with "grub2-mkconfig -o /boot/grub2/grub.cfg" o update /etc/fstab with any changed UUIDs o these things get recorded in the initramfs - update with "dracut --force --regenerate-all" [or use "man dracut" for commands to just regenerate a single initramfs]
As I recall at least one of the above things has tripped me up in the past when moving disks/partitions around.
Thanks for your quick reply!
I faintly remembered the dracut thing, so I tried that first - but it didn't help.
I will look into the UUID stuff tomorrow, although I had already checked that gparted really did not change UUIDs when moving partitions around. And as I said, I can get into Fedora after fiddling with the Grub commandline.
And, as an aside, when I simply exit the grub command line without doing anything else, I boot into Windows immediately!?
But, as I said, I will recheck everything you mentioned. Cheers
Am 17.04.2024 um 17:51 schrieb Go Canes:
On Wed, Apr 17, 2024 at 10:48 AM Klaus-Peter Schrage via users users@lists.fedoraproject.org wrote:
But rebooting still gets me to the dreaded grub>. So what am I missing? BTW, I did NOT use the grub2-install command which shoud not be used on UEFI systems.
I recently had similar problems. These are the things to check: o use blkid to get the current UUID(s) o check /etc/kernel/cmdline if it exists - make sure the UUID (if used) is correct for the new root disk o check /boot/efi/EFI/fedora/grub.cfg for correct UUID(s) - as far as I am aware you would have to edit the file to fix o check /boot/grub2/grub.cfg for correct UUID(s) - you should be able to update if needed with "grub2-mkconfig -o /boot/grub2/grub.cfg" o update /etc/fstab with any changed UUIDs o these things get recorded in the initramfs - update with "dracut --force --regenerate-all" [or use "man dracut" for commands to just regenerate a single initramfs]
As I recall at least one of the above things has tripped me up in the past when moving disks/partitions around. --
On Wed, Apr 17, 2024 at 12:42 PM Klaus-Peter Schrage via users users@lists.fedoraproject.org wrote:
I faintly remembered the dracut thing, so I tried that first - but it didn't help.
If the other problems aren't resolved, rebuilding initramfs probably won't help.
I will look into the UUID stuff tomorrow, although I had already checked that gparted really did not change UUIDs when moving partitions around. And as I said, I can get into Fedora after fiddling with the Grub commandline.
Make sure you are looking at the correct UUIDs. Each partition will have a UUID and a PARTUUID. In my case I needed the *new* UUID for the root partition in both of the grub.cfg files (*not* the PARTUUID). IIRC, I was getting dropped into the dracut shell (not grub) until I updated both of the grub.cfg files, and then was stopped at the grub prompt until I found and updated /etc/kernel/cmdline *and* rebuilt the initramfs.
So maybe you just need that last bit....
When I did my updates, I knew I needed to update /etc/fstab and /boot/grub2/grub.cfg, and rebuild initramfs, but was not aware of the EFI grub.cfg, and then was not aware of dracut using /etc/kernel/cmdline as part of the initramfs. It was an interesting adventure digging through all the google results until I found the relevant info.
Am 17.04.24 um 17:51 schrieb Go Canes: Step by step:
I recently had similar problems. These are the things to check: o use blkid to get the current UUID(s)
The current UUIDs correspond to the ones in /etc/fstab, that hadn't been changed btw.
o check /etc/kernel/cmdline if it exists - make sure the UUID (if used) is correct for the new root disk
root=UUID=047db84f-e100-4696-9c6b-b2e48fb11c55 ro That points to the new (and old) root partition
o check /boot/efi/EFI/fedora/grub.cfg for correct UUID(s) - as far as I am aware you would have to edit the file to fix
"search --no-floppy --root-dev-only --fs-uuid --set=dev ea60d506-7eb7-4174-ae54-5b47c7d08e17 set prefix ..." This UUID points to my /boot paretition - that should be ok?
o check /boot/grub2/grub.cfg for correct UUID(s) - you should be able to update if needed with "grub2-mkconfig -o /boot/grub2/grub.cfg"
There was one suspicious UUID concerning the kernel resume parameter. It pointed to a swap partition which was no longer present for a while. I deleted the corresponding line from /etc/default/grub and updated /boot/grub2/grub.cfg
o update /etc/fstab with any changed UUIDs
see above
o these things get recorded in the initramfs - update with "dracut --force --regenerate-all" [or use "man dracut" for commands to just regenerate a single initramfs]
I did that again, no success
In your other post, you mentioned PARTUUIDs. Frankly, I didn't know much about them, and I definitely didn't use them. But, as Felix had proposed in his post, I dived a bit deeper into efibootmgr (also new to me up to know), and found out that entries point to PARTUUIDs, in my case: FedoraHD(3,GPT,1ca6f5eb-cbea-11e9-a525-4ccc6ad8789c,0x24fc9800,0x32000)/\EFI\FEDORA\SHIM.EFI0000424f Windows Boot Manager HD(1,GPT,1ca6f5ea-cbea-11e9-a525-4ccc6ad8789c,0x800,0x24c60000)/\EFI\Microsoft\Boot\bootmgfw.efi0000424f
And I found, that two partitions (EFI, Windows) on my third harddisk have the same PARUUID:
/dev/sdc1: LABEL="WIN" BLOCK_SIZE="512" UUID="A1C61D016294FB66" TYPE="ntfs" PARTUUID="1ca6f5ea-cbea-11e9-a525-4ccc6ad8789c" /dev/sdc3: UUID="BEAD-09C3" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="1ca6f5eb-cbea-11e9-a525-4ccc6ad8789c" I don't know if that really matters ...
On Fri, Apr 19, 2024 at 9:31 AM Klaus-Peter Schrage via users users@lists.fedoraproject.org wrote:
But, as Felix had proposed in his post, I dived a bit deeper into efibootmgr (also new to me up to know), and found out that entries point to PARTUUIDs, in my case: FedoraHD(3,GPT,1ca6f5eb-cbea-11e9-a525-4ccc6ad8789c,0x24fc9800,0x32000)/\EFI\FEDORA\SHIM.EFI0000424f Windows Boot Manager HD(1,GPT,1ca6f5ea-cbea-11e9-a525-4ccc6ad8789c,0x800,0x24c60000)/\EFI\Microsoft\Boot\bootmgfw.efi0000424f
And I found, that two partitions (EFI, Windows) on my third harddisk have the same PARUUID:
/dev/sdc1: LABEL="WIN" BLOCK_SIZE="512" UUID="A1C61D016294FB66" TYPE="ntfs" PARTUUID="1ca6f5ea-cbea-11e9-a525-4ccc6ad8789c" /dev/sdc3: UUID="BEAD-09C3" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="1ca6f5eb-cbea-11e9-a525-4ccc6ad8789c" I don't know if that really matters ...
I don't think this matters for your Linux boot - no idea if it matters for your Windows boot.
The basic process is EFI is using its variables (which you can examine with efibootmgr) to find a device and the file on the device to use for the boot. That should be on the *.efi files in /boot/efi/EFI/fedora/. That in term should load grub2, which will then use /boot/efi/EFI/fedora/grub.cfg. It then uses this to find the device with /boot/grub2/grub.cfg.
As an example, here are the relevant bits from my system: [root@fubar ~]# efibootmgr BootCurrent: 0003 Timeout: 0 seconds BootOrder: 0003,0002 Boot0000* fubar HD(1,GPT,166f4bf1-c04a-447e-916a-2b0363cb6504,0x800,0x64000)/\EF I\fedora\shimx64.efi Boot0002* Fedora HD(1,GPT,166f4bf1-c04a-447e-916a-2b0363cb6504,0x800,0x12 c000)/\EFI\fedora\shimx64.efi Boot0003* Fedora HD(1,GPT,166f4bf1-c04a-447e-916a-2b0363cb6504,0x800,0x64 000)/\EFI\FEDORA\SHIMX64.EFI
All 3 entries use "HD(1," so we don't need the device UUID, and all 3 have the same UUID and point to the file "\EFI\fedora\shimx64.efi". This is as expected as the system is single-boot, although I'm not really sure why I have *two* entries labelled "Fedora". Anyway...
[root@fubar ~]# blkid | grep -i 166f4bf1-c04a-447e-916a-2b0363cb6504 /dev/nvme0n1p1: SEC_TYPE="msdos" UUID="21AA-D515" BLOCK_SIZE="512" TYPE="vfat" P ARTLABEL="EFI System Partition" PARTUUID="166f4bf1-c04a-447e-916a-2b0363cb6504"
As expected, the EFI variables are pointing to the EFI partition (via PARTUUID). On that partition shimx64.efi will load grub while will use grub.cfg from the same directory.
[root@fubar ~]# cat /boot/efi/EFI/fedora/grub.cfg search --no-floppy --fs-uuid --set=dev c5f18a2c-ee16-454e-b85d-6d7f03b86532 set prefix=($dev)/grub2 export $prefix configfile $prefix/grub.cfg
[ Since you are getting a grub prompt, I think we can assume you are at least getting this far. ]
The UUID maps to:
[root@fubar ~]# blkid | grep -i c5f18a2c-ee16-454e-b85d-6d7f03b86532 /dev/nvme0n1p2: UUID="c5f18a2c-ee16-454e-b85d-6d7f03b86532" BLOCK_SIZE="512" TYP E="xfs" PARTLABEL="/boot" PARTUUID="26ff026c-ee27-441f-b6fd-4b38791e5dc8"
So /boot/efi/EFI/fedora/grub.cfg points to the partition with /boot.
--> Confirm your config points to the proper /boot partition.
Now that grub knows how to find /boot, it can find /boot/grub2/grub.cfg.
[root@fubar ~]# grep -- --fs-uuid /boot/grub2/grub.cfg search --no-floppy --fs-uuid --set=root c5f18a2c-ee16-454e-b85d-6d7f03b86532 search --no-floppy --fs-uuid --set=boot 21AA-D515 [root@fubar ~]# blkid | grep -i c5f18a2c-ee16-454e-b85d-6d7f03b86532 /dev/nvme0n1p2: UUID="c5f18a2c-ee16-454e-b85d-6d7f03b86532" BLOCK_SIZE="512" TYP E="xfs" PARTLABEL="/boot" PARTUUID="26ff026c-ee27-441f-b6fd-4b38791e5dc8" [root@fubar ~]# blkid | grep -i 21AA-D515 /dev/nvme0n1p1: SEC_TYPE="msdos" UUID="21AA-D515" BLOCK_SIZE="512" TYPE="vfat" P ARTLABEL="EFI System Partition" PARTUUID="166f4bf1-c04a-447e-916a-2b0363cb6504"
--set=root has the correct UUID for /boot (in this case it appears "root" means the root of the grub config). --set=boot has the correct (device) UUID for the EFI partition.
--> Confirm your entries are correct. Double-check file system type. If grub.cfg was created by grub2-mkconfig I would expect them to be correct.
Now the grub config is going to be system-specific, but if you are getting this far you should have the grub menu that allows you to select which kernel/OS to boot.
[ If no grub menu, you are not getting this far. ]
Now grub loads the initramfs, etc. I *think* if there is a problem at this point you will get dropped into the dracut shell (as opposed to a grub shell).
I should also mention that my system is Fedora 38, but until you get as far as loading initramfs I doubt that matters as long as you have EFI and grub2.
Am 19.04.24 um 16:58 schrieb Go Canes:
The basic process is EFI is using its variables (which you can examine with efibootmgr) to find a device and the file on the device to use for the boot. That should be on the *.efi files in /boot/efi/EFI/fedora/. That in term should load grub2, which will then use /boot/efi/EFI/fedora/grub.cfg. It then uses this to find the device with /boot/grub2/grub.cfg.
[...]
--> Confirm your entries are correct. Double-check file system type. If grub.cfg was created by grub2-mkconfig I would expect them to be correct.
I am really grateful for your detailed explanation! I went through all the steps, checked the IDs from efibootmgr and blkid with respect to the various configuration files - and found no mismatch, but again I ended up with the grub prompt. Tomorrow I am going to spend another rainy afternoon double-checking - and then I'll give up and do a fresh fedora install on blank /dev/sda (which might be a good idea anyway after all those years of system-upgrade). Things that matter to me (home partition, VMs) are all stored on other devices anyway. Usually I want to find out thing (and nearly always got there), but now I am stuck.
On 4/20/2024 1:14 PM, Klaus-Peter Schrage via users wrote:
I am really grateful for your detailed explanation! I went through all the steps, checked the IDs from efibootmgr and blkid with respect to the various configuration files - and found no mismatch, but again I ended up with the grub prompt. Tomorrow I am going to spend another rainy afternoon double-checking - and then I'll give up and do a fresh fedora install on blank /dev/sda (which might be a good idea anyway after all those years of system-upgrade). Things that matter to me (home partition, VMs) are all stored on other devices anyway. Usually I want to find out thing (and nearly always got there), but now I am stuck.
I seem to recall that you duplicated the UUID's of the original partitions. If so, did you change them after you had moved the data? If not, you have 2 partitions with the same UUID, and how is grub supposed to know which one it should use?
Am 20. April 2024 20:51:04 MESZ schrieb Lester Petrie lmpetrie@bellsouth.net:
On 4/20/2024 1:14 PM, Klaus-Peter Schrage via users wrote:
I am really grateful for your detailed explanation! I went through all the steps, checked the IDs from efibootmgr and blkid with respect to the various configuration files - and found no mismatch, but again I ended up with the grub prompt. Tomorrow I am going to spend another rainy afternoon double-checking - and then I'll give up and do a fresh fedora install on blank /dev/sda (which might be a good idea anyway after all those years of system-upgrade). Things that matter to me (home partition, VMs) are all stored on other devices anyway. Usually I want to find out thing (and nearly always got there), but now I am stuck.
I seem to recall that you duplicated the UUID's of the original partitions. If so, did you change them after you had moved the data? If not, you have 2 partitions with the same UUID, and how is grub supposed to know which one it should use?
-- Lester Petrie -- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
No, the IDs should be unique. I have moved the partitions by Gparted, which kept the UUIDS (in detail: I copied the respective partition and deleted the origin immediately after).
new broom sweeps clean I guess - data is all there so lash on
On 20/04/2024 20:14, Klaus-Peter Schrage via users wrote:
Am 20. April 2024 20:51:04 MESZ schrieb Lester Petrie lmpetrie@bellsouth.net:
On 4/20/2024 1:14 PM, Klaus-Peter Schrage via users wrote: I am really grateful for your detailed explanation! I went through all the steps, checked the IDs from efibootmgr and blkid with respect to the various configuration files - and found no mismatch, but again I ended up with the grub prompt. Tomorrow I am going to spend another rainy afternoon double-checking - and then I'll give up and do a fresh fedora install on blank /dev/sda (which might be a good idea anyway after all those years of system-upgrade). Things that matter to me (home partition, VMs) are all stored on other devices anyway. Usually I want to find out thing (and nearly always got there), but now I am stuck. I seem to recall that you duplicated the UUID's of the original partitions. If so, did you change them after you had moved the data? If not, you have 2 partitions with the same UUID, and how is grub supposed to know which one it should use?No, the IDs should be unique. I have moved the partitions by Gparted, which kept the UUIDS (in detail: I copied the respective partition and deleted the origin immediately after).
-- _______________________________________________ users mailing list --users@lists.fedoraproject.org To unsubscribe send an email tousers-leave@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
Klaus-Peter Schrage via users composed on 2024-04-17 16:48 (UTC+0200):
After many years of maintaing dual boot setups (Fedora/Windows) my harddisk layout got a bit confusing: Linux and Windows partition were scattered on mainly two harddisks (all gpt). I was able to free a third harddisk (ssd) and copied the linux partitions boot, root and home over to the new disk, where they now reside as /dev/sda1, /dev/sda2 and /dev/sda3. I left the efi-partition on the disk /dev/sdc together with Windows 11. As in /etc/fstab all partitions are identified by their UUID, I didn't feel a need to adjust that file. Trying to boot brought me to the grub command line prompt. After some trial and error, the appropriate sequence of grub commands (set root=..., linux ..., initrd ...) made the system boot into a fully working Fedora 39 installation. From there I tried to repair GRUB2, following the guidelines at https://fedoraproject.org/wiki/GRUB_2?rd=Grub2#Updating_GRUB_2_configuration... namely those three steps:
# rm /boot/efi/EFI/fedora/grub.cfg # rm /boot/grub2/grub.cfg # dnf reinstall shim-* grub2-efi-* grub2-common
But rebooting still gets me to the dreaded grub>. So what am I missing? BTW, I did NOT use the grub2-install command which shoud not be used on UEFI systems.
It seems like you're using UEFI, yet remain unaware of the efibootmgr command.
Am 17.04.24 um 18:45 schrieb Felix Miata:
Klaus-Peter Schrage via users composed on 2024-04-17 16:48 (UTC+0200):
After many years of maintaing dual boot setups (Fedora/Windows) my harddisk layout got a bit confusing: Linux and Windows partition were scattered on mainly two harddisks (all gpt). I was able to free a third harddisk (ssd) and copied the linux partitions boot, root and home over to the new disk, where they now reside as /dev/sda1, /dev/sda2 and /dev/sda3. I left the efi-partition on the disk /dev/sdc together with Windows 11. As in /etc/fstab all partitions are identified by their UUID, I didn't feel a need to adjust that file. Trying to boot brought me to the grub command line prompt. After some trial and error, the appropriate sequence of grub commands (set root=..., linux ..., initrd ...) made the system boot into a fully working Fedora 39 installation. From there I tried to repair GRUB2, following the guidelines at https://fedoraproject.org/wiki/GRUB_2?rd=Grub2#Updating_GRUB_2_configuration... namely those three steps: # rm /boot/efi/EFI/fedora/grub.cfg # rm /boot/grub2/grub.cfg # dnf reinstall shim-* grub2-efi-* grub2-common But rebooting still gets me to the dreaded grub>. So what am I missing? BTW, I did NOT use the grub2-install command which shoud not be used on UEFI systems.
It seems like you're using UEFI, yet remain unaware of the efibootmgr command.
Thank you for pointing me to efibootmgr, quite new to me up to now. I am not sure if they might be related to my problem, But I have made some observations written down in my recent reply to Go Canes which i quote below:
But, as Felix had proposed in his post, I dived a bit deeper into efibootmgr (also new to me up to know), and found out that entries point to PARTUUIDs, in my case: FedoraHD(3,GPT,1ca6f5eb-cbea-11e9-a525-4ccc6ad8789c,0x24fc9800,0x32000)/\EFI\FEDORA\SHIM.EFI0000424f
Windows Boot Manager HD(1,GPT,1ca6f5ea-cbea-11e9-a525-4ccc6ad8789c,0x800,0x24c60000)/\EFI\Microsoft\Boot\bootmgfw.efi0000424f
And I found, that two partitions (EFI, Windows) on my third harddisk have the same PARUUID: /dev/sdc1: LABEL="WIN" BLOCK_SIZE="512" UUID="A1C61D016294FB66" TYPE="ntfs" PARTUUID="1ca6f5ea-cbea-11e9-a525-4ccc6ad8789c" /dev/sdc3: UUID="BEAD-09C3" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="1ca6f5eb-cbea-11e9-a525-4ccc6ad8789c" I don't know if that really matters ...
On Wed, Apr 17, 2024 at 11:48 AM Klaus-Peter Schrage via users < users@lists.fedoraproject.org> wrote:
After many years of maintaing dual boot setups (Fedora/Windows) my harddisk layout got a bit confusing: Linux and Windows partition were scattered on mainly two harddisks (all gpt). I was able to free a third harddisk (ssd) and copied the linux partitions boot, root and home over to the new disk, where they now reside as /dev/sda1, /dev/sda2 and /dev/sda3.
In preparation for converting my dual boot Win10+Fedora system to Fedora only, I needed to expand the Win11 partition on another dual boot system because some "mission critical" Adobe PDF documents require Windows.
I used gparted to shrink the Linux partition, move a couple small partitions to the end of the resulting free space, and expand Win11 to use the free space. Fedora booted without issues, Windows did some "repairs", but everything is working.
I left the efi-partition on the disk /dev/sdc together with Windows 11.
As in /etc/fstab all partitions are identified by their UUID, I didn't feel a need to adjust that file. Trying to boot brought me to the grub command line prompt. After some trial and error, the appropriate sequence of grub commands (set root=..., linux ..., initrd ...) made the system boot into a fully working Fedora 39 installation. From there I tried to repair GRUB2, following the guidelines at
https://fedoraproject.org/wiki/GRUB_2?rd=Grub2#Updating_GRUB_2_configuration... namely those three steps:
# rm /boot/efi/EFI/fedora/grub.cfg # rm /boot/grub2/grub.cfg # dnf reinstall shim-* grub2-efi-* grub2-common
But rebooting still gets me to the dreaded grub>. So what am I missing?
I assume you can still boot with manual grub commands.
Retrace your steps and double check UUID's, other typos, and misplaced quotes.
Recheck /etc/fstab and /etc/default/grub. You can also check for errors in the /etc/grub.d/10_linux section of /boot/grub2/grub.cfg.
As a final resort, you can edit /etc/grub2/40_custom to boot Fedora so you have two chances (trying different configs) to boot Fedora at each attempt.
BTW, I did NOT use the grub2-install command which shoud not be used on UEFI systems.
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 04/20/2024 03:16 PM, George N. White III wrote:
In preparation for converting my dual boot Win10+Fedora system to Fedora only, I needed to expand the Win11 partition on another dual boot system because some "mission critical" Adobe PDF documents require Windows.
In all the years I've been using Linux, I've never yet run across a .pdf file that Linux's default viewer couldn't read. What is it about those files that requires Windows to read?
On Sat, Apr 20, 2024 at 6:43 PM Joe Zeff joe@zeff.us wrote:
On 04/20/2024 03:16 PM, George N. White III wrote:
In preparation for converting my dual boot Win10+Fedora system to Fedora only, I needed to expand the Win11 partition on another dual boot system because some "mission critical" Adobe PDF documents require Windows.
In all the years I've been using Linux, I've never yet run across a .pdf file that Linux's default viewer couldn't read. What is it about those files that requires Windows to read?
a) fillable forms that explicitly say they must be completed using Windows, and b) dress patterns that use a very large page size and multiple layers. Until recently, my wife used Adobe Reader on a mac to print them on letter paper as tiles with lines marking the edges of the tiles. That no longer works and I haven't been able to do what she needs with linux tools.There are scripts to print PDF posters as tiles, but I haven't found one that duplicates what Adobe Reader produces. The ones I tried didn't support the edge marks and layer selection. Some did not preserve the design scale with acceptable accuracy. My wife often tests new patterns and finds glitches, so she needs to confirm that the glitches are present using Adobe software.
Joe Zeff:
In all the years I've been using Linux, I've never yet run across a .pdf file that Linux's default viewer couldn't read. What is it about those files that requires Windows to read?
George N. White III:
a) fillable forms that explicitly say they must be completed using Windows, and b) dress patterns that use a very large page size and multiple layers.
I was surprised to find that I could enter details into a PDF form on Linux last year (probably using Atril or Evince, I can't remember now). It saved itself as a filled-in form that I could print out. Although I've no idea whether the data saved in the form was machine-readable.
Am 20.04.24 um 23:16 schrieb George N. White III:
I assume you can still boot with manual grub commands.
Yes, linux ..., initrd ..., boot or: >configfile (hd0,1)/grub2/grub.cfg which immediately brings back the grub menu.
Retrace your steps and double check UUID's, other typos, and misplaced quotes.
Recheck /etc/fstab and /etc/default/grub. You can also check for errors in the /etc/grub.d/10_linux section of /boot/grub2/grub.cfg.
The only configuration file that I had edited manually was /etc/fstab, all the other ones were created/altered by commands to update grub. As far as I remember, the system simply wouldn't boot if there were a typo in fstab. As described earlier, I always ended up at the grub prompt.
What I found: If I write the "real" grub.conf directly to the efi partition (*|grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg), then I boot to the grub menu as desired (I have read in the fedora wiki that I should refrain from this ...). If I reinstall the grub rpms (|*dnf reinstall shim-* grub2-efi-* grub2-common), then a small grub.cfg is written to the efi partition, which simply should point to the location of grub.cfg in /boot/grub2/ - but it doesn't. So the errors seems to be in this file /boot/efi/EFI/fedora/grub.cfg:
search --no-floppy --root-dev-only --fs-uuid --set=dev 206c0b5f-eddf-42e8-96f1-e666c5635cd0 set prefix=($dev)/grub2 export $prefix configfile $prefix/grub.cfg
But here I am stuck. The UUID above definitely points to the boot partition: [root@localhost ~]# blkid|grep 206c0b5f-eddf-42e8-96f1-e666c5635cd0 /dev/sda1: LABEL="Boot" UUID="206c0b5f-eddf-42e8-96f1-e666c5635cd0" BLOCK_SIZE="1024" TYPE="ext4" PARTUUID="2924c08b -e043-4e4c-94e8-317dfab8b84e"
So, writing the actual grub.cfg to the efi partition as mentioned above might be a workaround, but I don't know if this will survive an update of the grub binaries.
*||*
On Sun, Apr 21, 2024 at 12:15 PM Klaus-Peter Schrage via users users@lists.fedoraproject.org wrote:
Am 20.04.24 um 23:16 schrieb George N. White III:
I assume you can still boot with manual grub commands.
Yes, linux ..., initrd ..., boot or: >configfile (hd0,1)/grub2/grub.cfg which immediately brings back the grub menu.
So this suggests the EFI grub.cfg is found and loaded, but it doesn't find /boot/grub2/grub.cfg
What I found: If I write the "real" grub.conf directly to the efi partition (*|grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg), then I boot to the grub menu as desired (I have read in the fedora wiki that I should refrain from this ...).
So if you can EFI grub.cfg correct, /boot/grub2/grub.cfg should be OK
So the errors seems to be in this file /boot/efi/EFI/fedora/grub.cfg: search --no-floppy --root-dev-only --fs-uuid --set=dev 206c0b5f-eddf-42e8-96f1-e666c5635cd0 set prefix=($dev)/grub2 export $prefix configfile $prefix/grub.cfg
Mine is: search --no-floppy --fs-uuid --set=dev c5f18a2c-ee16-454e-b85d-6d7f03b86532 set prefix=($dev)/grub2 export $prefix configfile $prefix/grub.cfg
Note the difference in the "search" line. Mine does not have the --root-dev-only argument. Other than that they appear to be the same (other than the UUID of course), Try editing that out?
After that I think you are deeper into grub2 than my experience goes. I.e., is $dev getting set correctly? etc.
Another thought, though a longshot..... Make sure the EFI grub.cfg has proper line terminators? I have no idea if grub cares, but mine has Unix-standard LF. But I'm wondering if you have CR-LF, maybe it treats the CR as part of the UUID? Which then causes it to not find the UUID?
Am 21.04.24 um 18:34 schrieb Go Canes:
On Sun, Apr 21, 2024 at 12:15 PM Klaus-Peter Schrage via users users@lists.fedoraproject.org wrote:
/boot/efi/EFI/fedora/grub.cfg: search --no-floppy --root-dev-only --fs-uuid --set=dev 206c0b5f-eddf-42e8-96f1-e666c5635cd0 set prefix=($dev)/grub2 export $prefix configfile $prefix/grub.cfg
Mine is: search --no-floppy --fs-uuid --set=dev c5f18a2c-ee16-454e-b85d-6d7f03b86532 set prefix=($dev)/grub2 export $prefix configfile $prefix/grub.cfg
Note the difference in the "search" line. Mine does not have the --root-dev-only argument. Other than that they appear to be the same (other than the UUID of course), Try editing that out?
I am really stunned now - thank you for this shot in the dark! I have checked/rechecked three times: /boot/efi/EFI/fedora/grub.cfg with flag "--root-dev-only": grub goes to prompt, $prefix is obviously not set. /boot/efi/EFI/fedora/grub.cfg without "--root-dev-only": grub menu is displayed, $prefix is correctly set to (hd0,1)/grub2.
After that I think you are deeper into grub2 than my experience goes. I.e., is $dev getting set correctly? etc.
Well, I am deeper into grub2 since two day or so. The discussion in this thread (and further reading induces) gave me a faint insight. (I really was a fan of the ancient grub and its simple possibility to add custom splash pictures to the grub menu: http://www.schragehome.de/splash/ - but that is truely outdated).
Some googling about "--root-dev-only" showed that it has been introduced in very recent grub packages (mine are 2.06-118) to cure a certain vulnerability (CVE-2023-4001). I found a bugzilla about that: https://bugzilla.redhat.com/show_bug.cgi?id=2263369
So I am not sure if this is a real solution, but for me at least a viable workaround. Thanks to all who contributed!
On Mon, Apr 22, 2024 at 8:26 AM Klaus-Peter Schrage via users < users@lists.fedoraproject.org> wrote:
[...]
I have checked/rechecked three times:
/boot/efi/EFI/fedora/grub.cfg with flag "--root-dev-only": grub goes to prompt, $prefix is obviously not set. /boot/efi/EFI/fedora/grub.cfg without "--root-dev-only": grub menu is displayed, $prefix is correctly set to (hd0,1)/grub2.
After that I think you are deeper into grub2 than my experience goes. I.e., is $dev getting set correctly? etc.
Well, I am deeper into grub2 since two day or so. The discussion in this thread (and further reading induces) gave me a faint insight. (I really was a fan of the ancient grub and its simple possibility to add custom splash pictures to the grub menu: http://www.schragehome.de/splash/ - but that is truely outdated).
Some googling about "--root-dev-only" showed that it has been introduced in very recent grub packages (mine are 2.06-118) to cure a certain vulnerability (CVE-2023-4001). I found a bugzilla about that: https://bugzilla.redhat.com/show_bug.cgi?id=2263369
So I am not sure if this is a real solution, but for me at least a viable workaround. Thanks to all who contributed!
Just upgraded 2 systems to Fedora 40 one on an internal drive and one an external drive and don't have "--root-dev-only" on either box. I have grub2-tools-minimal-1:2.06-119.fc40.x86_64.
Checking the src RPM page < https://src.fedoraproject.org/fork/jwrdegoede/rpms/grub2/commits/master#%3E:
This branch contains 1 commits https://src.fedoraproject.org/fork/jwrdegoede/rpms/grub2/commits/master# not in the upstream grub2 master *Add support for setting boot_success / boot_indeterminate grubenv flags* https://src.fedoraproject.org/fork/jwrdegoede/rpms/grub2/c/e8a6d3e8a1ec05499d2a44b6760114e73852fbad Hans de Goede • 5 years ago
Klaus-Peter Schrage composed on 2024-04-21 18:15 (UTC+0200): ...
It really doesn't take much to load a kernel and initrd. All my EFI PCs have only one Grub installation, even though there are upwards of 12 distros installed on each PC, no VMs. One of the latest updated hosts this:
menuentry "Fedora 40 defkernel 3 on P14" { load_video set gfxpayload=keep search --no-floppy --set=root --hint-baremetal=ahci0,gpt14 --label tg1p14f40 3 linux /boot/vmlinuz root=LABEL=tg1p14f40 noresume audit=0 initrd /boot/initrd }
That stanza lives in nvme0n1p7's /boot/grub2/custom.cfg, which is 100% under my own control, and is automatically offered by the installed Grub's /boot/grub2/grub.cfg. That file is pointed to by /EFI/<distroid>/grubx64.efi on the ESP, as directed by NVRAM, which ATM has only 2 entries:
# efibootmgr BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000,0001 Boot0000* <distroid> HD(1,GPT,<...>1b27,0x800,0xa0000)/File(\EFI<distroid>\grubx64.efi) Boot0001* UEFI OS HD(1,GPT,<...>1b27,0x800,0xa0000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f #
Where you see <distroid> above is the actual value in /etc/default/grub's GRUB_DISTRIBUTOR= on EXT4-formatted nvme0n1p7.
If you can correctly equate your installed values for those in my Grub stanza above, you should be able to boot by typing in each of the necessary lines from your grub> prompt to get booted.
-
Bryan -
Felix Miata -
George N. White III -
Go Canes -
Joe Zeff -
Klaus-Peter Schrage -
Lester Petrie -
Tim