[EN] How to setup two siduction SSDs in one PC?

[EdSid]

Hello,
I tried to set up two siduction SSDs in one PC to get a second emergency system. I wanted to switch to it by BIOS boot default. I installed seduction to each of them separated, the BIOS showed the SSDs to be bootable and they worked. But as soon as I attach both SSDs to the same PC, their "bootability" gets erased and the BIOS doesn't show bootable devices any more. After that it is also impossible to use just one of the SSDs, the siduction system is not recognised any more, the SSDs are not bootable.

Did anyone know what happend? How to make both SSDs bootable at the same PC?
In case it fails, how can I restore such a not bootable SSD?

[unklarer]

Linux actually works without this bootflag of a hard disk.
However, I know that the BIOS of PC's expects the bootflag for historical reasons. Otherwise it does not continue. I have such a PC myself.


Your mistake is that you installed the two siduction separately on the disks.
The installation should have been done with the presence of the other disk in the PC, with only one disk getting the boot flag. Both disks are always in the system.

So for example
-sda with bootflag and GRUB in the MBR of both disks
(siduction with active os-prober and an additionally created grub-mkdevicemap, so GRUB can handle the disks better)

-sdb without bootflag and GRUB in the PBR (siduction without active os-prober)


With the help of chroot this can be repaired also afterwards. New installations should not be necessary.

[ro_sid]

@EdSid
Although not totally correct, the term BIOS is often used for UEFI-boots, too (I often do so myself  ).
@unklarer assumes a classical BIOS boot, where the bootflag has a meaning.
[Remark: Each disk/ssd may contain a bootflag, this is no problem, but the BIOS boot-order can be.]
So, which is it: classical BIOS (or UEFi with CMS) boot or UEFI (native) boot?
The answer could narrow down the possible problem causes a bit.
Because you write that no disk/ssd is shown as bootable device. Strange!

[EdSid]

On installation the boot partition was set up to mount point /boot/efi and got the boot flag. For USB boot of the installation program it was necessary to deactivate "secure boot" at BIOS setting "windows OS" and I left it deactivated. This was the only change of BIOS after this:

I did such a thing before using Arch Linux, two installations each on a separate disk, the BIOS recognises them (shows the type of the SSDs) and I can choose the disk by BIOS choice at boot or by setting the boot order. But using Siduction and attaching both disks, first boot only one disk was recognised, second boot all vanished, BIOS doesn't show any bootable disks. You think, this is because of a special BIOS setting? There are no duplicate UUIDs, because there is no copy, but two separate installations.

[ro_sid]

On installation the boot partition was set up to mount point /boot/efi ...

Well, the mount is necessary, and it is likely, that you booted in UEFI, when installing, but this is not sure.
After booting in (classical) BIOS, a mounted /boot/efi does nothing for you.

...and got the boot flag.

In UEFI-Mode, this flag is irrelevant, as long as you do not have several FAT(32) partitions on that drive.

For USB boot of the installation program it was necessary to deactivate "secure boot" at BIOS setting "windows OS" and I left it deactivated.

Well, this will be necessary in the future, too, as Siduction can not be booted in secure boot mode, as far as I can tell. It has no (Microsoft-)signed kernel and modules.
But for many "BIOSes", there is another optioe: to boot in either "classic" (CMS) or "UEFI" mode. If you have it, and it was set to "classic", then your (Siduction) installation medium has been booted that mode, and nothing will get you out of that afterwards. Then "grub" would have been installed in classic/pc mode, regardless of your /boot/efi mount.

But since you are somewhat experienced (Arch Linux), you might be able to mount the UEFI-FAT partition and have a look there, if anything like "EFI/..." and/or "BOOT/..." is installed there.

On the other hand, the drive(s) not being recognized is a totally other thing, an no, I don't think, that there is something principally wrong with your kind of installation. Do both disks still appear in the "BIOS-/UEFI-setup" as "installed" or did they totally vanish?

"Bootability" might vanish, when for UEFI there is no FAT EFI partition - for whatever reason. And it will vanish for classical  mode, when no (more) boot flag is set or the (boot flag) marked partition contains not classical bootloader.

Last thing for this posting from me: When you are in UEFI mode, each installation makes an entry in the UEFI variables/nvram space. Both will say "siduction", so the second one most probably overwrites the first, otherwise you would have two entries both being labelled "siduction". You should be able to check on this by pressing the key responsible for a (one time) boot device change at (cold) start. For my system, this would be F12, but it may vary for yours. Then all stored UEFI entries will appear (sic!) and additionally all "bootable" drives. There you can have a look for none/one/two siduction entry/ies.

[EdSid]

I checked the BIOS and there is "Boot Option #1: UEFI Hard Disk:siduction", so it is UEFI for sure. The other disk is not shown in boot options, but listed in devices.

The last part of your post makes totally sense - do you know, how I can change the UEFI label from siduction to another name? My boot selection (F11) never showed more than one siduction to boot.

[unklarer]

I'm out of here...   

[scholle1]

Maybe the tip from another user will help:

NOTE: The "grub-install" command assumes standard configuration of siduction with EFI partiton at /dev/sda1 and the bootx64.efi file in /boot/efi/EFI/boot directory and the grubx64.efi file in /boot/efi/EFI/siduction directory. Other configurations would have to use the full command in the form of:

Code: [Select]

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=some_name_you_want

For this it is necessary NOT to install the bootloater during one of the installations. The EFI partition, mounted under /boot/efi/ is very necessary. After this installation boot into the live system and install the bootloader with chroot as described before.

[ro_sid]

do you know, how I can change the UEFI label from siduction to another name?

No and yes  . No, I never found a way to just alter (the label of) an existing entry. I always had to delete that entry and then, yes, create a new one. All with "efibootmgr", so please be careful and read its man-page.

Do an "efibootmgr -v' first and store/remember the settings.
With "efibootmgr -B -b 0001" you can delete the entry "1" (given with -b).
With "efibootmgr -c -b 0001 -d /dev/sdX -p 1 -l \\EFI\\siduction\\grubx64.efi -L Siduction" you do (re-)create it, giving it the "label" after -L. But be careful, the sdX device needs the correct "X" and it might even be an "nvmeYnX" device (mostly Y=0 and "X" the xth ssd device on that controller) or maybe something totally different. The "-p 1" describes the EFI-partition on the device (mostly 1) and the path to the bootloader (grubx64.efi) needs the double backslashes "\\". Of course the bootloader and its path have to be correct, the path counting from after "/boot/efi". You can either look it up (there), or the entry remembered with "efibootmgr -v" is your friend.

It also helps a lot to have an BOOT/... entry starting after "/boot/efi". Siduction does not seem to provide one per default. I just copied the contents from EFI/BOOT there and it worked. When this is installed (and correct), you can UEFI-Boot the device by just naming it in the entry list, no (special) UEFI-entry necessary. It is a mechanism to boot removable devices, normally, but also works for "fixed" ones.

Good luck!

[EdSid]

Thank you for the detailed answer. HURRAY!  I will try this next weekend, for the moment my new, siduction based home office should do the job. So for the next days - don't touch a running system! ;o)

[EdSid]

Problem solved. Unklarer was right with "Your mistake is that you installed the two siduction separately on the disks.".

Yesterday I tried Manjaro and installing the disk separately reproduces the problem. Keeping them both at the PC solved it:  The BIOS showed the two disks by their hardware name and an additional entry named "Manjaro". I think, the problem was in fact, that both disks had the same name.

Now the two systems boot (using the same home), so my fallback now works. But I'm on Manjaro now, because I was able to install my whole system Manjaro based in one evening, but did not succeed with siduction in two and a half days.

[ro_sid]

Yesterday I tried Manjaro and installing the disk separately reproduces the problem. Keeping them both at the PC solved it:  The BIOS showed the two disks by their hardware name and an additional entry named "Manjaro".

No real secret in this: The two "disks by their hardware" start through the (boot/efi/)BOOT entry, which Siduction does not seem to generate (remark: may be this should be changed/fixed). The "Manjaro" entry was generated by the/each last(!) disk install and is (most probably) booted from (boot/efi/)EFI/Manjaro.

Use the distribution that makes you happy. It uses a whole different package management system, than siduction, though!

[dibl]

.... through the (boot/efi/)BOOT entry, which Siduction does not seem to generate ...

Well ... here is my efi menu generated when I installed siduction here.

Code: [Select]

root@dibl-MOW:/home/don# efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0004,0005,0006,0007
Boot0000* siduction
Boot0004* ASUS    DRW-24B1ST   j
Boot0005* KINGSTON OM8PCP3512F-AB
Boot0006* WDC WD2003FZEX-00SRLA0
Boot0007* WDC WD2003FZEX-00SRLA0

[EdSid]

Use the distribution that makes you happy. It uses a whole different package management system, than siduction, though!

After CentOS was burnt by IBM, I tried Arch for about half a year, but the last update caused a heavy crash and anyway there was a lot of maintenance to do. Manjaro seems to provide updates/upgrades that are better tested. When it just runs , I will be happy with it.