I’ve had a batch 5 DIY laptop for about a week now, and the last time I tried to use it, it was turned off and seemingly dead. Charging didn’t turn on the LED, and everything else was completely unresponsive. I opened it up and disconnected the battery, and managed to get it to power off AC, this worked totally normally, but with the status LEDs blinking red. I cannot get power with AC and the battery connected at the same time, and nothing I do with the battery connected gets any indicators from the laptop. I have also tried pulling the CMOS battery for over 15 minutes with no luck. My laptop runs Arch, and the last time I used it I installed the latest kernel (1.15.3?). I don’t think this should impact it like that but it’s the only thing I can think of on my end that might have caused this. Any ideas on things I can do to troubleshoot this issue?
I believe I’ve managed to reproduce this issue. I had a Framework Laptop booted into Ubuntu 20.10 and I left it in suspend for almost a week without being plugged in.
My suspicion is that something in the battery might be faulty. I have another Framework laptop so I’ll attempt a battery swap and see if that resolves the problem.
[Edit] I’ve completed the battery swap and observed something odd. The original laptop (bad battery) was able to power on with the donor battery just fine. The donor laptop which inherited the bad battery was unable to start.
However, in the donor laptop, it was able to start charging the battery it seems. It’s currently charging now with an orange light even though it was completely unresponsive in the original laptop.
My current theory is that disconnecting the battery for some time may help with your situation if the battery has become “over-discharged.”
[Edit 2] The donor laptop with the “bad battery” has been able to charge to about 10% no problem, so for me, I think both laptops are working fine now.
Any idea on if there is a way to do this with a single laptop? I currently don’t get any indication that my laptop is charging right now. Also any ideas on how to prevent the issue from popping up again in the future?
If I retrace my steps, I am guessing if you disconnect the battery and then leave it off the charger for approximately 5-10 minutes, it should reproduce what I did.
To prevent this from happening, I’m not exactly sure why it happened and my best guess is the battery was drained completely and triggered some kind of safety circuit. My guess is that Linux suspend doesn’t hibernate and has a tendency to drain the battery completely. On my Windows installation, the system will go into hibernate and shut down the system.
I’m not that familiar with Linux, but it seems the solution is to configure the OS to suspend the system to disk after a set period of time, or to turn off the system if you intend to keep it off the charger for a considerable time. The other issue is related to battery drain during suspend, which is probably much faster in Linux than Windows for now until the software support improves.
I noticed something that appears to be connected. I left my Framework in standby and disconnected the charger just to run the battery down so that it wouldn’t be charging at 100% all the time - give it a bit of a rest.
But I went on a business trip and forgot to plug the charger back in. When I returned, the battery was completely empty as expected - but what I did not expect was that it did not start charging again when I plugged the cable back in. No amber LED and the power supply remained cool. Nothing happened when I pressed the power button. Nothing was making it charge.
Before I really started to panic I let it sit for a bit and when I came back some time later the amber LED was on. Went out to run some errands and by the time I got back a few hours later the LED was white. I haven’t powered it up but if I did I’d expect this to be a cold boot.
@Kieran_Levin stated that the little standby battery that’s usually a lithium CR2032 is a new rechargeable type charged off the main battery. My guess is that as long as it has a charge it will operate the recharging logic and LED status as normal, but if the main battery goes empty and stays there for long it will also empty and cannot activate the charging procedure (USB PD negotiation) or the status LED. However the main battery is probably being slowly charged by USB default (non PD) power along with this little battery, and once the little battery recharges sufficiently, it negotiates USB PD with the charger, activates the status LED and starts charging the main battery at high power.
This takes time. Leave it for 5-10 minutes.
But I wonder if the BIOS settings have been wiped? That’s another function of this battery. I’ll have to power it up and test.
Edit: date and time is good, it was a cold boot as I suspected. BIOS settings seemed to be retained.
I’ve ran into this issue just now this morning (left laptop playing video and it died). Pressing power button it blinks red twice and nothing happens. I have power plugged in so will wait and see what happens.
In any case, if it does eventually boot it would be great to fix or provide Linux configuration suggestions to avoid having to wait this long (been charging for 10-20 minutes) without being able to use computer (should be able to boot even if only have power with minimal charge, while battery plugged in).
Will update on outcome of whether it eventually powers on.
exact same issue also batch 5. Unplug the battery and it works. the battery also discharges abnormally quickly when in sleep with the lid shut. I’m losing 30% charge overnight. then I left it in sleep for a week and it would not power back on.
Thanks for the reports on this, everyone. We definitely are interested in more detail to debug this. Could you share:
- What version of BIOS you have (in Windows, this is visible in System Information)
- Whether any other USB-C charger you have available (even a phone charger) results in different behavior when the Framework Power Adapter isn’t making the charging LED come on?
- The serial number of your system (PM it to @FrameworkBee ). This is on the QR code in the front left Expansion Card bay.
We believe there is a BIOS 3.06-specific issue where a system that has it’s battery drained far enough in a specific way ends up in a state where USB-PD power adapters won’t charge it. We’ve identified a workaround for getting out of this state:
If you are using 3.06 BIOS (the default BIOS Batch 5 and 6 ships with), the current workaround until we have an updated BIOS is:
- Plug in a basic USB power adapter to let the laptop trickle charge for 30 minutes. When doing this, make sure the power adapter you are using is a basic, non-USB-PD one, like an adapter that uses a USB-A to USB-C cable, like in the image below. If the charging LED does not come on after plugging this power adapter in, you may be facing a different issue.
- After 30 minutes, unplug the USB power adapter and plug in your Framework Power Adapter or other USB-PD power adapter and boot the system.
We’re also working on a BIOS update now to resolve this issue fully.
Got mine booting again with @nrp’s suggestion, just gotta figure out to do with the replacement board I got in the mail today 
hmmm ive tried all the steps provided throughout this board and nothing. it won’t turn on anymore. nor does the led or power turn on when plugged in. nothing lights up. i even disconnected the battery to see if that was the issue. this doesn’t seem to bode well for framework if my laptop is already dead if it hasn’t even been used much. I thought it was think whole standby thing.
Have you removed the RTC battery?
You should contact support.
@Fraoch Thank you for mentioning RTC battery. I have a Batch 4 I installed the 3.06 BIOS upgrade on so I could dim the power button and also run without battery for playing around. I had the laptop in my bag for a week and change without using it and came to find it dead.
Connecting a USB-A to USB-C cable connected to an old 5V@2A adapter didn’t light up on the right side, nor did leaving that connected for 30 minutes before attempting to then connect my framework OEM USB-PD connector to the left side. Nada. Even leaving the USB-A right side connected overnight.
Was going to read thru once more before contacting support… but saw that and was like… OK. For others’ information, I opened laptop, unplugged battery, used spudger to push RTC battery out from the left side to the right per the arrow on the board. Then I reconnected top case ribbon cable and tapped power button a few times to discharge any caps. Re-inserted RTC battery, reconnected main battery, closed laptop. Once I did that, the tip from this post worked. I gave it 10 minutes on non-PD power on the right side, then connected PD on the left, and it lit up!
Interestingly enough, my battery level is at 92% right now. Not sure if it originally drained to zero to trigger issue originally or if it still had charge. For what it’s worth, when I had put it away, it was at 95% charge and I turned it off when done, so I was questioning the drained battery cause a bit. Entirely possible it was drained though and just leaving it on the 10W non-PD overnight got it this high. Either way, no lights on the charging ports during that time with either adapter, and power button didn’t do anything until disconnecting the RTC and battery. I did have to reset my BIOS settings of course.
okay i got it. following all these steps didnt help until i removed the cmos battery. only then did it recognize any power source pd or otherwise.
Does anyone have thoughts on how to properly configure a Linux distro to prevent this happening? There are two ways computers ‘sleep’ with Linux (at least with systemd.) They can suspend, which means saving state in memory and entering low power mode. And they can hibernate, which means serializing all memory to swap and then completely shutting off. The problem here seems to be with batteries draining when a computer is suspended, but not hibernated. However, as far as I can see, Fedora, with default install options, does not configure itself with enough swap space to hibernate. It seems that the laptop entering suspend, but not hibernate is what is causing this problem. I am not sure what the situation is with Ubuntu. Now, we could choose a different distro or configure manually. But given that Fedora is one of the two ‘officially supported’ Linux distros with tutorials on the Framework website, I think it seems reasonable to ask for support for some sort of sleep without disabling the battery on this distro.
Weirdly, however, I dug through the Fedora 35 thread, and I didn’t see anyone with this issue. So maybe it’s just me that having this problem on Fedora. If you’re reading this, please let me know if I’m misunderstanding anything or if you’ve found a satisfactory way to configure your system without this becoming a problem
I’m not a Linux pro but I remember vaguely when I was using it there was a recommendation that your swap space be at least your memory. So it’s possible people following that advice will never hit this issue? The other possibility is that perhaps the automatic installer just picks a swap space based on your Disk size and not based on your System Memory so it can vary depending on your system configuration.
Lastly, it’s possible to have this happen for everyone but nobody else is leaving their system on suspend until the battery dies and using Linux simultaneously.
Either way, I don’t think this is a Framework specific issue - I have a Clevo laptop that actually bricked its battery in a similar situation, so if there’s no permanent damage I think we’re getting lucky.
Well, this is REALLY BAD. I left my laptop (batch 4 DIY, LUKS-encrypted Debian 11) off during holidays, I now need to do some urgent work and it doesn’t turn on.
Happy New Year, I guess.
Edit - Apparently BIOS 03.07 which is now available solves this (while possibly preventing your laptopt to boot-see below). Batch 4 shipped with BIOS 3.02. May I suggest emailing owners for this type of bug and update ? - Apparently an email was sent about this - just not to all users !
Edit 2 :After the BIOS update, it won’t boot - my WD Black 1TB NVME is not found. This is apparently fixed with (yet another!) firmware update which can’t be done unless you have a full Windows 10 on the same system (WD dash control also requires Internet) 
Spent most the day installing Windows to USB - only managed to do this with WinToUSB free edition on another Win 10 system.
Edit 3: It seems EFI on the NVME was zapped when BIOS was upgraded by USB/EFI method, I was able to restore it by following the GRUB EFI reinstall guide at the Debian Wiki with some variations. See this thread for more details.
In the end I spent 2 days chasing after this and getting back the laptop working again.
I had good recent backups, restoring to be able to boot again was the last fun part and worked. Thanks @another user for the hint! Never ever suspected the BIOS USB/EFI upgrade method to bork my system like this in 2022.
Probably UEFI firmware lost track of your OS. Just use a recovery medium to enter the UEFI shell (Ubuntu’s live image or Arch install or w/e), type in FS0: (or whichever disk that’s displayed that looks like your boot media), then find your boot .efi file and execute it (e.g. if grub it’s probably grubx64.efi or something like that). The usual cd and ls commands work in the UEFI shell once you’ve selected your drive (again, probably FS0:).
Once there, reinstall your bootloader to your boot media (e.g. grub-install if you use that). If you’re using Ubuntu or something else that insulates you from the bootloader installation process, you might be able to get away with reinstalling the bootloader package.
I was having the same issue. I used @dmac8086 's suggestion of disconnecting both the RTC battery and the main battery and that was the only way I was able to get it to boot!! I’ve been working on fixing this for several hours and this is the first time I’ve had any luck.
Interestingly, my battery power was at 37% when it booted up, which may have been because I had it trickle charging for awhile, though no LED lights came on and there was seemingly no power in the laptop.