I had to replace the motherboard of my computer and now the disk that contains siduction no longer appears as a boot option in the BIOS.
I can boot using Debian Trixie, installed in a different disk, that does appear. At first, I could not boot on siduction, even from the menu option of the Debian's grub menu. I disabled "Secure Boot" on the BIOS, and now can boot from it. But siduction's disk still does not appear in the BIOS. (I'd like to set it as the default...)
Any ideas for how I could fix this? (FWIW, the new motherboard is MSI MAG X870 Tomahawk WiFi Gaming Motherboard (http://"https://us.msi.com/Motherboard/MAG-X870-TOMAHAWK-WIFI").)
Leider habe/n ich/wir viel zu wenig Informationen, aber da sich sonst niemand meldet, hier mal mein Versuch:
Im BIOS (Setup) nachsehen, ob die Disk überhaupt aufgeführt wird. Das ist allerdings sehr wahrscheinlich, da "Debian" "Siduction" ja starten kann.
Für mich eher ein Grund: Die "alte" Disk bootete nicht mittels UEFI, sondern im "Legacy Mode" und das neue Board/BIOS hat kein CS-Modul mehr, um so zu booten. Falls es so war und das neue BIOS doch darüber verfügt, die "Legacy-Boot"-Option einschalten. Falls es das nicht hat, die "alte" Disk per UEFI bootbar machen, was allerdings bei bisher fehlender EFI/fat(32)-Partition eventuell nicht so einfach wäre.
Thanks for the reply!
Yes, the disk containing siduction is listed, but not among the bootable devices. And I am pretty sure it booted by EFI:
Disk /dev/nvme0n1: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: Samsung SSD 990 EVO Plus 4TB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 5C5589A3-07E6-432A-86D9-61162E219324
Device Start End Sectors Size Type
/dev/nvme0n1p1 4096 618495 614400 300M EFI System
/dev/nvme0n1p2 618496 7795582163 7794963668 3.6T Linux filesystem
/dev/nvme0n1p3 7795582164 7814037101 18454938 8.8G Linux swap
But I will try setting it to legacy mode.
I was thinking that the problem was related to secure boot, since the change in hardware caused it, and maybe I needed to "authorize" the disk again, somehow. But it is odd that the trixie disk is still seen.
And, FWIW, here is Trixie's disk:
Disk /dev/nvme1n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 990 EVO 2TB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: AA46C948-F7D7-4BF8-BB20-E0DBD3F3D3D2
Device Start End Sectors Size Type
/dev/nvme1n1p1 4096 618495 614400 300M EFI System
/dev/nvme1n1p2 618496 3762944333 3762325838 1.8T Linux filesystem
/dev/nvme1n1p3 3762944334 3907029101 144084768 68.7G Linux swap
I recently bought a new motherboard -- an Asrock -- and learned it cannot see a GPT partitioned drive. Could that be your problem?
Quote from: dibl on 2025/11/15, 12:52:58
I recently bought a new motherboard -- an Asrock -- and learned it cannot see a GPT partitioned drive. Could that be your problem?
I think it does... The manual says:
Quote
Supports more than 4 primary partitions with a GUID Partition Table (GPT).
After googling around, one suggest was to "enroll a new key", but it *seems* it needs a shimx64.efi file in /boot/efi/EFI/siduction/, but it only has the grubx64.efi file.
# ls /boot/efi/EFI/siduction/
grubx64.efi*
I do have installed shim-sgined installed.
shim-signed:
Installed: 1.47+15.8-1
Candidate: 1.47+15.8-1
Version table:
*** 1.47+15.8-1 500
500 http://debian-archive.trafficmanager.net/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
So, I am at a loss...
Sorry, I answered in German, before. I just did not pay enough attention.
Quote from: finotti on 2025/11/15, 13:06:25
[...]
After googling around, one suggest was to "enroll a new key", but it *seems* it needs a shimx64.efi file in /boot/efi/EFI/siduction/, but it only has the grubx64.efi file.
So it firstly has an EFI partition and secondly, as long as "secure boot" is disabled, grubx64.efi is sufficient and shimx64.efi not needed.
Another idea: as far as I can say, all (boot-)directories not named "BOOT" are active/usable only, when an entry exists in the UEFI variables environment - which is most likely not present, if you did not "install" grub on the new board for that disk. So most likely (boot/efi)/EFI/siduction/ is discarded.
On the other hand, a "BOOT"-directory should always be respected - it is the way an external drive would be recognized for booting. So, do you have a "BOOT"-directory below that EFI directory in the partition?
Quote from: ro_sid on 2025/11/15, 14:14:13
So, do you have a "BOOT"-directory below that EFI directory in the partition?
Yes, but is empty:
# ls -la /boot/efi/EFI/
drwx------ - root 18 Mar 02:00 boot/
drwx------ - root 18 Mar 02:00 siduction/
# ls -la /boot/efi/EFI/boot/
(No output for the second command.)
Quote from: finotti on 2025/11/15, 14:21:51
Quote from: ro_sid on 2025/11/15, 14:14:13
So, do you have a "BOOT"-directory below that EFI directory in the partition?
Yes, but is empty:
# ls -la /boot/efi/EFI/
drwx------ - root 18 Mar 02:00 boot/
drwx------ - root 18 Mar 02:00 siduction/
# ls -la /boot/efi/EFI/boot/
(No output for the second command.)
That is not good! A shot in the dark would be to copy the contents of siduction/ into boot/, too, and then rename or better copy grubx64.efi there(!) as BOOTX64.EFI. There certainly are better ways, but it would be worth a try.
Thanks for your help!
I've copied the files, but it made not difference for the BIOS. It still cannot use the siduction disk for boot...
Quote from: finotti on 2025/11/15, 14:54:08
Thanks for your help!
I've copied the files, but it made not difference for the BIOS. It still cannot use the siduction disk for boot...
You are welcome, and that is a pity.
You can "activate" your previous (siduction-)settings by adding them to the UEFI variables. The program "efibootmgr" can enter them and even (re-)order the boot priority. But it is a little tricky (e.g. paths needing '\' instead of '/' and from the command-line, this means '\\'). Please read the man-page, but only act, when you are very confident to do the things right. One can make everything worse, too :-[. At the moment, I can not spare the time to tell you how it is done. May be, someone else can come to help.
What is harmless is just looking at how the settings are now: "efibootmgr -v".
Needed are the disk-id and partition in the way, UEFI does it, and eventually the actual boot-order and the wanted one.
Good luck.
Another option.
Use a siduction live medium and the 'chroot-helper' to switch to the siduction installation (nvme0n1).
First, execute the command umount /boot/efi
Second, edit the fstab by changing the entry for /boot/efi to the UUID of the partition nvme1n1p1.
Third, execute the command mount -t vfat /dev/nvme1n1p1 /boot/efi
The commands "systemctl daemon-reload" (However, I am not sure if it works in chroot.) and "mount /boot/efi" may also work.
Fourth, install grub in the chroot from nvme0n1 with a different name, e.g.grub-install --bootloader-id="siduction_nvme0n1"
Fifth, update the grub menu fileupdate-grub
Leave the chroot.
Check the names and order of the boot entries in a terminal with efibootmgr
As a result, you only use one EFI partition for both HDDs. The one from nvme1n1. This means that it is no longer necessary to select the HD in the UEFI.