indeed that is what is happening. it is trying to boot from the floppy (lol) < like the screenshot above shows < so weird
you know this makes me want to try with another keyboard (different type/model) just to see if this is ACTUALLY the case … if it IS then SeaBIOS is weird lol (or just primitive)
please do, this isn’t my first rodeo, or first time debugging keyboard issues with SeaBIOS. Once you have a working keyboard and can install an OS, then we can reattach the non-working one, do a default boot, and then pull the firmware boot log to see what’s going on. If needed, I’ll have you flash a test build with more verbose logging for SeaBIOS so we can try to resolve the issue.
As an observation, you should be able to remove the storage and still boot successfully, therefore you can fault isolate the storage.
Another option for the storage that you might try (or indeed for this whole problem) is … put the storage in an external enclosure, image it from another working PureOS system, then reinsert the storage. Even without a working keyboard, if it tries to boot from the hard disk then it might work that time (and would at least prove that the hardware and software are happy with the storage).
Any chance that you are using a keyboard with some non-US layout?
that is reassuring since for ME this IS actually my first rodeo and taking every chance i get to learn something from more experienced people …
that is music to my ears Sir ! i was about to ask my kbd manufacturer for help but i’ll postpone that untill we can get something more concrete out of this.
i will let you know once i’ve tried with the other kbd … right now i’ve something else going on unfortunately
Any plans for a “secure attention key” that does a non-maskable interrupt
into ring <0 ? Maybe two buttons and LEDs, wired directly, not USB or PCI,
so in a pinch one could interact with a hypervisor by morse code, or a popup
one KNOWS is securely presented from dom0.
One could imagine a s/w protocol where any legit input request showing could
be validated by dom0 when user sees screen widget and pushes the SAK,
and the border gets changed to indicate authenticity.
yes the “Fn” key is what changes LAYERS on this kbd but to get the actual “ESC” key i have to press “Mod” or double-tap it for permanence if i want that LAYER to remain active.
on my uhk kbd i have it configured to use the “~” as “Esc” on the BASE LAYER < just like a “normal” keyboard < i simply hit “Fn” + “Enter” (in my case) and it changes the entire KEYMAP to be whatever i want (this is done through the GUI-front-end-Agent < source code on github)
the Agent is available on github but it has an easy to use .AppImage for people that don’t want to compile from source.
one would be able to literally change everything on this kbd < they even offer a third-party fork of the firmware that does even CRAZY-er things than what the official firmware can do. i haven’t got to that point yet though …
i would not know what this “USB init/timeout” issue would be referring to but when i had my uhk connected to the LMini (even before i pressed the power-on button) the KEYMAP LED lit up and i was able to change from the default QWERTY keymap to my custom KEYMAP that has “ESC” on the base layer
so even before the LMini was powered-on i was able to make changes on the fly to my uhk. it would be unacceptable for me to NOT be able to use my uhk with the LMini after i get PureOS installed on the internal-main drive …
i’ll do the necessary jump-through-the-hoop-game with the other kbd in order for us to trouble-shoot what SeaBIOS doesn’t like about the uhk but NO MORE … maybe if we can get something useful there will be a firmware update for the uhk from the manufacturer that will allow this problem to go away … benefits of free-software and all that good stuff
there’s no reason to suspect the keyboard won’t work once the OS is booted – this is a singular compatibility issue with SeaBIOS, which isn’t uncommon (our CTO ran into it with one of her USB kb during testing). You’ll need to use another keyboard to get the OS loaded. Up to you if you care to help us debug the issue after that. I can’t personally buy every piece of incompatible hardware for troubleshooting.
why not ? this will likely help a few people down the road … beside i have an interest in this since the uhk manufacturer is very close (geographically speaking) to where i currently reside.
by “no more” i meant that i expect to be able to use my uhk kbd after we figure what is the issue in SeaBios and then i can put the other kbd to rest since i hate having a cluttered desktop and a 100+ keys keyboard really is more than i need most days … hope i didn’t offend by this. it’s just my weird typing and shit English
i might do that at SOME point … i just don’t know when.
that being said … i’m posting this from PureOS which i successfully installed on the main internal m2 drive …
i’ve chosen the “wipe-drive” not the manual option just to see if it installs properly with the Purism-Recipe … it was a bit different not having to set-up an /efi as fat32 and esp flag per my ususal UEFI debian clean-installs but hey it’s ALL good now … except i don’t get what’s up with the uhk not being able to push the “ESC”
the keyboard i’m currently typing from is a G-413 from Logitech (100+keys) and it’s SO weird typing on it …
if you would be so kind as to walk me through what i need to do in order to help you guys see what the SeaBIOS issue is with the UHK i’m listening. or should i attempt to flash PureBOOT directly and see if the same happens with the UHK there ?
i don’t mind doing a double test for FUTURE proofing but PureBOOT is what i’d like to use … although i don’t have an L-Key + Vault yet … are they mandatory for PureBoot ?
please excuse the many questions … should we take this private or should i start a new thread ?
start a new thread please, since your issue is keyboard compatibility with SeaBIOS on the mini, not anything related to Qubes. Please don’t flash Pureboot since that would prevent us from troubleshooting the issue; Pureboot, using Linux as a payload, is highly unlikely to exhibit the same issue.