|
Bugzilla – Full Text Bug Listing |
| Summary: | udev deletes device nodes | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.3 | Reporter: | Arvin Schnell <aschnell> |
| Component: | Basesystem | Assignee: | Xin Wei Hu <xwhu> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Critical | ||
| Priority: | P2 - High | CC: | 0.bugs.only.0, agk, aj, aschnell, boris, bruno, estellnb, forgotten_1-yzHWP3HO, forgotten_1LnIo8z5Ac, forgotten_ciXLpmu5Qn, forgotten_QtBI7gWTIh, forgotten_wVahB7imRu, grok, harbrink, hare, john, langv.msei, lulis, mario_bz, martin.wilck, O.Stahl, per, sasch.pe, timshel |
| Version: | Factory | Flags: | coolo:
SHIP_STOPPER-
|
| Target Milestone: | RC 2 | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Development | Services Priority: | |
| Business Priority: | Blocker: | Yes | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
udevadm monitor log
ausearch output YaST logs the latest initrd Additional change event to device mapper device fstab and yast logs |
||
|
Description
Arvin Schnell
2010-04-20 16:55:38 UTC
Created attachment 355651 [details]
udevadm monitor log
Created attachment 355652 [details]
ausearch output
Created attachment 355653 [details]
YaST logs
I guess, the device-mapper rules instruct udev to delete the node:
/lib/udev/rules.d/10-dm.rules
ACTION=="add", ENV{STARTUP}!="1", NAME="", GOTO="dm_end"
Unless something else is going on here, the device-mapper rules need to be fixed. In any case, even if this is not the problem here, device nodes must never be deleted by any udev rule. It is a very broken idea of device-mapper upstream how hotplug/udev/the driver-core interacts. We also, for very good reasons, don't do any "STARTUP" flagging in udev rules. This can never work reliably on today's systems. *** Bug 600853 has been marked as a duplicate of this bug. *** as a sidenote (as per duplicate bug 600853) -- it also fais in Milestone 6, KDE live iso. Arvin, If you remove the line mentioned in comment 4, does this bug disappear ? Xin, It's happening as early as in installation, therefore it's rather difficult to test it, this is stage1, remember we can't edit anything. I can confirm the problem happening in Milestone 6 (well, almost 7 as of today) still. Please treat it as critical, I agree with Kay, udev should never ever delete any devmapper nodes, it's just criminal. Can you please test it on your system where you have infrastructure to roll your own stage1 and release ASAP? It's a really nasty bug. Regards, -- grok I have a similar situation. The hardware is the following: paziz:~ # lspci 00:00.0 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a2) 00:01.0 ISA bridge: nVidia Corporation MCP78S [GeForce 8200] LPC Bridge (rev a2) 00:01.1 SMBus: nVidia Corporation MCP78S [GeForce 8200] SMBus (rev a1) 00:01.2 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a1) 00:01.3 Co-processor: nVidia Corporation MCP78S [GeForce 8200] Co-Processor (rev a2) 00:01.4 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a1) 00:02.0 USB Controller: nVidia Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1) 00:02.1 USB Controller: nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1) 00:04.0 USB Controller: nVidia Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1) 00:04.1 USB Controller: nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1) 00:06.0 IDE interface: nVidia Corporation MCP78S [GeForce 8200] IDE (rev a1) 00:07.0 Audio device: nVidia Corporation MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio (rev a1) 00:08.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1) 00:09.0 SATA controller: nVidia Corporation MCP78S [GeForce 8200] AHCI Controller (rev a2) 00:0a.0 Ethernet controller: nVidia Corporation MCP77 Ethernet (rev a2) 00:0b.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1) 00:10.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1) 00:12.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1) 00:13.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control 00:18.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control 01:07.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode) (rev 11) 02:08.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) 02:09.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) 03:00.0 VGA compatible controller: nVidia Corporation C77 [GeForce 8300] (rev a2) 06:00.0 FireWire (IEEE 1394): JMicron Technology Corp. IEEE 1394 Host Controller 6 gig ram. it is partitioned as the following: Disk /dev/sda - 160 GB / 149 GiB - ATA ST3160023AS Disk /dev/sdb - 1000 GB / 931 GiB - ATA ST31000528AS Disk /dev/sdc - 750 GB / 698 GiB - ATA ST3750330AS Disk /dev/sdd - 750 GB / 698 GiB - ATA ST3750330AS Disk /dev/mapper/nvidia_fajhbfec - 1500 GB / 1397 GiB Disk /dev/mapper/nvidia_fajhbfec_part1 - 1385 GB / 1290 GiB Disk /dev/mapper/nvidia_fajhbfec_part2 - 18 GB / 17 GiB Disk /dev/mapper/nvidia_fajhbfec_part3 - 21 GB / 20 GiB Disk /dev/dm-0 - 1500 GB / 1397 GiB Disk /dev/dm-1 - 1385 GB / 1290 GiB Disk /dev/dm-2 - 18 GB / 17 GiB Disk /dev/dm-3 - 21 GB / 20 GiB the following opensuse versions are installed: 11.1 : root is on sda4 and home is on dm-1; It boots continuously in about 40 seconds and runs very nicely. 11.2 (1) root is on sda1 and home on dm-1. boot hangs on udev, typical error mesages are "waiting to udev to settle" "device mapper ioctal... device doesn't appear to be in the dev hash table". somtimes boot gets only to run into level 1. then I use the commands dmraid -ay, mount /home and init 5. then boot is successfuly completed and everything runs nicely and stable. 11.3 (ms 7) root is on sda3 and home on dm-1. Same behavior as 11.2(1). 11.2 (2). root is on dm-2, home on dm-1 and boot on sda7. It boots in less then 30 seconds - no hangs. However, any attempt to install 11.3 (either ms 6 or ms 7) with a root on dm has failed. clean instalation failes with "system error code - 3030". upgrading the 11.2 (2) by choosing the update option from the installation media results with a boot which is unable to mount the dm-2 partition and falling into a shell. the same happens when trying to upgrade 11.2 (2) by chnging the repositories into factory and running export ZYPP_ARIA2C=1 and then zypper dup. I have checked the /etc/udev.d on all running versions and there is no 10-dm.ruls on any of them. (In reply to comment #10) > clean instalation failes with "system error code - 3030". This is because once the LV is created udev deletes it. So we have: /dev/system/tmp -> /dev/mapper/system-tmp which is all dandy, but then when you ls /dev/mapper all you get is a lousy 'control' and no system-tmp. (In reply to comment #9) > It's happening as early as in installation, therefore it's rather difficult to > test it, this is stage1, remember we can't edit anything. I can try and see if they are made immutable for the install > I can confirm the problem happening in Milestone 6 (well, almost 7 as of today) > still. Please treat it as critical, I agree with Kay, udev should never ever > delete any devmapper nodes, it's just criminal. Indeed crimimal :-( I think M7 is imminent; will it be fixed on time? with "immutable" I meant if I can make thm immutable just before the real stuff starts. (In reply to comment #12) > I think M7 is imminent; will it be fixed on time? M7 is being uploaded to the mirrors right now. We've passed the deadline. We're now aiming for Jun 17 RC1. This is now a blocker for RC Please note that when root is on a physical disk (e. g. sda) and only home is on the dm array - the installation is successful, although boot is sluggish (hangs some time on udev). This means that eventually the dm array is created, but far too late in the boot process. Hi all, I just update the device mapper and lvm2 package there in Base:System. It works on my side. Would you test this package ? Thanks. I have just updated all new packages. The system I have updated is 11.3 (ms 7) root is on sda3 and home on dm-1. unfortunately there is no improvment in the boot process. The relevant lines from dmesg are: [ 11.488051] device-mapper: uevent: version 1.0.3 [ 11.497874] device-mapper: ioctl: 4.17.0-ioctl (2010-03-05) initialised: dm-devel@redhat.com [ 11.595248] usbcore: registered new interface driver snd-usb-audio [ 11.680729] Adding 5245184k swap on /dev/sda6. Priority:-1 extents:1 across:5245184k [ 79.331174] device-mapper: ioctl: device doesn't appear to be in the dev hash table. [ 79.830294] loop: module loaded note the large delay between "Adding 5245184k swap" and "device-mapper: ioctl: device doesn't appear" (~78 seconds). all this time the message is "waiting for udev to settle". (In reply to comment #18) > I have just updated all new packages. The system I have updated is 11.3 (ms 7) > root is on sda3 and home on dm-1. > > unfortunately there is no improvment in the boot process. The relevant lines > from dmesg are: > [ 11.488051] device-mapper: uevent: version 1.0.3 > [ 11.497874] device-mapper: ioctl: 4.17.0-ioctl (2010-03-05) initialised: > dm-devel@redhat.com > [ 11.595248] usbcore: registered new interface driver snd-usb-audio > [ 11.680729] Adding 5245184k swap on /dev/sda6. Priority:-1 extents:1 > across:5245184k > [ 79.331174] device-mapper: ioctl: device doesn't appear to be in the dev > hash table. > [ 79.830294] loop: module loaded > > note the large delay between "Adding 5245184k swap" and "device-mapper: ioctl: > device doesn't appear" (~78 seconds). > all this time the message is "waiting for udev to settle". Have you rerun mkinitrd after updating ? no. I will do that soon and report. I have run mkinitrd mkinitrd Kernel image: /boot/vmlinuz-2.6.34-8-desktop Initrd image: /boot/initrd-2.6.34-8-desktop WARNING: All config files need .conf: /etc/modprobe.d/options, it will be ignored in a future release. Root device: /dev/disk/by-id/ata-ST3160023AS_3JS0MZLZ-part4 (/dev/sda4) (mounted on / as ext4) Resume device: /dev/disk/by-id/ata-ST3160023AS_3JS0MZLZ-part6 (/dev/sda6) modprobe: Module amd74xx not found. WARNING: no dependencies for kernel module 'amd74xx' found. modprobe: Module ide_pci_generic not found. WARNING: no dependencies for kernel module 'ide_pci_generic' found. Kernel Modules: thermal_sys thermal scsi_mod libata pata_amd ahci ata_generic processor fan pata_jmicron pata_marvell edd crc16 jbd2 ext4 pata_acpi sata_mv pdc_adma sata_sil sata_nv pata_atiixp pata_sil680 pata_netcell pata_it821x pata_cmd640 pata_atp867x sata_qstor pata_sis sata_sis pata_cs5520 pata_hpt3x3 sata_uli pata_mpiix pata_ns87410 sata_inic162x sata_svw pata_it8213 pata_hpt37x pata_ninja32 pata_sl82c105 pata_opti pata_via pata_artop pata_rz1000 pata_cypress pata_triflex pata_efar pata_ns87415 pata_serverworks pata_optidma pata_sch pata_sc1200 sata_promise pata_rdc pata_ali pata_radisys sata_via pata_pdc202xx_old sata_sx4 pata_pdc2027x pcmcia_core pcmcia pata_pcmcia ata_piix sata_sil24 pata_piccolo pata_oldpiix pata_hpt366 pata_cmd64x sata_vsc pata_cs5530 pata_hpt3x2n sd_mod Features: block usb resume.userspace resume.kernel Bootsplash: openSUSE (1280x1024) 46356 blocks and rebooted. exactly the same as before. the message in boot second 8 is "udevdm settle... failed." (In reply to comment #21) > I have run mkinitrd > > mkinitrd > > Kernel image: /boot/vmlinuz-2.6.34-8-desktop > Initrd image: /boot/initrd-2.6.34-8-desktop > WARNING: All config files need .conf: /etc/modprobe.d/options, it will be > ignored in a future release. > Root device: /dev/disk/by-id/ata-ST3160023AS_3JS0MZLZ-part4 (/dev/sda4) > (mounted on / as ext4) > Resume device: /dev/disk/by-id/ata-ST3160023AS_3JS0MZLZ-part6 (/dev/sda6) > modprobe: Module amd74xx not found. > WARNING: no dependencies for kernel module 'amd74xx' found. > modprobe: Module ide_pci_generic not found. > WARNING: no dependencies for kernel module 'ide_pci_generic' found. > Kernel Modules: thermal_sys thermal scsi_mod libata pata_amd ahci ata_generic > processor fan pata_jmicron pata_marvell edd crc16 jbd2 ext4 pata_acpi sata_mv > pdc_adma sata_sil sata_nv pata_atiixp pata_sil680 pata_netcell pata_it821x > pata_cmd640 pata_atp867x sata_qstor pata_sis sata_sis pata_cs5520 pata_hpt3x3 > sata_uli pata_mpiix pata_ns87410 sata_inic162x sata_svw pata_it8213 pata_hpt37x > pata_ninja32 pata_sl82c105 pata_opti pata_via pata_artop pata_rz1000 > pata_cypress pata_triflex pata_efar pata_ns87415 pata_serverworks pata_optidma > pata_sch pata_sc1200 sata_promise pata_rdc pata_ali pata_radisys sata_via > pata_pdc202xx_old sata_sx4 pata_pdc2027x pcmcia_core pcmcia pata_pcmcia > ata_piix sata_sil24 pata_piccolo pata_oldpiix pata_hpt366 pata_cmd64x sata_vsc > pata_cs5530 pata_hpt3x2n sd_mod > Features: block usb resume.userspace resume.kernel > Bootsplash: openSUSE (1280x1024) > 46356 blocks > and rebooted. > exactly the same as before. > the message in boot second 8 is "udevdm settle... failed." Would you run mkinitrd with '-f dm' ? Which enables the dm feature. Also, would you let me know the output of "rpm -q --changelog device-mapper | head" ? It should be something like: * Fri May 21 2010 xwhu@novell.com - Fix mkinitrd-devmapper to use udev rules for device mapper Thanks. no progress yet. mkinitrd -f dm Kernel image: /boot/vmlinuz-2.6.34-8-desktop Initrd image: /boot/initrd-2.6.34-8-desktop WARNING: All config files need .conf: /etc/modprobe.d/options, it will be ignored in a future release. Root device: /dev/disk/by-id/ata-ST3160023AS_3JS0MZLZ-part4 (/dev/sda4) (mounted on / as ext4) Resume device: /dev/disk/by-id/ata-ST3160023AS_3JS0MZLZ-part6 (/dev/sda6) modprobe: Module amd74xx not found. WARNING: no dependencies for kernel module 'amd74xx' found. modprobe: Module ide_pci_generic not found. WARNING: no dependencies for kernel module 'ide_pci_generic' found. Kernel Modules: thermal_sys thermal scsi_mod libata pata_amd ahci ata_generic processor fan pata_jmicron pata_marvell edd dm-mod dm-snapshot crc16 jbd2 ext4 pata_acpi sata_mv pdc_adma sata_sil sata_nv pata_atiixp pata_sil680 pata_netcell pata_it821x pata_cmd640 pata_atp867x sata_qstor pata_sis sata_sis pata_cs5520 pata_hpt3x3 sata_uli pata_mpiix pata_ns87410 sata_inic162x sata_svw pata_it8213 pata_hpt37x pata_ninja32 pata_sl82c105 pata_opti pata_via pata_artop pata_rz1000 pata_cypress pata_triflex pata_efar pata_ns87415 pata_serverworks pata_optidma pata_sch pata_sc1200 sata_promise pata_rdc pata_ali pata_radisys sata_via pata_pdc202xx_old sata_sx4 pata_pdc2027x pcmcia_core pcmcia pata_pcmcia ata_piix sata_sil24 pata_piccolo pata_oldpiix pata_hpt366 pata_cmd64x sata_vsc pata_cs5530 pata_hpt3x2n sd_mod Features: dm block usb resume.userspace resume.kernel Bootsplash: openSUSE (1280x1024) 46942 blocks paziz:~ # rpm -q --changelog device-mapper | head * Mon Apr 26 2010 ro@suse.de - fix pkgconfig file for device mapper * Sat Apr 03 2010 xwhu@novell.com - Upgrade to device-mapper 1.02. - Add libdevmapper functions to support synchronisation with udev - Check udev is running when processing cookies and retain state internally. - Add support for the "snapshot-merge" kernel target and as you can see, I was unable to locate the new package, even in your own directories. can you send a link? This looks very much like what I have just experienced when booting my system test system after zypper dup'ing to M7. Judging from the above, a solution is well under way, so I won't add any more diagnostics unless requested. *** Bug 607869 has been marked as a duplicate of this bug. *** (In reply to comment #23) > no progress yet. > and as you can see, I was unable to locate the new package, even in your own > directories. > can you send a link? You can use http://software.opensuse.org/search to search device-mapper and lvm2 package from Base:System/openSUSE_Factory . ok. I have located device-mapper-1.02.42-24.1.x86_64.rpm and lvm2-2.02.58-23.1.x86_64.rpm and installed them. then: aziz:~ # rpm -q --changelog device-mapper | head * Fri May 21 2010 xwhu@novell.com - Fix mkinitrd-devmapper to use udev rules for device mapper * Mon Apr 26 2010 ro@suse.de - fix pkgconfig file for device mapper * Sat Apr 03 2010 xwhu@novell.com - Upgrade to device-mapper 1.02. - Add libdevmapper functions to support synchronisation with udev - Check udev is running when processing cookies and retain state paziz:~ # rpm -q --changelog lvm2 | head * Fri May 21 2010 xwhu@novell.com - Fix mkinitrd-lvm2 to use udev rules for lvm2 * Mon Apr 26 2010 ro@suse.de - fix lvm2-clvm specfile so that patches apply * Sat Apr 03 2010 xwhu@novell.com - Upgrade to LVM2 2.02.58 - Rename liblvm.so to liblvm2app.so - Introduce lvconvert --use_policies paziz:~ # mkinitrd -f dm Kernel image: /boot/vmlinuz-2.6.34-8-desktop Initrd image: /boot/initrd-2.6.34-8-desktop WARNING: All config files need .conf: /etc/modprobe.d/options, it will be ignored in a future release. Root device: /dev/disk/by-id/ata-ST3160023AS_3JS0MZLZ-part4 (/dev/sda4) (mounted on / as ext4) Resume device: /dev/disk/by-id/ata-ST3160023AS_3JS0MZLZ-part6 (/dev/sda6) modprobe: Module amd74xx not found. WARNING: no dependencies for kernel module 'amd74xx' found. modprobe: Module ide_pci_generic not found. WARNING: no dependencies for kernel module 'ide_pci_generic' found. Kernel Modules: thermal_sys thermal scsi_mod libata pata_amd ahci ata_generic processor fan pata_jmicron pata_marvell edd dm-mod dm-snapshot crc16 jbd2 ext4 pata_acpi sata_mv pdc_adma sata_sil sata_nv pata_atiixp pata_sil680 pata_netcell pata_it821x pata_cmd640 pata_atp867x sata_qstor pata_sis sata_sis pata_cs5520 pata_hpt3x3 sata_uli pata_mpiix pata_ns87410 sata_inic162x sata_svw pata_it8213 pata_hpt37x pata_ninja32 pata_sl82c105 pata_opti pata_via pata_artop pata_rz1000 pata_cypress pata_triflex pata_efar pata_ns87415 pata_serverworks pata_optidma pata_sch pata_sc1200 sata_promise pata_rdc pata_ali pata_radisys sata_via pata_pdc202xx_old sata_sx4 pata_pdc2027x pcmcia_core pcmcia pata_pcmcia ata_piix sata_sil24 pata_piccolo pata_oldpiix pata_hpt366 pata_cmd64x sata_vsc pata_cs5530 pata_hpt3x2n sd_mod Features: dm block usb resume.userspace resume.kernel Bootsplash: openSUSE (1280x1024) 47010 blocks however, no progress has been made yet. (In reply to comment #27) > ok. I have located device-mapper-1.02.42-24.1.x86_64.rpm and > lvm2-2.02.58-23.1.x86_64.rpm and installed them. > then: > aziz:~ # rpm -q --changelog device-mapper | head > * Fri May 21 2010 xwhu@novell.com > - Fix mkinitrd-devmapper to use udev rules for device mapper > > * Mon Apr 26 2010 ro@suse.de > - fix pkgconfig file for device mapper > > * Sat Apr 03 2010 xwhu@novell.com > - Upgrade to device-mapper 1.02. > - Add libdevmapper functions to support synchronisation with udev > - Check udev is running when processing cookies and retain state > paziz:~ # rpm -q --changelog lvm2 | head > * Fri May 21 2010 xwhu@novell.com > - Fix mkinitrd-lvm2 to use udev rules for lvm2 > > * Mon Apr 26 2010 ro@suse.de > - fix lvm2-clvm specfile so that patches apply > > * Sat Apr 03 2010 xwhu@novell.com > - Upgrade to LVM2 2.02.58 > - Rename liblvm.so to liblvm2app.so > - Introduce lvconvert --use_policies > paziz:~ # mkinitrd -f dm > > Kernel image: /boot/vmlinuz-2.6.34-8-desktop > Initrd image: /boot/initrd-2.6.34-8-desktop > WARNING: All config files need .conf: /etc/modprobe.d/options, it will be > ignored in a future release. > Root device: /dev/disk/by-id/ata-ST3160023AS_3JS0MZLZ-part4 (/dev/sda4) > (mounted on / as ext4) > Resume device: /dev/disk/by-id/ata-ST3160023AS_3JS0MZLZ-part6 (/dev/sda6) > modprobe: Module amd74xx not found. > WARNING: no dependencies for kernel module 'amd74xx' found. > modprobe: Module ide_pci_generic not found. > WARNING: no dependencies for kernel module 'ide_pci_generic' found. > Kernel Modules: thermal_sys thermal scsi_mod libata pata_amd ahci ata_generic > processor fan pata_jmicron pata_marvell edd dm-mod dm-snapshot crc16 jbd2 ext4 > pata_acpi sata_mv pdc_adma sata_sil sata_nv pata_atiixp pata_sil680 > pata_netcell pata_it821x pata_cmd640 pata_atp867x sata_qstor pata_sis sata_sis > pata_cs5520 pata_hpt3x3 sata_uli pata_mpiix pata_ns87410 sata_inic162x sata_svw > pata_it8213 pata_hpt37x pata_ninja32 pata_sl82c105 pata_opti pata_via > pata_artop pata_rz1000 pata_cypress pata_triflex pata_efar pata_ns87415 > pata_serverworks pata_optidma pata_sch pata_sc1200 sata_promise pata_rdc > pata_ali pata_radisys sata_via pata_pdc202xx_old sata_sx4 pata_pdc2027x > pcmcia_core pcmcia pata_pcmcia ata_piix sata_sil24 pata_piccolo pata_oldpiix > pata_hpt366 pata_cmd64x sata_vsc pata_cs5530 pata_hpt3x2n sd_mod > Features: dm block usb resume.userspace resume.kernel > Bootsplash: openSUSE (1280x1024) > 47010 blocks > however, no progress has been made yet. Would you attach your initrd file here ? Thanks. Created attachment 363965 [details]
the latest initrd
I have tested openSUSE-KDE-LiveCD-i686-Build0625-Media.iso on the same (the above) computer. lbm2-2.02.58-2.1 device-mapper-1.02.42-2.1-x86 No dm partitions had been created while booting. I created them by dmraid -ay. installation failed with 3030 error. (In reply to comment #25) > *** Bug 607869 has been marked as a duplicate of this bug. *** Hi Arvine, I've tested the update package with GNOME Live CD M7, and it installed fine with LVM based schema. However, I still don't understand why you writing "add" into "/sys/block/dm-N/uevent". When "/sys/block/dm-N/uevent" is writable, it means dm-N is there already. It expects a writing of "change" instead I think. (In reply to comment #30) > I have tested openSUSE-KDE-LiveCD-i686-Build0625-Media.iso on the same (the > above) computer. > lbm2-2.02.58-2.1 > device-mapper-1.02.42-2.1-x86 > No dm partitions had been created while booting. I created them by dmraid -ay. > installation failed with 3030 error. This suppose to be a problem of boot.dmraid. I'm looking for an testing environment for this now. FYI. I've just upgraded to M7/build 623 - this test-system has hardware raid and LVM. On boot-up, I didn't get any /dev/dm-*, /dev/disk-by-id nor any of the LVM symlinks. Update:
I removed the ability to instruct udev to delete any device nodes, to work around this problem. This is already in Factory and will result in:
$ udevadm test .
parse_file: reading '/lib/udev/rules.d/10-dm.rules' as rules file
add_rule: NAME="" is ignored, because udev will not delete any device nodes, please remove it from /lib/udev/rules.d/10-dm.rules:52
The use of ENV{STARTUP} will always fail. We do not have such a variable, and it does not make any real sense to have one -- it only exists on Fedora.
Will it make it to RC1? In the meantime, is there a way to test it during Stage1 install? *** Bug 609228 has been marked as a duplicate of this bug. *** I tested the packages in Base:System for lvm2 and device-mapper* on an x86_64 system with the same nvidia dm HW. I have 2 root partitions: an 11.2 and a current M7 factory and a common /boot partition. The M7 Factory was having the stage1 errors described. Packages in Boot:System were installed. mkinitrd -f dm was run from a chroot mount of the M7 root with the /dev entries and /boot bound from the running 11.2 system. reboot and all was well with the world. Didn't need to change any udev rules. Package versions validated: lvm2-2.02.58-23.2.x86_64 device-mapper-32bit-1.02.42-23.2.x86_64 device-mapper-1.02.42-23.2.x86_64 Thanks No good news from here. Using the same packages: lvm2-2.02.58-23.2.x86_64 device-mapper-32bit-1.02.42-23.2.x86_64 device-mapper-1.02.42-23.2.x86_64 running mkinitrd -f dm and rebooting, I am stile getting the same errors as before. Part of dmesg: [ 10.344026] floppy0: no floppy controllers found [ 25.744779] device-mapper: uevent: version 1.0.3 [ 25.754734] device-mapper: ioctl: 4.17.0-ioctl (2010-03-05) initialised: dm-devel@redhat.com [ 29.226902] usbcore: registered new interface driver snd-usb-audio [ 30.498235] Adding 5245184k swap on /dev/sda6. Priority:-1 extents:1 across:5245184k [ 92.161165] device-mapper: ioctl: device doesn't appear to be in the dev hash table. [ 92.691908] loop: module loaded not the large delay (60 seconds) between swap and device-mapper. the messege Which appears during this time "waiting for udev to settle" (in red) "System Boot Controle failed boot.udev" I can confirm that a fresh installation using factory (03/06/10, 2.6.34-8-desktop kernel, build 2010-05-17 17:30:24) works and udev nodes are not deleted. Stage1 LVM-based partitioning now works as expected and the -3030 error is no longer happening. Stage2 installation works as well and the system boots without issues. I've just done a 'zypper up', rebuilt initrd etc. and rebooted - no /dev/dm* devices to be found. I'm using the -pae kernel. Still happends at install , latest openSUSE-NET iso from d.o.o/factory 3030 error Cristian, Can you please provide your autoinst.xml or _precise_ steps to reproduce? no improvment here yet. [ 81.868286] device-mapper: ioctl: device doesn't appear to be in the dev hash table. Boot this iso http://download.opensuse.org/factory/iso/openSUSE-NET-x86_64-Build0653-Media.iso left everything by default until the partition setup screen. select LVM setup, format the root partition as btrfs and left boot as is. in the package selection menu, select "Minimal text only" from the "other" menu. (In reply to comment #44) > Boot this iso > > http://download.opensuse.org/factory/iso/openSUSE-NET-x86_64-Build0653-Media.iso > > left everything by default until the partition setup screen. > > select LVM setup, format the root partition as btrfs and left boot as is. > > in the package selection menu, select "Minimal text only" from the "other" > menu. I just tested with Build0654, and it works fine. Haven't tried 0653 yet. Success!
using build o654 live-cd media I had been able to install ms 7 on a dm partition,
(same hardware as above).
section of dmesg :
[ 7.039342] Adding 5245184k swap on /dev/sda6. Priority:-1 extents:1 across:5245184k
[ 15.429682] device-mapper: ioctl: device doesn't appear to be in the dev hash table.
[ 15.730029] loop: module loaded
8 seconds now, 300 before!
uname -a
Linux linux-a3ki 2.6.34-8-default #1 SMP 2010-05-17 17:30:24 +0200 i686 athlon i386 GNU/Linux
lulicur1@linux-a3ki:~> cat /etc/SuSE-release
openSUSE 11.3 Milestone 7 (i586)
VERSION = 11.3
lulicur1@linux-a3ki:~> df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/nvidia_fajhbfec_part3
20641788 2861468 16731676 15% /
devtmpfs 1746228 292 1745936 1% /dev
tmpfs 1750768 4 1750764 1% /dev/shm
/dev/sda9 504740 30199 448481 7% /boot
/dev/mapper/nvidia_fajhbfec_part1
1352790904 15619720 1337171184 2% /home
congretulations.
Well, this is strange. The bug is back, this time with Jun 3 22:48 kernel/initrd, that's hours after my Comment #39. Has anything changed around that time? *** Bug 613250 has been marked as a duplicate of this bug. *** Have installed with iso build 669 and factory - works fine now. Jun 14 17:34 factory problem still there.
Uwe, do you think -3030 can be in any way AutoYast related?
I can see some people here are using dm-raid devices, this is happening for regular LVM created during installation with the following autoinst.xml:
<partitioning config:type="list">
<drive>
<device>/dev/os</device>
<partitions config:type="list">
<partition>
<create config:type="boolean">true</create>
<crypt_fs config:type="boolean">false</crypt_fs>
<filesystem config:type="symbol">xfs</filesystem>
<format config:type="boolean">true</format>
<fstopt>defaults</fstopt>
<loop_fs config:type="boolean">false</loop_fs>
<lv_name>tmp</lv_name>
<mount>/tmp</mount>
<mountby config:type="symbol">device</mountby>
<partition_id config:type="integer">131</partition_id>
<raid_options/>
<resize config:type="boolean">false</resize>
<size>max</size>
</partition>
</partitions>
<pesize>4M</pesize>
<type config:type="symbol">CT_LVM</type>
<use>all</use>
</drive>
<drive>
<device>/dev/sda</device>
<initialize config:type="boolean">true</initialize>
<partitions config:type="list">
<partition>
<create config:type="boolean">true</create>
<crypt_fs config:type="boolean">false</crypt_fs>
<filesystem config:type="symbol">ext4</filesystem>
<format config:type="boolean">true</format>
<fstopt>noatime,acl,user_xattr</fstopt>
<loop_fs config:type="boolean">false</loop_fs>
<mount>/boot</mount>
<mountby config:type="symbol">device</mountby>
<partition_id config:type="integer">131</partition_id>
<partition_nr config:type="integer">1</partition_nr>
<raid_options/>
<resize config:type="boolean">false</resize>
<size>97680896</size>
</partition>
<partition>
<create config:type="boolean">true</create>
<crypt_fs config:type="boolean">false</crypt_fs>
<filesystem config:type="symbol">ext4</filesystem>
<format config:type="boolean">true</format>
<fstopt>noatime,acl,user_xattr</fstopt>
<loop_fs config:type="boolean">false</loop_fs>
<mount>/</mount>
<mountby config:type="symbol">device</mountby>
<partition_id config:type="integer">131</partition_id>
<partition_nr config:type="integer">2</partition_nr>
<raid_options/>
<resize config:type="boolean">false</resize>
<size>32201932288</size>
</partition>
<partition>
<create config:type="boolean">true</create>
<crypt_fs config:type="boolean">false</crypt_fs>
<filesystem config:type="symbol">swap</filesystem>
<format config:type="boolean">true</format>
<fstopt>defaults</fstopt>
<loop_fs config:type="boolean">false</loop_fs>
<mount>swap</mount>
<mountby config:type="symbol">id</mountby>
<partition_id config:type="integer">130</partition_id>
<partition_nr config:type="integer">3</partition_nr>
<raid_options/>
<resize config:type="boolean">false</resize>
<size>2138209792</size>
</partition>
<partition>
<create config:type="boolean">true</create>
<crypt_fs config:type="boolean">false</crypt_fs>
<filesystem config:type="symbol">ext4</filesystem>
<format config:type="boolean">false</format>
<loop_fs config:type="boolean">false</loop_fs>
<lvm_group>os</lvm_group>
<mountby config:type="symbol">device</mountby>
<partition_id config:type="integer">142</partition_id>
<partition_nr config:type="integer">4</partition_nr>
<raid_options/>
<resize config:type="boolean">false</resize>
<size>max</size>
</partition>
</partitions>
<pesize></pesize>
<type config:type="symbol">CT_DISK</type>
<use>all</use>
</drive>
</partitioning>
What is _really_ scary that it did work before at time of Comment 39. Current uname says the kernel was built 2010-06-03 18:33:51.
The /dev/mapper/os-tmp node disappears during automated partitioning with autoyast.
The error 3030 is issued by libstorage (which YaST uses for partitioning) and simply means that the device node does not exist. Libstorage tests the existence of device nodes before many operations since synchronisation with udev is required. I can also confirm that normal (no Live CD, no AutoYaST) installation with LVM fails with todays build 0673. (In reply to comment #51) > The error 3030 is issued by libstorage (which YaST uses for partitioning) and > simply means that the device node does not exist. Libstorage tests the > existence of device nodes before many operations since synchronisation with > udev is required. > > I can also confirm that normal (no Live CD, no AutoYaST) installation with LVM > fails with todays build 0673. Hi all, May you add some reference to the build you are using, and the URL I can download and verify with ? Thanks. (In reply to comment #52) I'm installing using PXE boot. The kernel and initrd are taken from: http://download.opensuse.org/factory/repo/oss/boot/x86_64/loader/linux and http://download.opensuse.org/factory/repo/oss/boot/x86_64/loader/initrd the PXEboot entry is: label 2010 KERNEL factory APPEND initrd=initrd install=http://download.opensuse.org/factory/repo/oss/ insecure=1 textmode=1 SCSIBeforeUSB autoyast=http://my.local.url/11.3.xml As you can see above, the repository I'm installing from is http://download.opensuse.org/factory/repo/oss/ and a non-oss repo at: http://download.opensuse.org/factory/repo/non-oss I have posted part of the autoyast profile used to install in Comment #50. Just a word of warning -- it may be a Mandelbug -- if the partitioning is done manually, there may be different timing. You may consider creating an autoyast profile to properly reproduce this. Hi all, I think I´ve got a related bug - made fresh install of M7 on and SSD (ata2; zypper dup then to RC1, all worked smooth) - but they do not recognize that two other HDDs (ata5 and 6) of my system are bundled as raid - yasts partition-manager only sees the two additional hdds, not the raid-partitions. With 11.2 that worked fine. So I would also not be able to install on that raid (it was also not recognized during installation of M7). I hope this information is useful for you. If someone gives me a hint what to hack into the command line I can give additional informations for my system.... part of dmesg: [ 1.309077] scsi0-5 : ahci [ 1.309658] ata1: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffe900 irq 27 [ 1.309661] ata2: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 27 [ 1.309663] ata3: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffea00 irq 27 [ 1.309666] ata4: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 27 [ 1.309668] ata5: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 27 [ 1.309670] ata6: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 27 [ 1.767055] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 1.772841] ata1.00: ATA-8: SAMSUNG HD153WI, 1AN10002, max UDMA/133 [ 1.772846] ata1.00: 2930277168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA [ 1.778694] ata1.00: configured for UDMA/133 [ 1.789120] scsi 0:0:0:0: Direct-Access ATA SAMSUNG HD153WI 1AN1 PQ: 0 ANSI: 5 [ 2.665031] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.724523] ata2.00: ATA-8: OCZ-AGILITY2, 1.00, max UDMA/133 [ 2.724527] ata2.00: 97696368 sectors, multi 1: LBA48 NCQ (depth 31/32), AA [ 2.774701] ata2.00: configured for UDMA/133 [ 2.785150] scsi 1:0:0:0: Direct-Access ATA OCZ-AGILITY2 1.00 PQ: 0 ANSI: 5 [ 3.090024] ata3: SATA link down (SStatus 0 SControl 300) [ 3.977041] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 3.979039] ata4.00: ATAPI: Optiarc DVD RW AD-7240S, 1.04, max UDMA/100, ATAPI AN [ 3.981224] ata4.00: configured for UDMA/100 [ 3.993219] scsi 3:0:0:0: CD-ROM Optiarc DVD RW AD-7240S 1.04 PQ: 0 ANSI: 5 [ 4.869031] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 4.875383] ata5.00: ATA-7: SAMSUNG HD322HJ, 1AC01113, max UDMA7 [ 4.875387] ata5.00: 625142448 sectors, multi 0: LBA48 NCQ (depth 31/32), AA [ 4.881825] ata5.00: configured for UDMA/133 [ 4.892099] scsi 4:0:0:0: Direct-Access ATA SAMSUNG HD322HJ 1AC0 PQ: 0 ANSI: 5 [ 5.768041] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 5.774396] ata6.00: ATA-7: SAMSUNG HD322HJ, 1AC01113, max UDMA7 [ 5.774400] ata6.00: 625142448 sectors, multi 0: LBA48 NCQ (depth 31/32), AA [ 5.780843] ata6.00: configured for UDMA/133 [ 5.791097] scsi 5:0:0:0: Direct-Access ATA SAMSUNG HD322HJ 1AC0 PQ: 0 ANSI: 5 [ 5.806097] udev: starting version 157 [ 5.851938] sd 0:0:0:0: [sda] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB) [ 5.851969] sd 1:0:0:0: [sdb] 97696368 512-byte logical blocks: (50.0 GB/46.5 GiB) [ 5.851997] sd 0:0:0:0: [sda] Write Protect is off [ 5.852015] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 5.852019] sd 1:0:0:0: [sdb] Write Protect is off [ 5.852022] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 5.852039] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.852044] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.852231] sda: [ 5.852263] sdb: sdb1 sdb2 [ 5.852798] sd 1:0:0:0: [sdb] Attached SCSI disk [ 5.852828] sd 4:0:0:0: [sdc] 625142448 512-byte logical blocks: (320 GB/298 GiB) [ 5.852869] sd 4:0:0:0: [sdc] Write Protect is off [ 5.852871] sd 4:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 5.852889] sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.852989] sdc: sdc1 sdc2 [ 5.855465] sdc: p2 size 1250066432 exceeds device capacity, limited to end of disk [ 5.855665] sd 4:0:0:0: [sdc] Attached SCSI disk [ 5.855689] sd 5:0:0:0: [sdd] 625142448 512-byte logical blocks: (320 GB/298 GiB) [ 5.855730] sd 5:0:0:0: [sdd] Write Protect is off [ 5.855732] sd 5:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [ 5.855750] sd 5:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.855862] sdd: sda1 [ 5.864681] sd 0:0:0:0: [sda] Attached SCSI disk [ 5.878327] sdd1 [ 5.878658] sd 5:0:0:0: [sdd] Attached SCSI disk [ 5.933523] [drm] Initialized drm 1.1.0 20060810 (In reply to comment #54) > Hi all, > > I think I´ve got a related bug - made fresh install of M7 on and SSD (ata2; > zypper dup then to RC1, all worked smooth) - but they do not recognize that two > other HDDs (ata5 and 6) of my system are bundled as raid - yasts > partition-manager only sees the two additional hdds, not the raid-partitions. > With 11.2 that worked fine. So I would also not be able to install on that raid > (it was also not recognized during installation of M7). > I hope this information is useful for you. If someone gives me a hint what to > hack into the command line I can give additional informations for my system.... Would you run "dmraid -ay" manually there ? It sounds software raid is not built automatically. dmraid -ay RAID set "isw_eahfhfdjgg_tom" was activated device "isw_eahfhfdjgg_tom" is now registered with dmeventd for monitoring RAID set "isw_eahfhfdjgg_tomp1" was activated RAID set "isw_eahfhfdjgg_tomp1" was not activated RAID set "isw_eahfhfdjgg_tomp2" was activated RAID set "isw_eahfhfdjgg_tomp2" was not activated Thanks! That worked! Even if it looks strange that the partitions of the raid are now noted twice in yasts partition-manager - once as DM once as DM-RAID-isw_... . However I could mount now. How can I make this last permanently (suggesting that it will be gone after reboot). (In reply to comment #56) crazy! it lasted after reboot and also the double entrie is gone - thank you! Created attachment 370040 [details]
Additional change event to device mapper device
libstorage writes "add" into /sys/block/dm-N/uevent for udev synchronization.
However, from device mapper's point of view, "add" event means the device is
not ready for use at all. A device mapper device is ready for use only after the "change" event is got.
So even udev ignores the NAME="" rule, and 10-dm.rule don't set NAME="", this is still broken cause libstorage is expecting symbolic link.
I proposes this patch to libstorage. So that libstorage writes additional "change" into /sys/block/dm-N/uevent.
Please consider this for next RC.
I would like to hear the opinion of our udev maintainer about this. Maybe we can remove the udev trigger completely from libstorage. The original reason (bug #165192) seems not to apply anymore (at least running mke2fs and tune2fs cause the by-label links to be updated without writing "add" to uevent). udev watches change and updates the links for block devices, but device-mapper devices are completely excluded from this functionality, because they can't cope with any event they did not send themselves. upstream knows about the problems and is working on it. not sure if device-mapper/lvm is already fixed to allow "synthetic" additional events not originating from libdevmapper -- the last time I checked and talked to the guys, it just broke their setup. *** Bug 615588 has been marked as a duplicate of this bug. *** I tried to install RC1 and still have bug 609228 which is a duplicate of this bug. There is no change and I cannot install. Also, VERY IMPORTANT: I did not mention this and assumed it was related to this bug but is very critical: When this problem occurs and the install stops, one or more of the partition volume labels are destroyed preventing my normal 11.2 from booting. For instance, when I installed RC1 my /grub partition (no formatting) which is in LVM and is EXT3 had it's label blanked out as well as the "/" partition (formatted in LVM/XFS) where I tried to install RC1.This problem was also in MS7. I am using grub2 which is allows root and grub to be LVM. I am hoping this problem is related, if not we need a new problem opened. So far, no way to install MS7 or RC1. Kay, what do you suggest as short-time workaround for 11.3? We have RC2 next week and your comment #60 does not seem to answer #59 (at least in my understanding). (In reply to comment #63) > Kay, what do you suggest as short-time workaround for 11.3? Unfortunately, I can not suggest any straight-forward workaround. I guess, the current device-mapper/lvm code we currently ship can not work as expected, it is making assumptions about uevents which are not met on common systems (see the bugs at the end). > We have RC2 next > week and your comment #60 does not seem to answer #59 (at least in my > understanding). I tried to say: "the label,uuid-symlinks are usually _not_ updated for dm devices when filesystem metadata is changed. Device-mapper devices are excluded from udev's logic, because they don't behave as expected" and "using artificial events for device-mapper devices, like libstorage does, will break the current device-mapper/lvm assumptions" Which unfortunately means, with the current code, we have no simple solution for the problem. It's all work-in-progress upstream, and the lvm git repo has added a few workarounds (which we don't ship) for the most common problems: http://sourceware.org/git/?p=lvm2.git;a=blob;f=udev/10-dm.rules.in;h=0db88093aa9b22d321ecf749148b1b95a0b838f6;hb=HEAD#l47 But all this is likely not well tested, and might also not fully work as expected. I guess we have only two options: to update to the current dm/lvm code or go back to the old version which does not plug into udev. But I really don't know enough about device-mapper/lvm to make a decision here. The latest comments in the corresponding Red Hat bugs seem to state that the issues are addressed: https://bugzilla.redhat.com/show_bug.cgi?id=561425 https://bugzilla.redhat.com/show_bug.cgi?id=577798 Why not the solution proposed in comment #59? (In reply to comment #65) > Why not the solution proposed in comment #59? Because it's only one source of the events the current dm tools don't handle properly, and we have more: packages trying to apply a new config, kernel module updates, users running 'trigger', udisks installing 'watch' events, ... (In reply to comment #66) > (In reply to comment #65) > > Why not the solution proposed in comment #59? > > Because it's only one source of the events the current dm tools don't handle > properly, and we have more: packages trying to apply a new config, kernel > module updates, users running 'trigger', udisks installing 'watch' events, ... Let's stick with this bug first. This bug is about that rules for device-mapper doesn't work with artificial 'add' event. This is still true with the latest update, and I think it'll be true in foreseeable future. So, I think the suggestion in comment#59 is the right step to go. Then, on the other hand, I agree with Kay that the udev rules for device-mapper are broken with artificial uevents. Default assumption of source of the uevent is one thing, and avoiding racing is another. However, these issues will not affect installation process as far as I can see ... just my .2c. (In reply to comment #67) > This bug is about that rules for device-mapper doesn't work with artificial > 'add' event. It's the case for every event including 'change', not only 'add'. > This is still true with the latest update, and I think it'll be true in > foreseeable future. This sounds different: https://bugzilla.redhat.com/show_bug.cgi?id=561425#c16 > So, I think the suggestion in comment#59 is the right step > to go. It might only avoid one of a bunch of cases, where this will go wrong and lead to the removal of dm/lvm symlinks? (In reply to comment #64) > I guess we have only two options: to update to the current dm/lvm code or go > back to the old version which does not plug into udev. But I really don't know > enough about device-mapper/lvm to make a decision here. Looking at the available time frames, may I humbly suggest to go with the rollback? (also, cheekily bumping importance as it's a SHIP_STOPPER) Trying to install a new server here with factory of the day ( 22 June ) crash with system disque :
md0 ( sdg1,sdh1 ) raid1 ext4 for /boot
md1 ( sdg2,sdh2 ) raid1 -> vgsystem
-> lvsuse113 (ext4 Label SUSE113 ) for /
-> lvtmp (ext4 Label TMP) for /tmp
-> lvvar (ext4 Label VAR ) for /var
-> lvsnap (10GB) not formated, not mounted ...
Yast2 found /boot and can mount it .. in /dev/mapper/ exist the lvsnap
Not of the other are present.
We are on install system, so modification are not easy ( booted by pxe from the factory )
As said before, we are at 2 step of RC2, and the situation is (at my opinion catastrophic in server land where lvm is heavily used ) So a solution is more than needed. Or a way to do this ( I can't imagine what happen to a sysadmin upgrading it's 11.2 server with zypper dup .... after the reboot )
Can we raise it to P1 ?
(In reply to comment #68) > (In reply to comment #67) > > This bug is about that rules for device-mapper doesn't work with artificial > > 'add' event. > > It's the case for every event including 'change', not only 'add'. > > > This is still true with the latest update, and I think it'll be true in > > foreseeable future. > > This sounds different: > https://bugzilla.redhat.com/show_bug.cgi?id=561425#c16 No, it's not. At least not in the git repo yet. > > So, I think the suggestion in comment#59 is the right step > > to go. > > It might only avoid one of a bunch of cases, where this will go wrong and lead > to the removal of dm/lvm symlinks? Well, I tried again to submit an update of lvm2 into Base:System. The new udev rule works like this: -> If 'add' triggered by libdevmapper, /dev/dm-* will not be removed, but all symlinks will be removed -> If 'change' triggered by libdevmapper, /dev/dm-* and all symlinks will be created. -> If 'add|change' triggered by other source, /dev/dm-* will not be removed, all symlinks will be created according to the info from IMPORT{db}. I'd like to know if this is OK from udev's point of view. If it's OK, I'll try to make this upstream then. Thanks. (In reply to commen > > > This is still true with the latest update, and I think it'll be true in > > > foreseeable future. > > > > This sounds different: > > https://bugzilla.redhat.com/show_bug.cgi?id=561425#c16 > > No, it's not. At least not in the git repo yet. Sure, it's in the repo. All the IMPORT{db} stuff which is not in our package. > -> If 'add|change' triggered by other source, /dev/dm-* will not be removed, Primary device nodes will never be removed again, because recent udev versions, like the one we ship, refuses to do that, and ignores all the instructions from the device-mapper rules. > all symlinks will be created according to the info from IMPORT{db}. > I'd like to know if this is OK from udev's point of view. The stuff in the current lvm git repo is expected to solve some of the problems. It is surely 'ok' from udev point of view, but I can tell if that is sufficient to solve the current problems, or the right way to handle that from device-mapper's view. I guess it's all still work-in-progress at the device-mapper side at the moment. > If it's OK, I'll try to make this upstream then. With 'upstream' you mean our Factory package? (In reply to comment #72) > (In reply to commen > > > > This is still true with the latest update, and I think it'll be true in > > > > foreseeable future. > > > > > > This sounds different: > > > https://bugzilla.redhat.com/show_bug.cgi?id=561425#c16 > > > > No, it's not. At least not in the git repo yet. > > Sure, it's in the repo. All the IMPORT{db} stuff which is not in our package. Not sure what's IMPORT you are referring to. The latest update to 10-dm.rules in upstream is made about 2 month ago. And that doesn't help to this bug. > > -> If 'add|change' triggered by other source, /dev/dm-* will not be removed, > > Primary device nodes will never be removed again, because recent udev versions, > like the one we ship, refuses to do that, and ignores all the instructions from > the device-mapper rules. > > > all symlinks will be created according to the info from IMPORT{db}. > > I'd like to know if this is OK from udev's point of view. > > The stuff in the current lvm git repo is expected to solve some of the > problems. It is surely 'ok' from udev point of view, but I can tell if that is > sufficient to solve the current problems, or the right way to handle that from > device-mapper's view. I guess it's all still work-in-progress at the > device-mapper side at the moment. > > > If it's OK, I'll try to make this upstream then. > > With 'upstream' you mean our Factory package? Both Factory and device mapper upstream. What's with the LVM links? They will still be removed with any non-libdevmapper event, right? (In reply to comment #74) > What's with the LVM links? They will still be removed with any non-libdevmapper > event, right? LVM links will not be removed with non-libdevmapper event. (In reply to comment #75) > (In reply to comment #74) > > What's with the LVM links? They will still be removed with any non-libdevmapper > > event, right? > > LVM links will not be removed with non-libdevmapper event. The upstream version will remove the links, the version in Base:System won't. Just want to make it clear a little bit. Kay, I have tested what you write in comment #64. But on RC1 udev apparently does watch for metadata changes even on DM devices (tested with LVM). So maybe removing the artificial "add" event from libstorage is the best way to fix this problem. (In reply to comment #77) > Kay, I have tested what you write in comment #64. But on RC1 udev apparently > does watch for metadata changes even on DM devices (tested with LVM). That's a temporary thing in the udisks rules, which are only available on GNOME installations. > So maybe removing the artificial "add" event from libstorage is the best way > to fix this problem. I still don't think so. As mentioned earlier, to remove one of many possible event sources makes the issue appear less frequently, but does not solve the underlying problem in any kind. Device mapper needs to cope with that behavior, we can not control all tools which issue these events, and there a quite a few more besides libstorage. The dm/lvm release of yesterday is supposed to solve this problem at the dm level. Even if it's a temporary thing that metadata changes are handled it works now and we need a solution now. (And a final solution would also not need an artificial "add" event from libstorage.) I also agree that the communication between udev and device-mapper must still be fixed but I suppose this will take a lot more time. (In reply to comment #79) > Even if it's a temporary thing that metadata changes are handled it works now > and we need a solution now. Keep in mind that this will only work on GNOME. Other desktops still use HAL which does not install these watch rules. > (And a final solution would also not need an > artificial "add" event from libstorage.) I don't see how we can expect these to be automatically updated on all systems. In any case it should be 'change', 'add' is reserved for coldplug, and the very first event at device creation. > I also agree that the communication between udev and device-mapper must still > be fixed but I suppose this will take a lot more time. The release of yesterday looks promising. Unlike the version we ship, it has the potential to work much better. And most of the Red Hat bugs got closed now. But as said earlier, I can't really suggest anything here, I'm just watching the reports. Just to have a how-to survive until it's done. If you use partitioner, add a label to the partition (with this you have a second call to tune2fs which will finish in error : the infamous -3011 ) As root launch a udevadmin trigger and hop the /dev/mapper is repopulated ... Click continue dispite the error, and all operations finish successfully, minus the label (if you want it, reuse tune2fs, xfs_admin ...) Perharps one stupid solution, is to udev trigger at each step ? > In reply to comment #80)
>
> Keep in mind that this will only work on GNOME. Other desktops still use HAL
> which does not install these watch rules.
I tested with KDE.
(In reply to comment #82) > I tested with KDE. Then it's coming from some other rule. It's usually not the case. But what I meant regarding the problem, is that it should _not_ matter if udev does these artificial events (with 'watch') or libstorage is doing it (writing to uevent). Both types of event sources will cause exactly the same behavior as they both don't originate from libdevmapper, and removing them from libstorage will only make the links not updated in case udev does not trigger the watch events. Some large systems, or systems using many tiny writes with 'dd', or something similar are known to have problems with udev's 'watch' and are instructed to globally switch this off with a custom rule containing 'nowatch'. In short, I would not expect, that changing libstorage will solve any of the problems we are seeing. I updated the LVM2 package to the latest upstream release, which fixes this issue in a nice way. It's expected to be included in RC2, and fix this bug finally. I'm going to close this as fixed when the submit is accepted into openSUSE:Factory. Thanks. (In reply to comment #84) > I updated the LVM2 package to the latest upstream release, which fixes this > issue in a nice way. Can you please clarify which update we're specifically looking for? atm, I see an update to LVM 2.0.67 from you in the last days: rpm -q --changelog lvm2-2.02.67-36.1.x86_64 | head -n 11 * Wed Jun 23 2010 xwhu@novell.com - Update to LVM.2.02.67 - Require partial option in lvchange --refresh for partial LVs - Add replicators' LVs to dtree for activation - Add lvm2app interfaces to lookup a vgname from a pvid and pvname - Fix memory leak for invalid regex pattern input - Disallow the direct removal of a merging snapshot - Fix lvconvert error message when existing mirrored LV is not found - Add LVM_SUPPRESS_LOCKING_FAILURE_MESSAGES environment variable - Improve snapshot merge metadata import validation but upstream seems to be newer: @ http://sources.redhat.com/cgi-bin/cvsweb.cgi/LVM2/VERSION?cvsroot=lvm2 latest -> CVS Tags: v2_02_68. i'm guessing that's it ... ? (In reply to comment #85) > (In reply to comment #84) > > I updated the LVM2 package to the latest upstream release, which fixes this > > issue in a nice way. > > Can you please clarify which update we're specifically looking for? > > atm, I see an update to LVM 2.0.67 from you in the last days: > > rpm -q --changelog lvm2-2.02.67-36.1.x86_64 | head -n 11 > * Wed Jun 23 2010 xwhu@novell.com > - Update to LVM.2.02.67 > - Require partial option in lvchange --refresh for partial LVs > - Add replicators' LVs to dtree for activation > - Add lvm2app interfaces to lookup a vgname from a pvid and pvname > - Fix memory leak for invalid regex pattern input > - Disallow the direct removal of a merging snapshot > - Fix lvconvert error message when existing mirrored LV is not found > - Add LVM_SUPPRESS_LOCKING_FAILURE_MESSAGES environment variable > - Improve snapshot merge metadata import validation > > but upstream seems to be newer: > > @ http://sources.redhat.com/cgi-bin/cvsweb.cgi/LVM2/VERSION?cvsroot=lvm2 > > latest -> CVS Tags: v2_02_68. > > i'm guessing that's it ... ? Yes, as the time I'm updating, 2.02.67 was still the latest. btw: You need to update device-mapper to 1.02.49. A while ago, the new packages were accepted into Factory. So I'm closing this as fixed. Thank you all for the help to resolve this bug. These were my LVM test results: * device nodes are only missing for newly created lvm-volumes during setup * By manually creating the link from /dev/dm-0,.. to /dev/mapper/name the installation can proceed as if everything was fine: the link to /dev/lvm/name then gets instantaneously created and all utilities like lvdisplay start to work (mounted manually to /mnt/submountpoint + added in fstab). Fresh factory install 30/06/10 with autoyast xml from Comment 50. Verified working. /dev/mapper/os-tmp -> ../dm-0 brw-rw---- 1 root disk 253, 0 2010-06-30 14:28 /dev/dm-0 Did zypper dup from 11.3 RC1 to 11.3RC2 and rebooted and this is broken for me again. Now I get /dev/dm-0 and /dev/dm-1 for the two mirrored disk pairs on my system (fixing the autoyast use case mentioned above) but there are no _partX links created in /dev/disk/by-id for either DM device used to mount the OS, swap and home directories (nor associated /dev/mapper entries). I backed off my version of LVM2 and device-mapper and ran mkinitrd on the current *-12-desktop kernel to get running. Problem is every time a kernel update comes out, I need to go through this process to get it to boot. Don't think this meets definition of a "ship stopper", but the current solution does not address my use case back to square one. I have updated factory and could not boot after the upgrade - root could not be mounted on /dev/mapper/nvidia_iaahfbeep5 nor on /dev/mapper/nvidia_iaahfbee_part5. Also /dev/disk/by-id names have been changed and are different from their previous names. I have tryed to reinstall using net install from the current factory repository - the same results: unable to upgrade a previous installation, error 3030 while trying to make a fresh installation on mirrored disks. Finaly I have tried to install using openSUSE-KDE-LiveCD-x86_64-Build0694-Media.iso - with the same sad results. In my case this bug has not been resolved yet. Just for verification I have used the build 0654 media for re-installation on the same hardware as above. It installed as expected. linux-junu:~ # mount /dev/mapper/nvidia_iaahfbee_part5 on / type ext4 (rw,acl,user_xattr) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) devtmpfs on /dev type devtmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,mode=1777) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/sda6 on /boot type ext3 (rw,acl,user_xattr) /dev/mapper/nvidia_iaahfbee_part1 on /home type ext3 (rw) securityfs on /sys/kernel/security type securityfs (rw) none on /proc/fs/vmblock/mountPoint type vmblock (rw) linux-junu:~ # cat /etc/SuSE-release openSUSE 11.3 Milestone 7 (x86_64) VERSION = 11.3 linux-junu:~ # rpm -q | grep device rpm: no arguments given for query linux-junu:~ # rpm -qa | grep device libimobiledevice1-1.0.1-1.1.x86_64 device-mapper-1.02.42-4.1.x86_64 linux-junu:~ # rpm -qa | grep lvm lvm2-2.02.58-4.1.x86_64 This is the second (sucssefull) time I am using this version for installation. The previous installation has survived several upgrades until the July 1 st upgrade, which left it unbootable. Hi Martin & Israel: I guess both of you are referring to installation on fake raid devices. Am I right ? One big change of 11.3 around fake-raid devices is that it defaults (from what I tested so far) to use MD, instead of device-mapper based solution (dmraid for 11.2). Please check by "cat /proc/mdstat" to see if you have md126 or so running. Thanks. For Intel Software RAID the user can choose between using dmraid or mdadm. In my tests with dmraid the device nodes for the main dmraid is present but the nodes for the partitions are missing (see bug #619566). yes, it is fake-raid and I experiance exactly the same what martin is exeriancing. There are 3 HDs on the machine. One is used as a boot partition for the fake-raid OS, and the 11.3 OS, and on the fake raid only MS7 is instatalled. Here are outputs from the first one: uli@raidale:~> cat /etc/SuSE-release openSUSE 11.3 (i586) VERSION = 11.3 luli@raidale:~> uname -a Linux raidale 2.6.34-12-desktop #1 SMP PREEMPT 2010-06-29 02:39:08 +0200 x86_64 x86_64 x86_64 GNU/Linux luli@raidale:~> mount /dev/sda2 on / type ext4 (rw,acl,user_xattr) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) devtmpfs on /dev type devtmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,mode=1777) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/sda3 on /home type ext4 (rw,acl,user_xattr) /dev/sda5 on /mnt/newboot type ext3 (rw,acl,user_xattr) /dev/sda6 on /mnt/superboot type ext3 (rw,acl,user_xattr) fusectl on /sys/fs/fuse/connections type fusectl (rw) securityfs on /sys/kernel/security type securityfs (rw) luli@raidale:~> cat /proc/mdstat Personalities : unused devices: <none> raidale:~ # dmraid -ay RAID set "nvidia_iaahfbee" already active RAID set "nvidia_iaahfbee" was not activated RAID set "nvidia_iaahfbeep1" was activated RAID set "nvidia_iaahfbeep1" was not activated RAID set "nvidia_iaahfbeep2" was activated RAID set "nvidia_iaahfbeep2" was not activated RAID set "nvidia_iaahfbeep5" was activated RAID set "nvidia_iaahfbeep5" was not activated RAID set "nvidia_iaahfbeep6" was activated RAID set "nvidia_iaahfbeep6" was not activated RAID set "nvidia_iaahfbeep7" was activated RAID set "nvidia_iaahfbeep7" was not activated raidale:~ # cat /proc/mdstat Personalities : unused devices: <none> exactly as Martin have said/ And here are the outputs from the scond one: linux-junu:~ # cat /etc/SuSE-release openSUSE 11.3 Milestone 7 (x86_64) VERSION = 11.3 linux-junu:~ # uname -a Linux linux-junu 2.6.34-8-desktop #1 SMP PREEMPT 2010-05-17 17:30:24 +0200 x86_64 x86_64 x86_64 GNU/Linux linux-junu:~ # mount /dev/mapper/nvidia_iaahfbee_part5 on / type ext4 (rw,acl,user_xattr) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) devtmpfs on /dev type devtmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,mode=1777) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/sdc6 on /boot type ext3 (rw,acl,user_xattr) /dev/mapper/nvidia_iaahfbee_part1 on /home type ext3 (rw) securityfs on /sys/kernel/security type securityfs (rw) none on /proc/fs/vmblock/mountPoint type vmblock (rw) /dev/sdd1 on /media/disk type vfat (rw) linux-junu:~ # cat /proc/mdstat Personalities : unused devices: <none> I have an MSI AMD based motherboard with fake RAID as you suggest. I am currently running 11.3 RC2 but backed off 3 packaged and re-ran mkinitrd to have a running system. lvm2-2.02.58-23.2.x86_64 device-mapper-32bit-1.02.42-23.2.x86_64 device-mapper-1.02.42-23.2.x86_64 Xin Wie, I am not understanding if there is a way to convert mapper to MD or an option to get mapper working in current release... Open to suggestions and will test suggestions. System info for reference.... pinky:~ # cat /etc/SuSE-release openSUSE 11.3 (x86_64) VERSION = 11.3 [martin@pinky] $ cat /proc/mdstat Personalities : unused devices: <none> pinky:~ # dmraid -l asr : Adaptec HostRAID ASR (0,1,10) ddf1 : SNIA DDF1 (0,1,4,5,linear) hpt37x : Highpoint HPT37X (S,0,1,10,01) hpt45x : Highpoint HPT45X (S,0,1,10) isw : Intel Software RAID (0,1,5,01) jmicron : JMicron ATARAID (S,0,1) lsi : LSI Logic MegaRAID (0,1,10) nvidia : NVidia RAID (S,0,1,10,5) pdc : Promise FastTrack (S,0,1,10) sil : Silicon Image(tm) Medley(tm) (0,1,10) via : VIA Software RAID (S,0,1,10) dos : DOS partitions on SW RAIDs pinky:~ # dmraid -r /dev/sdd: nvidia, "nvidia_eeeidjai", mirror, ok, 488397166 sectors, data@ 0 /dev/sdc: nvidia, "nvidia_eeeidjai", mirror, ok, 488397166 sectors, data@ 0 /dev/sdb: nvidia, "nvidia_eebfhbed", mirror, ok, 390721966 sectors, data@ 0 /dev/sda: nvidia, "nvidia_eebfhbed", mirror, ok, 390721966 sectors, data@ 0 Note use of mapper partitions for root, home and boot. pinky:~ # mount /dev/mapper/nvidia_eebfhbed_part2 on / type ext4 (rw,acl,user_xattr) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) devtmpfs on /dev type devtmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,mode=1777) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/mapper/nvidia_eebfhbed_part1 on /boot type ext4 (rw,acl,user_xattr) /dev/mapper/nvidia_eeeidjai_part3 on /home type ext4 (rw,acl,user_xattr) fusectl on /sys/fs/fuse/connections type fusectl (rw) securityfs on /sys/kernel/security type securityfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) /proc on /var/lib/named/proc type none (rw,bind) proc on /var/lib/dhcp/proc type proc (ro) gvfs-fuse-daemon on /home/martin/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=martin) none on /proc/fs/vmblock/mountPoint type vmblock (rw) Thanks... martin Hi Israel & Martin: Would you try the latest device-mapper package from Base:System ? The last changelog should read: === Mon Jul 5 09:43:41 UTC 2010 - xwhu@novell.com - bnc#619566, fix error in "dmsetup export" patch, === And it may also be a good idea to update udev package from Base:System too. The last changelog should be: === Mon Jul 5 11:59:22 UTC 2010 - xwhu@novell.com - bnc#619283, Keep the udev db from initramfs. === It works on my side. Thanks a lot. In installed the latest udev and device-mapper as suggested from Base:System, rebooted and this resolved my issue. One observation, I watched the start up iterate through the device list a second time (the first was successful) but there was no harm done.. Thanks for looking into this... martin I added the base/system repository and upgraded the MS7 installation to 11.3. This time it was succsesfull. However, on another system, in which / is on a "real" disk and /home is on /dev/mapper there is still the 180 seconds hang which I have mentiond above. I have tested RC2 and although I got further I have two new problems I want to report. I originally opened bug 609228 which is a dup of this bug. I have a 2 disk system using LVM and XFS, I am not using RAID. RC 2 problems: 1. After the system is loaded onto the disk and the first reboot starts, I get a message that UUID=267044d9-7533-4739-b183-0571acd3ce1e no more events and the system waits for the root user ID. 2. During partition setup I always use the volume id/names and not UUID. Although I specified 3 partitions to be mounted that way the install ignored it and used UUID. Thinking that UUID may be the problem I changed fstab to soecify LABEL=... and got the same "no more events" anyway. So there seems to be two problems here. I attached the original install fstab and yast logs. There messages and boot message files were empty/0 bytes. Created attachment 374064 [details]
fstab and yast logs
Since this bug is marked fixed that does mean the LABEL= issue is resolved or should a new problem be opened?
I am reopening the problem to make sure my last negative results are viewed. If anything thinks the problem is not related them let me know and I will open a new bug. This is is a serious bug since it stops installation about half way. That uuid/label is broken is covered in bug #619461. I don't think the uuid/label issue is bug 619461. That describes not being able to mount by label. The problem I am having is that during partition setup I specify to mount by label but fstab does not contain the correct statements. Setup generated UUID mounts instead of LABEL= statements. I did this on 3 mounts and all were like that. FIY installed RC2 dvd onto an EEEPC with lvm and that works again. (In reply to comment #98) > I added the base/system repository and upgraded the MS7 installation to 11.3. > This time it was succsesfull. > However, on another system, in which / is on a "real" disk and /home is on > /dev/mapper there is still the 180 seconds hang which I have mentiond above. Hi Israel, Thanks for the feedback. Would you attach the output of "180 seconds hang" here? I'd like to see how this happens again. Thanks. (In reply to comment #97) > In installed the latest udev and device-mapper as suggested from Base:System, > rebooted and this resolved my issue. One observation, I watched the start up > iterate through the device list a second time (the first was successful) but > there was no harm done.. > > Thanks for looking into this... martin Hi Martin, Thanks for the feedback. Could you explain a little bit more about "start up iterate through the device list a second time" ? I Thanks. *** Bug 620360 has been marked as a duplicate of this bug. *** first system: /dev/sda2 on / type ext4 (rw,acl,user_xattr) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) devtmpfs on /dev type devtmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,mode=1777) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/sda8 on /boot type ext3 (rw,acl,user_xattr) /dev/mapper/nvidia_fajhbfec_part1 on /home type xfs (rw) fusectl on /sys/fs/fuse/connections type fusectl (rw) securityfs on /sys/kernel/security type securityfs (rw) none on /proc/fs/vmblock/mountPoint type vmblock (rw) [ 9.791002] CR2: 0000000000000010 [ 10.081057] ---[ end trace 7dd3047362c39444 ]--- [ 10.443159] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:07.0/input/input6 [ 10.578129] ieee1394: Host added: ID:BUS[0-00:1023] GUID[cf0a00000000028d] [ 10.639138] ieee1394: Host added: ID:BUS[1-00:1023] GUID[001e8c000189e2ba] [ 187.258272] device-mapper: uevent: version 1.0.3 [ 187.258438] device-mapper: ioctl: 4.17.0-ioctl (2010-03-05) initialised: dm-devel@redhat.com [ 187.326327] usbcore: registered new interface driver snd-usb-audio [ 187.362118] Adding 5245184k swap on /dev/sda6. Priority:-1 extents:1 across:5245184k [ 189.295537] device-mapper: ioctl: device doesn't appear to be in the dev hash table. second system (on the same machine): luli-e@paziz:~> mount /dev/mapper/nvidia_fajhbfec_part2 on / type ext4 (rw,acl,user_xattr) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) devtmpfs on /dev type devtmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,mode=1777) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/sda8 on /boot type ext3 (rw,acl,user_xattr) /dev/mapper/nvidia_fajhbfec_part1 on /home type xfs (rw) fusectl on /sys/fs/fuse/connections type fusectl (rw) securityfs on /sys/kernel/security type securityfs (rw) none on /proc/fs/vmblock/mountPoint type vmblock (rw) exactly the same behavior. Hoever, if I edit /etc/init.d/boot.udev and change udev_timeout=180 to 5, I get this: [ 7.143457] ieee1394: Host added: ID:BUS[0-00:1023] GUID[cf0a00000000028d] [ 7.210243] ieee1394: Host added: ID:BUS[1-00:1023] GUID[001e8c000189e2ba] [ 12.835361] Adding 5245184k swap on /dev/sda6. Priority:-1 extents:1 across:5245184k [ 74.579268] device-mapper: ioctl: device doesn't appear to be in the dev hash table. [ 74.932999] loop: module loaded here the 60 sec time out is due to boot.lvm I have to emphsize that this does not happen on every machine. In another machine using similiar but different motherboard and cpu, booy-up is smooth. After upgrading to openSUSE-11.3 RC2 if got a very similar problem to Martin (comment 89), see bug #620360. I tried to install newer device-mapper and udev packages from the Base:System repository as suggest in comment 96 from a LiveCD/chroot-environment without much success. Running "mkinitrd" in the chroot-env produces the following error: linux:/ # mkinitrd Perl-Bootloader: 2010-07-07 13:58:54 ERROR: UDEVMAPPING: dmdev /dev/dm-7 doesn't have defined DM_NAME in udev Perl-Bootloader: 2010-07-07 13:58:54 ERROR: UDEVMAPPING: dmdev /dev/dm-8 doesn't have defined DM_NAME in udev Perl-Bootloader: 2010-07-07 13:58:54 ERROR: UDEVMAPPING: dmdev /dev/dm-4 doesn't have defined DM_NAME in udev Perl-Bootloader: 2010-07-07 13:58:54 ERROR: UDEVMAPPING: dmdev /dev/dm-5 doesn't have defined DM_NAME in udev Perl-Bootloader: 2010-07-07 13:58:54 ERROR: UDEVMAPPING: dmdev /dev/dm-6 doesn't have defined DM_NAME in udev Perl-Bootloader: 2010-07-07 13:58:54 ERROR: UDEVMAPPING: dmdev /dev/dm-3 doesn't have defined DM_NAME in udev Perl-Bootloader: 2010-07-07 13:58:54 ERROR: UDEVMAPPING: dmdev /dev/dm-2 doesn't have defined DM_NAME in udev Perl-Bootloader: 2010-07-07 13:58:54 ERROR: UDEVMAPPING: dmdev /dev/dm-0 doesn't have defined DM_NAME in udev Perl-Bootloader: 2010-07-07 13:58:54 ERROR: UDEVMAPPING: dmdev /dev/dm-1 doesn't have defined DM_NAME in udev Perl-Bootloader: 2010-07-07 13:58:54 ERROR: Core::ReadFiles: Failed to open /boot/grub/menu.lst (In reply to comment #109) > After upgrading to openSUSE-11.3 RC2 if got a very similar problem to Martin > (comment 89), see bug #620360. > > I tried to install newer device-mapper and udev packages from the Base:System > repository as suggest in comment 96 from a LiveCD/chroot-environment without > much success. Running "mkinitrd" in the chroot-env produces the following > error: > > linux:/ # mkinitrd > Perl-Bootloader: 2010-07-07 13:58:54 ERROR: UDEVMAPPING: dmdev /dev/dm-7 > doesn't have defined DM_NAME in udev This is what the new udev package try to fix. As a workaround, you can try "udevadm trigger" before mkinitrd. Hope this helps. (In reply to comment #110) > (In reply to comment #109) > > After upgrading to openSUSE-11.3 RC2 if got a very similar problem to Martin > > (comment 89), see bug #620360. > > > > I tried to install newer device-mapper and udev packages from the Base:System > > repository as suggest in comment 96 from a LiveCD/chroot-environment without > > much success. Running "mkinitrd" in the chroot-env produces the following > > error: > > > > linux:/ # mkinitrd > > Perl-Bootloader: 2010-07-07 13:58:54 ERROR: UDEVMAPPING: dmdev /dev/dm-7 > > doesn't have defined DM_NAME in udev > This is what the new udev package try to fix. > As a workaround, you can try "udevadm trigger" before mkinitrd. > Hope this helps. Ok, I did 'udevadm trigger' several times, then 'mkinitrd', the Perl-Bootloader error message remains though... (In reply to comment #111) > Ok, I did 'udevadm trigger' several times, then 'mkinitrd', the Perl-Bootloader > error message remains though... Despite these errors it worked after reboot Same happen to me - upgrade from 11.2 to 11.3 RC1 During upgrade process with Live CD: - part1 of RAID is win7 and was not correctly detected by boot loader - failed to "format" existing "/" and swap directories from existing 11.2 installation (error -3030) - failed to copy installation files The tried online update (redirect repo's to 11.3 and "zypper dup" - run through quite fine - boot loader setup correctly After restart, Linux is not working anymore - RAID set "nvidia_iaaxxx" already active - RAID set "nvidia_iaaxxx" was not activated - waiting for "???-part6" of the RAID which is I believe the "/" directory - rudimentary bash environment available - RAID on Nvidia nforce chipset 570 (ca 2 yr old system) No attachment since Linux is not starting at all (wrote this from Win7 8-( correction of comment 113 I used 11.3 RC2 (In reply to comment #113) > Same happen to me > - upgrade from 11.2 to 11.3 RC1 > > During upgrade process with Live CD: > - part1 of RAID is win7 and was not correctly detected by boot loader > - failed to "format" existing "/" and swap directories from existing 11.2 > installation (error -3030) > - failed to copy installation files > > The tried online update (redirect repo's to 11.3 and "zypper dup" > - run through quite fine > - boot loader setup correctly > > After restart, Linux is not working anymore > - RAID set "nvidia_iaaxxx" already active > - RAID set "nvidia_iaaxxx" was not activated > - waiting for "???-part6" of the RAID which is I believe the "/" directory > - rudimentary bash environment available > - RAID on Nvidia nforce chipset 570 (ca 2 yr old system) > > No attachment since Linux is not starting at all (wrote this from Win7 8-( Hi Volker: This issue is fixed for GM. You may try the GM version of 11.3 with following steps: - Booting from 11.3 GM - Entering rescue mode - Install the latest device-mapper, udev into your 11.3 RC2 system - run 'mkinitrd' to refresh the initrd file to the latest - Reboot. Hope this help. Thanks. After some weeks of testing with udev-1.61 and device-mapper-1.02 from Base:System I can confirm that the issue seems to be fixed. Any chances that this is backported to 11.3 ? Think it has landed to 11.3. ;) Please feel free to reopen it if you have further concern. Thanks. This is an autogenerated message for OBS integration: This bug (598193) was mentioned in https://build.opensuse.org/request/show/42184 Factory / device-mapper |