|
Bugzilla – Full Text Bug Listing |
| Summary: | GRUB | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Lanfranco Gandolfo <gandolfo17> |
| Component: | Installation | Assignee: | Jiri Srain <jsrain> |
| Status: | RESOLVED FIXED | QA Contact: | Klaus Kämpf <kkaempf> |
| Severity: | Major | ||
| Priority: | P5 - None | ||
| Version: | Beta 3 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | yast2 logs | ||
|
Description
Lanfranco Gandolfo
2005-08-27 16:59:30 UTC
More info. I use a commercial Boot Manager, Acronis OS Selector, but I had never experienced anything like the above. could you please provide more information? fdisk -l y2logs: http://www.opensuse.org/index.php/Bug_Reporting_FAQ#YaST fdisk -l: Disk /dev/hda: 163.9 GB, 163928604672 bytes 255 heads, 63 sectors/track, 19929 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 6638 53319703+ 7 HPFS/NTFS /dev/hda2 6639 9379 22017082+ 83 Linux /dev/hda3 9380 19929 84742875 f W95 Ext'd (LBA) /dev/hda5 9380 9383 32098+ 4 FAT16 <32M /dev/hda6 9384 9484 811251 82 Linux swap / Solaris /dev/hda7 9485 14053 36700461 83 Linux /dev/hda8 14054 19929 47198938+ 83 Linux Disk /dev/hdb: 82.3 GB, 82348277760 bytes 255 heads, 63 sectors/track, 10011 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdb1 * 1 3901 31334751 7 HPFS/NTFS /dev/hdb2 5221 10011 38483707 83 Linux /dev/hdb3 3902 5220 10594867+ c W95 FAT32 (LBA) Partition table entries are not in disk order __________________________________________________________________________ Please notice that this was done from /dev/hda8 (not the SUSE partition) please provide y2logs http://www.opensuse.org/index.php/Bug_Reporting_FAQ#YaST Created attachment 48313 [details]
yast2 logs
(In reply to comment #5) > Created an attachment (id=48313) [edit] > yast2 logs > Thanks According to the logs, you set loader to be installed to /dev/hda8. It also looks like you first modified bootloader installation and then partitioning (which is obviously not good idea). Sorry, but can't help you here... Well, what I modified was the default partitioning suggested by YaST. What I still can't understand is why /dev/hda7 was made (and still is) also bootable. Besides YaST is the only installer to my knowledge which sets a default partitioning. It doesn't look like a good idea to me. Thanks anyway. And besides, shouldn't *all* the changes be committed only *after* you are ready with all your choices? YaST always installs GRUB also to boot sector of the partition holding /boot. This is useful as backup. I can accept the request to be able to switch it of as an enhancement for next version. Don't understand your last comment, bootloader settings are stored just before 1st reboot... "Don't understand your last comment, bootloader settings are stored just before 1st reboot... " What I mean is that I made all my changes in the main installation dialog, then I hit "I accept". I didn't change anything after that. So I can't understand were was the mistake from my part. And certainly it wasn't the first time I installed SUSE or other operating systems of all kind. In the original proposal, SL was proposed to be installed to /dev/hda8 as root partition. Then you entered bootloader configuration and set bootloader to be installed to /dev/hda8. After that, you changed to install SL to /dev/hda7. But since the bootloader location was already changed by you and you set the "custom" location (as in usual cases - SL + Win - you cannot boot from logical volume, /boot or / (root) are not offered in this case), YaST agreed it was your decission and didn't change it. Thus the behavior is correct. It is always better first set the final disk partitioning and then configure bootloader. GRUB and LILO are (as backup copy) always installed to the bootsector of the partition holding /boot directory (provided it is possible). That's why both /dev/hda7 and /dev/hda8 are working. I hope this explanation is sufficient... It has happened again. It has made my main OS on /dev/hda8 unbootable again. I am furious. And please DON'T TELL ME THAT IT WAS MY FAULT, because I DIDN'T TOUCH GRUB AT ALL. I only upgraded beta3 to RC1, and Grub wasn't mentioned anywhere. And logs from the update? I am sorry, it is too late now for the logs. I waited a couple of weeks for a reply, but eventually I wiped SUSE 10 RC1 from my HD. Sorry for the delay, which was caused by my vacation. There was a bug which occurred during update and which caused installation of bootloader to different location, this might be a duplicate, byt I'm not sure. Are you able to reprodce the bug with master? Solved in GM 10.0 |