[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Intresting dd fsck grub uuid fstab action



-------- Original Message --------
Subject: Re: Intresting dd fsck grub uuid fstab action
UTC Time: May 25, 2017 8:57 AM
From: pascal@plouf.fr.eu.org

Your lines are too long.

I didn't know that was a problem, I've learned to write and only hit return on -->
a paragraph.


Le 25/05/2017 à 05:11, Fungi4All a écrit :
> I experimented in switching a clone of my sid installation to an experimental, that was the plan.
> Since I was doing other things I thought I'll let the cloning take place unattended.
> Let's say sda5/6/7/8/9 were to be cloned to sdb5-9 (5 / 6 var 7 sw 8 tmp 9 home) all b partitions were slightly larger.
> I used dd bs=1M for each one and though all I had to do is log in sda5 edit the sdb5 fstab and then update-grub.
>
> 1 - Does dd leave uuid targets as they are, does it create new ones, or does it copy uuid from source to target?

dd does not care about UUID or any other metadata. It just copies every
bit of data. Filesystem UUIDs and labels are part of the data, so are
cloned verbatim if you clone the partition. Partition UUIDs and labels
(mostly used on GPT partition tables) are part of the whole disk data,
so if you clone the whole disk, you also clone the partition UUIDs and
labels.

I didn't know this, I thought uuids are only created during partition creation
and are not part of the partition's contents.  I've used dd for backup several
times but in temporaty mediums, not within the system.  I rarely have two
drives in one box.  I didn't copy the whole disk, just specific partitions of the
one disk into similar ones on the 2nd.

> 2 - When I rebooted sda5 was not booting up properly. Eventually I checked
its fstab and corrected it but at this poing the system run an fsck and I got
some errors and hit y,y,y,y, for fixing. I don't know if the errors came from
uuids existing in the system twice.

Did you clone the partition while it was mounted and used ? Then you
cloned a filesystem in a dirty state, no wonder why fsck found errors.

No, I'd never do that, but I did once trying to clone a live copy of a system on
top of a mininmal debian installation.  That tought me not to copy dev and
media while they are alive, becuase that may incoprporate all the mounted 
disks :)  No I used a different system on a different partition to copy a parked
debian sid.


> 3 - Updating grub seemed to have made a bigger mess as now I could
boot up but the partitions were mixed up between sda and sdb parts. It
would boot-up on root / of sda and have a home in sdb9 ....

If the cloned disk is intended to be used in the same machine as the
original one, you should change all identifiers, UUIDs and labels,
otherwise GRUB and libblkid will be confused with duplicates. One "U" in
UUID stands for "unique".

I know, it is in trillions or more a chance of creating two of the same in a life
time.  The first thing I did after dd was done, was to make a txt table of all
the sda* sdb* in order with uuids and rewrote the fstab on sdb, I thought 
the sda would be as it was.  But wasn't.  It wasn't all uuids that transfered
but seem enough for me not to notice they were the same and for sda5
to boot up and discover the discrepancy.  I speculate that fsck then instead
of giving sdb a new uuid it altered sda.  By the time the check was done
and I run grub-upd some of the uuid in grub belonged to sda partitions and
some on sdb.
By copying from sda to sdb I never thought the original would be affected, 
only the target needed fixing.  That threw me off.  But on the new grub.cfg
both entried would boot from the sda but with remaining partitions being 
a mismatch.

> 4 - Eventually to stay safe I booted from live usb and edited all the
partitions, gave them separate labels to avoid any confusion (as "Deb
on Sda6 var..."_) and switched to all new uuids to clear up the mess.
Re-edited fstab on bot sda and sdb (hd0 and hd1 dos5) and rebooted
sda and updated-grub again.

By default update-grub uses only filesystem UUIDs, not labels. So even
if you change labels, if multiple filesystem have the same UUID, any of
them may be selected.

You missed the point.
Here are some lines as an example

if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3 --hint='hd0,msdos3'  UUID on sda3  XXX
else
  search --no-floppy --fs-uuid --set=root UUID on sda3 YYY
fi
insmod png

On a correct grub both of those uuids are the same.  I ended up with two different ones without editing grub.cfg
I discovered this after I had made sure that all UUIDs are unique and both fstab files were correct.  I updated grub
and it would still only boot sda on the sdb entry.  The entry label itself would say Debian on sdb5 and it would boot
on sda5.  That made me think of looking at grub.  I replaced the mismatched uuids manually and it booted like A1

> 5 - Here is the unexplained part: My sda5 system booted up fine and normal, when I would try sdb5 the second line would say debian clean on sda5!!!
> So I went into grub.cfg to see what is going on. On the menu entry of the second installation the first line of each entry would have the proper sdb5 uuid, the following line - which I believe is the actual command - had the uuid from sda5. So, am I to assume that grub when it updates only replaces the first line of each entry expecting the next uuid will be the same, even if it is not?

When creating menu entries for another Linux system, update-grub copies
the contents from grub.cfg of the other Linux system, if it exists. So
check that grub.cfg on sdb has beed updated properly.

I don't use grub on sdb, I only use it on sda (not sda5) but sda5 is managing grub
for all partitions.  As far as I understand bios reads the MBR and the MBR tells it to
go and read the cfg. from /sda5/boot/grub/grub.cfg in what to do.  I know if I boot
up something on sda12 and install or reconfigure grub in there then 12 will
take control of booting all other bootable partitions in the system.
I can rename I think the boot/grub copy in sdb5 into deadgrub and it will not affect
anything.

Now, why on an everything fixed system update grub will end up having on the same 1
entry the above first line with uuid from sdb5 and a second line the uuid from sda5
I think this is grub's fault.  When I edited manually all the correct uuids both systems
booted up and had the other's partitions as mountable but not mounted.  On each
system I only have the system and home partitions in the fstab, everything else is
mounted optionally with sudo priviledges.  Unless I use the mounted volumes I 
unmount them.  That is my routine practice.

(AK)

Reply to: