I set up my UEFI system using refind to triple-boot Windows 10, Kubuntu 24.10 and Haiku (all 64bit), but I’m having some issues with it: (often) when cold-booting or (almost always) when booting after a Kubuntu session the Haiku boot hangs at the icons without any of them lighting up. No amount of restarts fix it. I’m also updating Haiku’s bootloader periodically (hrev58340 now) to see if there’s any improvement but no luck so far.
The only thing that fixes it seems to be using Windows 10 for 10+ minutes.
Any chance you can get a serial log? Onscreen debug probably won’t print anything, and what we really need is the early-boot debug information to see where things are getting stuck.
Ngl, I’m unfamiliar with how serial logging works, I assume some dedicated hardware is needed and I have none of that. If there’s some way I can make the bootloader dump a log somewhere in the drive or to another pc or display it at boot please let me know and I’ll try and grab it somehow.
Unfortunately the important part of this is likely the kernel/bootloader handoff, which isn’t logged anywhere but serial at the moment. We haven’t set up the frame buffer console that early, so the onscreen debug output won’t capture this.
I wonder if it’d be possible to get that to work, even as a hack… but for now, it’s not.
Well, I spent some time investigating getting the “bluescreen” console enabled much earlier in the boot, and it turns out that it wasn’t so difficult after all and we could have done this years ago. Implemented in hrev58344 (however, this depends on an 64-bit-specific mechanism, so it won’t do anything on 32-bit systems.)
Please retest after that and see if you get a KDL. If you don’t (or it’s not very useful), I can see about adding some more hacks to get onscreen debug output.
Strangely enough, since I upgraded to hrev58344 I am not experiencing the boot hangup after using Kubuntu, I have tried twice and the boot worked fine, I could’ve sworn it basically happened all the time. So weird.
I’ll keep trying to reproduce it and report back if/when it happens, but maybe enabling the console earlier fixed it somehow?
I dont think the bootloader is the problem, some devices have different operation modes, windows might switch a device int a mode which is compatible with haiku, while linux switches it into one that is incompatible with haiku
Wouldn’t surprise me. Tbh, as much as I want to get rid of Windows before they force Win 11 on my “unsupported” CPU (a Kaby Lake) Linux has been a terrible deal in this multi-boot configuration so I have to keep Windows installed as a failsafe.
Run Linux? Clock gets messed up on the other OSes. Fix it via Terminal? (the only way to fix things in Linux apparently) The system nags me about it being sub-optimal or whatever (and I don’t care tbh)
Update Grub? It wipes my custom bootloader setup so next time I boot it’s “Oops! All Linux!”
Want to edit the boot partition on Linux? Tough luck, it’s always mounted as read-only and KDE hates running anything graphical as root (why do they want to babysit me so much on a system that requires you to be tech-savvy anyway?) so you have to bust open the terminal.
Why does the system force you to do anything remotely useful only by terminal anyway? Are we still in the '90s?
This is why the “year of Desktop Linux” is a meme, the OS is, by design, almost as user-hostile as possible.
So. Dang. Frustrating. Microsoft may be scum for an endless amount of reasons but at least Win 10 doesn’t bat an eye at my multi-boot configuration and doesn’t get in the way.
Sorry for the rant, but Linux is so infuriating at times.
Wow, I thought my EFI multi boot setup was a pain, but … I don’t honestly remember much, but I’m sure it wasn’t that hairy. But I don’t have Windows, and the computer is a Thinkpad ca. 2018, possibly avoiding some issues right off. Instead I installed NetBSD, and Manjaro on the Linux partition. ReFind for the boot menu. It works but doesn’t seem to be really well supported by operating systems, so you have to hunt around for hints. MBR is easier all around.
Ok, it happened again after spending some minutes on Linux, I enabled on-screen logging but it showed nothing, aside from the boot screen with no icons active. Does serial logging have to be enabled as well for it to work? I didn’t check if that made a difference. (Though I guess I should’ve expected a KDL instead of a log in that screen?)
Whatever was logged by the bootloader before starting the boot process showed it recognized all partitions present (and some hardware, I think) without any errors, btw.
I rebooted into Windows, it showed me the dreaded “just a moment” screen for some reason (hadn’t seen it in ages) and a couple of minutes later Haiku was bootable again and it showed me the log during boot just fine.
I took a look at what this PC calls “BIOS configuration”
Boot options are:
Secure Boot Control is Off
OS Mode Selection is at “CSM and UEFI OS”
Fast BIOS Mode is On
PXE OPROM is Off
Iirc Haiku doesn’t boot with Secure Boot on from here.
Wow, I thought my EFI multi boot setup was a pain, but … I don’t honestly remember much, but I’m sure it wasn’t that hairy.
I’m so tempted to just blame Canonical on this ngl, too bad this laptop has a wonky dual-gpu setup with Nvidia Optimus/Prime and I could only make that freakshow work on Ubuntu-based stuff… for some reason. I would’ve gone with an Arch-based distro too otherwise, but after 2 days of unsuccessfully tinkering with it on EndeavourOS (and one on LMDE) I just gave up, I don’t have that kind of patience for tinkering with OSes anymore.
No icons lighting up means the kernel did not start. So you have only logs from the bootloader, and currently there is no way to show these on screen unless you completely disable the splash screen (this needs a recompilation ofthe bootloader). A serial port would work, if you can have one on the machine (not the case on most machines today).
I’d like to suggest having the bootloader disable the splash screen as a selectable boot option then, it sounds pretty useful for debugging and could maybe appeal to some people more than the standard boot.
And yes, unfortunately this laptop has no serial ports. The I/O is pretty barebones actually which is a shame.
On EFI systems, I don’t think we can really debug anything between the bootloader exit and the kernel debug output startup except via serial out. On legacy BIOS systems, there’s at least the theoretical possibility for VGA text output, but AFAIK this does not exist under EFI.
It’s too bad there isn’t some kind of virtual serial to RAM or something, since practically no one is any better off than MichaelPeppers here. I mean, I know what a serial port looks like because I had a computer in the '80s, not because I’ve seen one recently.
I meant “between bootloader exit and kernel debug output startup”, i.e. after ExitBootServices, so we don’t have EFI text output in that stage. But of course it could be getting stuck before that.
I was thinking if we could add a new boot loader debug option to help debugging early stage hang issues. If the option is activated Haiku boot loader would store the address of the boot log in EFI NVRAM variable. When the system hangs and is restarted there’s a chance the log stays in memory intact and can still be inspected from the boot loader upon the next boot.
For that to work, first we’d need to store the log at some addresses that wouldn’t be overwritten by EFI or boot loader data on the next boot (like above 128 MB, and then the boot loader should use AllocateMaxAddress type of allocation during the next boot).
Second, the RAM content needs to survive till the next boot, meaning the UEFI must not zero-fill RAM or perform full RAM check upon startup. If it does there’s usually an option to disable the behavior in the UEFI setup utility.
And the most important part is, the RAM content should stay intact after reset or power-off/power-on cycle. For that one I’ll quote a research paper on cold boot attacks:
Contrary to popular assumption, DRAMs used in most modern computers retain their contents for seconds to minutes after power is lost, even at operating temperatures and even if removed from a motherboard. Although DRAMs become less reliable when they are not refreshed, they are not immediately erased, and their contents persist sufficiently for malicious (or forensic) acquisition of usable full-system memory images
