I’ve had a Framework Laptop 13 (the Intel i5-1340p version) running Fedora Linux (currently version 41) for well over a year now. I’ve been really impressed with the product and enjoyed using it, and it’s been pretty much 100% reliable, until today. I had completely drained the battery the evening before and forgotten to plug it in overnight. I plugged it in this morning and tried to start it and something is very broken.
Every time I try to start it, it waits a few seconds and then flashes the diagnostics on the side LEDs - white, 12 green, orange, 8 green - which I’ve never seen it do before. Then the display backlight comes on and after a few seconds it starts the normal boot process, but ridiculously slowly. In total it takes about 20 minute from pressing the power button to getting a login prompt, and then another 10 minutes to anything resembling a functional desktop. Even then, applications take a very long time (sometimes minutes) to launch; the USB ports work only for power (no data); if the display goes to sleep it’s impossible it get it to wake up (or possibly it just takes a very long time and I haven’t waited long enough!).
Clearly the laptop isn’t really usable in this state, so here’s what I’ve tried so far to diagnose/fix it:
Review the messages printed during boot - seems to reveal that it is hanging at “start systemd-journald.service”. It keeps trying to start this service over and over again for quite a long time and fails repeatedly . I don’t think this is symptomatic of an OS problem (hence this not being in the Linux part of the forum - see below!) but included nonetheless in case it could be an indicator of something else
Booted the drive in a different machine -it behaves exactly as I expect the Framework to, takes no more than a minute or so to boot and works perfectly (which I think rules out a faulty drive and/or corruption of the OS installation)
Booted the Framework from a USB stick - it’s also extremely slow, and sometimes I can’t get it to work at all
Opened the laptop and performed a mainboard reset (although I’m not 100% sure I followed the procedure correctly, as there doesn’t seem to be a guide for the 13th gen Intel model specifically, but following the same procedure as for 11th gen systems ignoring the bits about the RTC battery seemed to work). After doing this, the system booted perfectly once, but it wouldn’t shut down properly (power button light stayed on after the OS had seemingly finished shutting down) and now if I try to boot it again it’s having exactly the same problems as before.
I feel that I’m rather hitting a brick wall with this, so I’d really appreciate some advice on what to try next to fix it. Let me know if you need any more info.
Sadly not. Exactly the same issue except I also now can’t get into the UEFI menu! (Pressing escape on boot does nothing, and selecting the option in the Grub bootloader menu just leads to a black screen with a white cursor in the top left)
Those instructions didn’t seem to correspond to the behaviour I see when I attempted them. The mainboard lights were blinking immediately on removing the input cover. Pressing the chassis intrusion switch stopped them blinking but then I didn’t have to wait at all for them to start blinking again after releasing it. It was immediate.
I’m also slightly confused about the fact that those instructions tell you to press the power button before reinstalling the input cover. The power button is on the input cover!
They are aimed at the 11th gen Intel boards but they did appear to work for this 13th gen one (the board did seem to have been reset, e.g. the system time was shortly after midnight) but as mentioned before, that only got it to boot properly once, then it was back to the same old mess.
$ sudo ectool battery
sudo: password for [username]:
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
Battery info:
Bad battery info value. Check protocol version.
$ sudo ectool battery 0
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
EC result 3 (INVALID_PARAM)
Battery info:
Bad battery info value. Check protocol version.
Out of interest I had a poke around in the battery information that I can get through the OS and came across this in the power information widget in the KDE panel:
I’m not especially sure if “Battery Health: 0%” is particularly meaningful (I don’t recall looking at that section before, so maybe it’s always said zero for all I know!) but it does certainly seem to align.
