On 28 Jul 2024 at 17:54, Samuel Sieb wrote: Date sent: Sun, 28 Jul 2024 17:54:13 -0700 Subject: Re: NVMe questions To: users@xxxxxxxxxxxxxxxxxxxxxxx From: Samuel Sieb <samuel@xxxxxxxx> Send reply to: Community support for Fedora users <users@xxxxxxxxxxxxxxxxxxxxxxx> > On 7/28/24 4:21 PM, Michael D. Setzer II via users wrote: > > On 28 Jul 2024 at 18:19, Go Canes wrote: > > > > From: Go Canes <letsgonhlcanes0@xxxxxxxxx> > > Date sent: Sun, 28 Jul 2024 18:19:38 -0400 > > Subject: Re: NVMe questions > > To: Community support for Fedora users > > <users@xxxxxxxxxxxxxxxxxxxxxxx> > > Send reply to: Community support for Fedora users > > <users@xxxxxxxxxxxxxxxxxxxxxxx> > > > >> On Sun, Jul 28, 2024 at 5:42 PM Patrick O'Callaghan > >> <pocallaghan@xxxxxxxxx> wrote: > >>> I tried disabling the SSD (in the bootable drives list). It made no > >>> difference. > >> > > > > Check the blkids on all devices. > > blkid > > > > If you clone a disk in a raw mode, the blkid's are the same on both > > devices, and since the boot process looks for the blkid to load, it > > would be using the first device it sees. > > > > In past, it use the /dev/sdx method so duplicate blkids would be ok, > > but now it can be an issue. If you disconnect the SSD drive it > > would probable work. > > > > Option would be to either remove the SSD drive, or change the > > blkids on it to be different than the nvme drive. > > > > Would be interesting to see what blkid reports, but pretty sure it > > would show same ids between SSD and nvme drives. > > > > I've been maintainer of G4L disk imaging project since 2004, so > > have seen this issue with cloning disks. > Not sure what you mean by wrong level? The boot done via grub2, so even if bios selects correct starting disk for boot, the grub entries will use the UUID. I recently upgraded a machine that had a 512G nvme to a 1TB SSD. Did a raw bit level image. NVME is currently in a usb nvme and inserted after boot, so it uses the correct mapping. /dev/sdb2: UUID="01d61794-271a-4d17-a901-47afee995382" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="dc614481-fb0d-41b9-b113-da75b13cb4aa" /dev/sdc2: UUID="01d61794-271a-4d17-a901-47afee995382" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="dc614481-fb0d-41b9-b113-da75b13cb4aa" /dev/sdb5: UUID="892e9432-1c99-4357-8213-6683c0692b55" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="data" PARTUUID="09269f06-ea87-4e38-8408-53b51d053a5b" /dev/sdb4: UUID="a041e51f-4fcb-48c3-b249-c39c1af03b5e" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="7882aee7-80f0-4981-9b00-ae76a013c653" /dev/sdc4: UUID="a041e51f-4fcb-48c3-b249-c39c1af03b5e" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="7882aee7-80f0-4981-9b00-ae76a013c653" /dev/sdb1: UUID="B5B5-43CF" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="96b31910-54bd-43ce-9164-775f9d2ea13d" /dev/sdc1: UUID="B5B5-43CF" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="96b31910-54bd-43ce-9164-775f9d2ea13d" /dev/sdb3: UUID="de10a0a9-fd86-4625-a768-67477a8a802d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8e12c483-7aa5-4f33-aa84-cd053e536373" /dev/sdc3: UUID="de10a0a9-fd86-4625-a768-67477a8a802d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8e12c483-7aa5-4f33-aa84-cd053e536373" The boot entry for default kernel is: cat 5454d68084c145e496d5ce383b5147de-6.9.11-200.fc40.x86_64.con f title Fedora Linux (6.9.11-200.fc40.x86_64) 40 (Workstation Edition) version 6.9.11-200.fc40.x86_64 linux /vmlinuz-6.9.11-200.fc40.x86_64 initrd /initramfs-6.9.11-200.fc40.x86_64.img options root=UUID=de10a0a9-fd86-4625-a768-67477a8a802d ro rd.driver.blacklist=nouveau modprobe.blacklist=nouveau rhgb quiet rd.driver.blacklist=nouveau modprobe.blacklist=nouveau grub_users $grub_users grub_arg --unrestricted grub_class fedora since this uses the UUID it doesn't matter the dev that bios is pointed to? At least as I under stand it. > You're at the wrong level. This is before Fedora is booted, so all of > that is not relevant. He's trying to get the BIOS to boot from it. > > -- > _______________________________________________ > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue +------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@xxxxxxxx mailto:msetzerii@xxxxxxxxx mailto:msetzerii@xxxxxxx Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+ -- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
