I’ve been installed opensuse 13.1 dual boot with windows 7. I set the boot or grub 2 on root partition. When I was rebooting the computer, It 's turned out that it boot into the windows 7 instead the grub 2 one! So, where is the problem?
Did you use a MBR set up or a EFI? Sounds like a MBR since you don’t install grub to a partition on a EFI machine. If you mixed EFI and MBR then it can be a little difficult to correct it. If this is a relatively new machine it probably has a EFI BIOS . But we can only guess
Basically you are saying it’s broke what is wrong. We need more info then that.
My take on that is the bootable flag * is still on the windows partition. In your favorite windows os you can probably see that using DISKPART but don’t ask me about windows. You can (probably) transfer that bootable flag to your suse partition too using DISKPART or any bootable media eg. dvd/cd.
Next guess please 
I’m using MBR
Re-run the install and set the grub options like this
https://dl.dropboxusercontent.com/u/10573557/13.1_install/13.png
Is it safe to reinstall? I’m afraid it will break the bootsector.
Yes
Just use the custom route and select the existing partitions
Here is a complete walk through
https://dl.dropboxusercontent.com/u/10573557/13.1_install/13.1_install.pdf
Boot with the 13.1 install DVD.
But, do not click on Install.
Instead, 3rd item down should be “Rescue System”. Click on that and wait for it to load.
It will stop with the line
Rescue login:
Type (without the quotes) “root” then press Enter.
You will now see the prompt, probably in a red font:
Rescue:~#
Do
fdisk -l
(that is a lower case “L”, not a numeral 1)
This will list your drives and partitions. Double-check which is the drive that you installed on to make certain you will be using the right drive and right partition when you run commands on the disk. In the following examples, I will use sdX to refer to the drive. You change the X to match your drive with the new Linux installation.
(ie: If the drive is listed as “sda” then replace the X with a in the following guide.)
If none of the partitions have the * under the Boot column, then no boot partition has been set. However, I suspect you will find it is set for the Windows partition, and the partition you chose as root (“/”) is the one where you want the * in the Boot column. If it is anywhere else, or is not there, you will need to set it.
I will proceed as if you want to set the second partition (sdX2) as the boot (or “Active”) partition (change the sdX2 to the correct one for your root partition in the following commands, if it is different).
Do:
parted
You will now have a prompt
(parted)
Do:
select /dev/sdX
(remember to replace the X with the correct letter for your drive)
You should get a confirmation message that the device is now selected.
Now, I am going to PRETEND that you have the Linux root partition installed in the second partition. So, I will be using the numeral “2” in the following examples.
Make sure you change that to match the correct partition that you have Linux root installed in, if it is not in the 2nd partition.
(However, do not panic if you guess wrong. You can just do this full procedure over again to change the flag to another partition at any time.)
Do:
set 2 boot
That is to set/reset the 2nd partition’s boot flag.
It will prompt you with the line New state?
Do:
on
When it is confirmed, do:
quit
You will be back at the Rescue:~# prompt.
Do:
reboot
If that was your problem, you should now see the Grub screen.
I confirm the standard installer (DVD) didn’t set the boot flags correctly, but GRUB2 installation was correct in a similar case.
Setting the boot flag to the root partition by whatever means (rescue system, GParted, etc.) solved the problem.
By default, it will not change the boot flag, if you already have a boot flag set. This is by design.
I don’t have the 13.1 DVD anymore, sorry.
The 13.2RC1 DVD (X86_64) I’m playing with at the moment, when setup with:
- boot from root partition
- set boot flag in boot partition
- install generic code to the MBR
sets the boot flag on my extended partition containing all my Linux stuff,
not the actual root partition containing the boot code (btrfs by default, BTW)
leaving GRUB2 stuck on reboot.
A “beta” snag or something else?
I have no problem with CLIs, and keep my rescue tools handy when installing,
but those things are keeping newcomers from joining.
No wonder Linux is still under 2% on desktops.
Have a nice evening,
Bruno
BTRFS is a problem I think that still grub is not able to write data to it even in 13.2. When doing resumes a write is needed to clear a flag. There also may be other reasons. But in any case if you want a fully functional system you still need a extX boot partition. BTRFS is still not fully ready no matter what the developer think. I admit it is come along but there are still large holes.
Resume should be no problem on 13.2.
A startup script resets that flag during resume, so you will get the standard boot menu on the next reboot.
Actually that’s already what pm-utils in 13.1 should do, but the script has a bug there so it doesn’t reset anything at all.
But in any case if you want a fully functional system you still need a extX boot partition.
Not really.
But that depends on what exactly you mean with “fully functional” of course.
I would definitely call my 13.1 system with btrfs (one partition for the whole system, including /, /boot, and /home) “fully functional”.
BTRFS is still not fully ready no matter what the developer think. I admit it is come along but there are still large holes.
The Grub2 issue is because grub2’s btrfs support is not complete, but that doesn’t say anything about btrfs itself.
In my experience on 13.1 (since it has been released) it is rock stable. What more would you need?
One nuisance might be the automatic creation of snapshots (although OTOH they might come in handy), but in my last factory installation in VirtualBox (or was it 13.2 beta? I’m not sure at the moment) they were disabled by default. This might depend on the size of the partition though.
You can of course enable/disable them later as well.
I cannot say much about the performance, but I don’t find it slow at least. (unless a snapshot os being created at the moment… )
I definitely do not see any “large holes” in btrfs, whatever that means.
Well full functional means no hassle in any function like resume. In 13.1 it seen to be a bit of a problem for some. I guess a work around is going to be in 13.2. I Assume that grub still does not know how to write to the btrfs partition. I still get the not quite ready vib from BTRFS.I hope I’m wrong but I fear I’m not. I know that we are going to see plenty of newbees run out of space because they toke the default and only allowed 20 gig root which has been the min recommendation forever and they don’t know or understand about snapshots. . Oh well guess we will see soon.
Well, Hibernate/Suspend/Resume has different problems (unrelated to grub2 or btrfs) for some people as well. If you see it that way, you would have to call the whole distribution (or Linux in general maybe) as not fully functional…
If you don’t use hibernate (I don’t really), this is irrelevant anyway though.
And I’m not aware of any other hassle in any other function btrfs would cause.
But resume works fine in this regard. The problem is just that grub2 cannot reset the boot entry that the sleep/hibernate script sets to avoid that a different OS is booted by mistake (as this could lead to dataloss). But this is done by openSUSE then during resume, on 13.2 at least.
In 13.1 it seen to be a bit of a problem for some. I guess a work around is going to be in 13.2.
Yes.
But as I said, that workaround actually already is in 13.1 (and earlier?), but it doesn’t work because of a bug in the script.
This is not difficult to fix really, one line has to be added:
Probably this can be released as update, but it’s not that critical on 13.1 as btrfs is not used normally (for /boot in particular; if you use it for any other partition, this is a non-issue anyway).
I Assume that grub still does not know how to write to the btrfs partition.
Correct, AFAIK.
But the same is true with LVM and RAID btw (and of course other filesystems that grub2 supports, other than “a chosen few”), grub2 cannot write to those either. Would you call those “not fully functional” or “not ready yet”? Of course they are not setup by default, but still.
I still get the not quite ready vib from BTRFS.I hope I’m wrong but I fear I’m not. I know that we are going to see plenty of newbees run out of space because they toke the default and only allowed 20 gig root which has been the min recommendation forever and they don’t know or understand about snapshots.
First of all, there is automatic cleaning up of snapshots configured by default. But that didn’t seem to work very well in 13.1 at least. Although I hardly have that problem with “disk full” here any more. I have a 40 GiB btrfs root partition btw.
Then as I mentioned, on a recent Factory or 13.2 Beta1 installation, snapshots were disabled by default for me. As mentioned, I think this probably depends on the size of the partition. I don’t know which size would be the threshold though.
Btw, there is a prominent checkbox to enable/disable them in the installer.
Oh well guess we will see soon.
Yes.
PS: I don’t really disagree with you. I just wanted to clarify a few things. I think it’s just plain wrong to say “btrfs is not ready yet”, especially if you don’t even have looked at/tried it yourself yet (from your statements this seems to be the case, please forgive me if I’m wrong…).
Btrfs is ready and fully functional (whatever that means, functions are still being added I think) IMHO. And I’m not the only one obviously, otherwise it wouldn’t have become the default.in openSUSE 13.2 (and SLES12 I believe).
I do fear myself that it might still be a bit too early to make btrfs the default file system exactly for those two reasons: incomplete support in grub2 and (seemingly spurious) “disk full” messages (because of the snapshots filling up the disk) confusing the user as “df” e.g. still shows Gigabytes free.
Let’s hope that the automatic cleaning of snapshots works better in 13.2.
The only issue that remains with grub2 I suppose is that if you use “grub2-reboot” to set an entry for the next boot, that entry will be permanent (unless that particular OS resets it) because grub2 isn’t able to reset it.
Maybe it would have been a good idea to suggest a separate /boot as well (with extX) in addition to making btrfs the default, but that’s too late to be changed now anyway, for 13.2 at least…
NOPE, the broken script is still in 13.2RC1.
Please Wolfi, try to push that patch before the release; otherwise the default installs enclosed with every Linux magazine before NewYear will be asking for trouble on laptops.
Gnome was wise enough to disable the “hibernate” button, but the default action for “critically low battery” is still “hibernate”.
At least, try to have the patch in the Update repo by day 1.
The other workaround, manually removing /boot/grub2/grubenv, only works till next “hibernate”, of course.
Be prepared for a number of newbies trapped from booting their Win* thing and asking for help
Which “broken script”?
AFAIK, pm-utils isn’t used at all any more in Factory/13.2 since months, even when it is installed. So even pushing that fix into 13.2 would not change anything.
A similar script has been written from scratch for systemd, but this should not have that bug.
I will have a look, but just to be sure that we are actually talking about the same thing:
That script is called during hibernate and resume. On hibernate it calls grub2-reboot to set the boot entry for the next boot to the currently running OS to disable the boot menu. On resume that same script should remove that set entry again (this is what grub2 fails to do on btrfs).
The pm-utils script in 13.1 fails to do the latter because of a bug.
If you still see that problem in 13.2 RC1, you should probably file a bug report against 13.2 though.
I tried it now (on Factory, but the snapshot from Oct 11 should be similar enough to 13.2 RC1), and indeed pm-utils doesn’t seem to be used at all when hibernating. According to the journal, the script /usr/bin/systemd-sleep-grub was run during hibernation instead.
Unfortunately the VM just crashed on resume (that’s apparently a problem with VirtualBox) so the entry was not removed, but the script looks ok and it removed the entry correctly when I called it manually with “/usr/bin/systemd-sleep-grub post”.
So this should actually work in 13.2 AFAICT.
BUT: Did you maybe see an error message flashing by when the boot menu should be shown?
error: sparse file not allowed
This would be a different bug: 849718 – GRUB menu not available: 'sparse file not allowed'
I saw this once in 13.1 months ago but cannot reproduce it any more since then.
But now I encountered it with Factory as well and added a comment.
I doubt that this one will be fixed until the release though, and it seems to be a general problem across distributions. But apparently it doesn’t occur very often.
Confirming the “sparse file not allowed” message on booting,
nonetheless modifying the 99Zgrub script according to your patch fixed the problem.
Now looking at http://bugzilla.opensuse.org/show_bug.cgi?id=849718
will report back if I see anything useful.
Bruno
I don’t quite believe that.
As mentioned, that script should not even be called, and the systemd script in 13.2 does the same and doesn’t have that bug.
And that script doesn’t really help with that “sparse file not allowed” either anyway (it might even cause it itself, that’s what happened to me on 13.1 when I tested it and that’s why I haven’t submitted it yet), as that is a completely different problem.
It would help if it would delete grubenv, but that’s not acceptable either as that would break other functionality, and the user/administrator might have put things into grubenv on purpose.
I think at the moment the main problem is that grub2 doesn’t seem to show the menu if it has problems reading an existing grubenv. This should be fixed, I’d say. Grub2 should act like grubenv is empty/doesn’t exist in this case.
Fixing/completing grub2’s btrfs support is probably unrealistic, especially in spite of 13.2.
And just as Andrei Borzenkov wrote in 849718 – GRUB menu not available: 'sparse file not allowed' :
reading the file might fail for different reasons, on any filesystem. And this is totally unrelated to hibernate/resume either.
Btw, I have read similar reports about that “no sparse files allowed” error on reiserfs, but a few years ago.