Announcement

**oshunluvr** · Mar 16, 2019, 02:56 PM

The UUID is different I suspect. Look at grub.cfg and check the UUIDs against your boot partition(s).

What I do when I move an OS for booting is manually edit grub.cfg and change the UUID of the boot OS, then boot to it, then run update-grub to let grub fix all the others automatically.

**oshunluvr** · Mar 16, 2019, 03:05 PM

Also, using grub-install with those mounts like that you would have to explicitly tell it where /boot/grub is with the --boot-directory= option.

**PhysicistSarah** · Mar 16, 2019, 03:09 PM

Originally posted by oshunluvr View Post

The UUID is different I suspect. Look at grub.cfg and check the UUIDs against your boot partition(s).

What I do when I move an OS for booting is manually edit grub.cfg and change the UUID of the boot OS, then boot to it, then run update-grub to let grub fix all the others automatically.

I used gedit's find and replace tool to replace all instances of the old UUID with the new one for /dev/sdc2. I'm going to reboot off of the liveUSB and see what happens.

EDIT 0:

The system booted into emergency mode. I might have an invalid fstab. Here are the logs (Just the tail end):

Code:

Mar 16 17:11:49 ConvergentRefuge systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'.
Mar 16 17:11:49 ConvergentRefuge systemd[1]: Startup finished in 10.754s (firmware) + 2.488s (loader) + 38.277s (kernel) + 1min 31.391s (userspace) = 2min 22.911s.
-- Subject: System start-up is now complete
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- All system services necessary queued for starting at boot have been
-- started. Note that this does not mean that the machine is now idle as services
-- might still be busy with completing start-up.
-- 
-- Kernel start-up required 38277546 microseconds.
-- 
-- Initial RAM disk start-up required INITRD_USEC microseconds.
-- 
-- Userspace start-up required 91391547 microseconds.
Mar 16 17:11:49 ConvergentRefuge systemd[1]: systemd-cryptsetup@cryptswap1.service: Job systemd-cryptsetup@cryptswap1.service/start failed with result 'dependency'.
Mar 16 17:11:49 ConvergentRefuge systemd[1]: dev-disk-by\x2duuid-b8fef08f\x2dc8a9\x2d49f9\x2d9cc7\x2dabbd362e4967.device: Job dev-disk-by\x2duuid-b8fef08f\x2dc8a9\x2d49f9\x2d9cc7\x2dabbd362e4967.device/start failed with result 'timeout'.

**Snowhog** · Mar 16, 2019, 04:17 PM

Was any partition on the OS before you moved it to the new SSD, encrypted?

**jlittle** · Mar 16, 2019, 05:45 PM

(The last time I looked at boot repair it had not been updated for EFI.)

With btrfs I'm not sure that chroot stuff applies. The chroot is not needed any more as it addresses a weakness in grub-install that is now fixed with --xxx-directory options.

First one needs to have the EFI and grub boot directories mounted somewhere. The standard places are /boot/efi and /boot/grub but if you're booted from a Live USB, or another install, the running /boot won't be right. Maybe

Code:

sudo mkdir /mnt/efi /mnt/boot
sudo mount /dev/sdc1 /mnt/efi
sudo mount /dev/sdc2 /mnt/boot -o subvol=@

Then, grub-install can be told what to do:

Code:

sudo grub-install --boot-directory=/mnt/boot/boot --efi-directory=/mnt/efi

The UEFI has to be told to boot to the SSD, but you've already done that I think. The mount points in /mnt are only temporary, grub-install works out what grub will think the "boot/grub" is on and writes it in to the EFI/ubuntu/grubx64.efi image.

It can be help understanding to run sudo efibootmgr -v to see what the UEFI has been told what to do, but its idea of device names is yet another scheme. grub-install should set the entry properly.

**PhysicistSarah** · Mar 16, 2019, 05:51 PM

Originally posted by Snowhog View Post

Was any partition on the OS before you moved it to the new SSD, encrypted?

There were 2 partitions on the SSD.
/dev/sdc1 This is the EFI partition I made before the install. It was created by Ubiquity
/dev/sda2 Contains @ and @home, originated from external SSD snapshots.

There is no LVM or encryption of any kind. That I set up.

**PhysicistSarah** · Mar 16, 2019, 05:56 PM

I used the commands, but it gave a few errors:

Code:

kubuntu@kubuntu:~$ ls /mnt
kubuntu@kubuntu:~$ sudo mkdir /mnt/efi /mnt/boot
kubuntu@kubuntu:~$ sudo mount /dev/sdc1 /mnt/efi
kubuntu@kubuntu:~$ sudo mount /dev/sdc2 /mnt/boot -o subvol=@
kubuntu@kubuntu:~$ sudo grub-install --boot-directory=/mnt/boot/boot --efi-directory=/mnt/efi
Installing for i386-pc platform.
grub-install: error: install device isn't specified.

After giving it /dev/sdc:

Code:

kubuntu@kubuntu:~$ sudo grub-install --boot-directory=/mnt/boot/boot --efi-directory=/mnt/efi /dev/sdc
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install: error: filesystem `btrfs' doesn't support blocklists.

**jlittle** · Mar 16, 2019, 07:30 PM

Originally posted by PhysicistSarah View Post

Installing for i386-pc platform.
...no BIOS Boot Partition...

That's not right, it's attempting a BIOS install, not a UEFI one.

Is the computer booted in BIOS mode? If booting from USB, some motherboards present two devices, one for a UEFI boot and another for a BIOS boot. I don't know if a UEFI install is possible from a BIOS boot.

**Qqmike** · Mar 16, 2019, 08:02 PM

I don't know if a UEFI install is possible from a BIOS boot.

I don't believe it is possible. If you want a UEFI installation (of an OS), you must boot in UEFI mode.

**PhysicistSarah** · Mar 16, 2019, 08:33 PM

I'm not entirely sure what this means. I have secure boot disabled if this is what is being discussed.

I don't know of any BIOS mode or UEFI mode.

When the prompt commes up after shutdown I just press ESC and go to boot from devices and choose the live USB.

**PhysicistSarah** · Mar 16, 2019, 11:04 PM

Aparrantly, the wrong grub package was being used.

I ran

Code:

sudo apt-get install --reinstall grub-efi

and ran

Code:

kubuntu@kubuntu:/mnt$ sudo grub-install --boot-directory=/mnt/sdc2/@ --efi-directory=/mnt/sdc2/@/boot/efi/
Installing for x86_64-efi platform.
Installation finished. No error reported.

And it successfully ran the command.

**PhysicistSarah** · Mar 17, 2019, 12:37 AM

Alright, progress!

I messed around with fstab and the system booted! I was able to log in and everything is fine... mostly. I ran sudo update-grub, but grub still doesn't boot the OS properly. I have to manually set root then prefix and use normal to get to a menu where I can boot from.

Any suggestions as to what I did wrong in fstab or how to remedy the grub situation?

**jlittle** · Mar 17, 2019, 01:57 AM

Originally posted by PhysicistSarah View Post

sudo grub-install --boot-directory=/mnt/sdc2/@ --efi-directory=/mnt/sdc2/@/boot/efi/

I don't understand the mounts you've got there, I'm guessing /dev/sdc2 is mounted on /mnt/sdc2, without using a subvol, and then /dev/sdc1 on /mnt/sdc2/@/boot/efi. Cool that it can be done that way, it's a bit simpler than my method.

However, I'd expect --boot-directory=/mnt/sdc2/boot

**PhysicistSarah** · Mar 17, 2019, 11:01 AM

That's a good point. I'll try that.

EDIT 0: I replicated the setup, and got this:

Code:

sarah@ConvergentRefuge:/mnt/sdc2/@$ sudo grub-install --boot-directory=/mnt/sdc2/@ --efi-directory=/mnt/sdc2/@/boot
Installing for x86_64-efi platform.
grub-install: error: /mnt/sdc2/@/boot doesn't look like an EFI partition.

sarah@ConvergentRefuge:/mnt/sdc2/@$ sudo grub-install --boot-directory=/mnt/sdc2/@ --efi-directory=/mnt/sdc2/@/boot/efi
Installing for x86_64-efi platform.
Installation finished. No error reported.

Announcement

Unable to Boot from GRUB After Moving OS to New SSD?

[GRUB] Unable to Boot from GRUB After Moving OS to New SSD?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment