Hi all,

I had some problems with my root partition, some errors in the file system which caused the system to remount read-only... don't know exactly. But it is only this partition, not the others on the disk.

So, I started ubuntu from CD and used gparted to create a new partition (without overlap with the broken partition) and copy the content from my root into the new partition.

So far, so good - everything is there, I can mount and see it...

But after I erased the old (broken) root, the system does not start anymore!?

My old root partition was /dev/hda2, my new root partition is /dev/hda4. They both have the same UUID because one is a copy of the other, I checked with "vol_id -u /dev/hda4"... (I think gparted uses dd to copy)


What I've done:

• grub: tried "grub-install /dev/hda" and start grub plus enter "root (hd0,3)" and "setup (hd0)"...
• menu.lst: I tried to manipulate the grub conf file menu.lst manually and replace (hd0,1) with (hd0,3) - remember, the UUID is the same, didn't need to change...
• fstab: Didn't need any change here either since /dev/hda2 (hda4) is not used anymore, the UUID is used and that's the same for the new partition...

Still: nothing!?

Any hints?

Maybe I have to cleanup the mbr and reinstall grub? How can I do that?

If you don't have the root partition in your fstab grub will not be able to find it.... Also considering that your boot directory with your kernel is 90% within your root partition. Grub also told you with error num 22 which translates to error Partition not found.

So make an entry in your fstab stating the root partition as /dev/hda4 point grub to this partition and you should be set.

Reinstalling grub also is an option, but as far as me is to much hassle.

Greetings Zhjim

First off: thanks for your reply!

No, there is an entry for the root partition in my fstab... it uses the UUID in the front, then mount point "/", then the options - not the "old" /dev/xxx pattern (why have these UUDI's been introduced anyway??). The UUID is the same for the new partition so I thought the fstab didn't need a change...

Do you think I can still write /dev/hda4 in the fstab instead of that UUID stuff? I'll try that later (when I'm home again ;-) ).

I would find that extremely unlikely.
Re-gen the UUID, or use the old /dev/[sh]da? namespace.

How could I re-gen the UUID? "vol_id" is for reading only, isn't it?

OK, I found this one here:
http://paulgoscicki.com/archives/200...schizophrenia/

So, using dd for cloning partitions DOES also copy the UUID... very UNIQUE... ;-)


The following command creates a new UUID:
tune2fs -U random /dev/hda4


Hopefully I can generate a new UUID, enter that in both the fstab and grub/menu.lst and be fine... :-)

"man uuidgen" would be a good start.
As you noted above it needs to be amended in both menu.lst and fstab.

YES!!

It turns out the UUID really was copied and need not be changed after all. I simply cloned the defect partition to a new one, that new partition was assigned the same UUID (by using gparted - or dd in general). After that the old (erroneous) partition could be deleted...

Only thing I did wrong all the time is re-installing grub: it was no wonder installing didn't work out - booting ubuntu from CD means that the partition is mounted somewhere but not "/", so when installing grub the

grub-install --root-directory=bla "(hd0)"

is needed!!

plus: the partition entry with correct UUID is need in both /boot/grub/menu.lst and /etc/fstab, AND an entry for the hard disk device (for me (hd0) ) is needed in /boot/grub/devices.map!

Now it works just as I wanted it to! But thanks anyway: I learned a lot about UUIDs... :-)

As did we all I suspect.
Personally I don't like using UUID, as I use a lot of different distros, and wind up reformatting (and moving) a lot of partitions.
Just causes grief IMHO.

UUID has its place in Linux and I thought the OP has handled it rather well.

Ubuntu is among the early distros switching to by-UUID method to identify a hard disk partition. This scheme works OK in SCSI/Pata/Sata/USB disks because a withdrawal of an old disk and insertion of a new disk can upset the disk names making it nearly impossible to pin down which one is sda, sdb, sdc etc.

For example one can run happily a Sata as sda but an insertion of a Pata can make the same Sata to become hdb because certain mobo scan the Pata controller first before scanning the Sata controller. ALthough SCSI disks are not common in the home computer market but an eSata disk may run as a SCSI variant and will grab the sda status if inserted, making the original Sata sda to become sdc. A lot of unknowns have yet to come out and so the by-uuid method should not be dismissed out of hand yet.

OK, I see there are advantages! Just came very surprising and it is also surprising that cloning a partition causes the same UUID... ;-)


I have another (or follow-up) problem: the new partition has errors, that's what ubuntu tells me when booting - but there are none: I checked using the Live-CD!

Does cloning a partition also clone file system errors!?

Please have a look at http://www.linuxquestions.org/questi...87#post2875387

Yes.

In using dd the program reads the "1" and "0" of the source disk/partition in the number of sectors defined by the bs parameter and duplicates them on the specified target.

You get exactly 100% of the mirror image of the original, including the filing system, boot sector, errors, virus etc etc.

I think the by-uuid is a product whenever a filing system is created and may be part of the filing indexing or accounting system in the boot sector. I have no idea how Linux would tackle two identical uuid names in the same disk. My guess would be the name is supposed to be unique and the kernel may load the first one it encounts. I did clone a few disks before but the same uuid was on different disk and nothing unusal was reported.

OK, so that is not what I wanted - I cloned the erroneous partition to get rid of the errors. It seems I still need to do a full new install!? :-(

Or is there a way to do a "cp -r" that includes keeping ownership and rights of the files being copied? Then I may get around a fresh install which I do not want since it usually takes ages until all software is installed as previously was...


That's also my impression. But actually, I didn't test it. What's handy here is that after cloning the UUID entries in fstab need no change! Only thing that has to be dine is setting root to the new partition (hd0,3) or what in the grub/menu.lst ...

Got the feeling you may be barking to the wrong tree.

The /boot partition contains nothing but the Grub directory, the kernel and the initrd files. If your root filing system has a problem then it has nothing to do with /boot. Therefore your /boot may be working perfectly.

The sequence of the event is Grub loads the kernel from /boot. Kernel does the hardware detection and loads the rest of the Linux from the / partition. You may need to do something about the partition that mounts /. This command should tell you something about the integrity of the partition

It was in deed two problems at the same time:

1. file system error The "old" partition had an error. Cloning it to a new partition also clones this error. I got around this problem by copying everything using "cp -r -p ...". Then I only needed to re-install grub and was all set.
2. last mount time in the future This is some strange issue that a lot of Debian / ubuntu users seem to have noticed. Some program (I am still unsure which one - maybe esfsprogs) writes to the partition with UTC and not using the timezone offset. So when booting the last mount time and last write time were in the future which is interpreted as an error - basically this is an endless process of booting, checking the file system and re-booting and checking and ... I live in the Berlin timezone (+2 hours), so all I had to do is shut down the PC and wait for 2 hours. After that it all went smoothly... ;-)