http://bugzilla.novell.com/show_bug.cgi?id=570541 http://bugzilla.novell.com/show_bug.cgi?id=570541#c0 Summary: YaST2 gets confused about multiple CD drives Classification: openSUSE Product: openSUSE 11.2 Version: Final Platform: x86-64 OS/Version: openSUSE 11.2 Status: NEW Severity: Normal Priority: P5 - None Component: AutoYaST AssignedTo: ug@novell.com ReportedBy: jkwan@vmware.com QAContact: qa@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.6) Gecko/20091216 Iceweasel/3.5.6 (like Firefox/3.5.6; Debian-3.5.6-1) My goal is to be able to perform a fully unattended install of openSUSE that does NOT require: - tftp/network server to store config file - remaster of pristine openSUSE installation medium using mkisofs This installation procedure would occur on a VMware virtual machine. My solution thus far (and one that works without much difficulty on Anaconda-based installers as well as Ubuntu) is to do this: - Scan the installation medium for kernel and ramdisk. - Build a new boot ISO using said kernel and ramdisk and copy the isolinux options to the new CD. At this time extra options will be prepended, such as 'autoyast=device://sr0/autoinst.xml'. - Boot the system with the following drive layout: * CD drive /dev/sr0: custom boot CD * CD drive /dev/sr1: pristine openSUSE ISO This way, we can boot from the CD with custom options and chain it into the install medium provided that the initrd is smart enough to scan each device before giving up. (Which is indeed the case for openSUSE right now.) Unfortunately it doesn't quite work this way right now, for some reason when autoinst.xml is on sr0 YaST blows up. For now I'm generating a floppy image that contains the autoinst.xml to work around this. So, the kernel command-line options I'm using right now: autoyast=device://fd0/autoinst.xml install=cd:/?devices=/dev/sr1 This works up to a point: - kernel boots and initrd launches linuxrc - linuxrc preloads the installation system successfully off /dev/sr1 - YaST2 begins and reads the autoinst.xml off the floppy Then, I get this: "Insert 'cd-XXXXXXXX (Disc 1)'" (with abort/retry/fail buttons) where XXXXXXXX is a seemingly random 8-byte checksum. If I choose Details, the URL that it tried was 'cd:///' (not the cd:/?devices=/dev/sr1 that I specified in the kernel command line.) Looking at y2log, it seems to just choose the first CD device and mount it and ignores the rest. This is the same behavior that has existed since at least openSUSE 10.0 or so. But sometimes, it does work - and looking in y2log, it looks like that is because a udev/HAL race condition makes it so that the CD devices are swapped and the first one that YaST2 tries happens to be the correct disk. The resolution I would like to expect from this bug is that it becomes clear how to define that the installation medium is present on sr1 OR that the cd:/// protocol is fixed so that it properly scans all devices instead of just the first one. And for now, I would love to hear any ideas for workarounds! Reproducible: Sometimes Steps to Reproduce: This could probably be reproduced with other virtualization software. 1. Create a VM with empty hard disk and TWO CD drives and a floppy drive. 2. To the first one, bind autoinst.iso (attached; please decompress first) 3. To the second one, bind openSUSE-11.2 DVD ISO. 4. To the floppy drive, bind autoinst.flp (attached; please decompress first) 5. Boot the virtual machine. Actual Results: Sometimes it will get to the final "Installation Settings" page, ready to install; sometimes, it will not, and halt with the 'Insert disc 1' error. Expected Results: It should reliably a) use settings from kernel command line and NOT probe /dev/sr0 at all, or b) the 'cd:///' default behavior should be fixed to probe ALL drives instead of just one. I'm sure you would love it if this bug is fixed, because that will allow users of VMware to more easily set up an openSUSE VM. Currently the fully unattended installation procedure is already functional for Ubuntu and RHEL/Fedora/CentOS/etc. using the same mechanism i've described. The only major distro not included is SuSE because of this bug and it has been this way for over a year now. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.