monovergent

For those interested in some numbers on how much a quad-core mod might affect your power usage and battery life. This post only covers power consumption of the CPU as measured by RAPL to eliminate other factors such as LCD panel type, attached USB devices, or number of SSDs installed.

Averages for dual-core i5-3210M, 35W TDP:

• Idle: 2.87 W
• Moderate load: 13.79 W

Averages for quad-core i7-3612QE, 35W TDP:

• Idle: 3.84 W
• Moderate load: 13.03 W

Since I have been unable to source a ULV-modded board, I am looking for justification to do the mod myself. As part of this, I tested a S230U with the dual-core i5-3317U, 17W TDP:

• Idle: 2.49 W
• Moderate load: 9.51 W

Will come back with more numbers if I succeed in putting the ULV chip in an X230. Don't hold your breath since it's a complicated operation with many potential issues. You are also welcome to DM me if you want to sell a ULV-equipped board.

Experiment setup:

• Command: sudo powerstat -R 10 10
• Idle: Debian 13 TTY, X session logged out
• Moderate load: Xfce desktop, Librewolf with uBlock Origin, playing a 720p Youtube video
• I am not sure how much this affects the numbers, but the S230U is on the stock BIOS while the two X230's are on Coreboot with me_cleaner.

For several years, I've entertained the idea of creating an online portfolio, but it's remained only an idea since I am not sure what I should put on it. What's a good way to decide what goes on the personally-identifiable portfolio and what should remain under pseudonyms?

In the interest of maximizing battery life, I've set up suspend-then-hibernate on my laptop. Using a discrete window manager, so I have a systemd unit that locks the screen when I close the lid. After an hour, it automatically goes into hibernation.

All is well, until I have to boot up from hibernation. I'm prompted to unlock LUKS, then I'm hit with a redundant lock screen once resumed. I've tried setting up systemd units referencing suspend-then-hibernate.target and hibernate.target, but I can't get it to kill the screen locker when resuming from hibernation only, so I don't have to type in my password twice. Is there any way to have systemd discriminate between the suspend and hibernate parts of suspend-then-hibernate?

Earlier post for context: https://lemmy.ml/post/35496495

TL;DR: Don't buy Huawei or Honor phones if you need bootloader unlocking capabilities. Even on units without a carrier lock. I couldn't unlock my Honor 90 Lite.

While the following comes from my experience attempting to unlock the bootloader on an Honor 90 Lite, it likely also applies to recent Huawei smartphones. Honor shares a great deal of its codebase with Huawei as it was a subsidiary spun off several years ago.

Unfortunately, a visible OEM unlocking toggle under the developer options does not guarantee bootloader unlocking in practice. It is up to the bootloader itself to accept unlocking commands, which manufacturers can patch out or severely restrict.

Prior to 2020, users could fill in a form on the Huawei/Honor website that provided the 16-character code required to unlock the bootloader. Instead of

fastboot flashing unlock

Huawei/Honor bootloaders require

fastboot oem unlock [16-CHAR CODE]

However, the form has since been discontinued, leaving us with

• Exploits for certain models with Kirin and Qualcomm SOCs
• Various paid and proprietary unlocking services
• Brute-force tools for models without known exploits

Since my phone does not have a known exploit and I don't feel like handing over my money to unlocking services with characteristically shady-looking websites, I am left with the latter option.

Brute-force with Luhn algorithm

For some time, the unlock codes were 16-digit numerical strings which were related to the IMEI and satisfied the Luhn algorithm (the same algorithm used as a rudimentary checksum for credit card numbers). This greatly narrows down the number of codes to be tried, such that I exhausted the entire space of 16-digit codes satisfying the Luhn algorithm in 45 minutes using the following Python scripts.

https://github.com/vcka/huawei-honor-unlock-bootloader

The better-known of the two Python scripts, this works mostly as intended, but does not stop once the space of 16-digit codes are exhausted, instead continuing up into 17-digit codes and beyond. However, an unlock code longer than 16 digits has never been attested.

https://github.com/borisgrigorov/bootloader-brute-force

This script did not appear in my initial search and didn't work out of the box on account of expecting a specific error message and stopping execution otherwise. However, it proved a friendlier script than the former with a quick patch and stopped once all 16-digit codes valid under the Luhn algorithm were exhausted.

Huawei/Honor are also known to require 16-digit alphanumeric codes, paritcularly on later models. Adding just the uppercase alphabet would make for a 16-character base-36 code, effectively conveying the information in a 25-digit base-10 code. Searching through this space would take about 800 million times longer. By the time this finishes, I can only hope that humanity has moved on past locked bootloaders. So I ditched any effort of extending the scripts to include alphabetic characters.

Trying both scripts with both IMEIs yielded no working unlock codes, so onto our next options.

Brute-force without Luhn algorithm

But what if it's still a 16-digit code, but it just doesn't add up according to the Luhn algorithm? How much longer would that take? The following C programs claim to be the fastest brute-force unlockers, neither of which use the Luhn algorithm.

https://github.com/Martazza/Huawei-Bootloader-Unlocker

The simpler and more well-known of the two, this simply increments up from 1000000000000000, testing each code along the way. At a rate of 200 guesses per second, my computer and phone would have burned through a good chunk of the world's remaining coal reserves by the time this finishes, even without accounting for alphabetical characters. So this is a no-go.

https://github.com/B83C/huawei_bootloader_unlocker

This optimizes upon the code of the former, incorporating portions of the fastboot source code to suppress unnecessary output. However, it appears to get stuck after guessing only 8 codes. I'll guess why in a bit.

Previously reported successes and time required to unlock

There are reports of the scripts utilizing the Luhn algorithm working on Huawei and Honor devices from around 2018 and 2019. Those attempts required continuous brute-forcing anywhere from several hours to several days. So why was my computer, featuring an i7-9700 also from 2019, able to iterate through all codes accoring to the Luhn algorithm in only 45 minutes? I am not certain, but my theory is that my phone had been silently discarding attempted codes without ever taking the time to evaluate them. The program from B83C is the only one to check the USB connection status and 8 attempts may have been the cutoff for my phone. I didn't bother with further testing. And unless someone manages to guess several million codes per second, at which point USB I/O would become a bottleneck, Martazza's code is of little practical use.

If it had taken longer to search through possible codes, my phone would have died during the process as it did not take in enough charge to sustain itself in fastboot. Fortunately, fastboot is kind enough to wait until the phone is ready again after disconnecting, charging, and reconnecting.

Other things that didn't work

• fastboot reboot fastboot: bootloader seems to double as fastboot for Huawei/Honor devices. fastboot with a white background and plain orange text doesn't seem to take any commands.
• Recovery menu accessed by holding volume up during boot: OTG upgrade does not allow choosing a file. USB upgrade allows the phone to show up under adb devices, but there is no dialog to grant permission.
• mtkclient: tried every button combination I could think of during power-up, but could not enter BROM mode
• Honor Suite: Just a dumbed-down syncing tool that requires admin privileges on Windows, no option anywhere related to bootloader unlocking. Worse yet, it doesn't even detect the phone in fastboot mode, even though the phone suggests opening Honor Suite when in fastboot.

Addendum: for thoroughness, shorting the internal test point to ground and plugging in USB brings the phone into "META MODE", after which the screen stays black. The phone is unresponsive to all commands I could think of and requires a power cycle, after which the RTC resets to the default date and time.

• and adb reboot edl and similar commands: simply does a normal reboot. fastboot edl seems to exist, but is prohibited from running.

Just to be clear: I could not unlock the bootloader of my Honor 90 Lite (CRT-NX1). Gotta love how we have to worry about things like Cellebrite cracking our precious data in a matter of hours while concerted efforts have done little against the accursed little bootloader.

I'm fine immediately after showering, but it's a mini-snowstorm if I go through my hair in the morning having showered the night before. Been that way for years, but far better than it was back when I used "anti-dandruff" shampoos that just made it worse. Hair is short, doesn't feel oily or only slightly. Happens across a variety of shampoos I've tried, though I'll admit I haven't looked beyond the 3-in-1 body wash shampoo combos. Sorry if this is a bit unappealing. Anyone else have a sort of "baseline" amount of dandruff? Or found a solution to this?

UPDATE: Thanks everyone for the helpful replies! It was eye-opening to learn that it's not always just "dandruff". Turns out it was the 3-in-1 soap all along. I finally got myself a proper bottle of shampoo (sulfate free wasn't much more expensive so I went for that) and realized that tight feeling when my hair dried was dry scalp. Super satisfying now that I can run my hand through my hair and eyebrows without getting an avalanche in my face.

When I moved to Coreboot, I also elected to encrypt my /boot partition, which is decrypted by the GRUB payload of Coreboot. I mostly worked on this by trial-and-error, which resulted in the workflow:

1. GRUB unlocks /boot
2. Keyfile in /boot opens /
3. Partition for /boot is listed in /etc/crypttab, with another keyfile to unlock /boot again from within Linux
4. /boot is mounted via /etc/fstab

Steps 3 and 4 always seemed inelegant to me, but after doing systemd-analyze, I realized how much those steps consume when booting (9 sec).

My questions:

• After GRUB unlocks /boot and boots into Linux proper, is there any way to access /boot without unlocking again?
• Are the keys discarded when initramfs hands off to the main Linux system?
• If GRUB supports encrypted /boot, was there a 'correct' way to set it up?
• Or am I left with mounting /boot manually for kernel updates if I want to avoid steps 3 and 4?

My performance is passable and my motivation is mediocre at work. I swear it was my dream job at some point, but I can't help but feel like it's become a slog. It makes my family proud and pays the bills comfortably though.

It's only recently settled in me that laziness isn't the word for it. I've found that I'll work my ass off for something if I'm genuinely and deeply passionate about it. Like the hobbies that cut into my time for sleep.

This has lead me to frequently daydream about "following my passions" and becoming self-employed instead of sticking with the conventional, safe career I previously envisioned. Living a life that brings me more joy. I've fantasized about making and selling gadgets. Perhaps becoming a content creator to promote those gadgets. All the things that bring me joy, but I have little time to do alongside my current job.

But I only have so much saved up and I'm lacking connections with those who have more resources. And in this economy, I don't know when I'll have another chance at my current job if I end up realizing that it was better. Will monetizing my hobbies inevitably ruin them? The grass looks greener on the other side, but will I go back to thinking the same once I'm on the other side? Or have you or someone you know pursued a genuine passion, made it a career, and never looked back?

I'll usually first notice it sometime in the afternoon, a stale, rubbery, maybe sour smell on my hands, especially the fingertips. Like a weak version of the smell that develops after wearing rubber gloves, even though I hadn't touched gloves all day. Quite annoying and makes me want to grit my teeth. Washes off with soap and water 9 times out of 10, but I'm also not bothered enough to do anything about it until I bundle it with a trip to the restrooms. I've never been able to trace down the source and it's been that way through school, work, and since at least 10 years ago in general. Anyone else experience this or know what might cause it?

For casual web browsing, coding, and document preparation, I'm getting just shy of 4 hours on a 6-cell and a little more than 6 hours on a 9-cell. Granted that's with a quad core mod, IPS display, and full Coreboot, so the typical power consumption with a browser window open might be anywhere from 13 to 16 watts.

How's your battery life? Any optimizations I might be missing out on?

Doesn't affect usability, but I am curious if other people see the timestamps (i.e. '6 hours ago') next to posts and comments in another language before the page fully loads in.

In my case, the timestamps show up in Chinese (or Japanese Kanji?) and are replaced with English once the page fully loads. Am using Librewolf, have CJK fonts installed, and system is set to English, if that is relevant.

Follow-up to my earlier write-up on Corebooting my i7-3612QE X230: https://lemmy.ml/post/23117122

---

Since I initially flashed the top 4MB BIOS chip with Coreboot via 1vyrain, the bottom 8MB remained intact with the Intel ME. Its contents are independent, so no need to worry about updating the 4MB BIOS for this procedure if it's already Corebooted.

I used an unmodified black CH341A with the included generic black clip. Pins 1-4 are on the side with the lever, align red wire of the clip with the indent or dot (pin 1) of the bottom 8MB chip.

While I purchased the CH341A with a 1.8 V converter, the chip was not detected with the converter in place, so I resolved to take a risk and do without it. Although the CH341A output reads 5 V on a multimeter, that's supposed to be the open-circuit voltage, which falls to around 3.3 V with any load, which the X230 chips should tolerate very well for the brief flashing operation. Please keep in mind that there's still a risk, especially if you are an owner of such a quad-core board.

Put the chip in the test clip and then plug in the CH341A into a system with flashrom and the iomem=relaxed kernel parameter. Save the contents of the chip:

flashrom -p ch341a_spi -r bottom.bin

It may detect multiple compatible chips. I couldn't really read the engraving on the chip itself, so I picked a random one. The particular choice shouldn't matter now, but might later. In this case,

flashrom -p ch341a_spi -r bottom.bin -c <YOUR CHIP>

Then verify that the dump matches the chip contents:

flashrom -p ch341a_spi -v bottom.bin -c <YOUR CHIP>

If anything fails, unplug the CH341A, redo the test clip, and plug in again.

Grab a copy of me_cleaner and run bottom.bin through it. It'll know what to do with the raw dump, no need to prep or otherwise bless the file:

python me_cleaner.py -S -O bottom_clean.bin bottom.bin

-S: In addition to stripping down the Intel ME, also set the AltMEDisable/HAP bit just in case

-O bottom_clean.bin: output result to bottom_clean.bin

Now to flash it the clean file back to the chip:

flashrom -p ch341a_spi -w bottom_clean.bin -c <YOUR CHIP>

This is where the specific selection of compatible chip does matter. On my first run, it failed to erase before writing the chip. Fortunately, it's mostly a matter of trial-and-error if you really can't read the chip markings and the other compatible model worked for me.

I can confirm that everything works as expected after the procedure, even the dreaded suspend-then-hibernate and resume. No noticeable changes in boot time, performance, or battery life.