Before you post please read how to get help
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. 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!
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:
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.
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?
I'm looking for any guidance, pointers, criticism, or encouragement you think I need before I move ahead. Thank you!
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.
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!!
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!
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?"
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!
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...
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".
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.
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...
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.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".
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...
Thank you, folks. I really appreciate the active Mint community. It's an amazing distro, and you're here when I need you.
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
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.
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.
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.
Get a terminal and do some:
apt purge nvidia --dry-runand 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-runis 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
dpkg -l '*nvidia*'should give some clue as to what packages are currently installed.
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.
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.
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.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.
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!
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!
pretty cool save, and a unique way to do this situation.
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
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.
Code: Select all
mike@dragon:~$ sudo partprobe /dev/sda
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:~$
Code: Select all
mike@dragon:~$ sudo mkdir /boot/efi
Code: Select all
mike@dragon:~$ sudo xed /etc/fstab
Code: Select all
/dev/disk/by-partlabel/EFI-boot /boot/efi vfat defaults 0 2
First mount the target directory.
Code: Select all
mike@dragon:~$ sudo mount /boot/efi
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:~$
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:~$
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.
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
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
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. 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
homepartition 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.
homepartition 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.
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.
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?