udev 070 segfaults

sl70 · Posted: Wed Oct 19, 2005 10:27 am Post subject: udev 070 segfaults

After updating udev to 070 I found that I couldn't sync my Palm using gpilotd. I got the cannot bind to port message. When I did udevstart it told me ``segmentation fault.'' I went back down to udev-068-r1 and things are fine. Should I file a bug report?

Romses · Posted: Wed Oct 19, 2005 1:21 pm Post subject:

I have the same problem.
i cannot boot, without udevstart, i do not have any harddisk-devive nodes

can anybody help me?

my udev-version is 070...

Greetings
Romses

nxsty · Veteran Joined: 23 Jun 2004 Posts: 1556 Location: .se

You need to update to udev 070-r1 to fix the segfaults.

Romses · Posted: Wed Oct 19, 2005 2:17 pm Post subject:

it works...
thanx

ahubu · Posted: Wed Oct 19, 2005 9:26 pm Post subject:

I had this too, I b0rked my system more or less... after emerging and doing some udev-rule-writing, I saw that it segfaulted and I though, HEY: let's reboot and see... BAD choice. It went nuts. So I booted from a x86 gentoo cd, mounted root and copied the udevstart file over from /mnt/livecd/sbin. luckily, that went fine and I could reboot safe and sound.

Phoei, that was close. At least for me.
_________________
Anne // Light travels faster than sound. That's why people appear bright until
you hear them speak. -Unknown

red-wolf76 · l33t Joined: 13 Apr 2005 Posts: 637 Location: Hannover

[AOL]Me too![/AOL]

How did this yellow rubbery piece of s*@t make it into stable after all? I update a box and next thing it won't boot? Does this happen on obscure setups only or why did this escape testing? Upgrading to 070-r1 worked like a charm, but this is really annoying...
_________________
0mFg, G3nt00 r0X0r$ T3h B1g!1111

Use sane CFLAGS! If for no other reason, do it for the lulz!

alistair · Developer Joined: 14 Jul 2005 Posts: 612

it can't be obscure setups because mine was the default from 068-r1 (i believe)

ribx · Posted: Thu Oct 20, 2005 3:58 pm Post subject:

i had the same problem (t_T) but a livecd fixes all you problems

nevertheless: this should never happen

_________________
The adopt an unanswered post initiative

guyr · Apprentice Joined: 17 Aug 2004 Posts: 209

Forums to the rescue again. I'm setting up a pretty vanilla P4 system (Dell 9100) and this just happened to me. Was running fine, then I did an emerge sync and got the udev segmentation fault. Was trying all sorts of odd things until I found this message thread. Thanks. I'd second the opinion that this was a pretty significant QA oops.
_________________
Guy Rouillier

ahubu · Posted: Fri Oct 21, 2005 6:39 am Post subject:

Well maybe I just don't understand the portage policy, but I don't understand why 0.70 is still in portage, since it breaks so badly. I could actually see no harm in deleting it completely from the portage tree (since it has been replaced by 0.70-r1). Maybe someone could clarify that. This would rule out the possibility of people downgrading to this b0rked version (for some reason or another).
_________________
Anne // Light travels faster than sound. That's why people appear bright until
you hear them speak. -Unknown

Bob P · Posted: Fri Oct 21, 2005 8:13 am Post subject:

wyv3rn · Posted: Fri Oct 21, 2005 10:50 am Post subject:

Bob P · Posted: Fri Oct 21, 2005 12:25 pm Post subject:

yep, that's the programming equivalent of sweeping a problem under the rug -- when a package like 70 is b0rken, the fix is applied in a release like 70-r1. then the fix is applied retroactively from 70-r1 to 70, thereby erasing the evidence of the problem.

this type of patching is the norm rather than the exception. as a result, people who don't have their ear to the ground won't notice how frequently little problems like these are quietly and discretely stomped out, and the entire system appears on the surface to be more stable than it actually is. as we've discussed in the other thread on this subject, whether or not you notice a problem like this with an ebuild is largely a matter of timing.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks

wyv3rn · Posted: Fri Oct 21, 2005 3:58 pm Post subject:

Personally I think it is the right thing to do. Bugs like this should not be left behind for someone else to trip on later. Let the bean counters complain.

ahubu · Posted: Fri Oct 21, 2005 4:32 pm Post subject:

wyv3rn · Posted: Fri Oct 21, 2005 5:43 pm Post subject:

I disagree. No one is trying to change history or deny the past existance of a bug. There are still entries in the Changelog. The broken ebuilds have been fixed, as they should be and a -r1 release was made to flag all those who upgraded to -70 before the fix got in. A good reason to leave the previously-broken-but-now-fixed ebuild is so that tools like revdep-rebuild will work properly. Otherwise they complain about not being able to rebuild the package because the ebuild is missing and it stops the whole thing until that is resolved.

ahubu · Posted: Sat Oct 22, 2005 2:36 pm Post subject:

wyv3rn · Posted: Sat Oct 22, 2005 5:09 pm Post subject:

I believe (maybe wrong) revdep-rebuild will only attempt to use the exact version already installed. I know it won't jump from something like 6.8.1 to 6.8.2, it will just stop until you fix it. Maybe -r1 to -r2 but I don't think it does. Yes it is an easy fix. It is still annoying to run revdep-rebuild, have a large list of rebuilds, leave your computer and come back only to find it failed a few packages in because the ebuild was missing. I just don't see any good reason to leave major bugs (like segmentation faults) in packages except for perhaps statistical purposes. It would be stupid IMO to allow statistics to trump actual system stability and usability. On top of that it would make portage bigger. In the case of texinfo-4.8-r1 and -r2 they would have to include the broken patch and the correct patch to keep it the same. Multiply that policy by thousands of packages and thousands of users and that's A LOT of wasted bandwidth and processing time all for the purpose of keeping statistics which can be kept via Changelog if you care that much anyway.