You are not logged in.
My MB has 4x M.2 slots. I have 3 of these occupied:
#1 has a 500GB device
#2 has a 256GB device
#3 is empty
#4 has a 2TB device
For the longest time, kernel naming these devices as follows:
/dev/nvme0n1 (256GB)
/dev/nvme1n1 (2TB)
/dev/nvme2n1 (500GB)
I recently, something re-assigned the association of the physical devices to their device names, affecting all 3 devices:
/dev/nvme0n1 (500GB)
/dev/nvme1n1 (256GB)
/dev/nvme2n1 (2TB)
What dictates this? I am using UUID for /etc/fstab so it is not a problem for the linux side, but the 256GB disc contains a windows environment which required me adjusting the grub entry for it. Thanks.
Last edited by graysky (2023-09-17 17:36:53)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
https://wiki.archlinux.org/title/Device_file#NVMe
Did you run a UEFI update or change anything else about the HW config (a new PCI device)?
Offline
Thanks for the link. I did remove an old SATA disk. Perhaps that is to blame.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
a
Last edited by wassapss (2023-09-17 20:59:00)
Offline
That's actually very likely.
Offline
Bah, this is annoying. The names seems to change upon rebooting... now we are back to:
/dev/nvme0n1 (500GB)
/dev/nvme1n1 (256GB)
/dev/nvme2n1 (2TB)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Grub can use UUIDs, can't it? But besides that - I don't think there'd be any reason to assume that the grub names would even map onto the same names at run time as these are kernel assigned names. Grub runs before the kernel starts, and when booting windows, the kernel doesn't load at all.
Last edited by Trilby (2023-09-18 18:47:34)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I've needed to reference a loopback call for booting to the Arch ISO like the following which ran into troubles with these naming changes:
menuentry 'ISO loopback-Arch (on /dev/nvme0n1p1)' {
set reldate=2023.09.01
###
set isofile="archlinux-$reldate-x86_64.iso"
set imgdevpath='/dev/nvme0n1p1'
loopback loop (hd3,1)/$isofile
linux (loop)/arch/boot/x86_64/vmlinuz-linux img_dev=$imgdevpath img_loop=$isofile earlymodules=loop
initrd (loop)/arch/boot/intel-ucode.img (loop)/arch/boot/x86_64/initramfs-linux.img
}
Last edited by graysky (2023-09-18 19:05:38)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
So change imgdevpath to use /dev/disk/by-* rather than the kernel's runtime block device name.
You may also have issues with grub's indexing / ordering of the devices (e.g., with hd3), but that's a different and purely grub issue.
EDIT: oh - those may not be populated at that point. Sorry I'm not sure if I can help with that as I don't use grub. Are you sure you need all that complexity, though? You're loading a kernel from an iso off of one partition, and also using another partition as what an initrd? What's the end goal of all that?
Last edited by Trilby (2023-09-18 19:38:44)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
As the wiki points out, the names are assigned first come, first serve.
HW/BIOS manipulations are prone to trigger a change in that, but if the nvme's show up in close proximity (but still random) you'll end up with this just the like.
Addressing the img_dev via /dev/disk/by-uuid/ doesn't work?
F5**
Last edited by seth (2023-09-18 19:39:29)
Offline
Yes, using labels or UUIDs works. I just wanted to know more about why the scramble.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline