Hi
I have read instructions for udev, I also found many example on how to do this. I want to lock in the SDA/SDB/SDC for my drives and I came up with a rule like this
KERNEL=="sd?", SUBSYSTEM=="block", ENV{ID_SERIAL}=="ST500DM002-1BC142_W2A56H8A", NAME="sda", RUN+="/usr/bin/logger ID_SERIAL=$ENV{ID_SERIAL} set to /dev/sda ", GOTO="END_PERSISTENT_DISK"
However, it is not clear to me is in what files I need to add my rules.
Do I add a random file "99-my-rules.rules" in "/etc/udev/rules.d/"?
Do I copy a file from "/usr/lib/udev" to "/etc/udev/rules.d/" and add my rules?
Do I need to be careful with the NUMBER, e.g. "60-my-rule.rules"?
Jobst
Le 28/02/2019 à 04:12, Jobst Schmalenbach a écrit :
I want to lock in the SDA/SDB/SDC for my drives
In short : use UUIDs or labels instead of hardcoding /dev/sdX.
https://wiki.archlinux.org/index.php/persistent_block_device_naming
Cheers,
Niki
Nicolas Kovacs wrote:
Le 28/02/2019 à 04:12, Jobst Schmalenbach a écrit :
I want to lock in the SDA/SDB/SDC for my drives
In short : use UUIDs or labels instead of hardcoding /dev/sdX.
https://wiki.archlinux.org/index.php/persistent_block_device_naming
Yeah - I strongly believe in labels, given the fact that *no* one can remember a UUID....
mark
On Thu, Feb 28, 2019 at 11:52 AM mark m.roth@5-cent.us wrote:
Nicolas Kovacs wrote:
Le 28/02/2019 à 04:12, Jobst Schmalenbach a écrit :
I want to lock in the SDA/SDB/SDC for my drives
In short : use UUIDs or labels instead of hardcoding /dev/sdX.
https://wiki.archlinux.org/index.php/persistent_block_device_naming
Yeah - I strongly believe in labels, given the fact that *no* one can remember a UUID....
mark
ls -l /dev/disk/by-uuid
(copy)
(paste)
On 2/28/19 11:02 AM, Phelps, Matthew wrote:
On Thu, Feb 28, 2019 at 11:52 AM mark m.roth@5-cent.us wrote:
Nicolas Kovacs wrote:
Le 28/02/2019 à 04:12, Jobst Schmalenbach a écrit :
I want to lock in the SDA/SDB/SDC for my drives
In short : use UUIDs or labels instead of hardcoding /dev/sdX.
https://wiki.archlinux.org/index.php/persistent_block_device_naming
Yeah - I strongly believe in labels, given the fact that *no* one can remember a UUID....
markls -l /dev/disk/by-uuid
(copy)
(paste)
I second Mark about filesystem labels. Labels you can read and type. UUIDs you can only copy and paste. Yes I did type them a few times, but... With upside there certainly comes downside of filesystem labels: if you are moving storage around you sometimes can hit the situation of having two identical labels. Which during last couple of decades I was able to get around.
Valeri
Phelps, Matthew wrote:
On Thu, Feb 28, 2019 at 11:52 AM mark m.roth@5-cent.us wrote:
Nicolas Kovacs wrote:
Le 28/02/2019 à 04:12, Jobst Schmalenbach a écrit :
I want to lock in the SDA/SDB/SDC for my drives
In short : use UUIDs or labels instead of hardcoding /dev/sdX.
https://wiki.archlinux.org/index.php/persistent_block_device_naming
Yeah - I strongly believe in labels, given the fact that *no* one can remember a UUID....
ls -l /dev/disk/by-uuid (copy) (paste)
That is, of course, assuming you have a running system, that you haven't replaced a hard drive, an MDraid's not giving you trouble, etc.
And oh, I put that in another system, and it's also got partition one labled boot... so? I'm not trying to boot off of it, I'm going to mount it on /mnt.
No, I dislike UUIDs. I dislike, strongly, lots of extra typing that doesn't really get me anything. MAYBE, if you're in a Google or Amazon datacenter, with 500,000 physical servers (I phone interviewed with them 10 years ago)... but short of that? Nope.
mark
No, I dislike UUIDs. I dislike, strongly, lots of extra typing that doesn't really get me anything. MAYBE, if you're in a Google or Amazon datacenter, with 500,000 physical servers (I phone interviewed with them 10 years ago)... but short of that? Nope.
You can (perhaps should...) use the World Wide Name, which is a manufacturer ID unique to each disk. Contrary to the /sdX, it doesn't change with different configurations, OS or computer. An example of such an ID is the following:
/dev/disk/by-id/wwn-0x50025ee3b4f5ca61
Many modern disks have their WWN printed on their labels.
miguel medalha wrote:
No, I dislike UUIDs. I dislike, strongly, lots of extra typing that doesn't really get me anything. MAYBE, if you're in a Google or Amazon datacenter, with 500,000 physical servers (I phone interviewed with them 10 years ago)... but short of that? Nope.
You can (perhaps should...) use the World Wide Name, which is a manufacturer ID unique to each disk. Contrary to the /sdX, it doesn't change with different configurations, OS or computer. An example of such an ID is the following:
/dev/disk/by-id/wwn-0x50025ee3b4f5ca61
Many modern disks have their WWN printed on their labels.
Why? And if I'm partitioning it, that won't work anyway. I partition, then format with -l <labelname> and I don't *have* to change configuration, if I'm say, replacing a failed disk. The labels I use *mean* something - root, export, etc. Why would I want a meaningless id? That's like companies who name everyone's computer some id, rather than, say, mrothltp?
Hell, a few hours ago, a manager came to me to ask about network issues. I thought I'd try to ping his system, and asked him the system name. Of *course* he couldn't remember it.
Self-documenting ia useful, if not carried overboard.
mark
On Feb 28, 2019, at 13:29, mark m.roth@5-cent.us wrote:
No, I dislike UUIDs. I dislike, strongly, lots of extra typing that doesn't really get me anything. MAYBE, if you're in a Google or Amazon datacenter, with 500,000 physical servers (I phone interviewed with them 10 years ago)... but short of that? Nope.
I’ve never in my career ever had to type out a UUID.
You don’t need to be that big to benefit from automation. Even small shops would benefit from reproducible builds. Not every system needs to have loveingly crafted artisanal partition labels.
All of this is moot, though, because I use lvm and so I just use /dev/volumegroup/logicalname, and that’s all assembled automatically in the kickstart. I only ever think about uuids when dealing with UEFI issues.
— Jonathan Billings billings@negate.org
Nicolas Kovacs wrote:
Le 28/02/2019 à 04:12, Jobst Schmalenbach a écrit :
I want to lock in the SDA/SDB/SDC for my drives
In short : use UUIDs or labels instead of hardcoding /dev/sdX.
https://wiki.archlinux.org/index.php/persistent_block_device_naming
Yeah - I strongly believe in labels, given the fact that *no* one can remember a UUID....
UUIDs can be helpful to automate things. On the other side they make things more difficult than needed.
In my example I had two quite large servers with existing hardware. One of the servers was already installed and in production. I had to clone the hole system onto the second box but make sure that all UUIDs are unique in the end.
Back in the old days that was an very easy task. But now, the hole system consisted of 91 UUIDs for block devices/LVM/filesystems alone, with additional UUIDs for other devices like ethernet interfaces.
I had a lot of fun!
Regards, Simon
On Thu, Feb 28, 2019 at 05:19:49PM +0100, Nicolas Kovacs (info@microlinux.fr) wrote:
Le 28/02/2019 à 04:12, Jobst Schmalenbach a écrit :
I want to lock in the SDA/SDB/SDC for my drives
In short : use UUIDs or labels instead of hardcoding /dev/sdX.
I **KNOW** how to use UUID's ... this is NOT the reason why I am doing this!
I *NEED* the order of the disks to be SDA(1st BIOS drive) SDB(2nd BIOS drive) SDC(3rd BIOS drive) and not SDA (1st BIOS drive) SDB(3rd BIOS drive) SDC (2nd BIOS drive).
Reason: it stuffs up the use of grub2* utilities leaving behind a bunch of error messages. The SDA (1st BIOS drive) and SDB (2nd BIOS drive) are part of a MDADM raid(1) system.
As soon as I plug in the third drive, the OS (or systemD) decides to put it into the SDB spot - I do NOT want that. When I the use any of the grub2 utils I end up with "missing drive" errors.
If I leave the drive out NO problem. I have managed twice to have the machine booting with the third drive as SDC, when that happens I I do not get any error messages.
Jobst
On 2/28/19 10:04 PM, Jobst Schmalenbach wrote:
On Thu, Feb 28, 2019 at 05:19:49PM +0100, Nicolas Kovacs (info@microlinux.fr) wrote:
Le 28/02/2019 à 04:12, Jobst Schmalenbach a écrit :
I want to lock in the SDA/SDB/SDC for my drives
In short : use UUIDs or labels instead of hardcoding /dev/sdX.
I **KNOW** how to use UUID's ... this is NOT the reason why I am doing this!
I *NEED* the order of the disks to be SDA(1st BIOS drive) SDB(2nd BIOS drive) SDC(3rd BIOS drive) and not SDA (1st BIOS drive) SDB(3rd BIOS drive) SDC (2nd BIOS drive).
Reason: it stuffs up the use of grub2* utilities leaving behind a bunch of error messages. The SDA (1st BIOS drive) and SDB (2nd BIOS drive) are part of a MDADM raid(1) system.
As soon as I plug in the third drive, the OS (or systemD) decides to put it into the SDB spot - I do NOT want that. When I the use any of the grub2 utils I end up with "missing drive" errors.
Try to switch physical connections of second and third drives, then you most likely will have the correct "BIOS" order of physical drives. As, as far as I understand, the letters are assigned in the order the bus scan discovers drives (or - though less likely - in reverse order, at least reverse order once was for network interfaces, like discovered ones were pushed into stack, and then used in the order they were popped out of the stack).
Valeri
If I leave the drive out NO problem. I have managed twice to have the machine booting with the third drive as SDC, when that happens I I do not get any error messages.
Jobst
On Fri, Mar 01, 2019 at 09:48:55AM -0600, Valeri Galtsev (galtsev@kicp.uchicago.edu) wrote:
On 2/28/19 10:04 PM, Jobst Schmalenbach wrote:
On Thu, Feb 28, 2019 at 05:19:49PM +0100, Nicolas Kovacs (info@microlinux.fr) wrote:
Le 28/02/2019 à 04:12, Jobst Schmalenbach a écrit :
I want to lock in the SDA/SDB/SDC for my drives
In short : use UUIDs or labels instead of hardcoding /dev/sdX.
I **KNOW** how to use UUID's ... this is NOT the reason why I am doing this!
Try to switch physical connections of second and third drives, then you most likely will have the correct "BIOS" order of physical drives. As, as far as
It seems I need to go that way as I learned that you cannot use UDEV to swtich the names of sdX as assigned by the kernel. You can only ADD (as in make an extra name) but not RENAME :-(.
It's weird though even in the BIOS they are assigned
SDA (mirror 1) SDB (mirror 2) SDC (extra rsync/backup drive).
It's not nice, though. The problem arises because I will NEVER have a backup/rsync drive in a system when I do an install that includes resetting of partition tables of SOME of the drives - a backup drive is a holy grail.
So I created the mirror (i.e. partitioning and starting mdadm) withou the backup drive.
As soon as I put that one back in I cannot use and of the grub2 utils without those errors "missing drive" as suddenly the the mirrors are on SDA and SDC.
So there must be some bug somewhere as the grub2 utils do not look at the UUIDs but somehow at the hardware sdX.
Jobst
-
Jobst Schmalenbach -
Jonathan Billings -
mark -
miguel medalha -
Nicolas Kovacs -
Phelps, Matthew -
Simon Matter -
Valeri Galtsev