[SOLVED] NVME Drive name changing - Dual boot

live4thamuzik · 2025-03-03 22:11:29

Full disclosure I do not currently have an issue, it's just something that has happened each time I have attempted dual boot where the 2 systems do not share the same disk and seem to fail to realize why it happens. Curious if anyone has ran into this and maybe knows the cause.
Just built a new PC over the weekend I got arch going and that's all happy but Id like to pop in another nvme and install windows for work related tasks.

Setup:
-Install Arch Linux on nvme drive /dev/nvme0n1, bootloader: grub (os prober enabled, using uuid for crypt device and root partition)
-Install Windows on nvme drive /dev/nvme1n1

Problem:
At first everything runs fine. Arch boots, asks for crypt pswd and correctly unlocks, finds root and loads SDDM, login is fine. I can also shutdown/reboot select windows from grub, that boots and works fine. Then, randomly after a reboot or cold boot the device names will change and grub will fail to unlock luks and not find the drive. After investigating, lsblk and fdisk but say Arch in now /dev/nvme1n1 and windows is now /dev/nvme0n1. Windows will keep on working no matter what but I then need to generate new uuids, update fstab, and fix grub. What I found interesting about the issue is that it does not matter where the drives are located on the board. I think it is a device detection thing from POST or when grub loads. Same outcome on 2 different laptops and a desktop PC.

CSM is off
Fast boot is enabled
I have secure boot off.
all hardware is within the last couple years.
running kernel 6.13.5-237-tkg-pds

Last edited by live4thamuzik (2025-03-05 00:00:48)

frostschutz · 2025-03-03 22:21:03

This is "normal". Device names in Linux are not fixed by design. sda, sdb, sdc can change their order. nvme0, nvme1, nvme2 likewise.

Whichever drive gets detected first, gets assigned a name first. This is random. Even if it was deterministic, unplugging a single drive at the start/in the middle would still shift names for all drives that follow.

This is why you use UUIDs for everything, or one of the /dev/disk/by-* symlinks.

For fixed drive names, you'd have to pass a list of serial numbers or pci paths to the kernel or something, so specific drive names can be reserved for specific drives. However no such system is in place, so it can't be done.

live4thamuzik · 2025-03-03 22:29:31

frostschutz wrote:

This is "normal". Device names in Linux are not fixed by design. sda, sdb, sdc can change their order. nvme0, nvme1, nvme2 likewise.
Whichever drive gets detected first, gets assigned a name first. This is random. Even if it was deterministic, unplugging a single drive at the start/in the middle would still shift names for all drives that follow.
This is why you use UUIDs for everything, or one of the /dev/disk/by-* symlinks.
For fixed drive names, you'd have to pass a list of serial numbers or pci paths to the kernel or something, so specific drive names can be reserved for specific drives. However no such system is in place, so it can't be done.

Thanks, I had a sneaking suspicion device detection was at play when it happened while using UUID. I guess if I want windows on its own hard drive I will need to use a sata ssd and keep the nvme for linux. Allowing linux to always be "nvme0" and windows will always appear as "sdX".

frostschutz · 2025-03-03 22:43:46

Yes, well, if that's somehow important to you. Even with just a single drive, you have to use UUIDs. Partitions can change their numbers too and all (if anything decided to edit the partition table for any reason).

If you have an USB stick, that could also end up as sda, and internal drive as sdb...

Basically if you use device names on the command line (for dd, fdisk, mount, ...), you have to develop the habit of checking which device is what first.

You can also use LVM in Linux, that way your Linux filesystems get /dev/vg/lv names that do not usually change. And LVM uses uuids and metadata internally.

Last edited by frostschutz (2025-03-03 22:44:19)

live4thamuzik · 2025-03-03 22:55:35

Okay that makes sense. I am still fairly new to linux. I remember reading that using UUID was the best practice in the wiki and have stuck to it. My current disk setup I like is partiton 1 (efi), partition 2 (/boot), partition 3 (luks then LVM with lv_root and LV_home). I can get away with most of my needs with qemu and libvirt. However, I just like running on baremetal and prefer to keep the two systems seperate.

Thanks for the insight.

cryptearth · 2025-03-04 05:48:26

live4thamuzik wrote:

but I then need to generate new uuids, update fstab, and fix grub.

uhm ... what?
you seem to do something wrong
uuids are, like thier name imply, unique identifiers - they don't change, there's no need to update fstab or grub

menuentry 'Arch Linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-15c36a64-f11c-4f7e-aa6a-3018475d6f6c' {
        savedefault
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root 15c36a64-f11c-4f7e-aa6a-3018475d6f6c
        echo    'Linux linux wird geladen …'
        linux   /boot/vmlinuz-linux root=UUID=15c36a64-f11c-4f7e-aa6a-3018475d6f6c rw
        echo    'Initiale Ramdisk wird geladen …'
        initrd  /boot/amd-ucode.img /boot/initramfs-linux.img
}

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/nvme0n1p3
UUID=15c36a64-f11c-4f7e-aa6a-3018475d6f6c       /            ext4            rw,relatime,stripe=32   0 1

# /dev/nvme0n1p4
UUID=1492773a-1139-4b8e-bfd3-d4558eb64b55       /home        ext4            rw,relatime,stripe=32   0 2

# /dev/nvme0n1p1
UUID=B053-F0B4                                  /efi         vfat            rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 2

# /dev/nvme0n1p2
UUID=da7e198e-53a6-4ccc-be94-761864c95bc9       none         swap            defaults        0 0

to me your problems sounds like user error by using the device paths instead of the uuids
read the instsll guide carefull:
genfstab -U
is for using uuids
grub-mkconfig also defaults to using uuids

if you need to change anything due to nvme0 and nvm1 get swapped you obvious use some non-unique identifier relying on a specific order of these base kernel names

live4thamuzik · 2025-03-04 18:43:46

I stayed in OP that I am using UUID. I can post my /etc/default/grub if you'd like.

To recap, I install arch on /dev/nvme0n1 using UUID for fstab and grub to find the disk and partitions. Os prober enabled

Windows is installed on /dev/nvme1n1.

Everything works fine. Until I reboot or change OS 2 or 3 times. When the kernel loads it's completely random which nvme drive is detected 1st and is labeled nvme0n1.
So if arch is "0n1" and windows is "1n1" from setup and then they switch dev name on boot thanks to device detection then I would need to regenerate a new uuid and fix fstab to match what level is showing. You can easily replicate the issue with the arch iso and 2 nvme drives. I've seen it 3 times.

If you want to see exactly how I setup my disks, I'll share my script with you on GitHub.

Scimmia · 2025-03-04 18:45:52

The UUID is part of the filesystem, it does not change when the device block name changes.

live4thamuzik · 2025-03-04 19:02:12

Scimmia wrote:

The UUID is part of the filesystem, it does not change when the device block name changes.

I understand what a UUID is and how they work.... I am using them and I did RTFM, many times... Idk maybe I'm not making the issue clear enough because I said I am using UUIDs several times now. The issue is that if I have 2 nvme's installed USING UUID, it's still a crapshoot which one is detected as nvme0 and which is nvme1. The unique identifier is still linked to "nvme0" and "nvme1". Regardless of using a UUID or not, if the kernel loads the disks in a different order than they were loaded on setup, grub still points to the wrong device. But I digress, Using one sata disk and 1 nvme disk solves the issue entirely. Because weather I use dev name or UUID the kernel can't confuse /dev/nvmeX with /dev/sdX

#edited for typos

Last edited by live4thamuzik (2025-03-04 19:04:29)

cryptearth · 2025-03-04 19:12:10

live4thamuzik wrote:

I can post my /etc/default/grub if you'd like.
If you want to see exactly how I setup my disks, I'll share my script with you on GitHub.

well - the how about: Please do so. Even in the case your uefi causes some switcheroo about the order how /dev/nvmeX nodes gets numbered (which sure do can happen) that's exactly what uuids are for: to provide a unique 128 bit identifier random enough even with low system entropy while generating them

also: please stop to drag this into some drama like "ahw you don't want to help me and I already told you and ... BLAH"
remember: everyone here is spending thier free pasttime and will to help others - if YOU not willing to at least work along with us to identify the issue to find a solution - be my guest and feel free to leave so we can spent our time on others

Scimmia · 2025-03-04 19:18:44

live4thamuzik wrote:

The unique identifier is still linked to "nvme0" and "nvme1".

This is wrong. Period, end of story. You have something else going on, because there is no way the UUID, which is not detected or calculated but written on disk, is changing because of this

live4thamuzik · 2025-03-04 19:37:58

cryptearth wrote:

also: please stop to drag this into some drama like "ahw you don't want to help me and I already told you and ... BLAH"
remember: everyone here is spending thier free pasttime and will to help others - if YOU not willing to at least work along with us to identify the issue to find a solution - be my guest and feel free to leave so we can spent our time on others

I'll post the grub defaults when I get home.
Script: https://GitHub.com/live4thamuzik/archl4tm (See global_configs.sh look for setup_lvm())

Dude who hurt you? I'm not dragging anything into drama, you responded to a post after I marked it as answered. Isn't that bumping? While I can't blame you for the default response based on experience with newer users, I wasn't convinced you read OP and made an assumption. I'm well aware folks on here are doing this for free in their personal time but getting a polite RTFM response isn't helpful either. I am more than happy to read and learn. yeah I've asked some questions on here and grateful for any and all responses, helpful or not. But don't go all neck beard on someone then get in your feelings because someone clapped back. You're not obligated to help either. I've learned 95% of this on my own. I never complained no one wanted to help. Check your ego

frostschutz · 2025-03-04 19:45:09

UUIDs pointing to the wrong device should not happen, unless you have duplicate UUIDs somehow. If you duplicated partition tables or filesystem with dd, that's one way for that to happen, in which case you have to change UUID for one side.

If `ls -l /dev/disk/by-uuid/abcd*` (replace abcd with any of your uuids) shows `-> ../../nvme0n1p9` (symlink pointing to partition 9 of nvme0) then after reboot, it might point to nvme1n1p9 or nvme2n1p9, but it would be one and the same device each and every time, only its name changed.

That's how UUIDs are supposed to work. You don't change them normally. You put UUID=abcd... or /dev/disk/by-uuid/abcd... into your fstab and that's it.

Last edited by frostschutz (2025-03-04 19:46:07)

live4thamuzik · 2025-03-04 19:48:40

Thanks frost. I have a spare system I've been testing with. I'll play around and start a new post if I need to bounce ideas of someone. This can be closed as the work around with putting windows on sata has been stable thus far.

live4thamuzik · 2025-03-04 21:18:31

Scimmia wrote:

This is wrong. Period, end of story. You have something else going on, because there is no way the UUID, which is not detected or calculated but written on disk, is changing because of this

I'm not saying my UUID's are changing if that is how it is coming off. I know those do not change. Excuse my ignorance if I miss understand this concept but are you saying when I run:

lsblk --output NAME,TYPE,UUID,FSTYPE,MOUNTPOINT

and get this:

NAME                    TYPE  UUID                                   FSTYPE      MOUNTPOINT
nvme0n1                 disk                                                     
├─nvme0n1p1             part  BA52-73B5                              vfat        /boot/efi
├─nvme0n1p2             part  0247c5fb-0463-4e18-bf9e-d8cf0468f955   ext4        /boot
└─nvme0n1p3             part  29d6a2fb-1f23-4227-9f02-80a7c2a26c2a   crypto_LUKS 
  └─volgroup0           crypt lvo8vD-gAv6-1niS-kd1b-2U5j-3Tlf-BP6xjD LVM2_member 
    ├─volgroup0-lv_root lvm   a0811ea2-280e-45c6-8c5f-ef5d05639e22   ext4        /
    └─volgroup0-lv_home lvm   0cbd0160-04ee-4f7e-ace1-513e2c17e971   ext4        /home

That 29d6a2fb-1f23-4227-9f02-80a7c2a26c2a and nvme0n1p3 are in no way, shape, or form, linked to one another? My thought was that while the UUID stays the same, if kernel swaps the device name, my fstab would till point the aforementioned UUID to nvme0n1, not nvme1n1 thus causing failure to unlock luks which is why I am making new UUIDs to put in fstab so everything aligns...

FSTAB:

File: /etc/fstab
───────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ # Static information about the filesystems.
   2   │ # See fstab(5) for details.
   3   │ 
   4   │ # <file system> <dir> <type> <options> <dump> <pass>
   5   │ # /dev/mapper/volgroup0-lv_root
   6   │ UUID=a0811ea2-280e-45c6-8c5f-ef5d05639e22   /           ext4        rw,relatime 0 1
   7   │ 
   8   │ # /dev/nvme0n1p2
   9   │ UUID=0247c5fb-0463-4e18-bf9e-d8cf0468f955   /boot       ext4        rw,relatime 0 2
  10   │ 
  11   │ # /dev/nvme0n1p1
  12   │ UUID=BA52-73B5          /boot/efi   vfat        rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mi
       │ xed,utf8,errors=remount-ro   0 2
  13   │ 
  14   │ # /dev/mapper/volgroup0-lv_home
  15   │ UUID=0cbd0160-04ee-4f7e-ace1-513e2c17e971   /home       ext4        rw,relatime 0 2

etc/defaullt/grub

# GRUB boot loader configuration
   2   │ 
   3   │ GRUB_DEFAULT=saved
   4   │ GRUB_TIMEOUT=3
   5   │ GRUB_DISTRIBUTOR="Arch"
   6   │ GRUB_CMDLINE_LINUX_DEFAULT="quiet splash cryptdevice=UUID=29d6a2fb-1f23-4227-9f02-80a7c2a26c2a:volgroup0 root=UUID=a0811ea2-280e-45c6-8c5f-ef5d05639e22 amdgpu.dc=1 amdgpu.enable_dc=1 loglevel=3"
   7   │ GRUB_CMDLINE_LINUX=""
   8   │ 
   9   │ # Preload both GPT and MBR modules so that they are not missed
  10   │ GRUB_PRELOAD_MODULES="part_gpt part_msdos"
  11   │ 
  12   │ # Uncomment to enable booting from LUKS encrypted devices
  13   │ GRUB_ENABLE_CRYPTODISK=y
  14   │ 
  15   │ # Set to 'countdown' or 'hidden' to change timeout behavior,
  16   │ # press ESC key to display menu.
  17   │ GRUB_TIMEOUT_STYLE=menu
  18   │ 
  19   │ # Uncomment to use basic console
  20   │ GRUB_TERMINAL_INPUT=console
  21   │ 
  22   │ # Uncomment to disable graphical terminal
  23   │ #GRUB_TERMINAL_OUTPUT=console
  24   │ 
  25   │ # The resolution used on graphical terminal
  26   │ # note that you can use only modes which your graphic card supports via VBE
  27   │ # you can see them in real GRUB with the command `videoinfo'
  28   │ GRUB_GFXMODE=2560x1440x32
  29   │ 
  30   │ # Uncomment to allow the kernel use the same resolution used by grub
  31   │ GRUB_GFXPAYLOAD_LINUX=keep
  32   │ 
  33   │ # Uncomment if you want GRUB to pass to the Linux kernel the old parameter
  34   │ # format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx"
  35   │ #GRUB_DISABLE_LINUX_UUID=true
  36   │ 
  37   │ # Uncomment to disable generation of recovery mode menu entries
  38   │ GRUB_DISABLE_RECOVERY=true
  39   │ 
  40   │ # Uncomment and set to the desired menu colors.  Used by normal and wallpaper
  41   │ # modes only.  Entries specified as foreground/background.
  42   │ #GRUB_COLOR_NORMAL="light-blue/black"
  43   │ #GRUB_COLOR_HIGHLIGHT="light-cyan/blue"
  44   │ 
  45   │ # Uncomment one of them for the gfx desired, a image background or a gfxtheme
  46   │ #GRUB_BACKGROUND="/path/to/wallpaper"
  47   │ GRUB_THEME="/boot/grub/themes/poly-dark/theme.txt"
  48   │ 
  49   │ # Uncomment to get a beep at GRUB start
  50   │ #GRUB_INIT_TUNE="480 440 1"
  51   │ 
  52   │ # Uncomment to make GRUB remember the last selection. This requires
  53   │ # setting 'GRUB_DEFAULT=saved' above.
  54   │ GRUB_SAVEDEFAULT=true
  55   │ 
  56   │ # Uncomment to disable submenus in boot menu
  57   │ #GRUB_DISABLE_SUBMENU=y

Last edited by live4thamuzik (2025-03-04 21:20:15)

live4thamuzik · 2025-03-05 00:04:55

Added the 2nd nvme installed windows, seems fine and I have seen device names change without causing issues thus far. only thing I did different was, after installing windows on the 2nd drive I went back into arch to run sudo os-prober to ensure it could find and mount windows correctly, then ran sudo grub-mkconfig -o /boot/grub/grub.cfg

cryptearth · 2025-03-05 01:14:17

I will keep it as short and simple as possible as there's too much nonesense:
you failed to follow the wiki!
https://wiki.archlinux.org/title/Dm-cry … t_loader_2

cryptdevice=UUID=device-UUID:cryptlvm root=/dev/MyVolGroup/root

your line

cryptdevice=UUID=device-UUID:cryptlvm root=UUID=

there's nothin much to say other than:

Dude who hurt you? [...] Check your ego

as you asked for it I sure won't fail you with a honest reply: idiots like you thinking they can outsmart the combined knowledge of people doing that crap for decades as thier jobs - failing at it - and can't stand people like me calling them out by just writing down the lines as they form in my head
the wiki gives you an example how to do it right - overall with the general install guide something to be done in about 20 lines
YOU: pointing to a repo with 1.500 (!) lines of script - and still fail along with complete bullshit just showing you not just got something a bit wrong at some point - but you don'T have any clue about what you're talkin about
I have to get my ego checked? well - doin my current job for 12 years now - and getting my ego stroked several times a day by my customers and my superiors - YOUR problem is that you can't stand people like me not just hiding behind anonymity of the internet but having the balls to even tell this someone 3 heads bigger then me straight into the face

using a sata drive fixes it

I highly doubt that using a drive just with a different physical connector does make the difference - and it doesn't even matter that sata is usually using AHCI instead of NVME used by M.2 - we dealing with FILESYSTEMS here! - and at that point we're already far from a blockdevice already - we're even past MBR vs GPT or ESP vs /boot vs /crypto-root - we're at a point where to read a filesystems header is so far beyond m.2 vs sata - nvme vs. ahci - that it wouldn't matter if its SCSI, USB, iSCSI from a PXE stack or E-IDE

So if arch is "0n1" and windows is "1n1" from setup and then they switch dev name on boot thanks to device detection then I would need to regenerate a new uuid and fix fstab to match what level is showing.

uhm - NOPE! - because a filesystems uuid remains the same no matter what a linux kernel gives it as device node naming

The unique identifier is still linked to "nvme0" and "nvme1"

NOOOO! it's NOT! - that's the WHOLE POINT of using a Universally unique identifier which is written to the very partition it designates - to de-couple it from how the kernel maybe names the device node in /dev so that it does NOT matter if a partition shows up as /dev/nvme0 and one boot and as /dev/sr4 on the next one

I understand what a UUID is and how they work

you very clearly DO NOT understand what a uuid is or how it works

Regardless of using a UUID or not, if the kernel loads the disks in a different order than they were loaded on setup, grub still points to the wrong device.

now we are past the "things that make you grr" topic but already jumping right off the cliff - you don'T even understand how a modern system boots
at the time of when grub reads its config and execute

search --no-floppy --fs-uuid --set=root 15c36a64-f11c-4f7e-aa6a-3018475d6f6c

there's is no linux kernel - as grub doesn't even know where to find it yet
HOW the F CAN grub point to the wrong device in the first place when it's perfectly fine reading its config and modules just fine from the correct one? and the point grub is running stuff like linux kernel device nodes or /dev doesn't even exists yet - grub has no concept of /dev/nvmeX - that's a linux kernel thing! if anything at all grub uses UEFI device path identifiers - looking something similar to how linux names pci devices - which then get abstracted by more simpler terms like (hd0,p1) and are resolved internally

Because weather I use dev name or UUID the kernel can't confuse /dev/nvmeX with /dev/sdX

that's just nonesense - these are both just block devices and in that completely identical to the kernel - only the underlying storage driver knows the difference between nvme and ahci

and I am the one who has to get his ego checked? yea - right ... at least I tried to give a helping hand - after

After investigating, lsblk and fdisk but say Arch in now /dev/nvme1n1 and windows is now /dev/nvme0n1.

I already knew: "yeap - user error" and could had passed along - at least I've tried - just to learn this isn't some weird bug but simple user error

https://bbs.archlinux.org/viewtopic.php … 0#p2210470
https://bbs.archlinux.org/viewtopic.php … 4#p2201104

next time I read your nick I won't even touch the topic - that you can be sure of

WorMzy · 2025-03-05 20:36:31

Let's tone it down a notch, please.

https://terms.archlinux.org/docs/code-o … ther-users
https://terms.archlinux.org/docs/code-o … -not-flame

I'm going to go ahead and close this topic to prevent it going any further off the rails.

Arch Linux

#1 2025-03-03 22:11:29

[SOLVED] NVME Drive name changing - Dual boot

#2 2025-03-03 22:21:03

Re: [SOLVED] NVME Drive name changing - Dual boot

#3 2025-03-03 22:29:31

Re: [SOLVED] NVME Drive name changing - Dual boot

#4 2025-03-03 22:43:46

Re: [SOLVED] NVME Drive name changing - Dual boot

#5 2025-03-03 22:55:35

Re: [SOLVED] NVME Drive name changing - Dual boot

#6 2025-03-04 05:48:26

Re: [SOLVED] NVME Drive name changing - Dual boot

#7 2025-03-04 18:43:46

Re: [SOLVED] NVME Drive name changing - Dual boot

#8 2025-03-04 18:45:52

Re: [SOLVED] NVME Drive name changing - Dual boot

#9 2025-03-04 19:02:12

Re: [SOLVED] NVME Drive name changing - Dual boot

#10 2025-03-04 19:12:10

Re: [SOLVED] NVME Drive name changing - Dual boot

#11 2025-03-04 19:18:44

Re: [SOLVED] NVME Drive name changing - Dual boot

#12 2025-03-04 19:37:58

Re: [SOLVED] NVME Drive name changing - Dual boot

#13 2025-03-04 19:45:09

Re: [SOLVED] NVME Drive name changing - Dual boot

#14 2025-03-04 19:48:40

Re: [SOLVED] NVME Drive name changing - Dual boot

#15 2025-03-04 21:18:31

Re: [SOLVED] NVME Drive name changing - Dual boot

#16 2025-03-05 00:04:55

Re: [SOLVED] NVME Drive name changing - Dual boot

#17 2025-03-05 01:14:17

Re: [SOLVED] NVME Drive name changing - Dual boot

#18 2025-03-05 20:36:31

Re: [SOLVED] NVME Drive name changing - Dual boot

Board footer