Coreboot on MacBook Air: A Possibility to Remember
by Pitfall
My MacBook Air is one of the models capable of running Coreboot, thanks to a software-based internal flashing method. This process exploits a security oversight in Apple's stock firmware that leaves the Flash Descriptor (FD) and Management Engine (ME) regions writable after a cold boot.
The general procedure involves two main stages[citation:2]:
Stage 1: A small, temporary Coreboot image is flashed onto the SPI chip by repartitioning the memory, shrinking the Intel ME firmware, and moving the reset vector.
Stage 2: After a cold boot, the temporary Coreboot runs without firmware protections, allowing the full ROM to be flashed.
A detailed, step-by-step guide for this advanced procedure is available on ch1p.io.
Important Note: This is a complex and risky process. The original developer of an automated script for this method (mmga) has archived the project and strongly advises against its use, recommending a manual, well-researched approach instead.
Automating Snapshots with timeshift-autosnap-apt
by Pitfall
To enhance my BTRFS snapshot strategy, I've implemented timeshift-autosnap-apt which automatically creates snapshots before APT operations.
Installation Process
Installed it from source because it's not official, I did an enhancement request on the mint repo.
git clone https://github.com/wmutschl/timeshift-autosnap-apt.git /home/$USER/Applications/timeshift-autosnap-apt
cd /home/$USER/Applications/timeshift-autosnap-apt
sudo make install
How It Works
Automatically creates Timeshift snapshots before any APT operation (install, upgrade, remove)
Integrates seamlessly with existing APT commands - no changes to your workflow needed
Works in conjunction with your existing grub-btrfs setup for bootable snapshots
Benefits
Exactly when it's most important, a snapshot is made
Automatic recovery points without manual intervention
Perfect complement to scheduled Timeshift snapshots
If an update breaks something, simply reboot into the pre-update snapshot
This tool combined with your existing BTRFS and grub-btrfs setup creates a robust, self-healing system similar to the one implemented in OpenSUSE Tumbleweed, made with zypper and snapper.
Enable Booting from Snapshots in Linux Mint with BTRFS
by Pitfall
One of the most powerful features of BTRFS is the ability to boot directly from snapshots, providing an excellent disaster recovery solution. After setting up BTRFS with proper subvolume structure, here's how to enable snapshot booting in Linux Mint.
Installing grub-btrfs
The grub-btrfs utility automatically detects BTRFS snapshots and adds them to your GRUB menu:
git clone https://github.com/Antynea/grub-btrfs.git
cd grub-btrfs/
sudo make install
Configuring the Service
Configure the grub-btrfs daemon to work with Timeshift snapshots:
Finally, update your GRUB configuration to include the snapshots:
sudo grub-mkconfig -o /boot/grub/grub.cfg
How It Works
The grub-btrfsd service runs in the background, monitoring for new snapshots
Each time a snapshot is created (manually or via Timeshift schedules), it's automatically added to the GRUB menu
On reboot, you'll see additional boot entries for each available snapshot
Booting from a snapshot provides a perfect recovery option if system updates or changes cause issues
Important Notes
Ensure your BTRFS structure follows the recommended layout with separate subvolumes
Timeshift snapshots should be stored in the @snapshots subvolume at the BTRFS filesystem root
Regular GRUB updates are required to include newly created snapshots in the boot menu
This setup transforms your Linux Mint installation into a resilient system where any problematic change can be instantly reverted by simply rebooting into a previous snapshot.
Debian on BTRFS
by Pitfall
Linux Mint is awesome, nontheless some adjustments are needed. I restored my system to integrate btrfs and automatic snapshot. Just remember some pitfalls:
Automatic partitioning is going to use ext4, so work with gparted to prepare in advance all the partitions.
@ and @home subvolumes are generated automatically, then at first boot you'll need to manually create at least a subvolume for /var/log and one for snapshots. If using Timeshift, then snapshots will go in /timeshift-btrfs mandatory. Beware to not create subvolumes inside the @ subvolume. To create them at top level, first mount @ on /mnt with sudo mount -t btrfs -o subvolid=5 /dev/sda3 /mnt then sudo btrfs subvolume create /mnt/@snapshots. Modify /etc/fstab accordingly UUID=xxx-yyy-zzz /timeshift-btrfs btrfs defaults,subvol=@snapshots 0 0. Do the same with @log.
Eventually other subvolume could be mounted for other well known directories, like /tmp or /opt.
Set Timeshift and use a backup utility for /home folder. Mint has one preinstalled.
My MacBook Air Wireless driver
by Pitfall
My MacBook Air Mid 2011 has a Broadcom BCM4322 chip, supported by broadcom-wl driver.
This driver isn't mantained anymore, so remember to manually download and install it by some mantained repo.
Just search for bcm4322 tumbleweed next time you wipe your system.
Maybe this site should be generated by a SSG
by Pitfall
Writing a devlog by hand in HTML is of course a lot of fun, but not very scalable,
and that's gonna be an issue sooner than later.
Granted I'll never be able to enjoy using a generator made by someone other than me,
what are the steps I should take to fake my commitment in doing this?
Start with something that assemble some html pages.
Content can be Posts or Pages.
The blog page has like 10 articles and truncated, titles are links.
RSS Feed.
Option to watch for changes and serve.
Include css, js and static files like images.
while preparing for this, this site should be more standard. Like every post is an article.
About containerization
by Pitfall
Of course I cannot keep commit-push every time I want to see an update on my blog.
Then I'll run a container, granted I do not wish to run a server on my personal computer.
The choice is for Podman on OpenSuse and container on macOS.
On macOS, start the container system with container system start.
Let's try to do that with similar command, I'll just swap podman with container in the Terminal:
container|podman run --rm \
-v "$PWD":/usr/local/apache2/htdocs/ \
httpd:latest
then visit the ip address in the container output. It's working while I write this.
Keep containers running after logout with loginctl enable-linger
if SELinux is enabled, folder and volume labels are the following; :ro is read only, :z is shared among containers, :Z is exclusive for the container using it.
to read a log of what went wrong with your quadlet: /usr/lib/systemd/system-generators/podman-system-generator --user --dryrun
a log of the service running: journalctl --user -xeu caddy.service
in rootless mode, always use systemctl --user <command>
a blog with a grain of salt, and a personal self-reminder.
by Pitfall
This is me, in an epic journey. That started with a learning journey about computer science, and now is more about learning what to do, not how to.
This is a pre tag
and it's block scope.
print("this is a code tag") and it's inlinable.
print("this is a pre+code tag")
Math can be inline like \(2^{2x}=4\), or displayed like: