Bug 100728

Summary: installation to second disk can make system unbootable
Product: [openSUSE] SUSE LINUX 10.0 Reporter: Forgotten User ZhJd0F0L3x <forgotten_ZhJd0F0L3x>
Component: InstallationAssignee: Jiri Srain <jsrain>
Status: RESOLVED FIXED QA Contact: Klaus Kämpf <kkaempf>
Severity: Blocker    
Priority: P5 - None CC: duwe, forgotten_OS1JNCFbCX, linuxblacksmith
Version: Preview 4   
Target Milestone: ---   
Hardware: Other   
OS: All   
Whiteboard:
Found By: Component Test Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Bug Depends on:    
Bug Blocks: 97395    

Description Forgotten User ZhJd0F0L3x 2005-08-04 14:25:11 UTC
This machine had
- windows xp
- suse 9.3
- suse 10.0pre3
on its internal SATA (/dev/sda) harddrive. Everything worked well.

Now i installed 10.0pre4 onto an external USB harddrive (/dev/sdb). I selected
to install grub onto /dev/sdb2 (root partition, sdb1 is swap). After the first
part of the installation, it rebooted but not into the second part but into
windows. Also, there is now no longer a boot menu on this machine, only windows.

The USB drive is connected to fix.suse.de now, mountpoint /media/10_0preview4/,
so you can salvage all the logs you might need to investigate this.
Comment 1 Jiri Srain 2005-08-08 09:30:27 UTC
Sorry, medium not found, can't get the logs. 
 
But, it is obvious that if you install GRUB into /dev/sdb2, it won't be 
loaded. It could work only if you 
- replaced MBR with generic code which loads the boot sector 
- activated the partition (both can be set via YaST) 
- your BIOS supports booting from USB 
 
If any of these conditions is not fullfilled, the system cannot boot. 
 
Did you set the boot loader location manually, or was it proposed? Could I get 
the logs somehow (/var/log/YaST2/*)? 
Comment 2 Forgotten User ZhJd0F0L3x 2005-08-08 14:24:02 UTC
somebody switched of the drive => switched on again and working.
I _think_ i did set the boot loader location manually, and told YaST not to
touch the builtin disk but you better check the logs.

The BIOS can boot from USB (e.g. USB-CD), but i do not know what needs to be on
the disk to make the BIOS boot from it.

Apparently the MBR on the internal drive was replaced since i no longer can boot
anything but windows there.
Comment 3 Jiri Srain 2005-08-08 15:23:11 UTC
The problem is that YaST actualized the code in MBR of /dev/sda, not sdb,  
which is obviously wrong in this case.  
  
It sounds to me that I should change the behavior to update MBR of the disk  
bootloader is installed to. Other way might be to let user specify which MBR  
to update. Torsten, what do you think? Does it make sense? 
  
The other problem is that with your configuration, the system wouldn't boot 
anyway. You would have to change the disks order (device map), as once you set 
BIOS to boot from USB, USB will be disk 0x80. And once you modify the device 
map, the MBR to be rewritten will be MBR on /dev/sdb -> you will get correct 
configuration. 
Comment 4 Torsten Duwe 2005-08-08 17:28:00 UTC
*** Bug 102292 has been marked as a duplicate of this bug. ***
Comment 5 Torsten Duwe 2005-08-08 17:36:42 UTC
In my first "spare the MBR" mail I wrote:  
if (installation to "/" or "/boot" into primary part. of 1st disk) {  
  
I should refine this to say "primary partition of first boot disk".  
 
I have now seen it at least twice here that the installation goes to a 
partition not on the first boot disk, but the MBR of the first boot disk is 
updated with generic code nonetheless. This is causing the trouble we see. 
 
So, do only update the MBR with generic code when the installation's "/" 
or /boot is on one of its primary partitions (quite common if you only have 1 
disk ;-) 
Comment 6 Jiri Srain 2005-08-09 08:11:52 UTC
Well, but this doesn't solve Stefan's problem (the disk can be disconnected 
leaving the machine unbootable). But I will change the behavior to install to 
bootsector only if the /boot partition is is on 1st disk. 
Comment 7 Jiri Srain 2005-08-09 08:18:44 UTC
Done in SVN, will submit for Beta2. 
Comment 8 Jiri Srain 2005-08-09 13:11:10 UTC
*** Bug 103011 has been marked as a duplicate of this bug. ***