Oops. Sorry.
that is exactly what i have done. followed your instructions to the letter and pressed the key “ESC” only once immediately after the text prompt appeared …
i even went a bit further and tried different combinations of usb ports + 2 different bootable storage media that i created with GDisks.
i will mention that BOTH storage media (one usb 3.0 128gb thumb drive from kingston and one external usb-3 to SATA SSD 128gb from Patriot) ARE working perfectly on another UEFI AMD desktop machine and i have been ABLE to select and boot into the PureOS LIVE environment. this with the EXACT SAME keyboard + mouse + display cable + monitor i used to connect to the LMini (that did NOT work as i described earlier)
so the question/mystery remains … why is it working PERFECTLY on ONE machine but not with the Librem Mini ?
@MrChromebox what is bugging me is if this weird thing is happening because i added my own RAM + storage combo instead of the options available from the Purism Online Store ?
my combination looks like this :
1 > RAM > Kingston hyperx DDR4 2400mhz 2 modules (16GB each) < they fit and look very nice in black
2 > storage > https://www.westerndigital.com/products/internal-drives/wd-red-ssd < the 500 GB m2 SATA variety (80mm length)
and just to be clear, when you do that, the boot menu does not appear, but the box proceeds to attempt to boot from the default/highest priority device (internal storage by default)?
If that’s correct, it has nothing to do with anything other than your attached USB devices, most likely the keyboard itself. How they behave on another system is irrelevant. SeaBIOS has its idiosyncrasies.
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)
indeed the boot menu does not appear
it’s weird but expected
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?
the one i am currently using is the ISO UHK variant not the ANSI one … it has the short L-Shift like this
and the ANSI is this
is this what you meant by 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
Looks to be a fairly standard layout actually … except for the Escape key.
Which modifier key do you have to use in order to use Escape? Fn?
I would try an even more standard keyboard.
it’s almost certainly a USB init/timeout issue and not an issue with the wrong scan code/key code being sent
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.
I was reacting to your ‘but NO MORE’
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
returning to original topic, can I get any more testers for the Mini / Qubes fix?
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.