Problem Booting Linux after restoring with True Image

Hi all,

I have such a problem:
I made a backup of my RHEL5 system with TI Home build 9709 which supports ext3 256 i-nodes filesystem. It was an IBM server with mirror raid 146Gb. Then I tried to restore it to the same machine with mirror raid 72Gb. Everything was ok, Acronis proportionally resized all the partitions, but I can't boot the system - I received a blank window with "GRUB" in the left high corner. Of course after reactivating Grub through Linux LiveCD everething works great ...
Then I tried to restore it to the same disk. In fact it was not just the same - it was stripe raid of 2x72Gv disks. So I have just the same sized 146Gb disk for the system (what is the difference it is mirror or stripe for software). But the same result. What can I do wrong?
Or is it a usual behaviour of Acronis ....?
Please help me , very nice software but I can't use it for Linux .....

 

goga:

This is usual behavior for TI when restoring ext2 or ext3 partitions. For reasons that I have never understood, TI zeros part of the boot sector of an ext formatted partition when restoring it. If you have GRUB installed to the boot sector of your Linux partition then it will "zap" part of the GRUB code.

As you have discovered, reinstalling GRUB from a Live Linux CD will fix this. As an alternative, can you install GRUB to the MBR of the disk? If so, it will survive imaging and you won't have to deal with this issue.

 

Wait Mark ...
I have installed GRUB in the MBR. Al least in the installation step of RHEL wizard it asks:
Where do you want to install a boot loader (GRUB or LILO), on the MBR or boot partition. I am choosing MBR cause it's a server system and there is only one OS installed ...

So where is the mistake of TI? Doesn't it restore something useful from MBR?

I didn't try to install boot loader on the boot partition for 5-6 years, last time it was LILO and when I have several OS on my computer. I didn't remember the beahviour but I can try such a way: to install a boot loader not on MBR. But I am not sure if I am able to boot such a way after installation.

 

goga:

I agree that for your intended use then you should install GRUB to the MBR.

What you have experienced is very unusual. With GRUB installed to the MBR I can restore the MBR and GRUB survives. If instead GRUB is installed to the boot sector of an ext3 partition and I restore the partition, GRUB does not survive and must be reinstalled from a Live Linux CD. With GRUB in the MBR I can also restore ext3 Linux partitions and they boot correctly afterwards. Our TI versions are different and I'm still stuck in the past with standard 128-byte inode Linux partitions, however, so one of these factors may be what's different.

When you restored your disk did you also include the MBR and Track 0 in the restore? And since you tested with two different types of RAID arrays, did the TI boot disk "see" the array properly as one disk?

Once you have GRUB successfully installed to the MBR and working then you can skip the restore of MBR and Track 0 in the future - just restore your partitions and the GRUB code in Track 0 will not be modified. That may be a workaround for you.

 

Mark:

Yes when I restored the disk MBR and Track 0 was also selected. I selected the whole disk. Ok probobly you are right and it will be a workaroung if I don's restore MBR and Track 0. But let's imagine that there was no Linux ang GRUB on the target disk !?

Yes TI saw my raid massive as whole disk. There was no problem with this ...


Look I found out that I am using 256 inode only after my Acronis attepts . You know I always update my servers with yum for the last update (and I have RHEL 5.3 now) and I think that it converts to 256 inodes automatically, because I found an old virtual machine with 5.2 version and there is 128 inode there. Probobly RHEL decides this by itself during installation, I don't know yet, I have to read about it.

Anyway I will try on this virtual machine, GRUB is also installed in MBR there. And write you back about my results.

 

Mark:

I made some tests today and recived very strange results ....
As I told before I found an old VMware machine RHEL 5.2 with ext3 inode 128 (8Gb HDD). I added second virtual HDD (ext3) for storing backup there, but Acronis returned an error. As far as I understood it can't write backups files on ext3 partisions. So I reformatted it as NTFS through Partition Magic Live CD.
Then I removed the system HDD 8Gb and added a new one 7 Gb, boot from Acronis and made a restore. And then reboot. I couldn't believe in that !!!! Linux was BOOTED without any problems ....

I decided that the matter was 128 inode. Then I installed RHEL 5.3 on Virtual Machibe 8Gb HDD and was suprised, all my partisions was 128 inode. I don't know how did I get 256 inode on my productive servers (I have /boot, /, /var, /var/spool, /usr and /tmp. All except /boot - 256 inode, /boot is 12? probobly I reformatted it thriugh Live CD (if I remember right) and mkfs.ext3 decided the size of inode by itself .... So I recived a new Virtual Machine with RHEL 5.3 all partisions 128 inode and made a backup with Acronis. Then removed system disk again in VMware configuration and added a new one 7Gb HDD amd made a restoe. And got blank screen with "GRUB" in the high left corner.
Unfortunely I deleted the backup from RHEL 5.2 and have no distributive now (I have already deleted it as thought that is useless fir me now) and can't check it for the second time. But how can this happen, how can it work with RHEL 5.2 and can't with 5.3 !?!?!?!?

 

That's correct for TI version 11 and later and it's one of the reasons that I've held onto version 10 since it can write to ext3 partitions.

Good! That's how it's supposed to work.

I don't have an answer for this. It must have something to do with any differences between the two versions of RHEL. By any chance do the two versions use different versions of GRUB?

Code:

grub --version

I know that on the recent versions of K/Ubuntu, the GRUB package had to be updated to be able to read inode-256 partitions; otherwise the system would be unbootable. Are there any other differences?

I think that when you only see "GRUB" on the monitor at boot time, it's a symptom that GRUB has started but is unable to locate the stage 1.5 loader file that is usually in the /boot/grub folder. If the boot process gets past that point then the error messages are more comprehensive.

 

Finally Mark,

I hope you will see this my answer after a little period of some test attempts with virtual machine and productive server.

By the way, Grub versions on rhel 5.2 and 5.3 are the same - grub-0.97-13.2. But I think the main problem was not in grub or Linux version and even not in Inode 256 ...

step by step:
I found 2 version of TI Enterprise Server and was successful in booting Linux on VMware. So I decided to try this versions on my productive hardware and was unsuccessful. But I tried this in such a way: took an image of 146Gb mirror massive and restore it to 76Gb. So I recived the same Grub problem. Then I decided that it's because of Inode 256 cause on my virtual machine there was 128. RHEL makes 128 by default. But when I installed this server I formatted it through live CD SLAX and it makes the Inode size according to the size of partition as far as I understood. In most cases it does 256 Inodes.
So I reformated through Live CD SLAX to 128 Inode but was again unsuccessful. So my idea of Inode size and of enterprise versions wasn't right or it was not the only reason. Suddenly I decided to restore an image with 256 Inode to mirror massive 146 Gb and it worked .... So it didn't work on a massive smaller with enough space and worked on the same massive (earlier it didn't work with another verion of TI and with 146 Gb stripe massive). Then I take an image from 76Gb system and restore it to 146 and it also worked. But it was very strange that it restores 73 Gb of disk and left another 73Gb as unpartitioned space. It didn't increase it proprotionally and didn't ask me about it.
What do you know about this? Some guys told me that in windows restoration it asks about resizing ....
So I stooped on that: made a CD disk with an image of 146Gb system with Inode 128 (it works, I have checked) and told that it won't work on smaller disks or proboble won't work. But this ****ing Acronis almost drove me crazy ....

 

In order to see the resize dialog box you have to start the restore by selecting only one partition at a time. If you select multiple partitions or the entire disk to restore then you won't see the resize dialog box.

After setting up the first partition to restore and choosing a target size, the restore wizard will ask if you want to restore any other partitions. Continue doing this until you have set up sizes for all partitions and then proceed with the restore.

 

Just do one partition at a time.

TI 2009 doesn't work this way. The partitions must be selected through the wizard in one pass. If you select everything, TI will switch to a "Disk" restore and you won't be able to resize any of the partitions.

 

Oh yes, you are right. I didn't try to restore partitions one by one. Now I tried on VMware and it really worked. But I think that proprotional resizing is also should be (like in the situation when we restore on a smaller disk).

And while restoring on a smaller disk can we select partitions one by one for manual resizing? I mean Acronis makes it proportionally (and that's good), but if we want to make it manual, can we?

 

I've never tried proportional resizing - I must be too much of a control freak. But yes, manual resizing works if you do one partition at a time.