Am 19. May, 2025 schwätzte Ryan Petris via PLUG-discuss so:
Yeah, I powered off the drive bay to see what would happen :).
And I'm guessing it was in-use when you powered it off, i.e. part of a
running mdadm array.
I powered off all the disks in the array after stopping it.
Granted, poweri
Device reordering has been the bane of sysadmins existence for a long
time. I still remember when a Sun firmware (with a hardware intervention
by the vendor) update changed the order it scanned for scsi devices and we
got different c0t0's in the c0t0d0s0 addresses. I had to learn Forth to
work ar
> Yeah, I powered off the drive bay to see what would happen :).
And I'm guessing it was in-use when you powered it off, i.e. part of a running
mdadm array.
> but I'm not rebooting for hot-pluggable
> drives
The problem is that if hot-pluggable drives are still in use at the time you
remove th
Am 18. May, 2025 schwätzte James Mcphee via PLUG-discuss so:
moin moin,
I've run into things similar and it depends on what you're running. If
it's udev, make a rule in /etc/udev/rules.d/numbered-rule.rules with
SUBSYSTEM=="block", ACTION=="add", ENV{ID_FS_UUID}==
"123e4567-e89b-12d3-a456-4266
Am 18. May, 2025 schwätzte Ryan Petris via PLUG-discuss so:
moin moin,
It picked up the wrong devices when powering the drive bay down and up
again. mdadm was showing and trying to use the orginal sd names rather
than the newly assigned names.
That doesn't sound right, something else must hav
> It picked up the wrong devices when powering the drive bay down and up
> again. mdadm was showing and trying to use the orginal sd names rather
> than the newly assigned names.
That doesn't sound right, something else must have been going on.
What likely happened is if the drive was lost unexpe
you can also tell mdadm which dir it can scan for devices. it's been a
while, and is very limiting, but a quick google says DEVICE
/dev/disk/by-uuid/* and this corresponds with my recollection. granted
that was centos5.
On Sun, May 18, 2025 at 8:12 PM James Mcphee wrote:
> I wasn't mdadm'ing,
I wasn't mdadm'ing, so i usually use the fs uuid. if you want the device
uuid, it'll need to be that guy and not using ID_FS_UUID. but it's pretty
basic down at that level, so as long as you keep your layers right, you
should be able to find the thing you want to bind to.
On Sun, May 18, 2025 at
I've run into things similar and it depends on what you're running. If
it's udev, make a rule in /etc/udev/rules.d/numbered-rule.rules with
SUBSYSTEM=="block", ACTION=="add", ENV{ID_FS_UUID}==
"123e4567-e89b-12d3-a456-426614174000", NAME="sda"
or whatever. Dunno if this does what you want, but yo
Am 17. May, 2025 schwätzte Ryan Petris via PLUG-discuss so:
You can't, unfortunately. The only thing in /dev you can technically
rename are network interfaces; the rest you can only add symlinks for,
which is what for instance /dev/disk/by-partlabel/* is.
A shame, I like long path names :)
W
You can't, unfortunately. The only thing in /dev you can technically rename are
network interfaces; the rest you can only add symlinks for, which is what for
instance /dev/disk/by-partlabel/* is.
Why do you care what mdadm shows for device names anyway? If you're concerned
that it will pick up
11 matches
Mail list logo
