Bugzilla – Bug 113766
yast segfaults, cause it accesses the udev database files directly
Last modified: 2005-09-05 08:05:25 UTC
Yast segfaults, cause it reads the private udev database without the udev tools. That format has changed in a recent version. This udev version is not submitted to autobuild until now. If you can't fix yast, we will need to work around it for 10.0. But please never access these files directly, they can change at any time to any format. sbin/yast: line 207: 5217 Segmentation fault $ybindir/y2base menu ncurses #0 0x417bb8f4 in read_udevinfo () from /usr/lib/gcc/i586-suse-linux/4.0.2/../../../libhd.so.11 │ #1 0x417c9192 in hd_scan_int () from /usr/lib/gcc/i586-suse-linux/4.0.2/../../../libhd.so.11 │ #2 0x417bc061 in hd_scan () from /usr/lib/gcc/i586-suse-linux/4.0.2/../../../libhd.so.11 │ #3 0x417bd6df in hd_list () from /usr/lib/gcc/i586-suse-linux/4.0.2/../../../libhd.so.11 │ #4 0x41686a9b in HwProbe::checkPath () from /usr/lib/YaST2/plugin/libpy2ag_hwprobe.so.2 │ #5 0x41688456 in HwProbe::Read () from /usr/lib/YaST2/plugin/libpy2ag_hwprobe.so.2 │
Yeah, well, the point is that 'udevinfo -d' of old times changed its output format and I figured if that's not stable I can as well read the db directly. I'm not aware of an official way to dump the db. Anyway libhd should not segfault even if the format changes. If you plan to submit it for beta-4 (aka today), then give me a test version before so I can fix libhd.
No, I will not submit it today. Probably during this week, but I can hold back the db changes if needed. Not segfaulting would be good enough for now. :) What information does yast need from udev? We can just add a "dump" and keep it stable. The dump at this time is a private feature of HAL, that changes the time we change the way HAL interacts with udev.
Removing the first line "P:<devpath>" from a dbfile causes yast to segfault.
Unless you submit it until 16:00 UT today (aka in time for ß4), it's not critical. I can look at it tomorrow, then. Hm, the 'P' line was seen as the start of a new entry. Anyway, what yast uses (if anything) is the the list of names udev creates for a device. But I'll have to check the code first. Can you give me such a brand new udev package?
No, it will not be submitted today, but fixing it during this week would be nice. The new udev is not released until now or packaged. I can send only a snapshot if you want, but I think we should rater add a sane "dump" instead and make yast use this instead of the db files - will look into it now... But note that udev does not store anything, if there is no custom information for a device. Recent udev versions store on a usual box only 40 db files for the 700 device nodes. Only if custom names or additional symlinks are created, udev will write a db file cause it needs this information for the "remove" event.
That is actually great. It would be even better if someone would remove all those old 709 udev db entries during an update. :-)
Hmm, you are not on tmpfs with /dev (mounted from initramfs)? That's the default for 10.0 and the db should not survive a reboot.
No, seems not to be done for updated systems.
Hmm weird, you have 700 db files after a reboot with beta3 and a SUSE kernel? How about a dump in this format, it will print the database content for all devices with one invokation of udevinfo: P: /block/hda/hda3 N: hda3 S: disk/by-id/ata-HTS726060M9AT00_MRH401M4G6UM9B-part3 S: disk/by-path/pci-0000:00:1f.1-ide-0:0-part3 S: disk/by-uuid/2E08712B0870F2E7 S: disk/by-label/XP E: ID_TYPE=disk E: ID_MODEL=HTS726060M9AT00 E: ID_SERIAL=MRH401M4G6UM9B E: ID_REVISION=MH4OA6BA E: ID_BUS=ata E: ID_PATH=pci-0000:00:1f.1-ide-0:0 E: ID_FS_USAGE=filesystem E: ID_FS_TYPE=ntfs E: ID_FS_VERSION=3.1 E: ID_FS_UUID=2E08712B0870F2E7 E: ID_FS_LABEL=XP E: ID_FS_LABEL_SAFE=XP P: /block/hdc N: hdc S: dvdram S: cdrom S: dvd S: cdrecorder S: disk/by-path/pci-0000:00:1f.1-ide-1:0 E: ID_TYPE=cd E: ID_MODEL=MATSHITADVD-RAM_UJ-811 E: ID_SERIAL= E: ID_REVISION=H102 E: ID_BUS=ata E: ID_PATH=pci-0000:00:1f.1-ide-1:0 P: /class/input/event0 N: input/event0 P: /class/input/event1 N: input/event1 P: /class/input/event2 N: input/event2 P: /class/input/event3 N: input/event3 ...
Yes. The format looks fine.
Here is a version with the segfault causing db and the export: "udevinfo -e": /work/built/mbuild/pomegranate-kasievers-115
segfault fixed
using 'udevinfo -e' now
On a side note: I assume that N & S entries refer to something below /dev. So network interfaces will not appear in udevinfo, or not?
udev does not keep a state of network interfaces. the names can change at any time. SUSE does not use udev ro rename netifs. yes, N and S are only for /dev nodes.
*** Bug 115136 has been marked as a duplicate of this bug. ***