Help with conversion scenario

English Install/Boot/Login
#1

I want to convert my disk formatting to 128 byte inodes instead of 256 byte. When I first installed I didn’t realize that 256 byte inodes would render my copies (on an XP drive) of Norton Ghost and True Image useless for ext3 since they only recognize 128 byte inodes.

I have experimented wth dump/restore and rsync as possibilities for saving my setup, reformatting identically (but with 128 byte inodes) and then restoring, but those experiments have left me feeling uncertain that it would work.

I have an idea but wanted to get some more expert opinion first.

Here is my drive situation (from df):

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2             20641788   7417232  12175916  38% /
udev                   1004980       792   1004188   1% /dev
/dev/sda3            218550600   7424548 200024336   4% /home
/dev/sdb1             51199116  39508876  11690240  78% /home/simon/win_c
/dev/sdb5            192988808 101852748  91136060  53% /home/simon/win_f
tmpfs                  1048576         0   1048576   0% /vtmp
gvfs-fuse-daemon      20641788   7417232  12175916  38% /home/simon/.gvfs

My thought is to:

  1. use gparted to shrink sda2 & sda3 to gain 100gb of free space
  2. install a new copy of OpenSUSE to the free space (same partitioning)
  3. do an rsync of everything from my current setup to the new one (from the Rescue prompt)
  4. ensure that I can boot into the new one and all is identical

Now I am not sure…

Should I delete the old partitions and slide the new ones to the left?

Or should I reinstall on the old partitions and then rsync back from the new to the old?

My big concern is booting after all is done. GRUB and me don’t seem to get along very well.

BTW, I will be physically disconnecting the sdb (XP) drive while I do all this to forestall any accidents).

Is this workable? Am I missing something important (probably :())

What about booting issues after all is done? How can I be sure I will be able to boot to where I want?

This is to be my weekend project and I want things to be mello.

Thanks,
Simon

#2

Just a quick thought re the booting . . .

Create a grub boot floppy (or CD if you have no floppy; that takes a bit more work). You can put just the grub shell on it, when you boot you’re in that shell and you do all the commands interactively on-the-fly. The “find” command (e.g., find /boot/grub/stage2) will tell you where the root partition is, so if you’ve added or deleted partitions you can easily find the kernel and from that deduce the root partition (for the kernel line). Bear in mind that the grub (-1) numbering aligns with the partition number from the table. What you’re doing could easily result in the partition number assignments not being the physical sequence on the drive. Besides grub shell boot media, you can also create it with a skeleton device.map and menu.lst; that way you don’t enter everything interactively but instead you edit the lines from the grub menu. However you approach it, with this project you need to be a bit familiar with grub; I would definitely not be doing the grub reconfig work here thru YaST.

Good luck.

#3

Thanks. Sounds a bit scarey. :frowning:

What about if after I delete the old partitions and move the new set to the start of the drive I just run the SUSE boot DVD and select ‘Repair’ and let it fix the boot issue?

Would that be likely to work?

Simon

#4

It might. But frankly, I’ve found the Repair System on the DVD to be a bit flakey. In particular, it has a propensity to break the menu.lst file. I would definitely want to have a backup mechanism.

Grub isn’t really difficult to work with, once one understands the fundamental rules, e.g., the driver/partition numbering, alignment to the bios boot sequence, how grub boots from the MBR, and the basic menu.lst commands. If you don’t, you’ll be completely reliant on the DVD, and won’t be able to verify if what it is doing is right or determine what it might be doing wrong.

#5

So, Simon, were you successful converting your ext3 partition from 256-byte inodes back to 128-byte inodes? Did you have a mellow weekend, or did you pull out your hair? Do you have any hints which you’d like to share?

Thanks,
Dave

#6

One gotcha to watch out for is that the partition UUIDs will change, so they won’t match the entries which name partitions by UUID in /etc/fstab, and in /boot/grub/grub.conf or /boot/grub/menu.lst. That will prevent your system from booting. So, after you have copied everything, you need to either change the partition UUIDs to match the menu.lst (or grub.conf) and fstab entries, or else edit menu.lst (or grub.conf) and fstab to make them match the actual new UUIDs for the new partitions.

You can view the UUIDs for the partitions with any of the following commands (I’m using /dev/sda1 as an example):

blkid /dev/sda1

/lib/udev/vol_id /dev/sda1

tune2fs -l /dev/sda1 | grep UUID

Under Fedora you could also do:

ls -l /dev/disk/by-uuid/

You can change the UUID for a partition like this:

tune2fs -U “desired36charUUIDstring” /dev/sda1

Dave Burton
Cary, NC
Geeks Alive! Computer Rescue - 481-2183