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.
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.
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.
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?
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):
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: