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.
