Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
grub recovery gets confused by --prefix option, system hangs during boot #210
while trying to recover a SLES11 x64 system with REAR everything went well but the system was unable to boot. GRUB installation was reported as beeing succesfull but in the detailed logging it failed:
GUB version 0.97 (640K lower / 3072K upper memory)
[ Minimal BASH-like line editing is supported. For the first word, TAB
Error 15: File not found
it seems the --prefix option did confuse it some kind of a way, with a simple:
setup --stage2=/boot/grub/stage2 (hd0)
everything went well.
Relax-and-Recover 1.14 / Git
the system did not have a dedicated boot partition, i think it went wrong because of this, according to the script the prefix stays /grub if no seperate disk is found:
i think defaulting to /boot/grub as the prefix makes sense anyway?
yes, there is no seperate partition for /boot, it exists on / however:
/dev/sda2 on / type reiserfs (rw,acl,user_xattr)
dbupdate:~ # cat /etc/fstab
@dagwieers knows this better. I was just sitting idly next to him when we wrote than and all I did was just nod when he asked a question :-)
But if I look at it, I think we want our initial search fot
Some background info (which is important to understand the why's I guess)
From the mail archive I found the following (from @dagwieers ):
Anyway, the reason there is a distinction between
The reason the grub installation code is more complex is because we had to
So how did we do this ?
To know exactly what devices are involved with the boot partition, we
If in this case bootparts is empty, it means that
The reason we have this complexity is because if you have software raid,
Once we know the boot partition(s) and we have the correct grub_prefix, we
So how to proceed to debug the problem ? Enable debugging and check what
PS: we're talking about code from
i tried to reproduce, the strange thing is:
after recovering the data to /mnt/local and exiting the rear> command prompt with "exit" it does not show any error, the grub failure however is reported to the logfile
if get back into the recovery mode again, skipping the disk partitioninig it then complains correctly about
HINT: If you can reproduce the issue, try using the -d or -D option !
Aborting due to an error, check /var/log/rear/rear-dbupdate.log for details
so it seems there must be a difference between executing the recovery the first and the second time!
++++ grep -E '^[^ ]+ /dev/sda2 ' /var/opt/sesam/var/lib/rear//var/lib/rear/layout/disktodo.conf
contents of diskalyout/todo:
disk /dev/sda 5368709120 msdos
done /dev/sda disk
I think the error is maybe also caused by the situation that /dev/sda1 is swap, and /dev/sda2 is / aswell as /boot/
I think I get it now, although I don't know why. Look at this piece of code:
# Find exclusive partitions belonging to /boot (subtract root partitions from deps) bootparts=$( (find_partition fs:/boot; find_partition fs:/) | sort | uniq -u ) grub_prefix=/grub if [[ -z "$bootparts" ]]; then bootparts=$(find_partition fs:/) grub_prefix=/boot/grub fi # Should never happen [[ "$bootparts" ]] BugIfError "Unable to find any /boot partitions"
If in your case
echo -e "/dev/sda2\n/dev/sda2" | sort | uniq -u
Let me do this on my own running system (this is a good way to debug the code BTW:
This is to be expected in my case (/dev/sda1 is the /boot partition). In your case it should return nothing. Which means / and /boot are the same device.