I run a win7/Suse 12,3 kde 32bit dual-boot and when i turn on my pc, the system don’t go pass the bios. It just hangs on the grub (Stooorage - Free Image Hosting). I remember before the last shutdown, i run an update where a new grub and kernel got installed, so i figure that must be the issue. I was thinking about reinstalling the bootloader through the live media, but i didn’t find that an option. It seems the installation process cannot go forward if i don’t chose to run a complete installation.
I don’t know if this could be a factor, but i have the /boot in a separate partition:
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00053535
Device Boot Start End Blocks Id System
/dev/sda1 2048 114690047 57344000 7 HPFS/NTFS/exFAT
/dev/sda2 114690048 169768959 27539456 83 Linux
/dev/sda4 * 169771006 1953519615 891874305 5 Extended
/dev/sda5 172036096 1953519615 890741760 7 HPFS/NTFS/exFAT
/dev/sda6 169771008 171724799 976896 82 Linux swap / Solaris
/dev/sda7 171726848 172023807 148480 83 Linux
It appears you have installed the Grub boot loader into an Extended Partition sda4. This works with openSUSE and grub, but the Windows partition program will not work properly with that configuration and if used, can mess it up. If the openSUSE root / partition is loaded in an extended partition, sda5 or higher, the normal solution is to load grub into the MBR, but your old method could work if you resolve to never run the Windows partition program on this setup. Be very careful as you could render this hard disk such that a total reload may be required.
So give us an fdisk -l and df command from terminal from the live openSUSE media and it would be nice to see the /etc/fstab file from your openSUSE install. The su - may not be needed:
su -
fdisk -l
df
So, you can use the second link you found to get in a position to run the commands from the first, but we need more information to help. Did you run the Windows Partition program by chance?
So if you booted from a LiveUSB, you already have a /boot folder. Anything to do with your original system would been to be mounted elsewhere. Meaning that there is a folder called boot on your root openSUSE install root partition and I guess you were mounting /dev/sda7 there in boot, but you must mount /dev/sda7 elsewhere when booting from a liveCD/USB drive. Further, having the root partition or the /boot partition on a logical drive normally means loading grub into the MBR.
I’m confused on which boot folder you’re referring. If you mean the one on my root partion where opensuse is installed (dev/sda2), the /boot folder there is empty because up-to installing Suse i set the /boot folder to be on a separate partion in dev/sda7. Where am i supposed to mount boot if i’m unable to rung grub2-mkconfig /boot/grub2/grub.cfg, since the grub to be repaired is in sda7?
That did it! With some errors though, but i can log onto both suse and win, so it must’ve fixed. Thanks!
linux:~ # chroot /mnt
linux:/> mount /proc
linux:/> mount /sys
linux:/> mount /dev/sda7 /boot
linux:/> grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-3.7.10-1.4-default
Found initrd image: /boot/initrd-3.7.10-1.4-default
Found linux image: /boot/vmlinuz-3.7.10-1.1-default
Found initrd image: /boot/initrd-3.7.10-1.1-default
Found memtest image: /boot/memtest.bin
ERROR: opening path /mnt/sys/block
ERROR: failed to discover devices
ERROR: opening path /mnt/sys/block
ERROR: failed to discover devices
ERROR: opening path /mnt/sys/block
ERROR: failed to discover devices
ERROR: opening path /mnt/sys/block
ERROR: failed to discover devices
ERROR: opening path /mnt/sys/block
ERROR: failed to discover devices
ERROR: opening path /mnt/sys/block
ERROR: failed to discover devices
ERROR: opening path /mnt/sys/block
ERROR: failed to discover devices
No volume groups found
done
linux:/> grub2-install /dev/sda
Installation finished. No error reported.
Any suggestions if can i do something now to prevent this in the future? Like getting /boot inside root, without doing a clean install? I don’t quite remember why i choose to dedicate a partition to /boot. I did this a few years ago, seen from someone or read somewhere it was safer and i’ve been running this type of setup ever since across multiple distros.
Hmm … looks like a bug, grub_installdevice points to partition 7 (/boot) which is impossible to boot from because it is logical partition. That explains boot failure after bootloader update. How long ago did you install your system? Logs from installation may still be present.
Anyway, now you have grub2 in MBR. So you should go into YaSY2 bootloader configuration and select booting from MBR and let it update configuration files. Verify that after that grub_installdevice contains (hd0) (not (jd0,7)) and that device.map still points (hd0) to your hard disk. You may also remove reference to USB flashdisk from device.map to keep it clean.
No, that’s not a bug. Well, maybe it is, but we would have to know more to determine this.
On one of my boxes, I have grub installed on “/boot” which is “/dev/sda6”.
If I set it up that way during install, then the installer wants to also install on the extended partition and set that active. I usually clear that, because I want to boot another way.
This works fine as long as you intend to chain-load boot using another grub, or you intend to boot from the Windows Boot manager, and add a copy of the boot sector to Windows.
If you installed with grub on “/boot” and booting from the extended partition, then it is a bug if reinstalling grub does not also update the extended partition. If you did not install to the extended partition, then it is your problem if you failed to update Windows Boot Manager. That is to say, it is a user bug, not an opensuse bug.
However, to emphasize a point I have previously made, reinstalling grub whenever “mkinitrd” is run causes problems for people who do this. And if they are using the Windows Boot Manager, they are probably naive users who won’t know that they must update the Windows Boot Manager after every “mkinitrd”.
You are right. I tested installation with /boot and / on logical partitions. Installer suggested bootloader location on extended partition and it was installed this way and grub_installdevice also contained extended partition as well. So it appears like at some point bootloader location was changed to /boot manually.
What do you suggest can be done about it? Having bootloader on logical partition is by itself not impossible - may be user wants to chainload it from another bootloader? It is not possible if this is the only OS (or your primary OS) but how should installer know it?
May be YaST2 should indeed ask user “Do you want to boot directly into this installation?” and filter choices depending on this. Or at least bring up large red warning explaining in “layman speak” the implications of having this choice.
The more I look at it, the more I agree with Fedora choice to disallow anything except MBR. You do not need to install any boot sector to chainload bootloader from another operating system (well, not sure about Windows …) so basically there are two sensible choices - “Boot from MBR” (may be selecting device) or “Do not install bootloader”. You select the first on primary installation and the second in all other cases.
If I may interject my opinion here, I also suggest that installing Grub into the MBR be the only choice when Extended/Logical and Windows Partitions are being used together. Installing Grub into an Extended Primary partition is a booting solution that often falls in on its self like a house of cards. Running the Windows Partition program does not understand it and may corrupt it and perhaps even an openSUSE update though you think a manual choice may have caused the problem this time. Loading Grub into the MBR in a dual boot setup can prevent Windows from wanting to install a service pack and having a generic MBR and active partitions is an easier setup to recover back to Windows control from, but making an Extended Partition as an Active partition is a kind of fluky solution in my opinion. I can only say that having a recovery setup in the openSUSE DVD install disk which would allow the install of a generic MBR boot loader and the ability to select the Active boot partition is what I would provide over ever placing Grub into an Extended Partition and marking it active for booting. I would also prevent /boot from being loaded into an logical partition unless grub is in the MBR. Anyway, these are only my opinion on the subject for anyone able to make such changes to the openSUSE installer.
When I setup opensuse this way, I am surprised that there is no warning to the effect:
“The system will be unbootable unless you have set up some alternative way of boot, which typically requires expertise”.
I totally disagree. That was a terrible Fedora choice. And the reasoning behind it is nonsense.
However, I agree with that. And I try to avoid using the extended partition that way.
My most recent install had “/boot” as “/dev/sda6”, which is a logical partition. During install, I unchecked the flag to boot from the extended partition.
I’ll describe three systems that I use:
System 1: There are two linux installs. For one of them, “/boot” is “/dev/sda1” and for the other, “/boot” is “/dev/sda6”. I currently have “/dev/sda1” set as the active partition, and it happily chain loads to the other installed version if I choose to boot that.
System 2: There are two linux installs. For one of them, “/boot” is “/dev/sda1” and for the other “/boot” is “/dev/sda5”. I currently have Windows 7 set as the active partition, with entries in the Windows boot manager to boot either linux installation.
System 3: There are currently two linux install. For one of them (opensuse), “/boot” is “/dev/sda1”. For the other (Fedora 18), there is no separate “/boot”, and it boots from the MBR because of an unbelievably stupid decision made by Fedora.
Since opensuse is my primary system, it is annoying that I have to go through the Fedora boot manager every time. The worst thing is that the Fedora install made opensuse unbootable, until I modified the boot menu. This is because my opensuse system is in an encrypted LVM, and the “osprober” does not find it.
