Bugzilla – Bug 156774
Install needs to stop spinning CDROM
Last modified: 2006-04-26 17:35:47 UTC
On several machines I have done network installs on, the CD / DVD drive spins during the entire install. It should spin the drive while it is using it, but should not have need to access the drive after it is copying things from the network. The spinning continues after the installation, until the system is rebooted.
Strange. Does removing the media break anything?
Removing the media during the file copy does not break anything. I think that it's fine to remove the boot CD once YaST is running, although I haven't removed the CD until the partition format begins. Another note: a DVD install does stop the drive spinning once the rpm install is complete. It appears to be specific to network installations.
Please attach the yast logs of this installation (/var/log/YaST2/).
Created attachment 72629 [details] save_y2logs output This was taken after a fresh http install. The CD drive is still spinning. I ejected the CD about 75% way through the rpm install phase. It continued without issue. The system rebooted before configuring the network, root pw, etc; it booted off the CD initially, and without being touched, it continued to spin through the end of the install.
Are these machines you noticed this on of the same hardware configuration? Please attach `hwinfo --cdrom'.
Created attachment 72820 [details] hwinfo --cdrom from system similar to one I also did DVD install with The exact lab machine I used to do both the network and DVD installs is being used by someone else now, this is from similar hardware.
Created attachment 72821 [details] hwinfo --cdrom from a system that spins the cdrom This is from a system with that has the CD spinning issue , but I have not done the DVD install on.
I don't think this is hardware dependent - I did a network install in VMWare yesterday, and noticed that the virtual CDROM icon kept blinking every so often, indicating something was being accessed. But the install had no problems when I disconnected the virtual cdrom.
Let's start with the usual suspect: ZYPP.
Michael, can you reproduce this behaviour ? I've seen similar things triggered by HAL
I can try to reproduce this with Beta8 as soon as I install it, however I normally perform a SLP installation with the first CD or mini.iso to boot from and I didn't notice this so far - however I might have missed it.
OK, this seems to be an issue. I performed an SLP-installation and it stops spinning until udev is started. After that, it spins for about 3 minutes and shuts down again. So I could not reproduce this. However if it spins up during the installation, I will report it here. Seems not to be a problem with udev.
resolving as invalid since we cannot reproduce it - I haven't seen it myself either.
Reopening per opensuse-factory mailing list thread, "SUSE install constant CD polling", dated 6 Apr 2006. http://lists.opensuse.org/archive/opensuse-factory/2006-Apr/0126.html From thread: >> Last night I was installing 10.1beta9 under VMware, and I had to leave >> the room on the "Language" screen. When I came back, I noticed that it >> coninuously polls for something on the CD.
Media handling ? HAL in vmware environment ? Marius, please have a look
This happens with RC1. I did a CD install, after it was finished with CD5, it keeps spinning it through the network config, registration, etc.
If I install from the network and the vm has also a physical cdrom drive connected to it also flashes the cdrom icon, although the cdrom drive try is open all the time.
AFAIK VMware flashes the icon if the OS attempts to access the CD rom virtual device (either if it's physical or not). In my tests, the virtual CD rom pointed to SUSE ISO file. OTOH, I also tried installing IPCop, Asterisk@Home and Ubuntu on the same VMware server, and none of them flashed the CD rom icon while idle, as SUSE install does.
It's not vmware specific. It happens with physical CDROM drives... You can hear them spinning long after they're not needed. When you take the CD out, it's hot still, when it should have cooled down if it was no longer being accessed. Not that it matters, as this is currently a "WONTFIX".