Bugzilla Bug 195839

In bug #189227 it was mentioned that udev-114 broke dmraid

udev115-r6 goes a step further.

I did a emerge -avuDN1 wine yesterday followed by a successfull etc-upgrade.
none of the udev rules where mentioned to require specific merging.

After a long day of work I shut down my PC just to find out the next morning
that fsck couldn't check/find my disks.

After some investigation it turned out /dev/md/[09] didn't exist anymore, they
where moved to /dev/md[09].

Now this would be ok if my fstab where updated to use the new locations.

I use /dev/md/* on all my servers aswell (rather then /dev/md*) so to just
bluntly change this behavior is kinda scary, making me to go to all locations,
attach monitor/keyboard and fixing it manually.

Well, the ebuild certainly will NOT touch your fstab, no way. We could grep
fstab and spit out some warning if you are using the abandoned ones, that's
about it.

Fair enough, I wouldn't expect it to touch my fstab :) but it shouldn't perform
those changes until atleast the root partition matches with the new system.

Makes me wonder if I can use UUID's for md devices like i use them for my
single disk system. maybe print that 'please use UUID=bla' for your root
partition or the like if even poss.

Also, maybe a backwards compatibility layer would be nice, have symlinks from
the old to the new location (with the warning et al).

(In reply to comment #2)
> Also, maybe a backwards compatibility layer would be nice, have symlinks from
> the old to the new location (with the warning et al).

Meh; that's equivalent to reverting the change altogether, the whole point was
to get rid of those. :) 

Yeah, but those changes gotta come incrementally :p

first it was /dev/md/X with a symlink /dev/mdX If you'd wanna change that,
(why? the structured directory approach was nice n clean?) i'd say first swap
files/symlink, so that /dev/md/X is a symlink to /dev/mdX and start warning
users
Next version warn them again if they havent' fixed their fstab
and update after that warn really loudly and remove the old one (or wait 1
patch)

That's my opinion anyway :)

Added this rule back to udev-116-r1.