The board will go down for necessary maintenance at 12:00 PM UTC (see current UTC time). We expect to be back 1 hour later at 1:00 PM UTC. Apologies for any inconvenience.

[Solved] New system, reusing old install?

Questions about Grub, UEFI,the liveCD and the installer
Forum rules
Before you post please read how to get help
mdevour
Level 2
Level 2
Posts: 70
Joined: Fri Aug 08, 2014 8:24 am

[Solved] New system, reusing old install?

Post by mdevour »

If you'd like to skip the torturous gyrations I go through in this thread, you can skip to my post that lays out the best approach I came up with...
viewtopic.php?p=1834575#p1834575

***

Up until a couple of weeks ago I was running Mint 19.2 on an older HP Pavilion mid-tower with an Intel quad-core, a few gigs of ram, an elderly nVidia card, root on a 500GB SSD, /home on a 750GB HDD, and a 2TB drive for backups. I had Timeshift backing up / and BackInTime backing up /home to the 3rd drive.

The thing started getting unstable, booting into the Mint 19 desktop with not everything working right. Then it stopped booting from the SSD at all and resurrected the Mint 17-something install I had preserved at the front of the backup drive from a previous upgrade. Then the power supply and/or motherboard finished dying, and it stopped even powering up.

I tell you all of that so you know how Mint was configured on the old hardware.

I just built a new machine. :D Ryzen 9 3900 X 12-core CPU, 64GB RAM, ASUS Crosshair VIII Hero MB, Geforce RTX 2080 GPU, and Corsair 1000W PSU and Carbide Spec-02 case. A big step up! :mrgreen:

As best I can, I'd like to bring the 19.2 installation I was using forward to the new hardware, to avoid having to re-install all my applications and customizations.

I just did a fresh install onto the SSD, with / and /home in separate partitions using up the drive. I had to add an EFI boot partition to the beginning of it. This tells me my SSD wasn't damaged.

Please tell me if I've got the rest of this right...

I can install the drive that has my old /home partition on it, do a fresh install to the SSD and tell it to re-use the old /home partition without formatting it! This ought to restore most of my settings and UI tweaks, at least, plus things like my browser history and bookmarks, right?

What it won't do is re-install all of my apps. For that I should run TimeShift and tell it to restore a recent system image? Will that work, hopefully? To do that I'll need to reprise the steps I learned about how to mount my backup partitions in my previous thread, first:

viewtopic.php?p=1724846#p1724846

I hope at that point the rest of my programs will be re-installed and working normally again. If everything is perfect I'll be able to install the latest updates and carry on as if nothing happened... much more quickly. :wink:

Now, how hopelessly naive am I being? Will Mint and the rest of my applications be resilient enough to survive transplant onto such radically different hardware? :shock:

I'm looking for any guidance, pointers, criticism, or encouragement you think I need before I move ahead. Thank you!

Mike D.
Last edited by mdevour on Fri Jun 26, 2020 8:36 pm, edited 2 times in total.

DisturbedDragon
Level 3
Level 3
Posts: 156
Joined: Mon Oct 29, 2012 6:29 pm
Location: Texas

Re: New system, reusing old install?

Post by DisturbedDragon »

So long as you booting the system the same, BIOS or UEFI, then just pop the drive in the new computer and boot. Done it several times with no issues. Hardware will be recognized at boot. After that just use driver manager for any needed proprietary CPU/GPU/NIC drivers.
AMD Ryzen 9 3950X 16C/32T | MSI x470 Gaming Pro | 1TB Crucial P1 NVMe | 1TB Samsung 960 Pro NVMe | 32GB DDR4 3200 | Nvidia RTX2080 OC | Linux Mint 20.0 Cinnamon

mdevour
Level 2
Level 2
Posts: 70
Joined: Fri Aug 08, 2014 8:24 am

Re: New system, reusing old install?

Post by mdevour »

Thanks for the response, DisturbedDragon. I think the old install was doing a BIOS boot, which is why I didn't have an EFI boot partition on the drive already. So, I'm definitely asking if restoring a TimeShift image from the old install over the top of the newly installed / partition will clobber anything important? :shock:

DisturbedDragon
Level 3
Level 3
Posts: 156
Joined: Mon Oct 29, 2012 6:29 pm
Location: Texas

Re: New system, reusing old install?

Post by DisturbedDragon »

In theory it should work fine. EFI is separate partition so it will not be touched.

Just as easily I think is to install new with new EFI partition and / partition. Use the existing /home partition where all your user settings and preferences are stored, just don't format on install.

You would have to install anyway to use Timeshift restore. No need for the extra step. Installing a couple applications after this should not take long at all.
AMD Ryzen 9 3950X 16C/32T | MSI x470 Gaming Pro | 1TB Crucial P1 NVMe | 1TB Samsung 960 Pro NVMe | 32GB DDR4 3200 | Nvidia RTX2080 OC | Linux Mint 20.0 Cinnamon

zaileion
Level 4
Level 4
Posts: 268
Joined: Sun Jan 25, 2015 6:01 pm

Re: New system, reusing old install?

Post by zaileion »

I have used TimeShift to restore an OS on multiple different computers. In fact I did a base install created a full backup of everything using TimeShift and simply do a restore on wnatever computer i want to put it on. Different RAM, different hard drive size, etc...

Here is one of my posts using timeshift on the same laptop with a new larger hard drive. Worked like a charm. viewtopic.php?f=42&t=304585&p=1708328&h ... t#p1708328

Simply boot the computer using Linux Live USB, connect your backup drive, run TimeShift to complete the restore and watch the magic. Amazing software TimeShift is!!

mdevour
Level 2
Level 2
Posts: 70
Joined: Fri Aug 08, 2014 8:24 am

Re: New system, reusing old install?

Post by mdevour »

Thank you for the reply, zaileion. You encourage me to trust TimeShift, with good reason.

However!

On the newly installed Mint 19.2 with / on the SSD and /home reusing the partition on the first HD, I created a directory /mnt/backup, chowned it to me, and modified fstab to mount it. Re-booted and TimeShift now sees all of my backups! 8)

I then instructed TimeShift to restore a recent system snapshot. It presented me with a list of about a half-million files that had to be created or restored. I carefully inspected every one of them... yes I did. Really...

It looked worth trying, so I set it loose. A gazillion lines flew up the screen for a number of minutes. It ended with a few lines of messages about doing something with grub, I think.

And... my SSD does not show up as a bootable device, and the system boots to the UEFI setup screen.

So it looks kinda like TimeShift did something to bollux up the EFI boot arrangements on the SSD.

I don't really know what questions to ask next, aside from "What can I do now?" :oops:

I can boot into the live USB I installed from, and mount the partitions Mint knows about. What to do from there I don't know yet. I feel like I'm close, though. This ought to be doable!

Help? :|

Mike D.

mdevour
Level 2
Level 2
Posts: 70
Joined: Fri Aug 08, 2014 8:24 am

Re: New system, reusing old install?

Post by mdevour »

Following up on my previous post...

viewtopic.php?p=1832007#p1832007

I've been trying to peel the onion on this. It's maddening trying to even decide what search terms to use.

I just finished trying to at least look at what's in my EFI partition from a LIVE USB session via the install media. Following instructions to sudo fdisk -l to identify the EFI partition ID (sda1), then sudo mount /dev/sda1 /mnt to supposedly mount it so I can then do things like browse with caja or the command line.

All the commands executed without complaint. Nothing appears to be mounted. It isn't there in caja(as superuser) and ls /mnt returns nothing. Oh, and if I execute the mount command a second time it says it's already mounted! What gives?

Or any other advice relevant to my topic, please...

Thank you,

Mike D.

User avatar
zcot
Level 5
Level 5
Posts: 998
Joined: Wed Oct 19, 2016 6:08 pm

Re: New system, reusing old install?

Post by zcot »

When you did the timeshift restore you should've unchecked the options about the bootloader stuff, since you changed schemes.

At this point, boot the live session making sure you are booted in uefi mode, do a full chroot to the installed system then install grub from there, something like sudo grub-install sda. Don't be confused about sda1 /boot partition, just install to the device and it will do the right thing in uefi mode. See if that brings you back up, -reinstalling grub from a proper mode chroot effectively "in the installed system".

mdevour
Level 2
Level 2
Posts: 70
Joined: Fri Aug 08, 2014 8:24 am

Re: New system, reusing old install?

Post by mdevour »

zcot wrote:
Sat Jun 20, 2020 11:56 pm
When you did the timeshift restore you should've unchecked the options about the bootloader stuff, since you changed schemes.
Thank you, zcot. In the version of TimeShift I'm running (fully updated install of Mint 19.2) I don't see any "leave the boot stuff alone" kind of option in the Settings dialogue. Is what you're thinking part of the Restore dialogue?

The reason I'm asking is that I decided to re-install last night and do all the updates so I had a fully running system. This was after a fiasco with Boot-Repair that left me with a mongrel combination of kernel and nVidia drivers that triggered a Secure Boot error message that scrolled endlessly up the console screen. :roll:

So I'm back to a known safe state right now, where I ought to be able to retrieve all of my installed apps by "rolling back" to a recent snapshot IF there's a way to keep TimeShift from clobbering bootup.

I think I'll tweak in TimeShift so it sees my backups again and try running it to see what the options are...
At this point, boot the live session making sure you are booted in uefi mode, do a full chroot to the installed system then install grub from there, something like sudo grub-install sda. Don't be confused about sda1 /boot partition, just install to the device and it will do the right thing in uefi mode. See if that brings you back up, -reinstalling grub from a proper mode chroot effectively "in the installed system".
I'm hazy on chroot without further study... Basically it effects the current console session and directs any output or modifications to the filesystem you've pointed it at? I can try this if TimeShift doesn't work on my second try.

OR, I can take Disturbed Dragon's eminently sensible suggestion to just start from where I'm at right now and manually re-install the 30 or so applications on my list... :mrgreen:

Thank you, folks. I really appreciate the active Mint community. It's an amazing distro, and you're here when I need you.

Mike D.

User avatar
eastrader
Level 1
Level 1
Posts: 41
Joined: Wed May 03, 2017 12:35 pm
Location: Dallas, Texas

Re: New system, reusing old drive install?

Post by eastrader »

I have a similar question. My laptop is failing, so wondering if I get a newer/used one with similar specs, can I remove my ssd and replace the drive in the newer one and boot up ok? Recommendations
Always learning.

User avatar
zcot
Level 5
Level 5
Posts: 998
Joined: Wed Oct 19, 2016 6:08 pm

Re: New system, reusing old install?

Post by zcot »

mdevour wrote:
Sun Jun 21, 2020 10:00 am
Thank you, zcot. In the version of TimeShift I'm running (fully updated install of Mint 19.2) I don't see any "leave the boot stuff alone" kind of option in the Settings dialogue. Is what you're thinking part of the Restore dialogue?
When you go to restore the snapshot look at bootloader options (advanced) and you can control everything there. See example: https://i.imgur.com/ZJTK4YH.png

User avatar
zcot
Level 5
Level 5
Posts: 998
Joined: Wed Oct 19, 2016 6:08 pm

Re: New system, reusing old drive install?

Post by zcot »

eastrader wrote:
Sun Jun 21, 2020 11:38 am
I have a similar question. My laptop is failing, so wondering if I get a newer/used one with similar specs, can I remove my ssd and replace the drive in the newer one and boot up ok? Recommendations
What we want you to do is make a thread of your own, there's nothing wrong with that, and it's encouraged. ;)

The simple answer is yes, because the kernel boots each time and detects the present hardware and acts accordingly based on that. Although if you have a custom nvidia driver in place, for one example, and get another laptop that doesn't have nvidia hardware then it will probably boot up into some hideous graphics mode, which you will then have to figure the correct solution for that even though it's probably easy.

But to get more into detail, then we become derailing mdevour's thread. ;)

mdevour
Level 2
Level 2
Posts: 70
Joined: Fri Aug 08, 2014 8:24 am

Re: New system, reusing old install?

Post by mdevour »

Okay, I just demonstrated that de-selecting any bootloader modifications while restoring a snapshot does not stop TimeShift from breaking the new install's UEFI boot setup when the backup is from a legacy BIOS boot system.

Among the first thing in the list of files is a whole raft of stuff in /boot and /boot/grub. That may have some effect? I didn't see anything to suggest TimeShift would be mucking about in the ESP, so I don't know why the drive stops showing up as bootable, unless the UEFI code traces the EFI boot stuff to its destination to make sure there's something there to boot?

Poking around further, I get the impression I might be able to boot the old snapshot by disabling the Secure Boot feature (enabling CSM, Compatibility Support Module), and letting TimeShift re-write the boot sector of the drive and reinstall grub?
...

Well, I just did that experiment. I enabled CSM in the UEFI, booted the live USB session, and figured out how to get TimeShift to see my backup partition... which meant opening Computer, right clicking on my backup partition and selecting Mount. With it mounted, I could use the Browse button in TimeShift to bring up the list of snapshots.

I carefully pointed the restore destination to the correct / and /home partitions, made sure re-installing grub was selected, and let'er rip. There were only a handful of files to be changed, including removing the /boot/efi directory and restoring a few others, since I'd recently restored all of the rest of the partition.

Indeed, I can now boot into my old install. The disk shows up as bootable in the UEFI, my original grub configuration appears to be there, and it eventually reaches the desktop.

All is NOT well, however! Clearly Mint is traumatized by waking up in it's new body...

As zcot has direly predicted, I've booted up into some hideous graphics mode!

Opening the Display app in Control Center, I'm using an "Unknown (default)" monitor, I'm locked into 640 x 480 resolution, the "detect monitors" button doesn't work and I can't change anything. The nVidia Settings app loads but presents a blank window with only Help and Quit buttons.

Driver Manager shows I'm using a "manually installed driver" and I cannot select either of the nVidia drivers that are offered. They're both greyed out.

I don't know if the display is the only obstacle, but it's the obvious first challenge. How do I get the system to reconfigure itself, or allow me to correct the settings?

I am so FREAKING close here! All my programs are re-installed, which was the whole point of this exercise in the first place, and those I've tried to run appear to be working.

I don't blame the poor thing for becoming confused, after all I've swapped the CPU, motherboard and GPU on it, spanning the greater part of a decade's worth of technological advances, and deprived it of an expansive dual monitor setup for a single, very small display... All between the time it went to sleep and woke up! I'd need therapy too. :lol:

I apologize for the way I'm bouncing all over the place, though I've had a reason for every staggering lurch.

If there turns out to be an easy way to reconfigure the video, I will be immensely grateful!

Thank you for all your advice and assistance.

Mike D.

User avatar
zcot
Level 5
Level 5
Posts: 998
Joined: Wed Oct 19, 2016 6:08 pm

Re: New system, reusing old install?

Post by zcot »

Working in 640x480 is hard, so first things first I would remove the nvidia driver and let the system automatically try to use nouveau(open source nvidia version).

Get a terminal and do some: apt purge nvidia --dry-run and see if it will list a package like "nvidia-340" or similar. It might likely also list nvidia-settings, nvidia-prime, and maybe something else too which should also be fine to purge. --dry-run is so it won't immediately just do the actions before you have a chance to see what's going to actually happen. If you like the looks of the output, up arrow and erase --dry-run(you can use the -s switch equally for a dry run, also --simulate is the same). Then reboot. Maybe you have to specify 'nvidia-*'. dpkg -l '*nvidia*' should give some clue as to what packages are currently installed.

User avatar
zcot
Level 5
Level 5
Posts: 998
Joined: Wed Oct 19, 2016 6:08 pm

Re: New system, reusing old install?

Post by zcot »

The best solution that I can think of if doing a snapshot restore in this situation would be telling timeshift not to do anything with the bootloader information, but also on the main screen you would need to mark the "/boot" directory(since you can't just skip that item), to be directed it at some irrelevant point like a temporary usb stick, or some other falsified partition area where you can trash it later. -this way the snapshot is really only replacing non boot stuff.

The best solution of all is reinstalling that initial fresh install in the same mode as the snapshot(bios/mbr scheme), then you don't have to deal with any of this at all when you deal with the snapshot.

mdevour
Level 2
Level 2
Posts: 70
Joined: Fri Aug 08, 2014 8:24 am

Re: New system, reusing old install?

Post by mdevour »

Both of your last two replies are excellent, zcot!

I ultimately used a command like apt purge '*nvidia*' --dry-run | grep -v 'not' to get a concise list of packages that were to be removed, excluding the hundreds of lines containing the phrases "not installed, so not removed" and "Note, selecting '<package name>' for glob..." Satisfied I wasn't removing the entire kernel or any such insanity, I ran it for real, then restarted.

It didn't change anything with the screen resolution or the display detection failure, but Driver Manager now was working again, showing nouveau installed and offering 440 and 335 version nVidia drivers. I chose the recommended 440 and again re-booted.

Yeehaw! Display's working again! <whew!> And it's using the nVidia driver.
The best solution that I can think of if doing a snapshot restore in this situation would be telling timeshift not to do anything with the bootloader information, but also on the main screen you would need to mark the "/boot" directory(since you can't just skip that item), to be directed it at some irrelevant point like a temporary usb stick, or some other falsified partition area where you can trash it later. -this way the snapshot is really only replacing non boot stuff.
Seeing as the default setting in TimeShift's Restore dialogue for /boot location is "keep on root device" it pretty much guarantees clobbering the boot files. As you say, it gives you the option of putting /boot somewhere else... So, yeah, mounting a little fake partition somewhere might work.

I could test that by re-installing fresh with efi boot, then, without doing any updates, restore the snapshot over the fresh install, turning off bootloader changes and mis-directing the /boot files to some safe place... I can imagine Timeshift being clever and deleting the existing /boot directory in order to move it to the alternative location... So keeping a copy of that directory somewhere else safe might help. If necessary, copy the original /boot back to root, and see if it still boots in efi mode. If nothing more subtle has been broken we'd be good!

Reading what I just wrote, it also seems likely that we could just preserve a copy of the /boot directory somewhere safe and copy it back after the restore operation clobbers the original? It would save trying to fool TimeShift and maybe having something else changed we don't expect...

The basic question we're addressing here is "How can you lift an existing install from BIOS to EFI boot without starting over from scratch?"

It can be approached from at least a couple of directions:

The one we're talking about, doing a bare-bones install to get the EFI boot setup working and restoring a snapshot of the system without clobbering /boot (or anything else important!).

Or, taking a fully working system that uses BIOS boot and re-writing the boot setup to work with EFI. Which, I assume is where your earlier suggestions about chroot and grub-install come into play?

I have what looks to be a working system now, and know how I got here. For that I am truly grateful to each of you who've offered advice and help.

I think I'll do a couple of these experiments just to see how they work and if I can streamline the process. Now that I know what to look for, I find there are lots of articles explaining how to convert BIOS to EFI boot in-situ, so I'm not doing much that's original. Perhaps combining a fresh install to establish EFI boot, and a method for doing a TimeShift snapshot restore that doesn't clobber the boot setup will be useful for others.

I'll report my results. Meanwhile, thank you, again, for all the help!

Mike D.

User avatar
zcot
Level 5
Level 5
Posts: 998
Joined: Wed Oct 19, 2016 6:08 pm

Re: New system, reusing old install?

Post by zcot »

Great news!

And I don't actually know how the stuff with /boot happens, but it seems to make sense. So in this case is it looking for where current /boot is mounted so that it could delete it and change it? I'm not sure if it will do that. It would seem, let's say on a really broken install where you're using a live session to restore, that the broken /boot is not readily known. I don't know how it comes out in the end though.

But great work on this mdevour! :D

pretty cool save, and a unique way to do this situation.

mdevour
Level 2
Level 2
Posts: 70
Joined: Fri Aug 08, 2014 8:24 am

Re: New system, reusing old install?

Post by mdevour »

About 3 weeks ago my elderly system died and I've built a new machine to replace it. I wanted to migrate my existing Mint 19.2 install to the new hardware.

The challenge was installing on a new machine that uses UEFI instead of BIOS, without having to start from scratch and lose all my settings and manually re-install more than 30 applications. The root disk was re-formatted and the TimeShift snapshots I have of my old system boot under BIOS.

The UEFI on most motherboards support BIOS or "legacy" boot by diabling Secure Boot or enabling some legacy compatibility mode. I felt it was time to update things, if I could do it without losing all of my user preferences and data.

After much experimentation and fiddling, I learned about two ways to do this. I'd like to report on both to the Mint forums by way of paying back a tiny bit of the help you've all given me. I'll do them in two posts for clarity. In this first method, I manually convert to EFI boot from a functioning BIOS bootable drive.

This process is well documented on the web and I'm not really offering anything new in this post. I've taken most of the following from this post on serverfault.com...

https://serverfault.com/questions/96317 ... -with-uefi

When I started following that guide, I was able to skip a few steps because in my gyrations I'd already done some of the preparatory work, including updating MBR to GPT, and creating an EFI boot partition. The disk still had a BIOS grub bootloader, however, and definitely booted under BIOS mode. If you're trying to do this from a different starting point, you will have to follow the steps laid out in the link above.

Here's what I had to do:

After booting into my working, BIOS compatible system, I first confirm whether the disk has an old-style MBR or the newer GPT. The parted command works for that.

Code: Select all

mike@dragon:~$ sudo parted -l
[sudo] password for mike:           
Model: ATA Samsung SSD 860 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  99.6MB  98.6MB  fat32              boot, esp
 2      99.6MB  500GB   500GB   ext4
I see that I have a fat32 formatted partition for efi with boot and esp flags set. So while my GPT is written with a BIOS grub bootloader, everything else is ready for conversion to EFI boot.

Now I ran gdisk to name the efi partition. I enter gdisk's prompt, use the p command to print the disk info, c to change the name of the partition, p again to confirm it, and w to write the changes and exit...

Code: Select all

mike@dragon:~$ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sda: 976773168 sectors, 465.8 GiB
Model: Samsung SSD 860 
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 7A191B99-EB69-4D49-8985-718563671FDE
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 4077 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          194559   94.0 MiB    EF00  
   2          194560       976771071   465.7 GiB   8300  

Command (? for help): c
Partition number (1-2): 1
Enter name: EFI-boot

Command (? for help): p
Disk /dev/sda: 976773168 sectors, 465.8 GiB
Model: Samsung SSD 860 
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 7A191B99-EB69-4D49-8985-718563671FDE
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 4077 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          194559   94.0 MiB    EF00  EFI-boot
   2          194560       976771071   465.7 GiB   8300  

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
As advised in the closing message from gdisk, I reload the partition table with partprobe so the system is using the updated table...

Code: Select all

mike@dragon:~$ sudo partprobe /dev/sda
Now run parted again to confirm the new table is in use...

Code: Select all

mike@dragon:~$ sudo parted -l
Model: ATA Samsung SSD 860 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name      Flags
 1      1049kB  99.6MB  98.6MB  fat32        EFI-boot  boot, esp
 2      99.6MB  500GB   500GB   ext4

I now took the additional step recommended in the footnotes of the above guide, to use my package manager to install the grub-efi metapackage, which removes and replaces the grub-pc package. Now I'm in a sort of in-between limbo state where if I tried to reinstall grub-BIOS I wouldn't be able to without reversing this step.


Now put a file system on the ESP with the mkfs command...

Code: Select all

mike@dragon:~$ mkfs -t vfat -v /dev/disk/by-partlabel/EFI-boot
mkfs.fat 4.1 (2017-01-24)
mkfs.vfat: unable to open /dev/disk/by-partlabel/EFI-boot: Permission denied
mike@dragon:~$ sudo mkfs -t vfat -v /dev/disk/by-partlabel/EFI-boot
mkfs.fat 4.1 (2017-01-24)
/dev/disk/by-partlabel/EFI-boot has 255 heads and 63 sectors per track,
hidden sectors 0x0800;
logical sector size is 512,
using 0xf8 media descriptor, with 192512 sectors;
drive number 0x80;
filesystem has 2 16-bit FATs and 4 sectors per cluster.
FAT size is 188 sectors, and provides 48025 clusters.
There are 4 reserved sectors.
Root directory contains 512 slots and uses 32 sectors.
Volume ID is 379c4ffc, no volume label.
mike@dragon:~$
Create the efi directory in /boot where the efi boot files will go on the root partition.

Code: Select all

mike@dragon:~$ sudo mkdir /boot/efi
Now use xed to edit fstab to add an entry for the /boot/efi directory...

Code: Select all

mike@dragon:~$ sudo xed /etc/fstab
Add the following line to fstab...

Code: Select all

/dev/disk/by-partlabel/EFI-boot /boot/efi vfat defaults 0 2
Now we should be able to install the Grub efi-mode bootloader.

First mount the target directory.

Code: Select all

mike@dragon:~$ sudo mount /boot/efi
Then run grub-install.

Code: Select all

mike@dragon:~$ sudo grub-install --target=x86_64-efi /dev/sda
Installing for x86_64-efi platform.
EFI variables are not supported on this system.
EFI variables are not supported on this system.
grub-install: error: efibootmgr failed to register the boot entry: No such file or directory.
mike@dragon:~$ 
I have no clue what those warnings are about, but they didn't seem stop me from finishing the process successfully.

At this point, re-boot and enter your UEFI setup screens, switch off compatibility mode or enable EFI mode, as needed on your system. Then re-boot again. Your installed system should end up in control and working. It took two boots for me, and I don't know why.

Now one final step, and we can do some testing...

Run grub-install again so it can update the UEFI boot selector...

Code: Select all

mike@dragon:~$ sudo grub-install
[sudo] password for mike:           
Installing for x86_64-efi platform.
Installation finished. No error reported.
mike@dragon:~$ 
And that should be it!


As a final test to prove to myself it was booting in EFI mode, I ran caja in superuser mode (sudo caja) and renamed the /boot/grub directory to /boot/bolluxed_up_grub, thinking that it would still boot if the /boot/efi directory was all that was needed, or else hang up, indicating the BIOS boot process was broken.

I re-booted into my UEFI settings and verified that it still saw the bootable drive. Exited and reset, and the boot process hung with an error message saying it "could not find file:/boot/grub/efi-something-or-other!"

Fooled me! Breaking it actually proved it was booting in EFI mode.

A quick tour with a live-USB session to rename the directory again and all was restored.

So now I've elevated a BIOS-boot install to EFI-boot non-destructively.

It's a complicated process, and as said in the above guide, it'd be easy enough to screw something up!

In my next post, I document another method that I haven't seen anywhere else, and has some definite advantages.

Mike Devour

mdevour
Level 2
Level 2
Posts: 70
Joined: Fri Aug 08, 2014 8:24 am

Re: New system, reusing old install?

Post by mdevour »

My aim here is a simple method to install Mint on a new machine with UEFI and restore a TimeShift snapshot from my old machine that booted under BIOS, to end up with my old install fully updated and running under UEFI.

My partition configuration is

/ on drive 1, a 500GB SSD
/home on drive 2, a 750GB HDD
/backup on drive 3, a 2TB HDD.

My system drive was newly re-formatted and empty. /home was preserved from my previous install. /backup contained all my Timeshift snapshots, as well as my BackInTime backups of user data, should I need them.

The overall approach is to do a fresh install in order to get a minimal copy of Mint running under UEFI, then restore a recent TimeShift snapshot of the system files from /backup so as to avoid having to manually re-install over 30 user programs. The trick is to do this without letting the restore process clobber the boot configuration of the new install.


Step 1) Do a fresh install of a base system, using the same version of Mint that was on your old system. Tell the installer to put the root directory on the target drive, in my case the 500gb SSD. Tell it to use the original /home partition without reformatting it!!! This conveniently preserves all of your user preferences as well as the configuration files for most of your programs.

When installation is complete, test that it indeed boots into a base system with your user interface customizations and settings largely intact but most of your user-installed programs missing.


Step 2) Boot into the install media again and copy the /boot directory to a safe place somewhere on your /home partition, where it won't get disturbed when you restore your system files.

To do this it is easiest to run the regular file manager as superuser, in order to have permission to muck around with files in / and preserve file ownership data. So here's the only thing we're going to do at the command line!

Open a terminal and type the following at the prompt...

Code: Select all

mike@dragon:~$ sudo caja
In Caja (as superuser), navigate to someplace safe like your /home/<user> directory and create a new folder, say /home/<user>/bootbackup.

Now click on File System. You should see your root directory, containing the /boot directory. Right click on it and select Copy. Navigate back to your /home/<user>/bootbackup directory and Paste a copy of the /boot directory there.

Close caja and shut down your system.


Step 3) Again boot from the install media, then run the TimeShift backup software, which you'll find in the Mint menu under System Tools. Since the program hasn't been configured in the Live USB session, it'll start you off in the settings Wizard. The first dialogue asks for Snapshot Type. I accepted the default RSYNC since that's what I used to create the snapshots on my old system. Click Next.

Now it asks you to select Snapshot Location and shows the list of disks and partitions it can see. Carefully select the partition where your backups are stored. In my case it is the 5th partition on my third drive, or sdc5. Choose what applies on your system. Now click Finish to return to the main TimeShift window.

All of your snapshots should be listed! Remember that these are all the BIOS boot compatible images from your old system.

Click on a recent snapshot to select it and click the Restore button. In the Restore dialogue box the three fields tell TimeShift where your /, /boot, and /home partitions are located. Make absolutely sure they're right! You do not want to overwrite any wrong partitions by mistake.

Click on the "Bootloader Options (Advanced)" button. In the Bootloader Options dialogue uncheck everything! This is crucial so that the restore operation does as little damage as possible to the boot configuration of your install.

Click Next and proceed with the restore operation. Be aware that it seemingly freezes sometimes while processing huge lists of files in various ways. Be patient.

When it's done, again reboot your system into the Live USB session from the install media.


Step 4) The above step leaves your disk un-bootable because the last part of the boot process depends on the files in /boot that you preserved earlier and which the Restore operation clobbered. So now, still working from the install media live session, copy the saved /boot directory back to your root partition.

Again, open the file manager as superuser.

Code: Select all

mike@dragon:~$ sudo caja
Navigate to your /home/<user>/bootbackup directory, right click on the copy of /boot you saved there, and select Copy.

Click on File System. Right click on the current /boot directory and click Move To Trash. Make sure you're in Icon View or Compact View, then right click somewhere there isn't a file or folder. You should now be able to Paste your saved copy of the /boot directory into /. Make sure it appears there.

Close caja and shut down your system. Remove the install media and re-boot.

Et voila! You should have a complete Mint install with all of your preferences and user-installed software exactly as it was on your old system, but booting via EFI. 8) Just do whatever software updates have accrued in the interim, and you should be ready to go.


Finally, we should do a couple of things to tidy up your installation. First, delete the directory where you saved that copy of the /boot files.

Open a file manager window and click on your home partition under Devices. You should see directories for root and your own user name. Right click on your user /home directory and click Open As Administrator. Right click on your /bootbackup directory and Move To Trash. Close the file manager windows.

Opening the home partition this way causes it to show up as an icon on the desktop. Right click the icon and select Unmount to close it and prevent any possibly unpleasant accidents.

More important, use Software Manager or Package Manager to install the grub-efi metapackage. This will uninstall grub-pc and replace it with the EFI version of grub, so if you ever want to do maintenance on your boot configuration you'll have the proper packages installed.


If you're making a significant leap in hardware configuration you might have to cope with driver problems or other issues; video drivers are a common example. The Mint Forums are your friend. :wink:

I hope this method might help some other users tackle this process. It is surprisingly simple and only requires the briefest of visits to the command line.

I also hope that experienced users will vet this guide for me. If there's anything wrong in it I'll happily correct it. If it's useful, perhaps we can post it as a Tutorial.

Thanks again for all the help you've given me here. Special thanks to zcot for the suggestions that inspired this experiment.

Mike D.
Last edited by mdevour on Fri Jun 26, 2020 9:32 pm, edited 3 times in total.

User avatar
arvy
Level 6
Level 6
Posts: 1079
Joined: Sat Mar 26, 2016 11:22 am

Re: New system, reusing old install?

Post by arvy »

mdevour wrote:
Fri Jun 26, 2020 9:21 am
My aim here is a simple method to install Mint on a new machine with UEFI and restore a TimeShift snapshot from my old machine that booted under BIOS, to end up with my old install fully updated and running under UEFI.
Uh, wouldn't it be simpler just to move (or copy/clone) the existing installation to a GPT drive and re-install Grub for UEFI-GPT booting it? What part of the plot am I stupidly missing? :?
System: Asus ROG Maximus XI Code mobo, Intel i9-9900K CPU, Nvidia GTX1080 GPU, 32 GB DDR4-3600 RAM, Sumsung Pro 2x512GB NVMe & 3x1TB SSD, Multiboot

Post Reply

Return to “Installation & Boot”