Description of problem: while trying to restore a machine, had to use grub2-mkconfig. Since I was working through boot failures, I had SystemRescue and Magia ISO USB sticks connected. grub2-mkconfig includes these media, then complains and fails. Version-Release number of selected component (if applicable): How reproducible: always. Steps to Reproduce: 1. run grub2-mkconfig with other storage devices connected. 2. 3. Additional info which I thought was a separate issue; but may be this same one: When I first setup this system (has only ever run Cauldron(mga9)), there was an external 1.5TB HD with 3 ext4 partitions (no swap). After many attempts at solving boot issues, discovered that this (now disconnected) external HD's UUID was still showing up in /boot/grub2/grub.cfg -- I thought I was going nuts when I couldn't find that UUID until I realized it was from the disconnected drive.
(In reply to Pierre Fortin from comment #0) > while trying to restore a machine, had to use > grub2-mkconfig. Since I was working through boot failures, I had > SystemRescue and Magia ISO USB sticks connected. grub2-mkconfig includes > these media, then complains and fails. Please re-create the situation, with the same USBs plugged in, and post the terminal output, or error messages. Also the output of $ inxi -Dlopu which I have just checked does include USB 'discs'. Do you have any reason not to use rEFInd bootloader? You can install it, and it can co-exist (pointlessly) with Grub - which one can well live without. But to be effective, it must be what is booted. A lot depends on one's EFI firmware. There is nothing to lose by trying it.
CC: (none) => lewyssmith
My first goal is to get the system to boot again... I've been trying to track down why it fails like this: - complains about qwerty-layout.uni at 9.559 - stalls - at 199.517 it complains about UUID 11FD-3498 which I just tracked down; it's the EFI partition on the old 1TB SSD previously removed. - at 309.316, complains again and drops into dracut. When I first switched out the 1TB for a 2TB, I was getting boot failures on UUIDs that were not in the system (the above 1.5TB external HD). Now, it's a removed 1TB SSD that can't co-exist in the same slot with the new 2TB; yet still appears in a new grub2-mkconfig'ed /boot/grub2/grub.cfg.... The more I dig into grub, the less I like it. Hmm... never thought to check; but does the BIOS use UUID to locate the EFI partition, or just scans for EFI partitions? That may be where the now non-existent UUID is coming from....? rEFInd: I'm too busy with tons of data to follow changes that don't impact me; so, no, was not aware of rEFInd (using camel-case helps realize what it may be -- thanks! :) Sounds promising... let me look into it.
Created attachment 13530 [details] BIOS Add boot option -- what's "available"; but don't recognize any... Finally back up... Had a quick peek at the BIOS; there are some devices that can be added to the boot selections; but I don't recognize any of those UUIDs -- maybe they are in the BIOS image...? $ inxi -Dlopu Drives: Local Storage: total: 46.41 TiB used: 24.69 TiB (53.2%) ID-1: /dev/nvme0n1 vendor: Seagate model: FireCuda 530 ZP2000GM30013 size: 1.82 TiB ID-2: /dev/nvme1n1 vendor: Seagate model: FireCuda 530 ZP4000GM30023 size: 3.64 TiB ID-3: /dev/sda vendor: Seagate model: ST2000DM008-2FR102 size: 1.82 TiB ID-4: /dev/sdb vendor: Seagate model: ST18000NM000J-2TV103 size: 16.37 TiB ID-5: /dev/sdc type: USB vendor: Seagate model: Expansion SW size: 5.46 TiB ID-6: /dev/sdd type: USB vendor: Seagate model: Expansion SW size: 5.46 TiB ID-7: /dev/sde type: USB vendor: Seagate model: Expansion SW size: 5.46 TiB ID-8: /dev/sdf type: USB vendor: Seagate model: Expansion SW size: 5.46 TiB ID-9: /dev/sdg type: USB vendor: Realtek model: RTL9210B-CG size: 953.87 GiB Partition: ID-1: / size: 95.56 GiB used: 39.38 GiB (41.2%) fs: ext4 dev: /dev/nvme0n1p2 label: N/A uuid: 1114d372-ab53-4a1b-9cf9-d2df52138f39 ID-2: /boot/EFI size: 299.4 MiB used: 568 KiB (0.2%) fs: vfat dev: /dev/nvme0n1p1 label: N/A uuid: 0415-DFFB ID-3: /home size: 1.67 TiB used: 316.19 GiB (18.5%) fs: ext4 dev: /dev/nvme0n1p4 label: N/A uuid: 556f86ae-60a3-4e7c-9e79-7b460b9206bd ID-4: /mnt/6A size: 5.41 TiB used: 5.01 TiB (92.6%) fs: ext4 dev: /dev/sdd2 label: 6A uuid: a1ade5b2-24c4-4d34-85f9-16a25fc142cf ID-5: /mnt/6B size: 5.41 TiB used: 4.81 TiB (88.8%) fs: ext4 dev: /dev/sde2 label: 6B uuid: bd9ae805-0b8c-4d65-83ce-87c88f193d2c ID-6: /mnt/6C size: 5.41 TiB used: 4.17 TiB (77.0%) fs: ext4 dev: /dev/sdc2 label: 6C uuid: d80691e2-13f2-4298-a243-d770469acf02 ID-7: /mnt/6D size: 5.41 TiB used: 2.17 TiB (40.2%) fs: ext4 dev: /dev/sdf2 label: 6D uuid: b72e3e29-2d14-4978-bd82-e6833686c7af ID-8: /mnt/a1 size: 1.79 TiB used: 1.14 TiB (63.5%) fs: ext4 dev: /dev/sda1 label: N/A uuid: 94cfdafe-9120-4d1c-853e-b8eec6944c6c ID-9: /mnt/db size: 16.3 TiB used: 4.84 TiB (29.7%) fs: ext4 dev: /dev/sdb1 label: DB uuid: a8975c7b-2c7b-436e-9d6a-e1dd1b3deca0 ID-10: /mnt/work size: 3.58 TiB used: 1.9 TiB (52.9%) fs: ext4 dev: /dev/nvme1n1p1 label: work uuid: f508f72e-5252-4199-846c-c422a5bca1de ID-11: /run/media/pfortin/a3bb11a0-6190-4b16-a95d-1985bc44b0a1 size: 884.09 GiB used: 316.09 GiB (35.8%) fs: ext4 dev: /dev/sdg4 label: N/A uuid: a3bb11a0-6190-4b16-a95d-1985bc44b0a1 ID-12: swap-1 size: 31.25 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/nvme0n1p3 label: N/A uuid: 447b948c-ee26-4893-a8c7-9f19ec63777f Unmounted: ID-1: /dev/sdc1 size: 200 MiB fs: vfat label: EFI uuid: 67E3-17ED # 6C ID-2: /dev/sdd1 size: 200 MiB fs: vfat label: EFI uuid: 67E3-17ED # 6A ID-3: /dev/sde1 size: 200 MiB fs: vfat label: EFI uuid: 67E3-17ED # 6B ID-4: /dev/sdf1 size: 200 MiB fs: vfat label: EFI uuid: 67E3-17ED # 6D ID-5: /dev/sdg1 size: 299 MiB fs: vfat label: N/A uuid: 11FD-3498 ID-6: /dev/sdg2 size: 50.29 GiB fs: ext4 label: N/A uuid: 957cd552-a8ad-4d8a-a90d-1c6eb3871ebd ID-7: /dev/sdg3 size: 4 GiB fs: swap label: N/A uuid: 63b04ef6-fb15-4f03-b7af-6573fb6070ec ## 6[ABCD] are 4 identical 6TB drives (p1 never used), ordered at different times -- looks like Seagate just literally clone them. I made p2 on each ext4. Being down for nearly 48 hours has backed up a lot of volunteer work... I may have to check out the grub2-mkconfig oddities on another system.
In comment 2, I stated: >yet still appears in a new grub2-mkconfig'ed /boot/grub2/grub.cfg.... This is incorrect -- the UUID quoted in the boot failure is nowhere to be found. grep -slR "11FD-3498" /boot/* returns nothing. So I have no clue where that error message originates.
Did you ever try the rd.hostonly=0 boot parameter as suggested in my first mailing list thread reply 2 days ago? It's needed if the old ESP's UUID remains in your initrd. e.g.: # lsblk -f | grep efi ├─sda1 vfat FAT32 TG1P01ESP 8759-E200 314M 2% /boot/efi ab85m:~ # lsinitrd /boot/initrd | grep E200 drwxr-xr-x 2 root root 0 Aug 12 17:37 etc/systemd/system/dev-disk-by\x2duuid-8759\x2dE200.device.d -rw-r--r-- 1 root root 46 Aug 12 17:37 etc/systemd/system/dev-disk-by\x2duuid-8759\x2dE200.device.d/timeout.conf lrwxrwxrwx 1 root root 42 Aug 12 17:37 etc/systemd/system/initrd.target.wants/dev-disk-by\x2duuid-8759\x2dE200.device -> ../dev-disk-by\x2duuid-8759\x2dE200.device -rw-r--r-- 1 root root 92 Aug 12 17:37 usr/lib/dracut/hooks/emergency/80-\x2fdev\x2fdisk\x2fby-uuid\x2f8759-E200.sh -rw-r--r-- 1 root root 37 Aug 12 17:37 usr/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2f8759-E200.sh
CC: (none) => mrmazda
I believe Pierre has fixed this by re-building initrd following specific advice from elsewhere. We can never properly deal with this bug as presented without the original setup which confused grub2-mkconfig and the error messages output. Or a more precise statement elaborating on the bug title "grub2-mkconfig includes other media". What should it not include? If installing to an internal 'disc', ignore all USB ones? That looks reasonable.
(In reply to Pierre Fortin from comment #3) > Created attachment 13530 [details] > BIOS Add boot option -- what's "available"; but don't recognize any... > Had a quick peek at the BIOS; there are some devices that can be added to > the boot selections; but I don't recognize any of those UUIDs -- maybe they > are in the BIOS image...? Only now had a look at that screenshot of BIOS. I do not think "Add boot option" was relevant, and agree that the list is a puzzle. This is all academic, but perhaps it represents 4 connected devices; and as for those Sig... UUIDs, a mystery. Close this aspect. As for UUIDs being in initrd, I have searched in vain here for that of the root partition - or a part of its UUID, which should be visible even if the initrd file is compressed.
Being tired is no excuse; but apparently I was not clear enough. The BIOS screenshot was only meant to show that the BIOS can contain what appear to be UUIDs. What is not clear to me is what those "UUIDs" might be, or how they get in there -- since they are unrecognized, I now doubt their utility. The UUID that kept causing the boot turned out to be one of three partitions on an old 1.5TB external/USB drive that was connected to the system shortly after acquiring the system. As I learned the extent of the data I would be working with, I started acquiring more and more and more storage. When I got to the point where the boot drive would be replaced by a larger one, I did an inventory and decided the 1.5TB was not needed; so I removed it. Now, the mystery: that drive never contained any bootable images. None of its partitions were ever swap space -- unless resume=<UUID> allows non-swap, ext4 partitions, it should never have appeared in grub.cfg... Once all was ready, including ensuring the fstab files on the 1TB and 2TB drives were configured as they should be if they are the boot disk. My bad in this whole mess was not understanding the role of grub.cfg with all of its entries. Regardless, the fact that it contained the UUID of [ohhhh!! ==>] partition TWO** should not have happened. ** the boot sequence is: BIOS->EFI->boot(usually p2) -- from all my debugging trying to restore the system, I only ever saw: - BIOS contains mageia, Dell, BOOT - EFI partition: mageia/grubx64.efi (does not contain UUIDs) -- besides, it's mounted onto /boot/EFI when the system is up. So I'm still not clear on how the boot decides to use the partition 2 where grub.cfg resides vs any other partition containing /boot/grub2/grub.cfg... Which comes first? Unfortunately, there is no way to know _when_ this 1.5TB drive's partition 2 was first introduced into grub.cfg -- it could have occurred on initial install in February through just before it became active when I was switching out the boot drive (with the 1.5TB disconnected -- I checked the UUIDs of all the connected drives and USB sticks I'd used, before thinking about that previously disconnected 1.5TB drive). What shocked me was seeing that UUID still in grub.cfg after running grub2-mkconfig. Since it may have been "walked" through the various kernels, I manually edited grub.cfg to replace that UUID with the correct one. When that was corrected, I had no idea my problem had morphed into the dracut/initrd issue. UUIDs in initrd: I too searched initrd -- actually, I searched the entire /boot with: "grep -slR <UUID> /boot" and "grep -slR <partial_UUID> /boot" (after I'd removed the offending UUID from /boot/grub2/grub.cfg). [more to report -- saving, and continuing in another comment...]
Created attachment 13532 [details] rdsosreport.txt Going through my notes during the outage; I have to correct some points. Looks like the 1.5TB drive was still connected when I first started the process of switching drives... So much happened; forgive my fuzzy recall... I swapped the NVMe drives a day earlier; but system booted from the 1TB/USB. I recall thinking "this sucks, new emails, gnu-cash updates, etc are ending up on the 1TB and I'll have to clean that up... :p " In the interest of accuracy and hopefully getting useful info... I just reconnected the offending drive, and blkid reports: /dev/sdh3: LABEL="DT" UUID="84b6945a-42b8-4a94-abc8-4df1397f4be4" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8d295714-03" /dev/sdh1: LABEL="NCDTwin" UUID="63BB-F222" BLOCK_SIZE="512" TYPE="exfat" PTTYPE="dos" PARTUUID="8d295714-01" /dev/sdh2: LABEL="NCDT" UUID="618c325f-424e-420d-9123-f0fc34eec73b" <=== BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8d295714-02" Partitions: NCDTwin is empty except for . and .. DT contains a few project files, the most recent dated Feb 26 2022 NCDT, the offender, is empty except for lost+found dated Dec 7 2021; even its "." entry is Feb 4, weeks before I received the new system. This tells me the drive was first partitioned on my old Dell M6800 laptop and a few project files placed on it; nothing else. There's no way I would have ever considered placing boot images on this drive. Note the UUID of sdh2; then check the attached rdsosreport.txt (Nov 22 02:58)... this confirms that UUID:...73b was in grub.cfg... Somehow, an empty partition's UUID on an external drive made its way into grub.cfg with no clue when. In preparation for the 1TB/2TB swap, I used mcc to delete all 5.x kernels. While debugging during the outage; I do recall scanning grub.cfg and seeing the ...73b UUID in all the 6.0.x kernel entries -- I manually edited these out at one point. If this triggers any ideas/questions, ask away...
(In reply to Felix Miata from comment #5) > # lsblk -f | grep efi > ├─sda1 vfat FAT32 TG1P01ESP 8759-E200 > 314M 2% /boot/efi WHOA!! $ lsblk -f | grep -i efi ├─sdc1 vfat FAT32 EFI 67E3-17ED ├─sdd1 vfat FAT32 EFI 67E3-17ED ├─sde1 vfat FAT32 EFI 67E3-17ED ├─sdf1 vfat FAT32 EFI 67E3-17ED ├─nvme0n1p1 vfat FAT32 0415-DFFB 298.8M 0% /boot/EFI The four drives with identical UUIDs are identical drives purchased at different times over a few months. They contained some recovery software that I decided to leave while making the rest of the drives a single ext4. This is the first time I've noticed the EFI flags https://www.walmart.com/ip/Seagate-ExpansionPLUS-6TB-External-Hard-Drive-HDD-USB-3-0-with-Rescue-Data-Recovery-Services-and-Toolkit-Backup-Software-STKR6000400/809036797?athbdg=L1100 Digging deeper... These VFAT partitions are 197M in size, and no longer contain any Seagate software (I had no reason to keep a separate copy). Rather they now all contain the same files -- the contents differ slightly: $ ll -R /mnt/6TB /mnt/6TB: total 1 drwxr-xr-x 3 root root 512 Nov 22 01:55 EFI/ /mnt/6TB/EFI: total 1 drwxr-xr-x 3 root root 512 Nov 22 01:55 Dell/ /mnt/6TB/EFI/Dell: total 1 drwxr-xr-x 2 root root 1024 Nov 22 01:55 logs/ /mnt/6TB/EFI/Dell/logs: total 2 -rwxr-xr-x 1 root root 710 Nov 22 01:55 diags_current.xml* -rwxr-xr-x 1 root root 715 Nov 22 01:55 diags_previous.xml* Two of the drives have a 01:55 timestamp, the other two show 01:58... This was early in trying to find the cause of the boot failure. This implies something decided to replace the contents of these small partitions with the above. The diags_{current,previous}.xml files all have nearly identical structures. I will post a spreadsheet showing the contents/differences... What troubles me here is that something re-used partition 1 on 4 external drives, deleting whatever was there previously -- wishing I'd kept a backup of one of those partitions; but 4 original copies should have been enough... > ab85m:~ # lsinitrd /boot/initrd | grep E200 > drwxr-xr-x 2 root root 0 Aug 12 17:37 > etc/systemd/system/dev-disk-by\x2duuid-8759\x2dE200.device.d > -rw-r--r-- 1 root root 46 Aug 12 17:37 > etc/systemd/system/dev-disk-by\x2duuid-8759\x2dE200.device.d/timeout.conf > lrwxrwxrwx 1 root root 42 Aug 12 17:37 > etc/systemd/system/initrd.target.wants/dev-disk-by\x2duuid-8759\x2dE200. > device -> ../dev-disk-by\x2duuid-8759\x2dE200.device > -rw-r--r-- 1 root root 92 Aug 12 17:37 > usr/lib/dracut/hooks/emergency/80-\x2fdev\x2fdisk\x2fby-uuid\x2f8759-E200.sh > -rw-r--r-- 1 root root 37 Aug 12 17:37 > usr/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby- > uuid\x2f8759-E200.sh # lsinitrd /boot/initrd | grep 17ED /boot/initrd does not exist
Created attachment 13533 [details] Contents of EFI/Dell/logs/diags_{current,previous}.xml files These are the contents of the files found as a result of: $ lsblk -f | grep -i efi ├─sdc1 vfat FAT32 EFI 67E3-17ED ├─sdd1 vfat FAT32 EFI 67E3-17ED ├─sde1 vfat FAT32 EFI 67E3-17ED ├─sdf1 vfat FAT32 EFI 67E3-17ED ALL timestamps (directories and files) are: sdc1 & sdf1: 2022-11-22 01:58:42.000000000 sdd1 & sde1: 2022-11-22 01:55:40.000000000 which indicates some process (not human) did this... It's reasonable to assume Seagate simply clone these hard drives which would explain the same UUIDs. Short of purchasing another drive, I have no way of knowing if the EFI flag was set previously. It is troubling that whatever these partitions previously contained (some Seagate recovery software per the ads) was deleted and replaced by: $ ll -R /mnt/6A1 /mnt/6A1: total 1 drwxr-xr-x 3 root root 512 Nov 22 01:55 EFI/ /mnt/6A1/EFI: total 1 drwxr-xr-x 3 root root 512 Nov 22 01:55 Dell/ /mnt/6A1/EFI/Dell: total 1 drwxr-xr-x 2 root root 1024 Nov 22 01:55 logs/ /mnt/6A1/EFI/Dell/logs: total 2 -rwxr-xr-x 1 root root 710 Nov 22 01:55 diags_current.xml* -rwxr-xr-x 1 root root 715 Nov 22 01:55 diags_previous.xml* Other than timestamps and diags_*.xml contents; everything is identical.
There appears to be a number of issues identified herein; so we may want to open separate reports and consider this a meta-bug... Definitely some weird things going on related to booting...
(In reply to Pierre Fortin from comment #10) > # lsinitrd /boot/initrd | grep 17ED > /boot/initrd does not exist It exists if you run lsinitrd /boot/initrd.img, or lsinitrd /boot/initrd<version>.img, or lsinitrd /boot/initrd-desktop.img, instead, or have made a copy of /boot/initrd.img named /boot/initrd for a /boot/grub2/custom.cfg for convenient Grub2 multibooting: # ls -Ggh /boot/initrd* lrwxrwxrwx 1 33 Oct 25 14:11 /boot/initrd -> initrd-5.19.12-desktop-1.mga9.img -rw------- 1 13M Jun 19 17:59 /boot/initrd-5.17.11-desktop-1.mga9.img -rw------- 1 13M Aug 12 00:57 /boot/initrd-5.18.16-desktop-1.mga9.img -rw------- 1 24M Oct 25 14:11 /boot/initrd-5.19.12-desktop-1.mga9.img lrwxrwxrwx 1 33 Jun 19 17:59 /boot/initrd-51711 -> initrd-5.17.11-desktop-1.mga9.img lrwxrwxrwx 1 33 Oct 25 14:11 /boot/initrd-cur -> initrd-5.19.12-desktop-1.mga9.img lrwxrwxrwx 1 33 Oct 25 14:11 /boot/initrd-desktop.img -> initrd-5.19.12-desktop-1.mga9.img lrwxrwxrwx 1 33 Aug 11 23:57 /boot/initrd-prv -> initrd-5.18.16-desktop-1.mga9.img lrwxrwxrwx 1 33 Oct 25 14:11 /boot/initrd.img -> initrd-5.19.12-desktop-1.mga9.img
(In reply to Felix Miata from comment #13) > (In reply to Pierre Fortin from comment #10) > > # lsinitrd /boot/initrd | grep 17ED > > /boot/initrd does not exist > > It exists if you run lsinitrd /boot/initrd.img, or lsinitrd > /boot/initrd<version>.img, or lsinitrd /boot/initrd-desktop.img, instead, or > have made a copy of /boot/initrd.img named /boot/initrd for a > /boot/grub2/custom.cfg for convenient Grub2 multibooting: I provided exactly what you asked for in comment 5 (with my UUID): > ab85m:~ # lsinitrd /boot/initrd | grep E200 ^^^^^^ Why did yours provide output? A symlink? Much has happened since your request, I had to find the right UUID in my notes to get what it had at the time in: >-----vvvv $ lsinitrd initrd-6.0.9-server-1.mga9.img.bak | grep 11FD -rw-r--r-- 1 root root 92 Nov 16 20:19 usr/lib/dracut/hooks/emergency/80-\x2fdev\x2fdisk\x2fby-uuid\x2f11FD-3498.sh -rw-r--r-- 1 root root 37 Nov 16 20:19 usr/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2f11FD-3498.sh After running dracut --kver: $ lsinitrd initrd-6.0.9-server-1.mga9.img | grep 11FD The current UUID is not found in lsinitrd output; in fact, I don't see any UUID in its output. How do I refresh this?: (not that it matters; should be correct at next boot) $ lsblk -f | grep EFI ├─sdc1 vfat FAT32 EFI 67E3-17ED ├─sdd1 vfat FAT32 EFI 67E3-17ED ├─sde1 vfat FAT32 EFI 67E3-17ED ├─sdf1 vfat FAT32 EFI 67E3-17ED ├─nvme0n1p1 vfat FAT32 0415-DFFB 298.8M 0% /boot/EFI The first four are how Seagate ships these drives (exact clones); I used gparted, unchecked boot and the flags instantly changed from boot,esp to msftdata -- yet lsblk must be checking internal data vs the drives. This is moot since these partitions originally contained Seagate recovery software; nothing now. They are useless, so leaving them for now; will see if the next boot messes with them...
(In reply to Pierre Fortin from comment #14) > (In reply to Felix Miata from comment #13) > > ab85m:~ # lsinitrd /boot/initrd | grep E200 > ^^^^^^ > Why did yours provide output? A symlink? (In reply to Felix Miata from comment #13) > # ls -Ggh /boot/initrd* > lrwxrwxrwx 1 33 Oct 25 14:11 /boot/initrd -> > initrd-5.19.12-desktop-1.mga9.img > -rw------- 1 24M Oct 25 14:11 /boot/initrd-5.19.12-desktop-1.mga9.img > lrwxrwxrwx 1 33 Oct 25 14:11 /boot/initrd-cur -> > initrd-5.19.12-desktop-1.mga9.img > lrwxrwxrwx 1 33 Oct 25 14:11 /boot/initrd-desktop.img -> > initrd-5.19.12-desktop-1.mga9.img > lrwxrwxrwx 1 33 Oct 25 14:11 /boot/initrd.img -> > initrd-5.19.12-desktop-1.mga9.img One initrd created 25 Oct 14:11: initrd-5.19.12-desktop-1.mga9.img with 4 symlinks to it created 25 Oct 14:11: initrd initrd-cur initrd-desktop.img initrd.img Grepping E200 in any of the 5 would have generated the same 5 line response as you see in comment #5.
Comment 5 had no "*"; I provided what you asked for... Sadly, in the heat of the fire; I didn't keep enough copies of various files, so there's no way to prove what was experienced; plus, this conversation is getting me nowhere.... Closing.
Resolution: (none) => INVALIDStatus: NEW => RESOLVED
(In reply to Pierre Fortin from comment #16) > Comment 5 had no "*"; I provided what you asked for... I didn't "ask" for anything. I provided an "e.g.", an example that would have been better for you had I selected a different one of my four symlinks, or the image file the symlinks link to. I don't consider this bug invalid, though its subject line could be better. Your experience does demonstrate that migrating to a new NVME does present booby traps. Better to call it incomplete than invalid.