PDA

View Full Version : 18.04 cloned to SSD still mounts HDD as file system root



klandingham
August 23rd, 2018, 04:53 PM
Hi,

I'm trying to clone an existing Ubuntu 18.04 system that's installed on a 1TB hard drive (sda1) to run from an 250MB SSD (sdb1). Only about 30GB is in use on the sda1 partition. The steps I followed:

1. Booted from Live USB, and used gparted to reduce sda1 to 100GB
2. Used clonezilla (https://clonezilla.org/) to clone the reduced sda1 partition to the SSD.
3. Assigned a new UUID to the SSD partition (because it was identical to the HDD UUID after the clone)
4. Modified /etc/fstab on the SSD to use the new UUID of the SSD.
5. Ran update-grub

On reboot, the grub menu appears to include an option to boot Ubuntu from the SSD. If I choose that, the system seems to come up normally, but then lsblk indicates that the file system root is still mounted on the HDD (sda1), instead of sdb1. (which AFAIK means that the system is still running from the hard disk.)

What have I missed?

Thanks in advance.

oldfred
August 23rd, 2018, 05:32 PM
Are you sure sda is HDD?
Drive order is normally set by UEFI/BIOS and its write of what hardware you have to drive. Then operating system uses that. There are some files than can override defaults.

May be best to see details, use ppa version with your live installer or any working install, not older Boot-Repair ISO:
Post the link to the Create BootInfo summary report. Is part of Boot-Repair:
https://help.ubuntu.com/community/Boot-Info

klandingham
August 23rd, 2018, 05:48 PM
> Are you sure sda is HDD?
As sure as I can be...lsblk yields:

sda 8:0 0 931.5G 0 disk
└─sda1 8:1 0 931.5G 0 part /
sdb 8:16 0 223.6G 0 disk
└─sdb1 8:17 0 223.6G 0 part

sda sure looks like the 1TB hard drive, and the root "/" looks like it's mounted there.

This is an older system that does not use/have UEFI.

I'm likely too much of a noob, but I'm afraid I understood very little of the section of your reply that starts with "May be best...". I'll start reading the link you gave me.

Thanks for the help!

tea for one
August 23rd, 2018, 06:04 PM
I assume that you have cloned your OS to a SSD to improve the performance and then I suspect you may use your larger HDD for storage/back ups etc.

Anyway, I have been through a similar process recently and here is my suggestion:-

Why not simply unplug/remove the source HDD and only boot the newly cloned SSD?

Then, you can test that everything is in order on your SSD without having to concern yourself which disk is mounted and where it is mounted.

Also you would not have to worry about changing UUID etc.

Of course, when you're happy that everything is OK, then you can re-purpose your large HDD.

Best wishes

klandingham
August 23rd, 2018, 07:27 PM
Thanks...I actually tried that. When I selected any of the Ubuntu options on the grub menu, I saw the same error message, something like "...device not found..." and there appeared to be a disk UUID displayed as well. I haven't memorized the full UUID's, but based on the last two characters of that UUID, it appears grub doesn't know about the SSD's UUID. I find this confusing, since at least one of the grub options mentions "sdb1", which I believe means the first partition ("1") of the second drive attached to the SATA controller ("sdb").

Thanks for the help.

tea for one
August 23rd, 2018, 08:42 PM
Cloning is a tricky cove.........

Anyway, I suspect that you still have more than one drive attached to your PC (possibly it could be a USB stick).

Are you using Clonezilla from a CD/DVD or a USB device?

Did you clone using images or device to device. I have found that using images yields fewer difficulties.

If you only have one drive attached and you have reached a grub menu, sdb1 should not exist.

Possibly, when cloning, you reproduced a grub menu that included all the other information that has become superfluous.

I suggest that you attach the cloned drive only and try and boot from the first entry on the grub list.

If that fails to boot, try the second entry (recovery option) and see what gives.

Thirdly, go back to square one, update grub on your original HDD so that you only have one OS entry, reclone (using images) your 100GB sda1 partition and report back.

By the way, you have got a personal data back up?

Good luck

klandingham
August 23rd, 2018, 09:39 PM
Hi, thanks for the follow-up.

I have two SATA drives attached at this point, the 1TB HDD on channel 0, and the 250GB SSD on channel 1. I also have a PCI RAID card in this machine with two 500GB drives, which are connected to that card.

My end goal is to have the system running on the SSD, and move larger, less-often-used stuff to the HDD.

I did the clone from a Clonezilla USB stick. I started by creating a backing up of the entire HDD, stored on the RAID array. I then attempted a disk-to-disk clone, but CZ complained (rightly so) that the target disk (SSD) was smaller than the source disk (HDD). I found several approaches to solving this, and since I did have a backup, I decided to shrink the HDD partition down to 100GB so CZ could clone it to the SSD (only about 30GB was in use). I then did a partition-to-partition clone. After that, I rebooted from the HDD and mounted the SSD. The SSD's UUID was identical to that of the HDD, so I changed it. Then I modified /etc/fstab on the SSD, changing the UUID to the new one. Finally, I ran update-grub, thinking it would do the "right thing" (apparently it didn't). That's where things stand right now.

I think you're right about having a cloned grub configuration on the SSD - I need to read more about grub to know how to check/fix it. Does grub use partition UUID's?

I have tried booting with the HDD disconnected - that's when I get the "device not found" grub errors.

Thanks again.

tea for one
August 23rd, 2018, 10:27 PM
Hello again

That is a wealth of new information.

I think that this should have been mentioned in your original post.

Regrettably, I have no experience of setting up a RAID array nor cloning such a device, therefore I am very reluctant to offer new advice.

I found this on the Clonezilla FAQs:-


Clonezilla does support hardware RAID, if your RAID device is seen as /dev/sda, /dev/sdb, /dev/hda, /dev/hdb, /dev/cciss/c0d0... on GNU/Linux. Clonezilla does support this.
On the other hand, if it's Linux software RAID, no, Clonezilla does not support that.

Both hardware RAID and software RAID are beyond my sphere of knowledge.

I'm sorry that I could not help further

Best wishes

I've just had a second thought.

In effect, because you have back-ups and your cloned drive does not quite function correctly, why not take a punt?

Remove all drives except the cloned SSD
Enter the recovery menu and update grub.
Failing that, use a live Ubuntu USB to update grub.
See what transpires.

klandingham
August 23rd, 2018, 11:56 PM
Hello again,

I guess my first post, in which I tried to outline the steps, wasn't detailed enough. Sorry.

I believe I have it working now, but I don't think I fixed it properly. I looked into the grub.cfg (on the HDD) and found the entries for booting from the SSD drive. I have no idea how or why, but in each of those entries, the lines specifying the kernel file had the HDD UUID as the "root" argument, instead of the SSD's UUID. I manually changed those, rebooted, and now sdb1 is mounted as the file system root.

I don't think this was the right thing to do, as all indications are that I shouldn't be manually editing that file. But after reading that editing /etc/grubd/10_linux was the proper approach and looking at that file, I'm baffled as to what would need to change there.

Thank you for your efforts!

oldfred
August 24th, 2018, 12:51 AM
You should not be editing grub.cfg which is recreated with sudo update-grub or an updated kernel or grub files.
And you do not update scripts.

If booted correctly into SSD, you should just need to do this to update entire menu.
sudo update-grub

Best to post link to summary report from Boot-Repair. It shows all sorts of details in one place.

klandingham
August 24th, 2018, 03:40 PM
Right. I didn't think editing grub.cfg was the correct approach.

I think I am almost there. I rebooted and chose the SSD boot option from the grub menu (it was 4th item) bypassing the default. Once running on the SSD, I did an "update-grub" as suggested. I followed that with "grub-install /dev/sda" (I was missing this point...if I understand correctly, if you change the grub configuration you must then reinstall it in the MBR section of the first boot drive as configured in the BIOS). Also, it appears that when updating, the current configuration gets put at the top of the grub menu.

I thought I was in good shape at the point, and rebooted. The SSD option is indeed at top of the grub menu, but alas, the default option has now become the 4th one down, the HDD boot! No idea why that happened.

I did follow the steps to create (and upload?) a Boot-Info report as suggested. The generated reference URL was paste.ubuntu.com/p/rbpTygSjf7/

Thanks for the help.

oldfred
August 24th, 2018, 04:05 PM
The only issue I see is that the grub in the MBR of sda is booting sdb's install.
Both installs have separate UUID & grub in each seems to be correct. Boot into sda & install grub to sda from there.

But these type of issues is why I typically suggest a new clean install. It takes about 10 minutes to install to an SSD, and after about an hour I have system fully configured. You just then restore /home and reinstall list of installed applications.
It also confirms if you your backup procedures are correct. And you still have old drive, in case your backup missed something.

klandingham
August 24th, 2018, 04:08 PM
Finally have this straightened out.

Thanks all, for the guidance.

davidf1234
October 3rd, 2018, 01:12 AM
Hi, my issue sounds very similar to yours. I have not tried removing the original HDD yet.

If you would not mind, could you share how you solved your problem? Please let me know thanks!

wildmanne39
October 3rd, 2018, 01:19 AM
Hello davidf1234, please start your own thread that way you can get the help you need.

Thanks