-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
ebsnvme-id creates broken sd* symlinks #37
Comments
Note: This only affects Fedora rawhide because Testing Farm Fedora 40 instances don't install amazon-ec2-utils by default. When I install it manually, the issue happens there as well. |
Rawhide Testing Farm machines started to get a set of symlinks like /dev/sda1 -> nvme0n1 (but *no* /dev/sda), via amazon-ec2-utils (amazonlinux/amazon-ec2-utils#37). They break `scsi_debug`, as that creates /dev/sda -- but then trying to create partitions on it doesn't have any namespace room for /dev/sda1 etc., as that is already taken. This breaks all storage tests which use a RAM disk. That package isn't yet installed in Fedora 39/40, only rawhide. We don't need it and it only causes trouble → kann weg. Fixes cockpit-project#20520
@martinpitt, thanks for filing this! I have a hard time understanding what problem these symlinks are trying to solve. They only seem to create chaos. If they are supposed to help with giving stable names to NVMe drives, I think that problem is already solved by ID_SERIAL, ID_WWN, and filesystem UUIDs. |
https://gitlab.com/testing-farm/infrastructure doesn't actually install that package -- I figure it's now part of the official Fedora rawhide AMIs? |
Rawhide Testing Farm machines started to get a set of symlinks like /dev/sda1 -> nvme0n1 (but *no* /dev/sda), via amazon-ec2-utils (amazonlinux/amazon-ec2-utils#37). They break `scsi_debug`, as that creates /dev/sda -- but then trying to create partitions on it doesn't have any namespace room for /dev/sda1 etc., as that is already taken. This breaks all storage tests which use a RAM disk. That package isn't yet installed in Fedora 39/40, only rawhide. We don't need it and it only causes trouble → kann weg. Fixes #20520
@martinpitt That would be helpful. Thanks for detailing out the problems you found. I missed these during testing! |
@major OK, I filed https://bugzilla.redhat.com/show_bug.cgi?id=2284397 . Thanks! |
This has cost mine and @vojtechtrefny's an hour or two of our lives as well: https://bugzilla.redhat.com/show_bug.cgi?id=2313526 |
Rawhide Testing Farm machines started to get a set of symlinks like /dev/sda1 -> nvme0n1 (but *no* /dev/sda), via amazon-ec2-utils (amazonlinux/amazon-ec2-utils#37). They break `scsi_debug`, as that creates /dev/sda -- but then trying to create partitions on it doesn't have any namespace room for /dev/sda1 etc., as that is already taken. This breaks all storage tests which use a RAM disk. That package isn't yet installed in Fedora 39/40, only rawhide. We don't need it and it only causes trouble → kann weg. Fixes #20520
We spent quite some time debugging a storage test regression in Fedora rawhide which essentially breaks
scsi_debug
and other devices, but only on RedHat's/Fedora's Testing Farm infrastructure -- which is essentially AWS EC2 machines with an API.Latest Fedora rawhide instances now have amazon-ec2-utils-2.2.0-2.fc41.noarch (which got introduced into Fedora very recently), which ships /usr/lib/udev/rules.d/70-ec2-nvme-devices.rules with
These instances have an NVME block device, and these rules cause the following symlinks to be created:
This is problematic in multiple ways:
If then a real sda comes along (e.g. with
modprobe scsi_debug
), this will create an actual/dev/sda
, but then it's impossible to create/see partitions on that, as the sda1 etc. names are already taken.This is most easily reproduced with
Curiously, it also does that for a partition:
that explains how the second udev rule can even work -- but this is really hackish!
My recommendation as former udev co-upstream is to just entirely remove these rules. They are not helpful, confusing, and break stuff. You can of course create symlinks in subdirs of /dev all you like, but please don't collide with kernel names.
Thanks!
The text was updated successfully, but these errors were encountered: