The PC coukd not boot Live!

[IvoMiguelGomesLagoa]

SkillFishOS version

26.06 Aetherium

Hardware

Generic PC (Intel/AMD)

Kernel flavor

7.0.11-skillfishos (BC-250 main)

Affected area

Kernel / boot

What happened?

Hey!
When i use GRUB2 in Ventoy, the PC shuts down itself when I select the boot choice of the SkillFishOS.
When I use the normal mode, when I select the Option SkillFishOS Live, it stays stuck on the underscore FROM GRUB, NOT FROM LINUX, I can tell it that it does not flash/switch to Linux instead of GRUB. when using ROSA Image writer, it shows grub>

Steps to reproduce

No response

Logs / output

[MTSistemi]

Thanks for the report, and sorry for the trouble.

Please try the current release first. The latest is 26.06.4 Aetherium, from the download page:

https://skillfishos.com/download/

The version field in your report says "26.06 Aetherium", which is the example text of the form, so we cannot tell which build you actually have. Earlier builds did have a GRUB problem that looks exactly like what you describe — GRUB loads, then nothing.

Which image did you write to the stick? SkillFishOS ships two, and they are not interchangeable:

Image	Runs on
SkillFishOS-26.06.4-Aetherium-BC250-amd64.iso	AMD BC-250 boards only. The kernel is built for that board and will not start anywhere else.
SkillFishOS-26.06.4-Aetherium-Generic-amd64.iso	Ordinary Intel/AMD PCs and virtual machines.

You selected "Generic PC (Intel/AMD)" as hardware but "7.0.11-skillfishos (BC-250 main)" as kernel, which is why we are asking. Please paste the exact file name of the ISO as it is on your disk, and if you can, its MD5 (md5sum <file>, or certutil -hashfile <file> MD5 on Windows) so we can rule out a damaged download.

And a bit more about the machine, please:

• make and model of the PC or the motherboard, and the CPU;
• UEFI or legacy BIOS, and whether Secure Boot is on;
• how you wrote the stick (you mention Ventoy and ROSA Image Writer — did a plain dd or Rufus in DD mode behave the same?);
• a photo of the screen where it stops is genuinely useful.

The grub> prompt you get with ROSA Image Writer means GRUB started but could not find its own configuration, which usually points at how the image was written rather than at the image itself. The Ventoy shutdown is a different symptom again, so let us separate the two.

One thing is on us either way: the boot menu did not say which machine each image is for, and the report form was asking for a kernel version two releases out of date. Both are fixed now — the menu says for AMD BC-250 boards only or for standard PCs, and the form asks for the ISO file name up front.

[MTSistemi]

Following up — three days on, and we would still like to get you booted.

Two things have moved since we last wrote, and one of them may be your problem.

1. Which image did you write? Your report lists the kernel as
7.0.11-skillfishos (BC-250 main) on a Generic PC (Intel/AMD). If that is what
is on the stick, it explains the symptom exactly: that kernel is built for the
AMD BC-250 board and will not run on an ordinary PC. GRUB loads, hands over, and
nothing happens — which is what you are seeing. The Generic image is a different
file:

SkillFishOS-…-Aetherium-Generic-amd64.iso     ← ordinary PCs and VMs
SkillFishOS-…-Aetherium-BC250-amd64.iso       ← the AMD BC-250 board only

2. Skip Ventoy for the test. Ventoy's GRUB2 mode chain-loads our bootloader,
and when it goes wrong it looks exactly like this: a grub> prompt or a dead
underscore. It is not that Ventoy is wrong, it is that it adds a layer while you
are trying to find out which layer is broken. Write the image straight to the
stick once — dd, Rufus in DD mode, or balenaEtcher — and see whether it
boots. If it does, we know where to look.

There is also a newer test build, 26.06.5, which fixes something close to
your description: the Generic edition used to carry the BC-250 kernel alongside
its own, and on an Intel machine that kernel would not boot. Say the word and we
will send you the link.

If you have moved on or solved it another way, just say so and we will close
this — no explanation needed. The issue stays open either way until we hear from
you; we would rather leave it open than assume.

[MTSistemi]

We found a cause that matches your symptom exactly, and it was our fault.

SkillFishOS builds its own kernel, and until now nobody had signed it. On a PC
with Secure Boot enabled — which is how nearly every machine leaves the factory —
the firmware refuses to run unsigned code. GRUB itself starts, hands over to the
kernel, and the machine stops right there. No message, no flashing cursor turning
into Linux: exactly what you described.

This is fixed. In the next image the kernel is signed with a SkillFishOS key, and
a tool enrols that key in your firmware so the machine will accept it. If Secure
Boot does block the boot anyway, the menu now says so in plain words instead of
failing in silence. We are not going to give you a date for the release, because
we would rather ship it right than ship it soon.

Two things you can try today, without waiting for us:

1. Turn Secure Boot off in your firmware setup (usually under Security or
   Boot), then boot the stick again. If that gets you in, we have confirmed the
   cause together.
2. Write the image straight to the stick, not through Ventoy. Ventoy's GRUB2
   mode chain-loads our bootloader, and when that goes wrong it looks like a dead
   underscore or a bare grub> prompt — the same picture as the problem above,
   from a different cause. Use the plain image on a plain stick for the test, so
   only one thing can be wrong at a time.

And we still do not know one thing we asked before: which of the two images did
you write? Your report lists the kernel as 7.0.11-skillfishos (BC-250 main) on
a Generic PC. If the BC-250 image is what is on the stick, that alone explains the
symptom — that kernel is built for one specific board and will not start anywhere
else. The file you want on an ordinary PC ends in -Generic-amd64.iso.

Thanks for the report. It sat on a real bug, and chasing it is what made us find
the signing problem.

[MTSistemi]

Follow-up: the fix is live now, not "coming".

The four kernel builds on the release page are signed with a SkillFishOS key
as of today, and the tool that enrols that key in your firmware already ships in
skillfish-base. So on an installed system you can turn Secure Boot back on:

sudo /usr/local/bin/skillfish-secureboot --registra

You do it once. It queues the request and explains the rest in your own language;
at the next start your firmware shows a blue screen asking you to confirm — the
decision stays with you, in front of the machine.

Booting the installer from a USB stick still needs Secure Boot off, and always
will: a key cannot be enrolled before the machine has started at least once. So
for your situation the order is: Secure Boot off → install → enrol the key →
Secure Boot back on.

One catch worth knowing if you get that far: a machine that already had kernel
7.2.0 installed keeps the unsigned build, because the kernel package skips the
download when that version is already there. The manual replacement is written up
in the wiki under Troubleshooting → The machine stops right after
GRUB,
and we tested it on a real board before writing it down.

Your report is what sent us looking, and what we found was our own missing
signature. Thank you for it.

[MTSistemi]

You were trying to boot the BC-250 image on a generic PC, and that image cannot work there — the fault is ours, not yours.

The kernel in it is 7.0.11-skillfishos, built with -march=znver2 for the AMD BC-250 specifically. On an Intel machine it does exactly what you describe: GRUB loads, hands over, and nothing happens — no kernel messages, because the kernel never gets far enough to print any. That also explains the difference you saw between Ventoy's GRUB2 mode and normal mode: both were reaching the same dead end by different routes.

There is a Generic edition for ordinary PCs. It carries a kernel built for plain x86-64 and named -skillfishos-x64 rather than -skillfishos, so the two can no longer be confused. Two things came out of your report:

• the naming. A kernel that only runs on one board should not be called by the same name as the one that runs everywhere. It is now -skillfishos-x64, and the difference is visible in uname instead of only at boot time;
• the build. The x64 kernel is now built with an explicit target and a config fragment that switches CONFIG_X86_NATIVE_CPU off. Without it, a kernel built on the build machine inherits -march=native from the starting config and ends up tuned to whatever CPU compiled it — the same class of failure you hit, just arriving from a different direction. Verified on the produced image: the symbol is off.

The Generic image for 26.06.7 is building now, with kernel 7.2.2-skillfishos-x64, and it is tested by booting it on an ordinary Intel machine rather than on a BC-250. I will close this once that test has passed, and I will link the download here.

Sorry it cost you the time. Thanks for describing the symptom precisely — "stuck on the underscore from GRUB, not from Linux" is what made it obvious where the boundary was.