[Solved] fstab UUID's are no longer valid after disk change from MBR to GPT

[ineuw]

I had to change one of my data drives from MBR to GPT for Windows 10, but their old partition UUID's still exist in fstab. There was no change to UUID of the Windows and Linux Mint boot partitions, except that swap file UUID changed because it is on the changed drive. There is no data risk. Everything was backed up.

I am still in Windows, not daring to start Linux Mint because I don't know what can happen, and what should be done to avoid the unpleasantness of reinstalling LM? Again there is no data files at risk.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Linux Mint 19 Cinnamon 64 bit desktop. 8th generation Intel Pentium CPU, 16gb RAM, 1 x 120gb SSD for boot, 2 x Seagate barracudas for data. (500 + 1000 mb)

[rene]

fstab doesn't generally specify filesystems to mount by partition ID or UUID but by filesystem/swap UUID; certainly it does so by default on Mint so unless you explicitly changed things there should be no change necessary, assuming the filesystems/swap themselves were untouched.

You in any case need not worry. Even if necessary after all, you can just boot a Mint Live USB/DVD, figure out the new UUID's and change the installed system's /etc/fstab from there.

But before getting into that... just try and boot; unless you did something non-standard, things should just continue to work.

[ineuw]

You in any case need not worry. Even if necessary after all, you can just boot a Mint Live USB/DVD, figure out the new UUID's and change the installed system's /etc/fstab from there.

But before getting into that... just try and boot; unless you did something non-standard, things should just continue to work.

Thanks for the reply, but it would not go past the Linux Mint logo to boot. How would it be possible for the LM Live USB to access and edit the fstab file of another system? Isn't it protected? I have the 64bit Boot recovery USB, Gparted USB, and of course the LM 19 live USB and the installation boots from the EFI partition,that much I know that / root is where the boot flag is.


--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Linux Mint 19 Cinnamon 64 bit desktop. 8th generation Intel Pentium CPU, 16gb RAM, 1 x 120gb SSD for boot, 2 x Seagate barracudas for data. (500 + 1000 mb)

[catweazel]

How would it be possible for the LM Live USB to access and edit the fstab file of another system? Isn't it protected?

That's how old wives tales start. Unless the drive is encrypted, you can take @rene's advice and make the change.

[ineuw]

How would it be possible for the LM Live USB to access and edit the fstab file of another system? Isn't it protected?

That's how old wives tales start. Unless the drive is encrypted, you can take @rene's advice and make the change.

The drive is not encrypted, But before starting a tale as an old wife I must ask. Have you tried it? If so, What would the steps be?

[catweazel]

The drive is not encrypted, But before starting a tale as an old wife I must ask. Have you tried it? If so, What would the steps be?

Boot the live USB, mount the OS and sudo nano -w /<mount.point>/etc/fstab. Ctrl-o to save, ctrl-x to exit.

Use sudo blkid to get the drives UUID before editing fstab.

[ineuw]

Boot the live USB, mount the OS and sudo nano -w /<mount.point>/etc/fstab. Ctrl-o to save, ctrl-x to exit.

Use sudo blkid to get the drives UUID before editing fstab.

Thank you, that's what I figured out about a minute before your first post. In earlier times I tried without 'sudo' and failed. All I did was to leave the boot UUID's and erased everything else. It's easier for me to rebuild fstab in my normal LM working environment. Thanks again.

[catweazel]

Thanks again.

You're most welcome.

[tenfoot]

Hi Catweasel

Why are you in disguise?

[catweazel]

Hi Catweasel

Why are you in disguise?

The goatee is accurate.

[rene]

Thanks for the reply, but it would not go past the Linux Mint logo to boot.

Had to be away shortly after replying; it not simply booting through would imply you did more than minimally convert from MBR to GPT. Perhaps recreate the partitioning? If it got as far as the logo then it's by the way also likely that you were just in a time-out: systemd invokes a 90 second time-out when it can't find its configured swap or a filesystem to be mounted at boot. If you wait it out you boot into the system without it/them enabled/mounted.

In any case: I see all's sorted now...

[ineuw]

Thanks for the reply, but it would not go past the Linux Mint logo to boot.

Had to be away shortly after replying; it not simply booting through would imply you did more than minimally convert from MBR to GPT. Perhaps recreate the partitioning? If it got as far as the logo then it's by the way also likely that you were just in a time-out: systemd invokes a 90 second time-out when it can't find its configured swap or a filesystem to be mounted at boot. If you wait it out you boot into the system without it/them enabled/mounted.

In any case: I see all's sorted now...

I am amazed how insightful some people are. It happened exactly as you wrote. On the first try, I quit before letting the 90 second time out expire. On second try, I exercised more patience. Now that I know, I came to realize that the lack of patience cost me hours spent on reinstalling LM at an earlier date. This is akin to the story of a movie goer who after seeing the MGM lion appear on screen, left the theater because he was sure that he has seen the film earlier.