Chaospott/site
47
1
Fork 3
Code Issues Pull Requests Releases Activity

Typos

Browse Source
This commit is contained in:
T
2026-07-11 13:21:44 +02:00
parent 6377d9686c
commit fe59b4f3ab
1 changed files with 8 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
_posts/blog/2026-07-11-ideapad.markdown
+8 -8
View File
@@ -1,7 +1,7 @@
---
layout: post
title: "Lenovo IdeaPad 330S-15ARR Recovery"
date: 2026-07-11 12:42:23
date: 2026-07-11 11:20:23
post_author: 지지 aka CyReVolt
---
@@ -9,7 +9,7 @@ One of our members was facing issues with a laptop, so we teamed up.
## Problem
After a suspend, the laptop no longer came up and the screen remained black.
After suspending, the laptop no longer came up and the screen remained black.
Nothing helped; unplugging the main battery and the CMOS battery, unplugging AC
and trying to power cycle multiple times did not do the trick.
@@ -33,7 +33,7 @@ That gave us `7wcn38ww.exe`.
## Unpacking
From earlier experience, we knew that `innoextract 7wcn38ww.exe` would extract
it for us, and we got a directory named `app/` containg the file `BIOS.cap`.
it for us, and we got a directory named `app/` containing the file `BIOS.cap`.
That file is larger than the flash chip, because it is an _upgrade_ image, a
UEFI application containing the actual image.
@@ -60,7 +60,7 @@ similar. So we gave it a try and flashed the fresh image to the laptop.
## Almost there
![laptop and firmware menu]({{ site.url }}/media/2026-07-11/ideapad_recovery_step1a.jpg)
![laptop and firmware menu](/media/2026-07-11/ideapad_recovery_step1a.jpg)
We then tried to boot again, and we were very pleased to see the Lenovo logo,
followed by the OS bootloader. But the OS failed to boot, showing a black screen
@@ -68,7 +68,7 @@ only, and no kernel output.
So we went into the firmware settings, and saw that the product name was set to
"ILLEGAL". Weird.
![laptop and firmware menu]({{ site.url }}/media/2026-07-11/ideapad_recovery_step1b.jpg)
![laptop and firmware menu](/media/2026-07-11/ideapad_recovery_step1b.jpg)
An attempt to boot a fresh Linux Mint image from a USB stick worked though. So
we installed that on a new partition, rebooted, but once again, the kernel did
@@ -101,7 +101,7 @@ dd if=backup.rom bs=4096 skip=494 count=1 | \
And we finally saw the product name show up in the firmware menu, the kernel
happily booted, and the owner of the laptop is happy again.
![laptop and firmware menu]({{ site.url }}/media/2026-07-11/ideapad_recovery_step2.jpg)
![laptop and firmware menu](/media/2026-07-11/ideapad_recovery_step2.jpg)
## Recap
@@ -132,8 +132,8 @@ blocks of 64 bytes each that had been cleared:
002f 03e8 ff ff ff ff ff ff ff ff |........ | 002f 03e8 ff ff ff ff ff ff ff ff |........
```
So we conclude that some race condition may have occured when the firmware tried
to handle the suspend request, but since it is closed source and we did not
So we conclude that some race condition may have occurred when the firmware tried
to handle the suspend request, but since it is closed source, and we did not
intend to spend weeks and years reversing all the components that are part of
the power management, we are leaving it at this point.