[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 26, 2017 5:35 AM
From: deblis@lionunicorn.co.uk

On Thu 25 May 2017 at 16:41:37 (-0400), Fungi4All wrote:
> 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.

… and I get the impression that that's exactly what you did:
1 dd
2a "log in sda5" (is that mount, or boot?)


2b edit an fstab file (to what purpose, at this point?)

Why would I edit the fstab in the original installation that I copied from?
From sda5 I edited the new copy on sdb5 but sda5 did not boot my first
time around.  The fsck messages I could only think were pertaining to
something wrong in the new partitions but even IT did not make sense.

3 run update-grub

Yes, thinking that at least this would fix the original booting up.
Either source or target wouldn't matter.

Assuming that your copies are good, and that the apparent
"alterations" to sda… arise from misunderstanding or misinterpreting
UUIDs (or that they actually post-date your running update-grub), then
your problems arise from one or both of:

I had no intention to alter anything in sda, why would I.  It was just a
source to copy from an already functional system.  The only change
would have been an additional entry to grub.cfg in sda5 for booting to

Booting into sda5 with both devices sda and sdb connected,
Running update-grub with both devices sda and sdb connected.

That only happened after I had already copied the "new" uuids on sdb5
to the fstab there.  Simple copy-paste of 5 uuids from /dev/disk/by-uuid

> > 1 - Does dd leave uuid targets as they are, does it create new ones, or does it copy uuid from source to target?

I assume that's your reporting of step 1.


> > 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.

Something about partition inconsistencies but the print was too small for me to read
in detail, never mind remembering.

Is that "log in"? What did you correct in fstab? What was wrong?

The only thing I did to fstab up to this point was at the target installation, not the original.
It took a few reboots trying to figure out why the source was so affected.  At this point
I think I got the target to boot but what it was doing as the entry of Debian on sdb5 it
would boot sda5 while using sdb6,7,8,9.  The reason I guess is because sda5 and sdb5
still had the same uuid.  At some point when I used gparted to check all 10 partitions and
create new uuids and labels, and redid both fstab to the new uuids I went back to sda5
and reupdated grub.  Then the entry for sdb5 was still booting up from sda5!
That is when I went into grub.cfg and discovered the two uuids used for that entry had
2 different uuids, for the same entry.  The first was sdb5 the next was sda5's uuid.

Is sda the same disk as it was when you ran dd? There's no reason why
it should be if the kernel races to label them sda and sdb. How did
you check?

Yes, dd run from a stick sdc "dd if=sda5 of=sdb5 bs=1M" then 6,8,9
7 was swap created with gparted, why copy it?  

Why does a system suddenly run an fsck?

It run on recovery so I can run update grub before a full boot-up.
Before the login root prompt it reported the disk problems that never
had before with the same disks.  But I'm pretty sure it checks filesystems
in every boot because I remember it says hit ctrl-C to skip filechecks.

> > 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 ....

Yes. I would expect grub to be completely confused about what to
write in …wherever/grub/grub.cfg and possibly have no idea which
MBR it related to, with two disks present.

With the same 2 disks grub had been updated before, at least 2 times
recently.  I don't understand you reasoning, but again:  After all uuid's
were unique and both fstabs have been edited and double-checked.
update-grub runs and on the next reboot it is asked on menu entry
Debian on sdb5 to boot and it boots sda5 because on its cfg file it has
2 different uuids for the same entry.
Any explanations?

> 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.

This makes me wonder whether you've taken on board Pascal's comments
re different types of UUIDs.

And when did fsck start handing out UUIDs to filesystems, let alone devices.

I have no clue what fsck did, I assumed at that point that leaving gaps between
partitions in an extended one was a problem and extended the end of a partition
to avoid the gap.  I am clueless of fsck's capabilities.

> > 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.

And we're left guessing what the contents are.
Do remind me, what is msdos3 here?

I am not on that system now, but it is a different system and it is a logical part.  
I remember 4 is the extended partition and the 5-11 are within it.

> > 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?

No idea. Again, we don't know what you've written where, when you say
"switched to all new uuids to clear up the mess". And what's the
"second installation"? What are you calling an entry, and a menu entry?

Instead of twiching my eyes to read uuids digit by digit and since once published
they are unique, at about the 3rd round I usded gparted and asked it to issue new
uuids, to make sure they are unique.
Grub at boot comes up and has some entries, ie
Debian 8
Debian 8 recovery
Debian 9
Debian 9 recovery
Debian 10

This is what I call menu entries.  They are separated in the cfg file bu groups 00
10  20  30 ... and contain sub-entries of the each installation, as recovery modes
and booting other linux images.  If they are not called menu entries this is what
I mean by entry.

> 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.

Well, that depends on whether you install it or just configure it.

If it exists in the mbr and grub as a package is installed in sda12 then updating
takes control of booting from sda5 and on the next boot the grub.cfg that matters
is on sda12, right?  If you I monitor, as I do, to only allow sda5 to ever update
grub the rest are there installed in case I ever need to use them.

When you generate a new grub.cfg file, grub collects bits and pieces
from the grub.cfg files it finds on the various partitions it guesses
are linux systems. This new grub.cfg will normally be written in
whatever filesystem contains /boot/grub/. However, that's not
necessarily the grub.cfg that was read and acted upon when you just
booted, nor necessarily the grub.cfg that will be active when you next
boot. You can demonstrate this to yourself by adding a word, say, to
one of the id strings.

So let's say I install lubuntu in a single new partition sda100, and reboot the
system Debian on sda1 for example, and flubuntu is not even there, there is
a /boot but no /boot/grub and I go and manually create a boot/grub/grub.cfg
and I write "all work and no play makes Jack a dull boy" will it make a difference
to Debian's grub?  I believe it will find the /boot and the images there and 
write a "menu entry" to properly boot flubuntu and even display the available
kernels to boot from.  Now if I boot flumuntu, install grub, then the "...Jack" will
be replaced with new entries.  This has been my experience.
Nothing to do with auto-updating and replacing one uuid and leaving an old
one in there for the same "entry" "pick" single booting option which caused
unnecessary havoc.

A grub-install, the one that writes typically to the MBR, will make
future boots read the new configuration file.

Thus, if you maintain a backup linux installation on your machine,
and the kernel is updated on the backup, the new grub.cfg that is
then configured will have no direct effect on booting. However, if
your backup system gets an update of its grub package, that will
write a new boot image, and now the backup's grub.cfg will be the
active one on next booting.

Perfect agreement, by experience this is exactly how it has worked
from day one of ever seeing a grub screen.  I have not even hinted

> [various complaints] I think this is grub's fault.

I'm not sure blaming grub will help you straighten out your system.
I only hope that one of your disks still carries a suitable clone
of the other.

1st of all my problem was all figured out and both work fine, is not
a matter of trying to fix anything.  I had it all fixed the night/morning
before I wrote the message.  

What I am looking for is an explanation why grub on its own will
blend two different uuids for the same "entity" and booting action.
It labeled the entry on its own,  Debian 9 on sdb5 and its single
action contained two different uuids  that I did not edit. It would
then proceed with booting and end up on mounting sda5.  
Because the one id it had was from sdb5 the second
was from sda5.  Sda5 was all correct at that point, but on grub's
primary and residing entry it does not even use a uuid.  Right?


cheers back

Reply to: