Bug 1084357 - linuxrc fails to find the cdrom symlinks in /dev/disk/by-* with udev v237
linuxrc fails to find the cdrom symlinks in /dev/disk/by-* with udev v237
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Steffen Winterfeldt
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-03-07 17:53 UTC by Franck Bui
Modified: 2018-03-09 09:51 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Franck Bui 2018-03-07 17:53:10 UTC
It happens only with qemu started like QA does:

> /usr/bin/qemu-system-x86_64 -serial file:serial0 -soundhw ac97 -vga cirrus -global isa-fdc.driveA= -m 1024 -cpu qemu64 -netdev user,id=qanet0 -device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 -device virtio-scsi-pci,id=scsi0 -device virtio-blk,drive=hd1,serial=1 -drive file=disk.img,cache=unsafe,if=none,id=hd1,format=qcow2,discard=on -drive media=cdrom,if=none,id=cd0,format=raw,file=/home/fbui/tmp/iso/openSUSE-Staging_N-Staging-DVD-x86_64-Build215.2-Media.iso -device scsi-cd,drive=cd0,bus=scsi0.0 -boot once=d,menu=on,splash-time=5000 -device usb-ehci -device usb-tablet -smp 1 -enable-kvm -no-shutdown -device virtio-serial -chardev socket,path=virtio_console,server,nowait,id=virtio_console,logfile=virtio_console.log -device virtconsole,chardev=virtio_console,name=org.openqa.console.virtio_console

If the more usual --cdrom option is used for creating the cdrom device then there's no issue.

Here are the details:

--- %< ----
update_device_list(1)
scanning devices
Downloading AutoYaST file: disk:/autoinst.xml?device=*label/OEMDRV&quiet=1
update_device_list(0)
rescanning devices
device not found (err = 0): *label/OEMDRV
url mount: trying disk:/?device=*label/OEMDRV (path = /)
url_setup_device: disk:/?device=*label/OEMDRV
Failed to download AutoYaST file.
dud url: disk:/?device=*usb*&all=1&quiet=1
Reading driver update: disk:/?device=*usb*&all=1&quiet=1
update_device_list(0)
rescanning devices
device not found (err = 0): *usb*
url mount: trying disk:/?device=*usb* (path = /)
url_setup_device: disk:/?device=*usb*
dud url: disk:/?device=*label/OEMDRV&quiet=1
Reading driver update: disk:/?device=*label/OEMDRV&quiet=1
update_device_list(0)
rescanning devices
device not found (err = 0): *label/OEMDRV
url mount: trying disk:/?device=*label/OEMDRV (path = /)
url_setup_device: disk:/?device=*label/OEMDRV
repository: looking for cd:/
update_device_list(0)
rescanning devices
device not found (err = 0): 
repository: not found
no openSUSE Tumbleweed repository found
repository: looking for hd:/
update_device_list(0)
rescanning devices
url mount: trying hd:/?device=disk/by-id/virtio-1 (path = /)
(Disk)
url_setup_device: hd:/?device=disk/by-id/virtio-1
device not found (err = 1): 
repository: not found
no openSUSE Tumbleweed repository found
--- >% ---

I'm not sure how the list of symlinks paths used to find the ISO was generated but it looks pretty weird.

Also I don't know if it's actually used since it doesn't match any symlink even in the working case (when --cdrom is passed).

After booting the rescue system, I can see the following symlinks:

ttyS0:rescue:~ # find /dev/disk
/dev/disk
/dev/disk/by-uuid
/dev/disk/by-uuid/2018-03-07-03-03-54-00
/dev/disk/by-path
/dev/disk/by-path/pci-0000:00:04.0-scsi-0:0:0:0
/dev/disk/by-label
/dev/disk/by-label/Test-Build215.2
/dev/disk/by-id
/dev/disk/by-id/scsi-0QEMU_QEMU_CD-ROM_cd0
Comment 1 Franck Bui 2018-03-07 17:55:35 UTC
Steffen could you give some help here ?

How the ISO is supposed to be found ?

Thanks.
Comment 2 Steffen Winterfeldt 2018-03-08 10:14:23 UTC
I don't understand the question. I construct all my qemu vms in a similar way and didn't see any problems testing the installer so far.

Technically, linuxrc looks for the cd drive with the repo and passes the link to the installer.
Comment 3 Franck Bui 2018-03-08 10:21:12 UTC
(In reply to Steffen Winterfeldt from comment #2)
> 
> Technically, linuxrc looks for the cd drive with the repo and passes the
> link to the installer.

According to the linuxrc logs in comment #0, the symlink doesn't exist in the environment used by the installer, right ?

How can I see the symlink found by linuxrc and passed to the installer ?
Comment 4 Steffen Winterfeldt 2018-03-08 10:53:59 UTC
According to the log in comment 0 there is no cd and you cannot start yast.

But below you are able to run the rescue system so there of course _is_ a cd, else you couldn't have started it.

That's why I don't know what you are aiming at.

In general, if the installer was found and you want to know what device is used, boot with 'startshell=1' and check the 'zypprepourl' entry in /etc/install.inf. To continue the install just exit the shell.
Comment 5 Franck Bui 2018-03-08 14:54:23 UTC
Ok I badly described the issue I think, sorry for the confusion: I think now that it's linuxrc which fails to find the cdrom device.

Linuxrc pops up the following message: "To use the selected repository a matching boot image is needed. Download it now and restart?"

Could you help to figure out why ?

Just in case you want to reproduce, you can download the ISO here: https://openqa.opensuse.org/tests/627783/asset/iso/openSUSE-Staging:N-Staging-DVD-x86_64-Build215.2-Media.iso

Thanks
Comment 6 Steffen Winterfeldt 2018-03-08 16:16:57 UTC
That popup is just a sign in this case that it didn't find the cd.

This staging n image looks badly broken. Modules are not loaded correctly by udev. The first sign is that the drm video modules are not loaded and it stays at vga resolution.

You can start with manual=1 and then on console 9 look around. Looks rather desolate.
Comment 7 Franck Bui 2018-03-09 07:36:07 UTC
I finally found it.

The udev rule that takes care of loading drivers have been changed: the drivers are loaded on "add" event type only. Previously it was done on any types but "remove", see commit 9b32afa9f241fe8febc0a754850f1e7331caf6e3 for details.

However /scripts/udev_setup (re)triggers device events by using "udevadm trigger". Since the type of event is not specified, "change" type is assumed.

This prevents most of all modules from being loaded hence the issues we're facing.

So I would suggest to fix /scripts/udev_setup and make sure "--action=add" option is passed to "udevadm trigger", since it's really the type that should be used.

Steffen can you take care of this ?

Thanks
Comment 8 Steffen Winterfeldt 2018-03-09 09:15:57 UTC
Like this:?

https://github.com/openSUSE/installation-images/pull/235
Comment 9 Franck Bui 2018-03-09 09:18:24 UTC
(In reply to Steffen Winterfeldt from comment #8)
> Like this:?
> 
> https://github.com/openSUSE/installation-images/pull/235

yes or maybe you can do what systemd-udev-trigger.service does:

$ systemctl cat systemd-udev-trigger.service 
# /usr/lib/systemd/system/systemd-udev-trigger.service
[...]
ExecStart=/usr/bin/udevadm trigger --type=subsystems --action=add ; /usr/bin/udevadm trigger --type=device
Comment 10 Steffen Winterfeldt 2018-03-09 09:29:20 UTC
fine with me; pr adjusted
Comment 11 Franck Bui 2018-03-09 09:32:31 UTC
as commented on github, you forgot --action=add on the second call.
Comment 12 Steffen Winterfeldt 2018-03-09 09:40:43 UTC
I trusted you cut&paste in comment 9

Anyway - ok now?
Comment 13 Franck Bui 2018-03-09 09:46:08 UTC
it looks ok now. Thanks.
Comment 14 Steffen Winterfeldt 2018-03-09 09:51:42 UTC
submitted