LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 01-18-2019, 01:09 AM   #1
WFV
Member
 
Registered: Apr 2012
Location: CA
Distribution: Arch
Posts: 171

Rep: Reputation: Disabled
udev changes /dev/sd* most every reboot, can they be static?


I understand udev names devices as they become known during boot, so sda might be sdb, c, or d next reboot - I've already setup fstab to use UUID's for long time so always have bootable system. Replaced power supply 2 mo's ago and since then the /dev/sdX's are no longer persistent, but also maybe due to systemd updates. What I'm after is that my SSD root drive is always /dev/sda, and my HDD /home drive is always /dev/sdb, and two other internal HDDs follow suit.
Based on this and this I've come up with this udev rule /etc/udev/rules.d/10-local.rules
Code:
ATTR{ID_MODEL}=="SanDisk_SDSSDHII120G", ATTR{ID_SERIAL_SHORT}=="153984400672", KERNEL=="sd?", NAME="sda"
ATTR{ID_MODEL}=="WDC_WD2003FZEX-00SRLA0", ATTR{ID_SERIAL_SHORT}=="WD-WMC6N0K3T174", KERNEL=="sd?", NAME="sdb"
ATTR{ID_MODEL}=="WDC_WD4002FYYZ-01B7CB1", ATTR{ID_SERIAL_SHORT}=="K7HMGMEL", KERNEL=="sd?", NAME="sdc"
ATTR{ID_MODEL}=="WDC_WD2003FZEX-00Z4SA0", ATTR{ID_SERIAL_SHORT}=="WD-WMC5C0D2D0PM", KERNEL=="sd?", NAME="sdd"
but not sure if the rule is correct, haven't loaded it and rebooted yet...
Not sure if /usr/lib/udev/rules.d/60-persistent-storage.rules will overwrite this. Reviewing Arch Wiki, seems I'm on the right path, but hoping I can get some clarification and guidance here.
Anyone more knowledgeable in writing udev rule for static /dev/sdX can help?
Thank you.
EDIT: edited title

Last edited by WFV; 01-19-2019 at 09:42 PM.
 
Old 01-18-2019, 05:56 AM   #2
wpeckham
Senior Member
 
Registered: Apr 2010
Location: Continental USA
Distribution: Debian, Ubuntu, Fedora, RedHat, DSL, Puppy, CentOS, Knoppix, Mint-DE, Sparky, Vsido, tinycore, Q4OS
Posts: 3,045

Rep: Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332
I have not run into the problem, but I HAVE implemented a solution for other reasons. Here are TWO ideas that may help.

#1 if you use software raid, devices are recognized by the raid identifier. Clearly, this only helps if you have multiple devices and can organize them into raid devices.

#2 if you LABEL the volumes, and then mount them by LABEL, the UUID can do anything it wants and it will have no effect. I suggest you look into applying a LABEL to your devices.
 
1 members found this post helpful.
Old 01-18-2019, 11:46 AM   #3
WFV
Member
 
Registered: Apr 2012
Location: CA
Distribution: Arch
Posts: 171

Original Poster
Rep: Reputation: Disabled
@ wpeckham, Thank you, not sure I understand your suggestion. Nothing RAID, just a very basic setup:
Code:
lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 111.8G  0 disk 
└─sda1   8:1    0 100.6G  0 part /
sdb      8:16   0   1.8T  0 disk 
└─sdb1   8:17   0   1.8T  0 part /home
sdc      8:32   0   3.7T  0 disk 
├─sdc1   8:33   0     4M  0 part 
├─sdc2   8:34   0     1T  0 part /mnt/d1rootbkp
└─sdc3   8:35   0   2.7T  0 part /mnt/d2homebkp
sdd      8:48   0   1.8T  0 disk 
├─sdd1   8:49   0  59.6G  0 part 
└─sdd2   8:50   0   1.8T  0 part 
sr0     11:0    1  1024M  0 rom  
sr1     11:1    1  1024M  0 rom
sda, b and d are labeled:
Code:
blkid
/dev/sda1: LABEL="root" UUID="*****" TYPE="ext4" PARTUUID="*****"
/dev/sdb1: LABEL="HOMER" UUID="*****" TYPE="ext4" PARTUUID="*****"
/dev/sdc1: PARTUUID="*****"
/dev/sdc2: UUID="*****" TYPE="ext4" PARTLABEL="BROOT" PARTUUID="*****"
/dev/sdc3: UUID="*****" TYPE="ext4" PARTLABEL="BHOME" PARTUUID="*****"
/dev/sdd1: LABEL="ROOTBKP" UUID="*****" TYPE="ext4" PARTUUID="*****"
/dev/sdd2: LABEL="HOMEBKP" UUID="*****" TYPE="ext4" PARTUUID="*****"
but I don't find in the udev disk attributes "LABEL", which makes sense, as only the paritions are labeled. Correct me if I'm wrong but if referring to fstab using labels I'm pretty sure it makes no difference labels vs uuid as neither change on their own. fstab doesn't assure udev will load disks so that SSD is always /dev/sda it only assures it is always "/". This started when I replaced power supply, the 6.5yrs preceding always loaded /dev/sdX as per above, so I think the power outlets on the new power supply don't all turn on at once (within ms but still not all at once and order of operation isn't repetitious) so next reboot sda might be sdd .
 
Old 01-18-2019, 12:27 PM   #4
273
LQ Addict
 
Registered: Dec 2011
Location: UK
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 7,367

Rep: Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258
I'm not sure I understand this: Do the UUIDs of the disks change?
The "/dev/sd*" designation is handed out to the first drive to claim the letter and is irrelevant for anything but hotplug devices?
 
Old 01-18-2019, 01:00 PM   #5
WFV
Member
 
Registered: Apr 2012
Location: CA
Distribution: Arch
Posts: 171

Original Poster
Rep: Reputation: Disabled
@ 273, no the uuid's don't change, i just blanked them out "*****" in the post. "/dev/sd*" changes, and though I understand why as you mention, which is why I switched fstab to use UUID's a long time ago instead of sd*, the sd*'s never changed on every reboot until I replaced the power supply (about the same time systemd upgraded to 240). I was reading up on how to make internal SATA drives always claim the same sd* on every boot (like they used to). This so that the disk physically connected to the mobo at SATA1 which is my SSD and "/" drive will always claim /dev/sda1, and the disk physically connected to mobo at SATA2 which is my "/home" drive will always claim /dev/sdb1. Same for the other two physically connected to mobo at SATA3 and SATA4 respectively claim /dev/sdc... and /dev/sdd.. with every boot. Arch Wiki states that udev rule can be used to do this. I've read
Code:
man udev
but not all of the subsets (5)(8) etc so far, and read several other forums than those mentioned and was asking here if the udev rule I'm considering is correct for udev? I will test it this weekend as feel confident if it doesn't work it can be removed even if have to chroot to remove it (worse case).

EDIT: so the Wiki using udev rule for /dev/sd* only applies to hotplug devices? it gives those examples but seems to imply it can be done for internal drives as well.

Last edited by WFV; 01-18-2019 at 01:03 PM.
 
Old 01-18-2019, 01:04 PM   #6
273
LQ Addict
 
Registered: Dec 2011
Location: UK
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 7,367

Rep: Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258
My advice would be to just use UUIDs. This isn't new, I saw it 10 years ago, and so on. It's simply a result of how the motherboard and power supply are configured.
 
Old 01-18-2019, 01:35 PM   #7
WFV
Member
 
Registered: Apr 2012
Location: CA
Distribution: Arch
Posts: 171

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by 273 View Post
My advice would be to just use UUIDs. This isn't new, I saw it 10 years ago, and so on. It's simply a result of how the motherboard and power supply are configured.
Thanks, yes has been around long time, I just haven't had to deal with it until recently. Looks like the ways to use udev rule for static /dev/sd* claiming are spelled out in
Code:
man 7 udev
EDIT: grammar

Last edited by WFV; 01-18-2019 at 01:37 PM.
 
Old 01-18-2019, 01:37 PM   #8
273
LQ Addict
 
Registered: Dec 2011
Location: UK
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 7,367

Rep: Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258
I really don't understand why you are trying to do this?
 
Old 01-18-2019, 02:01 PM   #9
WFV
Member
 
Registered: Apr 2012
Location: CA
Distribution: Arch
Posts: 171

Original Poster
Rep: Reputation: Disabled
Mostly has to do with sdd1 and sdd2. /dev/sdd I only mount manually occasionally and then rsync some files there, so have a couple rsync scripts I run and don't want to run them to the wrong place if after a pc reboot sdd is no longer sdd. So to keep from making that mistake want to set system to always claim same /dev/sd* per disk every reboot regardless of discovery. I thought to change the power connectors but realized reboot reordering wasn't consistent either, in other words if sda always booted to sdd on first cold boot or reboot, then the power cable approach may work, but sometimes its sdc, sometimes sdb, usually after 3 or 4 reboots or a second cold boot, everything falls into SATA1 = sda, SATA2 = sdb, SATA3 = sdc, SATA4 = sdd which is what I'm after. SATA5 and 6 = sr0 and 1 but not concerned if those two switch order. Because Arch is a rolling distro, pc gets rebooted often enough, the extra reboots for device names I want to eliminate.
 
Old 01-18-2019, 04:33 PM   #10
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 18,140

Rep: Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935
rsync is all about files - and filesystems. It doesn't care about the real device, and neither should you - use -L on the mount command.
KISS

Mind you, I'd be worried about that power supply. I've had situations where different distros on the same machine report different disk order, but they never changed within each distro. In my case it was because of a mix of (E)IDE and SATA drives.
 
2 members found this post helpful.
Old 01-19-2019, 12:46 PM   #11
WFV
Member
 
Registered: Apr 2012
Location: CA
Distribution: Arch
Posts: 171

Original Poster
Rep: Reputation: Disabled
@ syg00 thank you. It's a brand new P/S but doesn't mean possible defect. I'm going to check the EC Mode switch as I think its on but is not accessible from outside the desktop case.
Understood on rysnc but completely missed the mount -L operation
KISS is subjective in Linux; some of Linux greatest features are that one can build their own pc almost any way desired as linux freedom practically spans the entire spectrum of individual human:computer endeavor, including simplicity, complexity, triumph and error. Perhaps the udev rule in this forum was an unintended consequence of the writers of udev? i dunno.
Back to original question, if I understand the Wiki and udev man pages correctly then the udev rule should work, haven't tried it, probably won't based on support in this forum, there are simpler and better means of approach
 
Old 01-19-2019, 07:13 PM   #12
wpeckham
Senior Member
 
Registered: Apr 2010
Location: Continental USA
Distribution: Debian, Ubuntu, Fedora, RedHat, DSL, Puppy, CentOS, Knoppix, Mint-DE, Sparky, Vsido, tinycore, Q4OS
Posts: 3,045

Rep: Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332
WFV: the device names udev gives the devices should be irrelevant, you should not be using them. You use the UUID or LABEL to mount, and then address by the mount. If you are addressing the mounted data using rsync and the device name, you are already wrong.
(By wrong here I do not mean that you cannot make it work, but that you should not. You are building something that is easy to break and simple to have break without detection and with potentially catastrophic consequences.)

WHY would you want to address the devices and partitions by the device name instead of the mount path?
 
1 members found this post helpful.
Old 01-19-2019, 10:10 PM   #13
WFV
Member
 
Registered: Apr 2012
Location: CA
Distribution: Arch
Posts: 171

Original Poster
Rep: Reputation: Disabled
wpeckham: agreed regarding udev. The fourth drive I don't mount in fstab, just manually occasionally. So for years ran
Code:
# mount /dev/sddX /path/to/mount/point
and umount when done, because that particular drive always claimed sdd. Point taken by all who replied here, thanks all.
I checked the P/S and eco switch was off. Eco switch is about energy-saving when running so have no idea if it impacts startup or not but checked it anyway, as syg00 pointed out could <still> be problem with the new P/S. I reattached the first three drives so that the SSD "/" drive is first of the parallel connectors, "/home" drive is second, theoretically being parallel connections it shouldn't matter. Didn't test anything else about the P/S. Rebooted normal (sda,b,c,d = sata1,2,3,4), no special rule.
Maybe the Arch Wiki should also warn against using udev to statically assign internal drive names? It implies that udev rule can be used to avert such changes:
Quote:
Because udev loads all modules asynchronously, they are initialized in a different order. This can result in devices randomly switching names. A udev rule can be added to use static device names. See also Persistent block device naming for block devices...
and man 7 udev elaborates a little more.
I'm going to mark as solved because
Code:
# mount -L
will do as needed. The title is edited to reflect the original problem, rebooting changes internal drive letters.
 
Old 01-19-2019, 10:30 PM   #14
mrmazda
Senior Member
 
Registered: Aug 2016
Location: USA
Distribution: openSUSE, Debian, Knoppix, Mageia, Fedora, others
Posts: 1,772

Rep: Reputation: 544Reputation: 544Reputation: 544Reputation: 544Reputation: 544Reputation: 544
As this seems to have begun when PS was replaced, there is a non-obvious implication that SATA cables may be involved too, as in having R&R'd them in working in and out the new and old power cables. So, it may be worth time spent on SATA cable swapping, and/or replacement.

If all the SATA power leads are not the same length, maybe putting the shortest one on intended sda and the longest one on intended sdd would make a difference. Same might apply if your SATA control cables are not all identical.

Does smartctl report any issues with your sdd or sdc?

You do have intended sda on SATA port 0/1 and intended sdd on SATA port 3/4, right?

Is a motherboard BIOS update available?
 
1 members found this post helpful.
Old 01-19-2019, 11:28 PM   #15
WFV
Member
 
Registered: Apr 2012
Location: CA
Distribution: Arch
Posts: 171

Original Poster
Rep: Reputation: Disabled
@ mrmazda: all of the drives pass smart although sdb had S.M.A.R.T. ERROR in the BIOS post before replacing P/S (but passed smartctl tests), after replacing P/S BIOS post shows "S.M.A.R.T. cable & status OK" on all 4 drives, smartctl ok also.
sdb (2TB HDD) and sdc (4TB HDD) are < 6mo old.
The control cables are new with P/S (modular, all same length) but yes worth looking into the sata cables, they are different lengths and purchased most of them about same time as pc (almost 7yrs ago, some a year or two later). SDA cable is longer than the others - very good point (not sure if the shorter cable will reach without moving the drive location, but can do that too).
Yes intended drives physically connected to mobo: sda SATA port 1, sdb port 2, sdc port 3, sdd port 4 (DVD's in ports 5 & 6).
No BIOS updates available, is an Asus M5A88-M with last latest bios from Dec 2013, reports as May 2013 however, its flashed with the ROM from Asus website of Dec 2013:
Code:
  BIOS Info: #0
    Vendor: "American Megatrends Inc."
    Version: "1702"
    Date: "05/01/2013"
Thank you for your feedback.

EDIT: redid the SATA cables so shortest to longest are SATA1,2,3,4 (1=/, 2=/home, 4TB hdd=3, umounted 2TB=4 physically) but made no difference, first boot rearranged... not a SATA cable thing.

Last edited by WFV; 01-25-2019 at 11:46 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Technology Changes Us, Changes Society, and Changes Governments LXer Syndicated Linux News 0 10-10-2016 02:00 PM
network interface names having strange names because of udev rules pascaltaf Linux - Kernel 5 01-08-2015 09:07 AM
udev: persistent scsi disk names cothgr Linux - Software 3 06-27-2014 04:44 PM
Changes to /etc files revert changes after reboot yeahya Linux - General 2 11-22-2010 08:42 PM
Device name changes each time I connect a USB drive? Can this be static? bartlet Linux - Newbie 1 11-02-2008 05:12 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 08:38 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration