Bug 181571

Created attachment 87033 [details]
log.tar.bz2 - the hole /var/log as bar.bz2 archive

I have a similar problem to the bug indicated. I have another linux system on /sda, and I needed to install the road show Eval cd's onto /hda alone in isolation.   The first time I did it, a week ago, I thought I made an error, because, even though I insisted via expert mode, to not use /sda.  The installer overwrote directories and files on that drive.  It took 10 hours to recover.

Subsequent to the road show, I was more cautious. Again, unchecking the option to use /sda via expert mode, and checking the displays showed that it was going to overwrite the other disk. There did not appear to be a method to exclude a drive.  The word delete was frightening, and perhaps should be replaced by "remove". I did not try to find out if it should be remove. 

In order to install the evaluation product safely, I had to open the case and unplug the /sda drive. 

This is a very dangerous bug and must be fixed. Hard disks are getting very inexpensive and many systems currently have multiple drives installed. One cannot have Yast writing files where it wants.

-> Leslie:

This bug is about the Boot loader written to a bad place, not about lost data in the partitions. So lowering priority back.

Created attachment 100895 [details]
YaST2.tar.bz2 - the hole /var/log/YaST2 as tar.bz2 archive

The badly written boot loader is a problem that I could now reproduce on another computer. Having yet installed an 10.1. Now installing second (independend) 10.1 from CD. Choosing /dev/hda3 as location for the bootloader (I want to leave the MBR as is and make with the old suse 10.1 an entry there for starting the partition hda3). But the boot loader gets written to MBR.

This bug is an install stopper. BUG BUG BUG

SUSE10.x installer, not only did it merge files to the disk(/dev/sda) that was unchecked/unselected to exclude it in the install process, but the install program formatted the /dev/sda boot and swap partitions, destroying the data that was there and assigning SUSE10 files to them. How was I to later remove that drive? Will the boot and swap files magically appear on the /dev/hda? 

I suppose that if there are systems with only 1 linux system on 1 hard disk, as opposed to 2 linux versions resident on 2 hard disks, with the safety copy to be migrated to SUSE10 after a successful SUSE10 install, that the bug is inconsequential if the partition is reformatted. 

But to overwrite a disk that was to be removed after a successful migration to SUSE10.x is a Major critical bug.

I went back to Fedora Core 5, I redid the install with it to the damaged disk. Their installer program respected the unchecking of the /dev/hda SUSIE10 install and I rebuilt that system that I lost  (on /dev/sda). It only took overnight. 

I was able to do the install safely, only by physically unplugging the /dev/sda cable from the mother board, and then installing SUSE10.x.  

In our park of many hundreds of PC's, not all have more than one hard disk, but there are some that do.  

Again, if Fedora Core5 (rpm based system) can a parallel install correctly, then so SUSE10.x should do so too.

If you feel I am out of line, then leave the problem level as is, and let Bugzilla send me a advice when the install process is repaired. I will then re-evaluate SUSE10.x+1 which will of course require a new install dvd.

-> Leslie:

Hm. I don't say that your problem isn't a bug or that it isn't important. But it is a problem with partitioning/formating. This has nothing to do with the boot loader (the boot loader even must not be installed in the /boot or the root partition). So I think you should open a new bug with your problem. Here it is out of topic. Thanks.

Tim, could you please add some more information, as there are two completely different systems, one with one SATA disk, the other one with 2 ATA disks, both with completely different partitioning.
eg in the first scenario, you have a root partition on sda7, which would require grub to be in the MBR.
So lets concentrate on one of the systems.
- fdisk -l
- /etc/fstab from both installed systems
- /etc/grub.conf
- /boot/grub/[menu.lst,system.map]

Leslie: Your problem is completely unrelated, so please open another bug.

Okay. Let's focus to the second system (yet because I'm now living in Germany and have no longer access to the first system).

Created attachment 101501 [details]
data_linux1.tar.bz2 - the data from the linux installed first

Created attachment 101502 [details]
data_linux2.tar.bz2 - data from the second linux, which is causing the error

Here is the data from the second linux, which is causing the error.

As described, this system has written it's bootloader to MBR - so I've changed the menu using this second linux (the way the the first linux is booted automaticly instead of the second).

None of your installations seem to write grub into the MBR, which is good :-)
That takes us to the question, what is in your MBR.
If it's a generic one, you can simply select the grub to use first by activating hda2 or hda3 (only one of them at a time).

Reopening the issue.

The problem is that the installation shouldn't write into the MBR, but it does. To describe the order:

1. Installing first linux (see data1), writing to MBR during installation (desired behavior). So now I had grub from linux_1 in the MBR.

2. Installing second linux. During the installation, I choosed "write grub to partition /dev/hda3" (the idea was to add later an entry using linux_1 to grub in the MBR, referencing to this partition). But the installation process has written its grub to the MBR. So now I had grub, but the wrong one. Here is the issue: the installation system writes grub to MBR also when I expecitly say that I don't want this.

3. Than I've changed the start menu using linux_2 (as yet linux_2 had written its grub to MBR). But that's something that I had done manually.

Furthermore I've tested what happens when I make changes to grub using linux_2. Yast has yet choosed "Other: /dev/hda3". I left this how it is. However, the changes where written to the MBR, not (only) to hda3.

So the problem seems to exist not only during installation but also after the installation.

What gets you to this conclusion? according to all your attachments, grub _was_ installed into the partition, in all cases. Your MBR is likely a leftover from the 10.1 installation.

I suggest you make sure that a "generic MBR" is installed during your next installation!

If you succeed to do so anyhow, maybe even DOS "fdisk /MBR" (there's also a yast button somewhere, I use dd), then save that using "dd if=/dev/hda count=1 of=mbr.generic". Then reproduce your problem, if possible, and reopen with both the generic and the changed mbr attached.

I am quite confident that your problem goes away once you managed to get a generic MBR installed!

Well, the new MBR has the grub menu that corresponds to the second installation I've done. The first one is overwritten. Reopening.

*** This bug has been marked as a duplicate of bug 213256 ***

Would you please be so kind and not mix 10.1 bugs with 10.2 bugs?
Especially if they are not related.

Comment #16: I can assure you, there is no grub menu in MBR. ;-)
Could you please add the infomation Torsten requested?

Created attachment 102958 [details]
mbr.generic

Okay, I've reached the point where I no longer understand the structure of the problem. Sorry.

Now I've used yast to write a new generic MBR (yast from linux_1), and now also the menu created by linux_1 shows up. (Could not use fdisk /mbr as I have no Windows on my computer ;-)

As far as I have understand, I make now a new installation (substituting linux_2)? To report than the new MBR? Okay, I'll do that with 10.2beta1, but give me some days. I'll do that during the next week.

Okay, it seems that this was a problem of the MBR. Trying it 2 times, I could not reproduce the error. So I close as invalid.