Bugzilla – Bug 132296
Installation from DVD fails after initial boot
Last modified: 2006-07-24 09:12:59 UTC
I have a working Suse 9.2 on /dev/hdb2. I started the installation of Suse 10.0 on /dev/hda2. Installation works fine until the initial reboot. YaST (?) doesn't find the flag to resume installation. But when I boot my old 9.2, suddenly the resume flag is found. MAJOR or even CRITICAL, as it could have destroyed my working installation.
Please, describe the problem more. What happened after the reboot exactly? Did the installation start? Did you suspended 9.2 system into disk before starting the installation? PLease, attach y2logs from 10.0 system (see http://www.opensuse.org/Bug_Reporting_FAQ#YaST)
Created attachment 57051 [details] YaST2 logs of Installation
More detailed: I did NOT suspend to disk before. I started a fresh new installation (suse10.0) on /dev/hda2 from dvd. It worked fine, including the reformatting of the partition, the hardware detection, the installation of the selected software. It also worked fine, as into the new grub entry my old suse 9.2 installation on /dev/hdb2 was included. After installation of rpm-packages, the newly installed system is booted. And usually, after this initial boot from harddisk a resume flag is found - but this wasn't found with the 10.0 installation, but on my old system (9.2), later. The state of the system after the faulty reboot: not root account, no users defined. No complete installation, in a word. The resume flag was found, and the demand for a root password came, when I booted my old suse 9.2. I ignored the messages about an incomplete installation, and I guess, any other reaction could even have spoiled my old working installation. So it's between major and critical, imho. ( Meanwhile, I did install suse 10.0, using a screwdriver; but that's an other story. )
Jiri, please have a look at the workflow.
I have no clue what causes this problem. The system has been switched to /mnt before reboot, the file name to write as the flag is in fact hardcoded. Are you able to reproduce the problem? How are the mount points set just before reboot (during the countdown)?
No feedback, thus resolving as INVALID. Please, reopen if you can reproduce the bug on final version with all patches applied (and attach new logs).