[UNSOLVED, CLOSED] Inaccessible BIOS on Toshiba Dynabook Tecra X40-E

kousu · 2025-10-22 19:51:38

I have a Toshiba Tecra X40-E that I just installed Arch on.

Before I installed Arch, I pulled out the battery (to replace the SSD). After that, it booted to a screen that told me to press F2 to reset the firmware settings (apologies, I'm not sure of the exact wording). That worked fine. Also, several times I was able to tap F2 during the initial "Dynabook" boot logo to get into the firmware settings (which Toshiba calls "BIOS" even though it's UEFI), or tap F12 to get a boot menu. I installed Arch using that boot menu, and at some point reset the firmware settings; I hope that wasn't a foolish move.

Anyway, somewhere between installing Arch and resetting the firmware, F2 and F12 are no longer responding during boot, and I am blocked from the "BIOS". I have tapped these keys furiously. I have held fn while tapping them furiously in case their meaning had been swapped somehow. I have held the buttons down while pressing the power button. I have held them down for three seconds after pressing the power button and then released. I have turned off the power and waited 30 seconds each time before doing any of these. Nothing works, I boot straight from the Dynabook logo to the Arch logo to the kernel boot log.

I searched around and found that, within Arch, I can run

systemctl reboot --firmware-setup

Also, this has the same effect:

efibootmgr -n 0000 && systemctl reboot

Either gets me back into the BIOS, finally. There I can use my mouse -- the firmware setup is a GUI -- but not my keyboard. The keyboard lights up when I press it but the BIOS ignores its input entirely. That's odd. The keyboard was working in the BIOS, it's how I configured the settings I had before.

Knowing that that inspired me to try an external USB keyboard and with that I was able to press F2 to get in, but only when I press it on the external keyboard.

I wonder if the reason is that I have "fast boot" enabled in the BIOS. I've read elsewhere, including the Toshiba support site, that fastboot will block accessing the BIOS. But that page says F2 should still work:

Fast Boot can be enabled or disabled in the BIOS setup, or in HW Setup under Windows.
If you have Fast Boot enabled and you want to get into the BIOS setup. Hold down the F2 key, then power on. That will get you into the BIOS setup Utility.
You can disable the Fast Boot Option here. You will need to disable Fast Boot if you want to use the F12 / Boot menu.

and also, more to the point, I don't have a Fast Boot Option in my BIOS. At least, it's not exposed in the setup utility. I'm sort of worried fastboot was disabled but resetting the BIOS enabled it but as a secret feature that can only be turned off using Toshiba's Windows-only firmware config tool.

I'm not sure what I've done. Maybe this isn't a Linux problem at all, but I can't tell at this point. I just know everything worked before I installed Arch.

I'm booting using UKI, built with

$ cat /etc/mkinitcpio.d/linux.preset 
# mkinitcpio preset that builds a https://wiki.archlinux.org/title/Unified_kernel_image
# which is an EFI-bootable file that bundles the contents of /etc/kernel/cmdline, a splash image,
# and the kernel and initrd into one single file, without a second-stage bootloader like GRUB or syslinux.

#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux"

PRESETS=('default' 'fallback')

# Build into the default boot path for 64-bit EFI ($ESP/boot/bootx64.efi)
# which means that there's no need to modify the system EFI settings.
default_uki="/boot/efi/boot/bootx64.efi"
default_options="--splash=/usr/share/systemd/bootctl/splash-arch.bmp"

fallback_uki="/boot/efi/boot/archlinux-linux-fallback.efi"
fallback_options="-S autodetect"

# cat /etc/mkinitcpio.conf.d/hooks.conf 
HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block lvm2 encrypt filesystems fsck)
# cat /etc/mkinitcpio.conf.d/modules.conf 
# for reading from /boot during boot
MODULES=(vfat)
# grep -R . /etc/cmdline.d/    # this is how I configure my kernel command line
/etc/cmdline.d/tty.conf:vga=773 consoleblank=600
/etc/cmdline.d/iwlwifi-workaround.conf:# iwlwifi bug workaround: https://bbs.archlinux.org/viewtopic.php?pid=2072845#p2072845
/etc/cmdline.d/iwlwifi-workaround.conf:iwlwifi.disable_11ac=true iwlwifi.disable_11ax=true
/etc/cmdline.d/root.conf:cryptdevice=UUID=288ad484-a180-4b6e-a6cc-c41fa5008277:cryptlvm root=/dev/lvsys/root rw
/etc/cmdline.d/psi.conf:# Pressure Stall Information: https://docs.kernel.org/accounting/psi.html
/etc/cmdline.d/psi.conf:psi=1

Also

I'm not sure if my bootloader setup is relevant -- it shouldn't be, logically -- but I have read in several threads reports of the BIOS going inaccessible after installing Linux and we all know computers aren't actually logical

Here's my EFI entries:

# efibootmgr
BootCurrent: 0003
Timeout: 5 seconds
BootOrder: 0003,2001,2002,2006,2004,2005,0002,0000,0001
Boot0000  Boot Device List	FvVol(90d48ac7-b731-4c31-8616-acb45d50d720)/FvFile(8aac995e-8c22-4818-bd75-a9ef04a5ed04)
Boot0001  Diagnostic Menu	FvVol(90d48ac7-b731-4c31-8616-acb45d50d720)/FvFile(11480c78-2d02-4947-8a66-d7cb16e4961a)
Boot0002  UiApp	FvVol(90d48ac7-b731-4c31-8616-acb45d50d720)/FvFile(cd2c0d2c-49e0-4698-ab5a-192548ae90b4)
Boot0003* HDD/SSD	PciRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x0)/NVMe(0x1,00-1B-44-8B-42-CF-1B-71){auto_created_boot_option}
Boot2001* USB Memory	{251a5b43-a4b6-4c7f-a56f-bff793b7070c}
Boot2002* USB ODD	{251a5b43-a4b6-4c7f-a56f-bff793b7070c}
Boot2004* LAN1	{251a5b43-a4b6-4c7f-a56f-bff793b7070c}
Boot2005* LAN2	{251a5b43-a4b6-4c7f-a56f-bff793b7070c}
Boot2006* FDD	{251a5b43-a4b6-4c7f-a56f-bff793b7070c}

Here's my hardware info:

# dmidecode
# [....]
Handle 0x0013, DMI type 1, 27 bytes
System Information
        Manufacturer: TOSHIBA
        Product Name: TECRA X40-E
        Version: PT482C-06D00UHQ
        Serial Number: XXXXXXXXXXXXXXXXXXX
        UUID: 3cb68818-419d-4030-97d8-0a0e466a4981
        Wake-up Type: Other
        SKU Number: PT482C
        Family: TECRA
# [....]
Handle 0x0012, DMI type 0, 26 bytes
BIOS Information
        Vendor: TOSHIBA
        Version: Version 2.50  
        Release Date: 10/19/2021
        ROM Size: 8 MB
        Characteristics:
                PCI is supported
                BIOS is upgradeable
                BIOS shadowing is allowed
                Boot from CD is supported
                Selectable boot is supported
                EDD is supported
                Print screen service is supported (int 5h)
                8042 keyboard services are supported (int 9h)
                Serial services are supported (int 14h)
                Printer services are supported (int 17h)
                ACPI is supported
                USB legacy is supported
                BIOS boot specification is supported
                Function key-initiated network boot is supported
                Targeted content distribution is supported
                UEFI is supported
        BIOS Revision: 2.50
        Firmware Revision: 1.40
# [....]

Some other threads with similar problems:

- https://bbs.archlinux.org/viewtopic.php?id=282332 - sort of similar, but no clear solution just "reinstall" somehow magically fixed it
- https://bbs.archlinux.org/viewtopic.php?id=273692
- https://bbs.archlinux.org/viewtopic.php?id=281915 - this one especially has similar symptoms, except it was worse in that case because `systemd reboot --firmware-setup` didn't even work, and it wasn't a Toshiba. Fixed by finding the CMOS jumper (I'm not sure I have a CMOS jumper, though I think unscrewing the case and disconnecting the battery would probably do the trick)
- https://bbs.archlinux.org/viewtopic.php?id=285674 - another "install Arch -> lose BIOS" situation. Unclear if that was ever resolved.
- https://bbs.archlinux.org/viewtopic.php?id=294049 - "install Arch -> lose BIOS". Fixed with a firmware update :S :S :S
- https://bbs.archlinux.org/viewtopic.php?id=300026 - "install Arch -> lose BIOS". Fixed by deleting a stray efibootmgr entry that was confusing the firmware. Scary! Acer laptop. Maybe not relevant because I didn't edit my EFI vars; I put my kernel in the default boot location specifically so I wouldn't have to mess with efibootmgr.
- https://bbs.archlinux.org/viewtopic.php?id=251091 - fixed by reinstalling grub. I'm not using grub but this and the other thread suggest that EFI boot entries that firmwares aren't "expecting" can give them aneurysms
- https://bbs.archlinux.org/viewtopic.php?id=257399 - this person considered `reboot --firmware-setup` to be a solution. I don't, I don't want to depend on having a working OS to configure the hardware underneath it.
- https://bbs.archlinux.org/viewtopic.php?id=257884 - not solved

Questions:

- Does anyone else have a Tecra? I'd like to compare notes, even if you have an older/newer model.
- Is there a secret BIOS setting for "make the keyboard work during UEFI" that I've disabled by accident? How do I turn it back on?
- Does anyone know if this model supports fast boot?
- Is there a way to configure "fast boot" without going into the BIOS or installing Windows? Maybe I can use efibootmgr for that? Is "fast boot" just setting the boot timeout to 0?

Thanks for any assistance or insights any of your might have to share. I'm really stumped on this one.

Last edited by kousu (2025-10-29 22:21:59)

cryptearth · 2025-10-22 22:23:06

kousu wrote:

Is "fast boot" just setting the boot timeout to 0?

although it varies from bios to bios - but "uefi fast boot" is far more complicated than just removing a timeout
most general it skips a bunch of POST hardware checks and initialization to speed it up to get to the OS faster
this is supposed to work best in combination with windows fast boot option: when windows is "shut down" with both uefi and windows fast boot enabled the system is not really shut down but rather suspended in some very deep hibernate mode
the idea is: instead of properly fully cleanly shutdown the OS and unload all stuff merely it's state gets saved to disk (hibernation) - including the hardware state - and on "power up" the state is just loaded back into memory
the issue: the hardware is not properly reset but is kept in an state to make it available as fast as possible - by skipping usual checks and proper reset and init but just rely on "it's in about roughly same-enough-ish state when on 'shut down' so just load its state from disk back into ram should do the trick" while windows-only special black magic drivers handle the few issues caused by this
and - fun fact: the hardware is designed to work this way - so trying to run linux on a system not specifically designed to be used with linux (pretty much everything with a "certified for windows" sticker on it) will have this "design" (or more correct: issue with anything else but windows)

it's one of those: "sure, you're free to run any software on this device - as long as its the specific windows version this device was certified with" kinda idioms

so - the TLDR: most "fancy" stuff is specifically designed for windows and only works properly with windows - when you use linux - just disable all that crap - yes, it will cost you a few more seconds to boot - but at least your system should do a full power-on reset and clean init so stuff like the built-in keyboard works during POST to enter the uefi

or - do some research upfront before bying new hardware if its linux compatible - like System76 or Frame.Work

kousu · 2025-10-23 00:41:23

so - the TLDR: most "fancy" stuff is specifically designed for windows and only works properly with windows

I am worried it is something like that. I would love to disable the Windows-trained parts, but I can't even get back in right now! I pulled the battery to see if that would help and now I can't even get past "Date and Time reset to default, Press [F2] key to set Date and Time" because the BIOS doesn't respond to key presses, so it's a brick :'(

And like I said even when I was able to get in via booting to Linux -> `systemctl reboot --firmware-setup` I couldn't see a fast boot toggle in there. I appreciate the input. Do you think I can assume that it's probably not something toggleable with any kind of linux utility, then? It'll be something proprietary?

or - do some research upfront before bying new hardware if its linux compatible - like System76 or Frame.Work

I hear that, but the point of using free software for me is to freely choose devices, apps and workflows. Refurbishing mass-market products is cheaper and more accessible than buying from niche manufacturers (though I believe 100% there's a place for both!!). And anyway I've run into firmware bugs with System76 before too, so no one's perfect.

Maybe F2 being ignored is not a linux problem at all, so I'm going to try to get some hardware help in parallel. I don't know. The keyboard works when Linux is booted but maybe I jiggled something loose that is a problem only during early boot. I'm still hoping someone with experience in this corner case is around and is willing to compare notes!

Last edited by kousu (2025-10-23 00:42:01)

kousu · 2025-10-29 22:24:27

I ended up getting the motherboard replaced and both Arch and the BIOS seem fine on the new motherboard. So I don't know if it was subtle hardware damage or corrupt firmware. Either way, probably not an Arch issue after all.

Arch Linux

#1 2025-10-22 19:51:38

[UNSOLVED, CLOSED] Inaccessible BIOS on Toshiba Dynabook Tecra X40-E

#2 2025-10-22 22:23:06

Re: [UNSOLVED, CLOSED] Inaccessible BIOS on Toshiba Dynabook Tecra X40-E

#3 2025-10-23 00:41:23

Re: [UNSOLVED, CLOSED] Inaccessible BIOS on Toshiba Dynabook Tecra X40-E

#4 2025-10-29 22:24:27

Re: [UNSOLVED, CLOSED] Inaccessible BIOS on Toshiba Dynabook Tecra X40-E

Board footer