Bug 881969

Created attachment 654558 [details]
File: anaconda-tb

Created attachment 654559 [details]
File: product

Created attachment 654560 [details]
File: type

Created attachment 654561 [details]
File: ifcfg.log

Created attachment 654562 [details]
File: storage.log

Created attachment 654563 [details]
File: version

Created attachment 654564 [details]
File: environ

Created attachment 654565 [details]
File: executable

Created attachment 654566 [details]
File: anaconda.log

Created attachment 654567 [details]
File: syslog

Created attachment 654568 [details]
File: hashmarkername

Created attachment 654569 [details]
File: packaging.log

Created attachment 654570 [details]
File: cmdline_file

Created attachment 654571 [details]
File: release

Created attachment 654572 [details]
File: program.log

For whatever reason, your /dev/sr1 device does not get an ID_FS_TYPE entry in its udev data, so anaconda doesn't know what it is.

*** Bug 877667 has been marked as a duplicate of this bug. ***

what is the output of:

# /lib/udev/cdrom_id --debug /dev/sr1

with the "IPMI virtual media" inserted?

Created attachment 657006 [details]
Output of /lib/udev/cdrom_id --debug /dev/sr1

Attached along with is the output of "/lib/udev/cdrom_id --debug /dev/sr1" as requested

Any thoughts/work around for this issue? I am willing to test out any patches or look at installer code if you can point me to the right place in code. Thanks

Well, seems like the "IPMI virtual media" emulation of the cdrom does not support a lot of standard SCSI IO commands. Not much we can do here. Fix the emulator or add some "quirks", which we already have.

What is the output of:

# blkid --noraid -o udev -p /dev/sr1

Created attachment 666412 [details]
Output of blkid -o udev -p /dev/sr1

Running "blkid" with "--noraid" option did not work.

I removed the --noraid and ran it. The output is attached.

From the output looks like it has the "ID_FS_TYPE" field present. 

Also this box is couple of years old and all earlier Fedora releases have worked with its IPMI virtual media.

ok, one last command:

# udevadm info /dev/sr1

Created attachment 666819 [details]
Output of udevadm info /dev/sr1

Thanks for your help so far.

ok, the udev rules are:

# probe filesystem metadata of optical drives which have a media inserted
KERNEL=="sr*", ENV{DISK_EJECT_REQUEST}!="?*", \
  ENV{ID_CDROM_MEDIA_TRACK_COUNT_DATA}=="?*", \
  ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}=="?*", \
  IMPORT{builtin}="blkid --offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}"

# single-session CDs do not have ID_CDROM_MEDIA_SESSION_LAST_OFFSET
KERNEL=="sr*", ENV{DISK_EJECT_REQUEST}!="?*", \
  ENV{ID_CDROM_MEDIA_TRACK_COUNT_DATA}=="?*", \
  ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}=="", \
  IMPORT{builtin}="blkid --noraid"


So, the culprit here is the missing ID_CDROM_MEDIA_TRACK_COUNT_DATA

As we can see in the cdrom_id output, the virtual cdrom does not emulate all functions a real cdrom has. Therefore ID_CDROM_MEDIA_TRACK_COUNT_DATA is unset.

We probably have to add more quirks here.

Following your post I attempted trying to modify /usr/lib/udev/rules.d/60-persistent-storage.rules. I modified this file and removed the line

ENV{ID_CDROM_MEDIA_TRACK_COUNT_DATA}=="?*", \
(only for the # single-session CDs do not have ID_CDROM_MEDIA_SESSION_LAST_OFFSET case)

I did this by opening up initrd.img, modifying the rules file and then rebuilding the initrd.img.

I found upon reboot my change is lost i.e. something overwrites the files during bootup. I did notice the line

"# do not edit this file, it will be overwritten on update" in /usr/lib/udev/rules.d/60-persistent-storage.rules, so I guess I cannot expect my changes to be present.

What is the proper way to modify /usr/lib/udev/rules.d/60-persistent-storage.rules such that I can try the above workaround?

Came across some discussion on this issue and the above workaround was suggested here
https://bugs.freedesktop.org/show_bug.cgi?id=52474

boot with "rd.break=pre-udev" added to the kernel command line

# vi /usr/lib/udev/rules.d/60-persistent-storage.rules
# exit

Created attachment 686980 [details]
rd.break=pre-udev

Thanks for the parameter.

I followed the steps and edited /usr/lib/udev/rule.d/60-persistent-storage.rules.
Then typed exit.

After that the box continued booting until it dropped me to the "switch_root" prompt (see attached screenshot). At the prompt I verified the 60-persistent-storage.rules had my changes. I typed exit again and it brought the installer graphical UI.

However after that it gave me the same error. I switched to the terminal and checked the 60-persistent-storage.rules and I did *not* see my changes. In summary the changes were lost, they were present until I typed exit at "switch root" prompt.

(In reply to comment #28)
> Created attachment 686980 [details]
> rd.break=pre-udev
> 
> Thanks for the parameter.
> 
> I followed the steps and edited
> /usr/lib/udev/rule.d/60-persistent-storage.rules.
> Then typed exit.
> 
> After that the box continued booting until it dropped me to the
> "switch_root" prompt (see attached screenshot). At the prompt I verified the
> 60-persistent-storage.rules had my changes. I typed exit again and it
> brought the installer graphical UI.
> 
> However after that it gave me the same error. I switched to the terminal and
> checked the 60-persistent-storage.rules and I did *not* see my changes. In
> summary the changes were lost, they were present until I typed exit at
> "switch root" prompt.

yes, the changes you make in the initramfs do not have any effect on the real root where the installer lives.

You can however do:

pre-root break:
edit /usr/lib/udev/rule.d/60-persistent-storage.rules
exit

switch-root break:
edit /sysroot/usr/lib/udev/rule.d/60-persistent-storage.rules
maybe mount writeable before with "mount -oremount,rw /sysroot"
exit

/sysroot is the real root in the initramfs switch-root stage

Thanks Harald. Modifying /sysroot/usr/lib/udev/rule.d/60-persitent-storage.rules worked. 

I also had to modify /sysroot/usr/lib/udev/rules.d/42-usb-hid-pm.rules 
I had to comment out entry for 046B i.e. supermicro IPMI. Doing so kept the mouse and keyboard alive, otherwise I was without it in the installer GUI.

After these two manual changes I could install Fedora 18. Sorry could not test it out earlier and let you know.

I now need to make these changes in the installer so that it can happen automatically. I looked at the initrd and anaconda sources, but could not trace where these files get generated. Do you have any pointers regarding where I should focus. Thanks for your help so far.

You might also change the kernel command line parameter:

inst.stage2=hd:LABEL=....

to

inst.stage2=hd:/dev/sr0


I also "fixed" cdrom_id:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=a0ec302b9309bc56f6bed6162e47ad6c27165747

Yes I have been changing inst.stage2 to hd:/dev/sr1 (my hardware has both physical dvd(sr0) and virtual dvd(sr1). Is the non detection of LABEL also due to bad virtual CD emulation? Wonder if there is a way around it, otherwise I will need two ISO's, i.e. one for physical media and one for virtual media with different isolinux.cfgs.

Also I figured out how to make the udev rules stick by adding following to “bin/dracut-pre-pivot” 

+sed -i 's/ENV{ID_CDROM_MEDIA_TRACK_COUNT_DATA}=="?\*",//' /sysroot/usr/lib/udev/rules.d/60-persistent-storage.rules
+sed -i 's/046b/BEEF/' /sysroot/usr/lib/udev/rules.d/42-usb-hid-pm.rules

getarg 'rd.break=pre-pivot' 'rdbreak=pre-pivot' && emergency_shell -n pre-pivot "Break pre-pivot"
source_hook pre-pivot
 
I like how modular dracut is compared to the older monolithic initrd. Like how you can break into various stages of booting.

Thanks for the systemd change you made.

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.