You are not logged in.
I have been working on installing archlinux and xen to run a xenserver with archlinux as my dom0. The installation of the grub went fine. A potential problem was me trying to install grub to my boot partition the first time on accident. Following are the commands I used to install grub.
# grub-install /dev/sda1
As you'd expect, I was informed that installing this way was a bad idea, and that the installation would not continue. I meant to use the following command instead:
# grub-install /dev/sda
Which completed successfully.
After that, I created the grub.conf
# grub-mkconfig -o /boot/grub/grub.config
Completed successfully.
The actual output of these commands are exactly what I would have expected from them. If desired, I can post the output, but they were what would be expected form a successfully completed command.
After running through the installation and creation of the grub.conf file, I rebooted and was presented with the grub menu selection screen. While the xen entry was certainly found and put in the grub.conf (which I checked afterwords), there were only two entries: Archlinux and Archlinux booting from the backup ramfs. Thinking that this may have been the correct behavior for a server that is running a baremetal hypervisor, I choose the normal Archlinux entry and was greeted with an error screen informing me that a UUID for a partition that does not exist was not able to be found. Trying the bakup archlinux entry gave me the same result.
I am now unable to boot the system. Rebooting into live media, remounting partitions, arch-chroot into the /mnt directory, and reinstalling grub and recreating the grub.conf file has gotten me nowhere.I have several questions about this:
Is it possible that the UUIDs and grub.conf from my previous install could have been preserved somehow? The previous install used gpt partitioning while this one used mbr.
Is there something that I am missing to get grub to create the file and use it?
Do special procedures have to be followed to clear gpt formatted disks before using mbr?
Last edited by ephreal (2015-03-15 05:42:40)
Offline
I had the sudden idea to check with gdisk and see if there was still information left over from the previous install, and indeed there is. Gdisk quickly informed me that there was a damaged gpt header. I would assume that this would be the secondary gpt header created for redundancy at the end of the gpt partition table scheme, which would explain why it still tries to boot to a non-existent grub.conf and UUID. Therefore, my first question was answered by me: some data IS indeed preserved and that can cause trouble when attempting to swap back to mbr.
Offline
Seeing as data seems to be present still, I'm going to try reformatting the disk as gpt and doing a complete reinstall of the system. If that works, then I'd still like to know if special procedures have to be followed to get the gpt partitioning scheme off before reformatting with mbr. I had used fdisk /dev/sda to create the mbr table, and as far as I know, fdisk is not gpt aware, which means it would not have known to delete the secondary header as well.
I'll continue with the installation for now and post if it succeeds in booting. If so, I would recommend to anyone who uses gpt on a disk to continue to do so without trying to reformat as mbr, possibly even while swapping hard drives between systems as general use backup data drives.
Offline
You should use fdisk rather than gdisk if it is an MBR-type disk.
If gdisk is used on an MBR disk it will just try to convert the table to GPT.
The presence of a GPT backup table at the "end" of an MBR disk is of no consequence and can be ignored.
I do not know why your system would not boot originally as I have no experience of xen or hypervisors.
Jin, Jîyan, Azadî
Offline
Thanks for clearing that up!
As it now stands, the server when installed to gpt formatted disks is now stuck in an eternal reboot cycle. I'm going to try some reinstallation of grub packages again and see if that clears up that problem. Any other advice would be welcomed on getting this up as it's now been about a day of me trying to get this while a normal arch install usually takes me about an hour.
Offline
Possible progress:
After taking a break to stop thinking about the server, I came back and reconfigured the partitioning scheme as follows:
/dev/sda1 - bios boot partition
/dev/sda2 - root partition. Mounted at /mnt
/dev/sda3 - swap
/dev/sda4 - lvm partition for vm's
After reinstalling grub with the bios/boot partition unmounted, I am now presented with a grub command prompt. Progress? As it stands, this is now less of an installation issue as it is a non-booting issue. Does anyone have any advice? I'm going to try to boot via grub prompt, but that has traditionally been hit and miss with me. If you'd like any commands posted, it may take a little bit as I'll have to transfer the output between devices.
Offline
Having no luck, I looked into syslinux a bit and gave it a try, and am now booting just fine. This doesn't solve the initial issue of having grub consistently show the wrong UUID, but it is a workaround.
Thank you Head_On_A_Stick for the clarification.
EDIT: The information for setting up xen with syslinux was found here and here. I'd just like to remind anyone using syslinux for the first time that the default root partition is /dev/sda3 and has to be changed in the config file. Got me 5 times in a row!
Last edited by ephreal (2015-03-15 05:52:24)
Offline