this post was submitted on 11 Oct 2025
24 points (100.0% liked)

technology

24272 readers
255 users here now

On the road to fully automated luxury gay space communism.

Spreading Linux propaganda since 2020

Rules:

founded 5 years ago
MODERATORS
context@hexbear.net
SexUnderSocialism@hexbear.net
gaycomputeruser@hexbear.net
Wakmrow@hexbear.net
SwitchyandWitchy@hexbear.net
24
Breathing life into some disposed of ChromeBooks (hexbear.net)
submitted 4 months ago by invalidusernamelol@hexbear.net to c/technology@hexbear.net
14 comments fedilink hide all child comments
 

So I'm helping a local tech non-profit refurbish some old Chromebooks for distribution to halfway houses and immigrants that need computer access for legal stuff. The current need is basically a rock solid platform for getting to websites, reading email, and editing mostly shared Google docs.

Issue is that the hardware is no longer supported by Google.

We've gone ahead and got Coreboot flashed on all 40 devices and have settled on using Fedora-Onyx (Atomic distro with a Budgie UI).

We need to install some flatpaks on each machine and set up a base configuration. Easy enough with rpm-ostree and some manual configuration, but I was wondering if anyone here has had more experience with managing the atomic distros.

Basically I want to have it so the volunteers just need to plug in a USB installer stick and get a fully setup instance. Is there an easy way to take a tree and transfer it to another machine that isn't using something like clonezilla? I'm assuming we could just maintain an image and rebase to thatafter installing, but I'm not fully aware of the easiest way to accomplish that.

all 15 comments
sorted by: hot top controversial new old
[–] hellinkilla@hexbear.net 7 points 4 months ago (1 children)

I don't know how to do that. If you don't get any good leads I suggest re-asking it with the question up front, which if I understand it, is something like "What's the easiest way to install the exact same custom Fedora system on multiple identical devices?"

The fact they are chromebooks or what they are for is probably irrelevant? The only thing I would really wonder about is if you are planning to encrypt them, which might not be a bad idea if the intended purpose is legal situations of marginalized people. That might make the nature of the device more relevant.

I did a quick websearch, and found they have something called Kickstart, would that help you? Otherwise I think what you are looking for could also be described as backing up and restoring the system to another machine. I assume fedora recommends or ships with some kind of system backup software; what about using that?

I also have in my bookmarks (but have never used) mkosi "A fancy wrapper around dnf --installroot, apt, pacman and zypper that generates customized disk images with a number of bells and whistles."

I have run linux on a few chromebooks, it is a great pairing if all the hardware is supported. Storage is an issue. You have to be very, very disciplined to keep your system tight. I don't know how fedora/atomic copes with upgrades but if it keeps a bunch of shit cached/backed-up after completion as other distros do, you run into problems pretty quick with your storage being 100% full which can be difficult to diagnose and get out of if you don't know your way around. And if you are going to have swap, which is handy and expected by many users to be able to close the lid and retain the state without power, you have even less storage to work with.

As long as you have realistic expectations about not being able to have a million firefox windows open at once, chromebooks are great and should serve you well.

[–] invalidusernamelol@hexbear.net 4 points 4 months ago (1 children)

The reason for using atomic is so updates are automatic, and a device can be wiped by nuking /var/ which is essentially exactly the same as factory resetting a Chromebook.

I did look into Kickstart, I might end up using it. Seems more designed for automating the installer process, and not post install system config. I'm probably gonna do some more research into saving and exporting ostree layers so I can manage the package layers and just manually copy over the /var/ from an already configured system.

End of the day there's only so much you can do with 16GB of emmc storage, and because most other distros we tried on these machines were no longer maintained or incredibly unstable. The layer cache can be limited and old versions can be pruned. Since these are meant to be incredibly minimal, the base system is only ~2GB after install and config. Which fits in the 2GB of Ram. Definitely not winning any speed races, but for 3-4 tabs and minor workloads it's usable.

I'll have to investigate encryption aspect, I think easily nukable might be enough. Especially if there's a performance cost to decrypting the drive on startup. Especially since most of the users of these devices are gonna be using G-Drive for file storage anyways.

[–] hellinkilla@hexbear.net 3 points 4 months ago (1 children)

My understanding is that it is difficult/impossible to properly erase solid state memory due to how the devices work. Better descriptions than I could manage:

Even to the extent you can it's very slow. Certainly slower than the 5s lost to decryption on boot.

More relevant barriers would be the added complexity of initial set up, and the friction of having to know and enter an extra password on boot.

though work is to be done in the cloud, obviously there has to be some local cache. Even on an unencrypted device that might be non trivial to access (I don't know how). An attacker would have to be specifically motivated and knowledgeable. On the other hand, the data could be very very sensitive, desirable, and not available by easier means. So if there was a raid search arrests, if devices were stolen sold or given away, the information could end up somewhere bad. It could be the government or it could be someone's ex husband.

I think it's totally a question of risk model. Not one answer for all situations.

I think it's worthwhile, if it makes sense with your situation, to at least nuke users files. people will always accidentally or purposefully download stuff to their computers, and a much more realistic threat than a forensic deconstruction is that the next person who hops on the device sees someone else's birthday pics, browser history, bank statements or whatever. I wonder if there might even be some tools or scripts available to help run a public computer like that; shouldn't have to make from scratch.

[–] invalidusernamelol@hexbear.net 3 points 4 months ago (1 children)

These will be going to single users as far as I know. They're priced to the org at ~$30 and that money comes from their grant.

These are some of the lowest end Chromebooks I've worked with tbh. The emmc is so incredibly slow that the network speeds are bottlenecked by it lol. The A B updates that ostree does take around 15 minutes to build and use ~80% of the CPU in the background (luckily that's only done once a day at midnight or if they specifically request updates).

LUKS encryption would be easy to enable, but someone would inevitably forget their password and we'd have to break the news that the resume they were working on is lost forever. I'll probably include instructions on how to encrypt specific folders so they can have secure locations that they set up.

If we set up LUKS with a shop password and share it, that also just kinda defeats the purpose. Now they're all using the same password. Could use the device code as a salt, but that's still easy to guess and hard to remember.

Running an rm -rf on the var partition should be moderately quick, and since it's a btrfs filesystem, we could also just totally overwrite the logical volume and reassign it. On non spinning disk storage, overwriting the block headers is more than enough to scuttle access to the data.

[–] hellinkilla@hexbear.net 4 points 4 months ago (1 children)

Yeah that totally makes sense. I've had a hell of a time trying to get encryption working properly and smoothly. In theory it should be OK but once you introduce any kind of complexity there are problems. One complexity being using really shitty hardware, which I'm well acquainted with. And it probably isn't a good idea to implement something that has a lot of new-to-you techniques because you do not want to realize there is a problem that needs to be fixed on every machine after a month.

BTW you should count on the devices failing in mysterious and unrepairable ways. Eventually they all fail and you can't do much about it. Sometimes slowly and sometimes suddenly stop out of nowhere.

I was thinking about the shared password issue and I think it still protects against stuff being found if stolen or lost. I don't think you'd want individual decryption passwords. Impossible to manage.

I wonder if your users will want to use thumb drives or other external storage. On the one hand it would be good to encourage using gnome disks or something to encrypt them, but that is terribly incompatible outside linux. So if you make it difficult to store stuff, people will end up putting all their stuff on a FAT32 doohicky that floats around in their purse or pocket, where it could find its way virtually anywhere. So I think moderation is very sensible to avoid incentivizing workarounds that are way worse.

[–] invalidusernamelol@hexbear.net 2 points 4 months ago (1 children)

Totally agree with you there. The atomic stuff is new to me as well, but after seeing the weird compatibility and stability issues that these things had with a regular install, I figured it was worth the plunge to have the A/B update system. Also means installing a bunch of stuff is harder for the end user unless they know the 3 commands you need to bypass the ostree lol.

I wish people would just natural have a better time understanding technology, but reality is that 90% of the people we distribute computers to barely know how to use a keyboard and many don't speak English. These machines are single purpose devices, and any additional security we add will just make them toss it in the trash.

We do have education sessions where we teach people how to use a browser, how to open Gmail, how to identify a scam, etc. I've been wanting to expand those classes to have some basic Intro to Linux, intro to Python, intro to Bash, etc. type classes that teach people the bare minimum so they can start learning. But that's only gonna work with the kids. Any older person that gets one of these devices needs to have it work as frictionless as possible with a minimal amount of interaction.

[–] hellinkilla@hexbear.net 2 points 4 months ago

I wonder of it would be worthwhile to have a few machines designated by interface language to support non English users. The localization takes up massive space if you get all of it. But maybe like a few Spanish-enabled machines or whatever is most relevant.

I like to share my computer hobby with people too but its a tough sell. it requires a massive investment of time and attention to get comfortable with the basics. Out of reach for most adults. I feel like its a victory if I just get people to look at what's on the screen, like peruse the menus and see what the system is offering to you. Most just click the icon they know they need ignore the rest. I think anything that encourages simple exploration of the available tools is empowering. Once you see what the computer can already do, then you start to think about what it could do.

[–] FumpyAer@hexbear.net 4 points 4 months ago (2 children)

You could use clonezilla (GUI) or dd (terminal) to create a disk image of an installed system with customizations and then flash it to the laptops. But I don't know if that will necessarily take fewer steps or require less technical know-how than simply booting from the live USB and installing normally.

Maybe it would be worth it if you are installing tons of stuff on each laptop.

[–] FumpyAer@hexbear.net 4 points 4 months ago* (last edited 4 months ago) (2 children)

That Kickstart thing hellinkilla posted seems like the most sensible option. If you read that page, it says that there is a kickstart config file that is auto generated during the install process. And then afterwards, you can add a list of packages to install inside that file.

[–] invalidusernamelol@hexbear.net 3 points 4 months ago

Already messed with kickstart, it's super useful to automate anything you can setup in the installer. Packages are a bit more difficult since you can only install from their base package list as far as I can tell. Plus using atomic means I need to use a flatpak which is installed in userland after install.

Thanks everyone for all the ideas, mkosi seems like a really need utility that I'll probably end up using.

[–] invalidusernamelol@hexbear.net 3 points 4 months ago

Probably gonna end up just trying to simplify the installation process, and maybe just have an install script that removes the Firefox layers, then installs the required stuff from flathub. Can also overwrite the default configs for browsers and such with a setup script that pulls them from a repo.

[–] stupid_asshole69@hexbear.net 2 points 4 months ago (1 children)

Atomic isn’t the direction I’d go with it, you’re likely better off with a dd script.

Some of your emmc speed problems will go away after doing badblocks -wsv -b [your block size as reported by smartctl] or spinrite lvl3+ if you’re able. The reason is that flash sucks and gets worse over time until it’s rewritten but everyone designed the controllers to be write averse so now they fiddlefuck around trying to read data that would be rewritten in idle time by a sane controller/os.

Is your operational model “put all the old hardware back out into the world and then go away” or more like “provide minimal support to these devices once they’re issued”?

[–] invalidusernamelol@hexbear.net 1 points 4 months ago* (last edited 4 months ago) (1 children)

Providing minimal support is a huge aspect. It's a small shop and large orders like this aren't uncommon. I'll definitely look into optimizing the emmc, as that's a huge bottleneck. The primary goal is always to eek out as much life from devices that were slated to be landfilled as possible and provide minimal working solutions for free or as close to free as possible.

These Chromebooks are veritable e-waste and making it so we can get some last mile usage out of them while having a system that's moderately fault tolerant (btrfs is good for the unreliability of the emmc) is key. Plus the AB updates mirror normal Chromebook functionality.

The atomic style with flatpak also makes it really hard for an inexperienced end user to fully bork their system as the base image and root is read only. Having all the user files in a separate volume also means it's trivial to migrate them to a new machine or wipe an old one. This is essentially an experiment at this point, but we've had a ton of very positive feedback from people about Linux. All the elderly people find it easier to use since they aren't constantly being pushed notifications and spyware. Plus the atomic updates mean they don't have to worry about manually running apt/dnf upgrade to get updates and the whole process is just handled automatically in the background.

[–] stupid_asshole69@hexbear.net 2 points 4 months ago

Another way to completely rewrite the emmc, which is often the solution to slow flash, is dd if=/dev/urandom of=/dev/[your device id].

The flash cell loses charge over time and takes more operations to read correctly so you “see” slower reads and writes. It can happen even when reading newly written information because the controller isnt just reading each bit, but whole blocks. So if the controller decided to shove your new 200 byte file in the same 2048 byte block as some old information whose pointer got dropped then it’s still gonna be slow to access that new file because the integrity mechanisms are designed around the mediums physical block size. Rewriting all of it at once fixes the problem.

It’s often worth losing one of your minimum ten thousand write cycles to get normal predictable io performance back. Also going over your rated write cycles just means the flash will lose data integrity over time faster when powered off. I have a scratch device on my server made from many old ssds that is completely fine despite coming up on a million plus write cycles because I’m not relying on it to endure being turned off for a month.

It may be worthwhile to consider working out how to do a swap when someone brings you a non working unit. Then you can hand over a new one, make sure they’re able to use it and have their files or access to their passwords (bitwarden?) or whatever then handle the returned unit on your own time.