|
Bugzilla – Full Text Bug Listing |
| Summary: | Installation hangs if / is a md-device. | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Manfred Hollstein <mh> |
| Component: | Installation | Assignee: | Neil Brown <nfbrown> |
| Status: | RESOLVED DUPLICATE | QA Contact: | Klaus Kämpf <kkaempf> |
| Severity: | Blocker | ||
| Priority: | P5 - None | CC: | aj, marc.ruehrschneck, mge, Raghavendra_Biligiri, suse-beta, wwlinuxengineering |
| Version: | Beta 8 | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | YaST2 logfiles including generated /etc/fstab | ||
|
Description
Manfred Hollstein
2006-03-16 17:54:30 UTC
Hmm, this is reproduceable on my system; just started a second try and it hangs at exactly the same step. Here some further details: Booting from Beta8-mini.iso Choose http://172.31.17.252/install/sl-10.1/os as install-source Network is fully functional, can ping the server and running "wget http://172.31.17.252/install/sl-10.1/os" creates a directory listing as index.html. I tried to upload a compressed archive of /var/log/YaST2, but that was too big and got rejected by the bugzilla server. (In reply to comment #1) > I tried to upload a compressed archive of /var/log/YaST2, but that was too > big and got rejected by the bugzilla server. Try re-compressing it with bzip2 instead of gzip. If it's still > 5 MB: Do you have some webspace where you could upload it? If yes, post the URL here. OK, I cannot install at all, therefore I'm raising the severity of this report. I'll upload the log files to some webspace as Christian suggested, and post the URL once it's done. Created attachment 73648 [details]
YaST2 logfiles including generated /etc/fstab
Logfiles from the third installation attempt, this time with the generated /etc/fstab file included. Note, that I accepted almost all (just not the proposed partitioning) proposals this time, so it is a pretty standard installation now.
Same happens for an x86_64 installation. As I had been able to upload the smaller logfiles from the default installation, I'm not going to post any URL anymore (in case you're lurking...). Update: I tried to install from a DVD9 media, but this one failed as well. Next attempt was to install it in a VMware session, and this one got over the critical point. One of the differences between the virtual machine and my real system is, that the real system only uses existing /dev/mdX devices configured as RAID1 on SATA2 disks, while the virtual machine uses a single SCSI device. Maybe the installer/partitioner has problems with (existing) soft-RAID MD devices?
Anyway, here is my setup (should be obvious from the logs):
/ /dev/md12 (/dev/sd{a,b}12) ext3
/boot /dev/md3 (/dev/sd{a,b}8) ext2
GRUB is installed in /dev/md3, the MBR is not touched.
Update 2: Installed on the original hardware again, this time using the single devices, ie. /dev/sda8 for /boot and /dev/sda12 for /, and it happily continued and started the package installation. So, my suspicion was right: the current installer/partitioner does not work in setups with soft-raid devices involved. Last log entry is: librpmDb.cc(globalInit):142 librpm init done So this seems to be a problem with package installation, not with yast2-storage. I can remember there were once problems with libdb and access to media with nonstandard sector sizes. Maybe this is something similar. To narrow down the potential source(s) of this problem, please keep in mind that this is new since Beta8 and worked before, ie. Beta7! *** Bug 159326 has been marked as a duplicate of this bug. *** *** Bug 160534 has been marked as a duplicate of this bug. *** *** This bug has been marked as a duplicate of 159435 *** |