EDIT: skip to the legacy BIOS and GRUB 0.99/2.0 etc. boot solutions here:
http://www.linuxquestions.org/questi...ml#post5228896
Although complicated and confusing (to me), the legacy BIOS booting issues turned out to be relatively minor compared to the larger issues of how to properly convert MBR->GPT, and how to move, align, and resize encrypted RAID partitions safely.
Tool bugs could complicate matters let alone one's unawareness of what a tool is actually doing (and not doing) as it performs partition table conversion or partition resizing and moving or file system resizing.
EDIT: link to Ubuntu's MBR->GPT migration guide:
http://askubuntu.com/questions/84501...untu-boot-from
This is a complicated procedure that I just found and I immediately identified issues that might have caused me to corrupt my disk copies while migrating them and expanding them to fill the new physical disks.
dd'ing the MBR partitions directly to larger physical volumes with larger physical sector sizes was probably a bad idea and I have abandoned it. Someone else facing a less complicated migration might be able to use dd to copy to new volumes successfully and easily.
Probably best to start by testing your system BIOS boot first by installing Linux uder GPT on a blank disk and troubleshooting the GRUB 2.0 boot, then considering if GRUB 0.99 complicates booting your migrated server (see the link to booting solutions I discovered, above).
Then at least you will know in advance how feasible and labor-intensive your planned in-place migration is.
Mine turned out to be potentially feasible but incredibly complicated and required abandoning GRUB 0.99 chainloading so I decided to boot my old server drives in a temporary system and build the new server from scratch.
I will also dd the existing OS to the new server (multiboot new and existing OS) before copying in the server data over network. The existing OS already has everything installed for the RAID and encryption and Mythtv and NFS, and could save me lots of time. This was the major reason for attempting dd in the first place.
I will probably also try to get chainloading working with GRUB2. It preserves maintenance function when one OS gets corrupted and allows for trivially easy scripted OS backup/restore from an encrypted partition (hides duplicate UUID that might confuse the boot). A chainloading 0.99 bootloader rarely needs anything except menu changes and is very stable. I hope to do something similar with GRUB2 since it is GPT aware.
One additional thought I had was in addition to backing up the OS I will also back up the bios-grub partition and the boot record to unencrypted files using a backup/restore script. That way I can restore everything 'boot' to its last known good configuration easily without having to chroot or other nastiness.
Wish me luck and same to you!
------------------
Hello everyone, this is my first post here. My background is retired electrical design engineer with a stint as disk controller application/design engineer so I should know but somehow I managed to screw this up.
My system is an Intel dg965wh Core2 Duo bios boot (no EFI) all firmware updated to the 'latest' 5 year old version with (originally) 2 400MB and 4 1.5TB SATA drives formatted to MBR with a dedicated boot partition for GRUB on one of the 400MB drives and all operating systems chainloading with GRUB2 installed to their respective partitions.
There is 4.5TB of audio/video etc. library on a RAID5 volume and one of the 1.5TB drives failed. The system was full anyway so I decided to install 6 4TB drives instead as this is my fileserver for my HTPC that runs in multiple rooms.
The operating system I use most is Ubuntu 12.04 LTS booting from a working drive so I left it as installed, especially since MythTV database requires MySQL and migrating it is finicky. It needs the exact same version of Ubuntu in order to be compatible with the existing database and I decided to skip the backup process since I have a copy already on the original drives if anything does not work out.
I use the desktop Ubuntu because my computing skills are patchy. I have had to basically learn everything 'NIX on my own. I am familiar with shell scripting but no guru and the server install intimidates me, especially since I cannot use it to verify MythTV is working unless I run a desktop version anyway or have uber skills to do everything with baling wire and chewing gum. Maybe that is part of my problem.
In hindsight I should have tried a new install to the new drives first just to make sure there was compatibility. I did not think of that. I took it for granted that I could fix any issues and now I have too much invested in the copy to wipe it and start over.
So my plan was to just copy the existing volumes to new drives and massage everything into the new system with more bigger drives in each RAID by using parted, gparted, grub-install to mold it into a bootable system.
First I used DD to copy all the drives bit-for-bit. Then I ran a utility to convert the drives to GPT (forgot which utility, but I know it comes with Ubuntu). Sorry I do not remember the commands I used; it was a year ago I tried to do this and I still have not got it working so I came here.
After copying the drives and before/after(?) converting them I also ran a utility to align the partitions since I also went from 512B to 4KiB sectors and DD did not align them of course, it left them as the original DOS spec said primary 0 at sector 63.
Once everything was in the correct format, I then used gparted to expand the volumes and move them around into the new boot/RAID/data partitions.
The last step was to load an Ubuntu LiveCD and run grubinstall(?) from a chroot to the existing installed OS. I figured GRUB was not going to boot a GPT so I decided to forego chainloading and just let one installation of GRUB2 (from the pre-existing main OS) handle the bootloading and deal with the pain of configuring GRUB2 for multiple OSs later.
It seemed to work but it did not boot. It says 'insert bootable disk' or something like that. So I never even got as far as rejoining all the RAIDs and expanding them with more partitions. I am still working on getting the bootloader running.
I did falter over the reserved grub partition but I decided to use the dedicated 200MB chainloading GRUB multiboot partition as the reserved partition. I think it is type bios_grub? and I had to run yet another utility to change the type from the original. I forgot the name of that utility but it was probably gparted. Anyway the type is correct. I eventually ignored all the 'set the boot flag' type comments on various forums because none of that information seemed to be correct. It did not work anyway.
I did not wipe the bios_grub(?) partition. I just left it as is with all my old GRUB menu files and documentation of the partition table and chainloading etc. on it. I figured that grub-install was going to ignore the formatting and write the bootloader in binary without regard to any filesystem, since BIOS booting systems boot from a reserved area within the MBR partition anyway, not from within a filesystem.
I really thought I was doing OK until I hit a brick wall at boot.
Anyway, there are so many places this process could have been derailed and I do not know where to start troubleshooting, or how. I really am not looking forward to viewing the hexadecimal to find out what the GPT actually looks like at the low level.
First off, I could have made a mistake when I converted from MBR to GPT. There is something called a protective MBR to help a bios machine boot a GPT without EFI. Did the conversion utility include a protective MBR? Did I pass the correct parameter to force it? I cannot remember the answer to either, or if I was even aware at the time. How would I check for this, short of looking up the hexadecimal for a GPT with MBR on Wikipedia etc. and comparing byte-by-byte in a hex editor (I do not even remember which editor willl let me view a disk directly)? How would I know if I checked properly or if there was some undocumented glitch somewhere that makes the actual hex data vary from what I can look up online?
Secondly, the Ubuntu installation I chrooted to was originally installed on an MBR. Did all the libraries etc. for GPT get installed by the liveCD when I first installed Ubuntu on the MBR server, and does grub-install know how to write a bootloader to a GPT if it was originally installed on MBR? How the heck would I even know if this is possible let alone check that it is configured properly to do this job? Would I have to run some installation under Synaptic and if so how would I know what needs installing and how would I configure it given all this usually happens with a fresh install during hardware detection?
Thirdly, perhaps the motherboard cannot boot a GPT. I think an Intel Core2 Duo bios should be able to but the motherboard I have is sort of a mongrel budget desktop 'media center' Vista-ready motherboard with 7.1 audio as its main selling point. Whoop.
I have looked up the process of migrating to GPT and one thing I noticed is that some motherboards just will not boot a GPT or at least require some massaging to get it working.
I would have checked for this if I thought to try it before copying all the data and re-working all the partitions. Then at least I would have known if this motherboard even boots a GPT at all. Now that I have done all that work I am loathe to delete it all just to check if the thing will boot at all.
I tried installing a small ATA drive but somehow Linux utils I used, or the installation utility on the liveCD (forgot which way I tried), would not let me install a GPT on the drive. Is there some minimum size requirement? Will Ubuntu install GPT on an ATA drive?
I am loathe to try it with one of the original 1.5TB SATA drives. First, it is my backup copy, and second, given my luck with a small ATA drive I do not know if 1.5TB SATA drive will take a GPT under Ubuntu 12.04 at all. MBR can handle up to 2TB. Is the limitation some other size constraint, is it ATA vs. SATA, is it 2TB, or what? I might delete everything on the volume just to find out that I cannot even test a GPT on that drive anyway.
So here I am, stuck. My last thought was to try a fresh install of Ubuntu 12.04 on a different partition, perhaps one of the other OSs (the only one I kept was Ubuntu Studio). Maybe then I might figure this out. The issue there is that I wrote that version to sdb thinking I would multiboot it off the OS on sda. sdb is not in the same state as sda but it is the best I can think of.
So given this situation, is there anyone here who knows of direct straightforward troubleshooting steps I can take to rule out these potential pitfalls one by one and get to the root of this problem?
Thanks in advance for your patience reading this post. I was not sure what was relevant so I just put everything in it I could think of. I am no uber guru, just a middling engineer trying to repair and expand the capacity of an old file server.
