Basically, my first drive is SATA SSD (with PureOS) and the second one is M.2 (I put it the spare M2 slot, PureOS detects it as /dev/sdb). My aim is to carry on loading PureOS from SATA SSD. Do I need to do sudo grub-install /dev/sda?
As far as i understood @mladen the problem here is that that there is no option to change the order in which seabios (the coreboot payload) looks for bootloader. So when an m2 device is installed it will only search for a bootloader there and you have to manually select an other devices if nothing is present on your m.2 device.
This is far from ideal but there is nothing you can do from the OS side. And it has nothing to do with the sda and sdb naming which is given by the OS and the problem lies before the OS is loaded.
So for a solution look into seaBIOS options. I’m not sure what you can do there but it might be possible to change these option if you compile your own Coreboot with custom settings. @kakaroto might have a solution for this. Or look into the coreboot thread:
Be careful with the coreboot stuff. These are just pointeres to possible solutions i have never tried or used. I actually never used coreboot my self. So you might wanna wait gather more informations from more experience users on this first.
I would also choose @mladen solution of a second MBR partition on the M.2 device. Its just some MB extra and i don’t see any big disadvantage on this solution.
The advice from Mladen was such that you boot from your M.2 drive. He was suggesting that you install the MBR on that drive as a result of that.
His suggestion was probably such as it is much more difficult to recompile coreboot with the settings you want. In the future this will probably not be the case for various reasons.
However, as you can select the boot drive now on startup, you could just live with that and select the boot drive on every restart, reinstall the OS on your M.2 drive, or recompile coreboot and use the system as you prefer.
I would split the boot process in 3 parts. First coreboot+seabios which initilies the hardware and then look for a bootloader. Second the bootloader, which can live on any device but is unfortenetlly only automaticaly selected on m2 devices. Selecting the kernel and a initramfs from any drive via bootloader.
After step 3 nothing of the bootloader part is present in ram or anywhere. Its just a step in betwenn which handels the part which is to complex for the corebot but musst handel reading partitions and selecting kernels.
So if you install a adittional bootloader on the m.2 devices and select the pureos on the sata drive, after boot there is no difference from the case where you booted from a bootloader on the sata device.
There is no reinstling or system partition moving involved. This is why it is concidered the esiest solution.
Only down side is if you remove the m.2 device an put an other one without a bootloader on it in, you have to select the sata drive manually like you do now.
You can change the boot order with this script : Change boot order
I think the fact that seabios doesn’t ignore the m.2 device if it doesn’t find it bootable is the real bug here which needs to get fixed at some point.
I’m in a similar situation. If I understand @mladen’s suggestion correctly, running grub-install on the secondary disk will install a MBR/GPT grub boot image there, which will point straight back at the primary disk.
So, the problem is SeaBIOS is limited and wants to boot only /dev/sdx, but the OS and boot sector is all on /dev/sdy. If you run grub-install sudo grub-install /dev/sdx (the new/secondary disk), then grub will configure a shim boot sector that points back at the /boot partition on /dev/sdy.
Is that right? Or was @mladen suggesting a full reinstall, to put the OS directly on whatever disk SeaBIOS expects?
I’m reluctant to run @mladen’s commands for a couple reasons:
I’m using LUKS full disk encryption
I’m using Qubes OS
The Qubes dom0 is LUKS, and so is the secondary drive. The secondary drive is mounted in the Librem’s internal SATA slot, but I essentially use it as an external “USB” drive. So it’s just one giant LUKS partition, literally nothing else on it.
So, I’m worried grub-install might overwrite my LUKS header. And/or, that Qubes dom0 needs grub-install to be run in a special/different way because it’s not running directly on the hardware (it’s running inside Xen hypervisor).
I have finally tried your script and it did NOT work on Purism 13.
Here is what I have got:
Select the default order in which devices will attempt booting:
1 - Boot order: M.2 SSD disk first, 2.5" SATA disk second
2 - Boot order: 2.5" SATA disk first, M.2 SSD second
** Note: regardless of the option chosen above, you can always select
** a different boot device by pressing ‘ESC’ at boot time.
Enter your choice (default: 1): 1
change_bootorder.sh: 29: [: 1: unexpected operator
change_bootorder.sh: 37: [: 1: unexpected operator
flashrom v0.9.9-1-stable-11-d36385d-dirty on Linux 4.18.0-2-amd64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Calibrating delay loop… OK.
coreboot table found at 0x7aad3000.
WARNING! You seem to be running flashrom on an unsupported laptop.
Laptops, notebooks and netbooks are difficult to support and we
recommend to use the vendor flashing utility. The embedded controller
(EC) in these machines often interacts badly with flashing.
See the manpage and https://flashrom.org/Laptops for details.
If flash is shared with the EC, erase is guaranteed to brick your laptop
and write may brick your laptop.
Read and probe may irritate your EC and cause fan failure, backlight
failure and sudden poweroff.
You have been warned.
Proceeding anyway because user forced us to.
Found chipset “Intel Skylake U Premium”.
This chipset is marked as untested. If you are using an up-to-date version
of flashrom and were (not) able to successfully update your firmware with it,
then please email a report to firstname.lastname@example.org including a verbose (-V) log.
Enabling flash write… Warning: Setting Bios Control at 0xdc from 0x8b to 0x89 failed.
New value is 0x8b.
Warning: SPI Configuration Lockdown activated.
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn’t found automatically.