udev-182 in -current

Neil65 · 07-22-2012, 09:53 PM

Is this working for anyone? Mine is stuck in a reboot-loop not able to find /dev/sda4 (my root partition) Had to roll back to udev-165

btw, if you find cdrecord is not working on the new udevs, you need to restore this line to /lib/udev/rules.d/80-drivers.rules

SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_device", TEST!="[module/sg]", RUN+="/sbin/modprobe -bv sg"

willysr · 07-22-2012, 10:13 PM

yes, it worked on my desktop, workstation, and laptop

inph · 07-23-2012, 01:09 AM

mine worked fine with huge-smp, fixing some firmware loading problems as well.

ill323 · 07-23-2012, 01:22 AM

Quote:

Originally Posted by Neil65

Is this working for anyone? Mine is stuck in a reboot-loop not able to find /dev/sda4 (my root partition) Had to roll back to udev-165

Same problem here, have to roll back to udev-165.

I noticed there was a udev segmentation fault.
After that e2fsck not able to find /dev/sda5 (my root partition), it just reboot.

BTW, I'm running 3.5.0 kernel(without module support).

udev-175 worked fine.

volkerdi · 07-23-2012, 01:31 AM

udev-176 and later no longer creates the /dev entries (relying on devtmpfs), so make sure CONFIG_DEVTMPFS is enabled in your kernel.

cgorac · 07-23-2012, 01:48 AM

After upgrading to latest set of changes, my Slackware64 installation is hanging upon trying to start desktop environment - for example, I can see KDE loading, but keyboard and mouse are not responding. It's really vanilla installation, with NVIDIA binary driver added only (that I reinstalled after this upgrade, but this didn't help), on ThinkPad W520 laptop. So far, the only suspicious thing I've found is that t the end of boot, after gpm loaded, following message is printed:
O0o.oops(): [server_tools.c(76)]: Could not open (null)

ill323 · 07-23-2012, 01:52 AM

Quote:

Originally Posted by volkerdi

udev-176 and later no longer creates the /dev entries (relying on devtmpfs), so make sure CONFIG_DEVTMPFS is enabled in your kernel.

Yeah! After enable it, udev-182 worked fine!
Thank you very much!

(I disabled this option cause I want to compile a "minimal" kernel).

cgorac · 07-23-2012, 02:06 AM

Quote:

Originally Posted by cgorac

After upgrading to latest set of changes, my Slackware64 installation is hanging upon trying to start desktop environment...

After downgrading to udev-175, I am able now to start KDE properly (in particular, keyboard and mouse are responding).

On the other side, I've checked dmesg, and I can see:
[ 5.792041] udev[1178]: starting version 165
[ 7.014032] udevd[1383]: starting version 175
there - don't know is this supposed to be this way, or I should do something to disable starting version 165?

TommyC7 · 07-23-2012, 02:22 AM

cgorac, you need to rebuild your initrd.

cgorac · 07-23-2012, 02:47 AM

Quote:

Originally Posted by TommyC7

cgorac, you need to rebuild your initrd.

Thanks, that fixed it indeed. Out of curiosity - how users were supposed to know this?

rworkman · 07-23-2012, 02:55 AM

Quote:

Originally Posted by cgorac

Thanks, that fixed it indeed. Out of curiosity - how users were supposed to know this?

On one hand, that's a legitimate question. On the other hand, this is not a new release of Slackware - we're talking about the development branch that's intended for users who either know how the system fits together or want to *learn* how it fits together. If you're not in one of those groups, then you should wait for the release, after which rebuilding the initrd will be an obvious step due to the kernel upgrade.

Now, which of those two hands has the most appropriate answer? I'm not sure; I think they're both appropriate. :-)

cgorac · 07-23-2012, 07:23 AM

Quote:

Originally Posted by cgorac

Thanks, that fixed it indeed.

Just to clarify it here: I was intending to say that udev-182 upgrade worked fine, once I ran mkinitrd after doing the upgrade.

@rworkman: I don't know... I consider myself knowledgeable user, for >10 years I'm using Slackware only; but for example, even that I'm using generic kernels from long ago, I still don't know exactly after which upgrades mkinitrd should be run (except, of course, after kernel upgrade), nor where/how to found this info.

rworkman · 07-23-2012, 07:43 AM

Understood. Even though I didn't elaborate on it as much, I really did mean it when I said that it was a legitimate question. I'm still trying to figure out how to best document an answer (and where to document it).

guanx · 07-23-2012, 07:55 AM

Got an excessive delay on startup with udev-182:

Code:

[   10.697038] Console: switching to colour frame buffer device 128x48
[   10.701558] fb0: radeondrmfb frame buffer device
[   10.701600] drm: registered panic notifier
[   10.701705] [drm] Initialized radeon 2.12.0 20080528 for 0000:01:00.0 on minor 0
[   11.101238] cfg80211: World regulatory domain updated:
[   11.101297] cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[   11.101367] cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[   11.101437] cfg80211:     (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[   11.101506] cfg80211:     (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[   11.101576] cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[   11.101646] cfg80211:     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[   11.480030] intel8x0_measure_ac97_clock: measured 50476 usecs (2433 samples)
[   11.480099] intel8x0: clocking to 48000
[   15.956865] IBM TrackPoint firmware: 0x0e, buttons: 3/3
[   16.187311] input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/serio2/input/input7
[   40.828124] cfg80211: failed to add phy80211 symlink to netdev!
[   40.828878] ipw2200: Detected geography ZZH (13 802.11bg channels, 4 802.11a channels)
[   40.904203] Adding 8388604k swap on /dev/sda3.  Priority:-1 extents:1 across:8388604k

Switching back to udev-175 solved the problem.

Neil65 · 07-23-2012, 07:19 PM

Thanks, CONFIG_DEVTMPFS fixed it for me. I was also testing 3.4.x and 3.5.x, and had not known about that kernel parameter. Like the last poster, I've also seen some episodes of slowness. Reboot again and its fine. Testing too much stuff at once so I can't attribute it to the kernel or udev. I'm leaning towards udev though. Doesn't fill me with confidence for systemd.