This is maybe a bit silly, but Perl has a die() function that is really handy for quitting a script with an error message. And I kind of miss it in Bash. So it can be defined with this simple one-liner:
function die { echo $1 ; exit 1 ; }
And then it can be used with something like:
unzip thefile.zip || die "Unzip returned with error status"
The Perl feeling, in Bash.
In this post, I suggest manipulating the Message IDs of outgoing mails, so that legit inbound replies to my mails are easily detected as non-spam. I also show how to do this with Thunderbird (Linux version 91.10.0, but it works with practically all versions, I believe).
Each email should have a Message-ID header, which uniquely identifies this message. The value of this header should consist of a random string, followed by an ‘@’ and a string that represents the domain name (referred to as FQDN, Fully Qualified Domain Name). This is often the full domain name of the “From” header (e.g. gmail.com).
For example, an email generated by Gmail’s web client had Message-ID: <CAD8P7-R2OuJvGiuQ-0RQqgSSmDguwv1VdjHgQND4jMJxPc628w@mail.gmail.com>. A similar result (same FQDN) was obtained when sending from the phone. However, when using Thunderbird to send an email, only “gmail.com” was set as the FQDN.
Like anything related to email, there are a lot of actors, and each has its own quirks. For example, rspamd adds the spam score by 0.5, with the MID_RHS_NOT_FQDN rule, if the Message ID isn’t an FQDN. I’m not sure to which extent it checks that the FQDN matches the email’s From, but even if it does, it can’t be that picky, given the example I showed above in relation to gmail.com.
It’s quite rare that people care about this header. I’ve seen somewhere that someone sending mails from a work computer didn’t like that the name of the internal domain leaking.
All in all, it’s probably a good idea to make sure that the Message-ID header looks legit. Putting the domain from the From header seems to be a good idea to keep spam filters happy.
In an reply, the In-Reply-To header gets the value of the Message ID of the message replied to. So if a spam filter can identify that that the email is genuinely a reply to something I sent, it’s definitely not spam. It’s also a good idea to scan the References header too, in order to cover more elaborate scenarios when there are several people corresponding.
The rigorous way to implement this spam filtering feature is storing the Message IDs of all sent mails in some small database, and check for a match with the content of In-Reply-To of arriving mails. Possible, however daunting.
A much easier way is to change the FQDN part, so that it’s easily identifiable. This is unnecessary if you happen send emails with your own domain, as spam senders are very unlikely to add an In-Reply-To with a matching domain (actually, very few spam messages have an In-Reply-To header at all).
But for email sent through gmail, changing the FQDN to something unique is required to make a distinction.
Will this mess up things? I’m not sure any software tries to fully match the FQDN with the sender, but I suppose it’s safe to add a subdomain to the correct domain. I mean, if both “mail.gmail.com” and “gmail.com” are commonly out there, why shouldn’t “secretsauce.gmail.com” seem likewise legit to any spam filter that checks the message?
And by the way, as of August 2024, a DNS query for mail.gmail.com yields no address, neither for A nor MX. In other words, Gmail itself uses an invalid domain in its Message ID, so any other invented subdomain should do as well.
Click the hamburger icon, choose Preferences, and scroll down all the way (on the General tab) and click on Config Editor.
First, we need to find Thunderbird’s internal ID number for the mail account to manipulate.
To get a list of IDs, write “useremail” in the search text box. This lists entries like mail.identity.id1.useremail and their values. This listing allows making the connection between e.g. “id1″ and the email address related to it.
For example, to change the FQDN of the mail account corresponding to “id3″, add a string property (using the Config Editor). The key of this property is “mail.identity.id3.FQDN” and the value is something like “secretsauce.gmail.com”.
There is no need to restart Thunderbird. The change is in effect on the next mail sent, and it remains in the settings across restarts.
The need for this feature has been questioned, as was discussed here. So if any Thunderbird maintainer reads this, please keep this feature up and running.
Instead of playing around with the Message-ID, it would be possible to add an entry to the References header (or add this header if there is none). The advantage of this way is that this can also be done by the MTA further down the delivery path, and it doesn’t alter anything that is already in place.
And since it’s an added entry, it can also be crafted arbitrarily. For example, it may contain a timestamp (epoch time in hex) and the SHA1 sum of a string that is composed by this timestamp and a secret string. This way, this proof of genuine correspondence is impossible to forge and may expire with time.
I haven’t looked into how to implement this in Thunderbird. Right now I’m good with the Message-ID solution.
Working with Linux kernel’s workqueues, I incremented a kref reference count before queuing a work item, in order to make sure that the data structure that it operated on will still be in memory while it runs. Just before returning, the work item’s function decremented this reference count, and as a result, the data structure’s memory could be freed at that very moment.
The thing was, that this data structure also included the work item’s own struct work_struct. In other words, the work item’s function could potentially free the entry that was pushed into the workqueue on its behalf. Could this possibly be allowed?
The short answer is yes. It’s OK to call kfree() on the memory of the struct work_struct of the currently running work item. No risk for use-after-free (UAF).
It’s also OK to requeue the work item on the same workqueue (or on a different one). All in all, the work item’s struct is just a piece of unused memory as soon as the work item’s function is called.
On the other hand, don’t think about calling destroy_workqueue() on the workqueue on which the running work item is queued: destroy_workqueue() waits for all work items to finish before destroying the queue, which will never happen if the request to destroy the queue came from one of its own work items.
I didn’t find any documentation on this topic, but there are a couple of comments in the source code, namely in the process_one_work() function in kernel/workqueue.c: First, this one by Tejun Heo from June 2010:
/* * It is permissible to free the struct work_struct from * inside the function that is called from it, this we need to * take into account for lockdep too. To avoid bogus "held * lock freed" warnings as well as problems when looking into * work->lockdep_map, make a copy and use that here. */
And this comes after calling the work item’s function, worker->current_func(work). Written by Arjan van de Ven in August 2010.
/*
* While we must be careful to not use "work" after this, the trace
* point will only record its address.
*/
trace_workqueue_execute_end(work, worker->current_func);
The point of this comment is that the value of @work will be used by the call to trace_workqueue_execute_end(), but it won’t be used as a pointer. This emphasizes the commitment of not touching what @work points at, i.e. the memory segment may have been freed.
process_one_work(), which is the only function that calls the work item’s function, is clearly written in a way that ignores the work item’s struct after calling the work item’s function.
The first thing is that it copies the address of the work function into the worker struct:
worker->current_func = work->func;
It then removes the work item from the workqueue:
list_del_init(&work->entry);
And later on, it calls the function, using the copy of the pointer (even though it could also have used the original at this point).
worker->current_func(work);
After this, the @work variable isn’t used anymore as a pointer.
It’s rarely necessary to make an issue of installing and maintaining the GRUB bootloader. However, for reasons explained in a separate post, I wanted to install GRUB 2.12 on an old distribution (Debian 8). So it required some acrobatics. That said, it doesn’t limit the possibility to install new kernels in the future etc. If you’re ready to edit a simple text file, rather than running automatic tools, that is. Which may actually be a good idea anyhow.
Grub has two parts: First, there’s the initial code that is loaded by the BIOS, either from the MBR or from the EFI partition. That’s the plain GRUB executable. This executable goes directly to the ext2/3/4 root partition, and reads from /boot/grub/. That directory contains, among others, the precious grub.cfg file, which GRUB reads in order to decide which modules to load, which menu entries to display and how to act if each is selected.
grub.cfg is created by update-grub, which effectively runs “grub-mkconfig -o /boot/grub/grub.cfg”.
This file is created from /etc/grub.d/ and settings from /etc/default/grub, and based upon the kernel image and initrd files that are found in /boot.
Hence an installation of GRUB consists of two tasks, which are fairly independent:
Note that grub-install populates /boot/grub with a lot of files that are used by the bootloader, so it’s necessary to run this command if /boot is wiped and started from fresh.
What made this extra tricky for me, was that Debian 8 comes with an old GRUB 1 version. Therefore, the option of chroot’ing into the filesystem for the purpose of installing GRUB was eliminated.
So there were two tasks to accomplish: Obtaining a suitable grub.cfg and running grub-install in a way that will do the job.
This is a good time to understand what this grub.cfg file is.
grub.cfg is a script, written with a bash-like syntax. and is based upon an internal command set. This is a plain file in /boot/grub/, owned by root:root and writable by root only, for obvious reasons. But for the purpose of booting, permissions don’t make any difference.
Despite the “DO NOT EDIT THIS FILE” comment at the top of this file, and the suggestion to use grub-mkconfig, it’s perfectly OK to edit it for the purposes of updating the behavior of the boot menu. This is unnecessarily complicated in most cases, even when rescuing a system from a Live ISO system: There’s always the possibility to chroot into the target’s root filesystem and call grub-mkconfig from there. That’s usually all that is necessary to update which kernel image / initrd should be kicked off.
That said, it might also be easier to edit this file manually in order to add menu entries for new kernels, for example. In addition, automatic utilities tend to add a lot of specific details that are unnecessary, and that can fail the boot process, for example if the file system’s UUID changes. So maintaining a clean grub.cfg manually can pay off in the long run.
The most interesting part in this file is the menuentry section. Let’s look at a sample command:
menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-a0c2e12e-5d16-4aac-b11d-15cbec5ae98e' {
recordfail
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root a0c2e12e-5d16-4aac-b11d-15cbec5ae98e
linux /boot/vmlinuz-6.8.0-36-generic root=UUID=a0c2e12e-5d16-4aac-b11d-15cbec5ae98e ro
initrd /boot/initrd.img-6.8.0-36-generic
}
So these are a bunch of commands that run if the related menu entry is chosen. I’ll discuss “menuentry” and “search” below. Note the “insmod” commands, which load ELF executable modules from /boot/grub/i386-pc/. GRUB also supports lsmod, if you want to try it with GRUB’s interactive command interface.
The menuentry command is documented here. Let’s break down the command in this example:
Bottom line: If there are no submenus (in the original file there actually are), this header would have done the job as well:
menuentry 'Ubuntu for the lazy' {
The other interesting part is this row within the menucommand clause:
search --no-floppy --fs-uuid --set=root a0c2e12e-5d16-4aac-b11d-15cbec5ae98e
The search command is documented here. The purpose of this command is to set the $root environment variable, which is what the “–set=root” part means (this is an unnecessary flag, as $root is the target variable anyhow). This tells GRUB in which filesystem to look for the files mentioned in the “linux” and “initrd” commands.
On a system with only one Linux installed, the “search” command is unnecessary: Both $root and $prefix are initialized according to the position of the /boot/grub, so there’s no reason to search for it again.
In this example, the filesystem is defined according to the its UUID , which can be found with this Linux command:
# dumpe2fs /dev/vda2 | grep UUID
It’s better to remove this “search” command if there’s only one /boot directory in the whole system (and it contains the linux kernel files, of course). The advantage is the Linux system can be installed just by pouring all files into an ext4 filesystem (including /boot) and then just run grub-install. Something that won’t work if grub.cfg contains explicit UUIDs. Well, actually, it will work, but with an error message and a prompt to press ENTER: The “search” command fails if the UUID is incorrect, but it wasn’t necessary to begin with, so $root will retain it’s correct value and the system can boot properly anyhow. Given that ENTER is pressed. That hurdle can be annoying on a remote virtual machine.
I added these lines to my grub.cfg file in order to allow future self to try out a new kernel without begin too scared about it:
menuentry 'Unused boot menu entry for future hacks' {
recordfail
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
linux /boot/vmlinuz-6.8.12 root=/dev/vda3 ro
}
This is just an implementation of what I said above about the “menuentry” and “search” commands above. In particular, that the “search” command is unnecessary. This worked well on my machine.
As for the other rows, I suggest mixing and matching with whatever appears in your own grub.cfg file in the same places.
So the question is: How do I get the initial grub.cfg file? Just take one from a random system? Will that be good enough?
Well, no, that may not work: The grub.cfg is formed differently, depending in particular on how the filesystems on the hard disk are laid out. For example, comparing two grub.cfg files, one had this row:
insmod lvm
and the other didn’t. Obviously, one computer utilized LVM and the other didn’t. Also, in relation to setting the $root variable, there were different variations, going from the “search” method shown above to simply this:
set root='hd0,msdos1'
My solution was to install a Ubuntu 24.04 system on the same KVM virtual machine that I intended to install Debian 8 on later. After the installation, I just copied the grub.cfg and wiped the filesystem. I then installed the required distribution and deleted everything under /boot. Instead, I added this grub.cfg into /boot/grub/ and edited it manually to load the correct kernel.
As I kept the structure of the harddisk and the hardware environment remained unchanged, this worked perfectly fine.
Truth to be told, I probably didn’t need to use grub-install, since the MBR was already set up with GRUB thanks to the installation I had already carried out for Ubuntu 24.04. Also, I could have copied all other files in /boot/grub from this installation before wiping it. But I didn’t, and it’s a good thing I didn’t, because this way I found out how to do it from a Live ISO. And this might be important for rescue purposes, in the unlikely and very unfortunate event that it’s necessary.
Luckily, grub-install has an undocumented option, –root-directory, which gets the job done.
# grub-install --root-directory=/mnt/new/ /dev/vda Installing for i386-pc platform. Installation finished. No error reported.
Note that using –boot-directory isn’t good enough, even if it’s mounted. Only –root-directory makes GRUB detect the correct root directory as the place to fetch the information from. With –boot-directory, the system boots with no menus.
If you insist on running update-grub, be sure to edit /etc/default/grub and set it this way:
GRUB_TIMEOUT=3 GRUB_RECORDFAIL_TIMEOUT=3
The previous value for GRUB_TIMEOUT is 0, which is supposed to mean to skip the menu. If GRUB deems the boot media not to be writable, it considers every previous boot as a failure (because it can’t know if it was successful or not), and sets the timeout to 30 seconds. 3 seconds are enough, thanks.
And then run update-grub.
# update-grub Sourcing file `/etc/default/grub' Generating grub configuration file ... Found linux image: /boot/vmlinuz-6.8.0-36-generic Warning: os-prober will not be executed to detect other bootable partitions. Systems on them will not be added to the GRUB boot configuration. Check GRUB_DISABLE_OS_PROBER documentation entry. Adding boot menu entry for UEFI Firmware Settings ... done
Alternatively, edit grub.cfg and fix it directly.
This is really not related to anything else above, but since I made an attempt to install Debian 8′s GRUB on the hard disk at some point, this is what happened:
# apt install grub
# grub --version
grub (GNU GRUB 0.97)
# update-grub
Searching for GRUB installation directory ... found: /boot/grub
Probing devices to guess BIOS drives. This may take a long time.
Searching for default file ... Generating /boot/grub/default file and setting the default boot entry to 0
Searching for GRUB installation directory ... found: /boot/grub
Testing for an existing GRUB menu.lst file ...
Generating /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /boot/vmlinuz
Found kernel: /boot/vmlinuz-6.8.0-31-generic
Updating /boot/grub/menu.lst ... done
# grub-install /dev/vda
Searching for GRUB installation directory ... found: /boot/grub
The file /boot/grub/stage1 not read correctly.
The error message about /boot/grub/stage1 appears to be horribly misleading. According to this and this, among others, the problem was that the ext4 file system was created with 256 as the inode size, and GRUB 1 doesn’t support that. Which makes sense, as the installation was done on behalf of Ubuntu 24.04 and not a museum distribution.
The solution is apparently to wipe the filesystem correctly:
# mkfs.ext4 -I 128 /dev/vda3
Actually, I don’t know if this was really the problem, because I gave up this old GRUB version quite soon.
My Debian 8-based web server had been running for several years as an OpenVZ container, when the web host told me that containers are phased out, and it’s time to move on to a KVM.
This is an opportunity to upgrade to a newer distribution, most of you would say, but if a machine works flawlessly for a long period of time, I’m very reluctant to change anything. Don’t touch a stable system. It just happened to have an uptime of 426 days, and the last time this server caused me trouble was way before that.
So the question is if it’s possible to convert a container into a KVM machine, just by copying the filesystem. After all, what’s the difference if /sbin/init (systemd) is kicked off as a plain process inside a container or if the kernel does the same thing?
The answer is yes-ish, this manipulation is possible, but it requires some adjustments.
These are my notes and action items while I found my way to get it done. Everything below is very specific to my own slightly bizarre case, and at times I ended up carrying out tasks in a different order than as listed here. But this can be useful for understanding what’s ahead.
By the way, the wisest thing I did throughout this process, was to go through the whole process on a KVM machine that I built on my own local computer. This virtual machine functioned as a mockup of the server to be installed. Not only did it make the trial and error much easier, but it also allowed me to test all kind of things after the real server was up and running without messing the real machine.
To make things even more interesting, I also wanted to push the next time I’ll be required to mess with the virtual machine as long as possible into the future. Put differently, I wanted to hide the fact that the machine runs on ancient software. There should not be a request to upgrade in the foreseeable future because the old system isn’t compatible with some future version of KVM.
So to the KVM hypervisor, my machine should feel like an Ubuntu 24.04, which was the latest server distribution offered at the time I did this trick. Which brings the question: What does the hypervisor see?
The KVM guest interfaces with its hypervisor in three ways:
Or so I hope. Maybe there’s some aspect I’m not aware of. It’s not like I’m such an expert in virtualization.
So the idea was that both GRUB and the kernel should be the same as in Ubuntu 24.04. This way, any KVM setting that works with this distribution will work with my machine. The Naphthalene smell from the user-space software underneath will not reach the hypervisor.
This presumption can turn out to be wrong, and the third item in the list above demonstrates that: The guest machine gets its IP address from the hypervisor through a DHCP request issued by systemd-networkd, which is part of systemd version 215. So the bluff is exposed. Will there be some kind of incompatibility between the old systemd’s DHCP client and some future hypervisor’s response?
Regarding this specific issue, I doubt there will be a problem, as DHCP is such a simple and well-established protocol. And even if that functionality broke, the IP address is fixed anyhow, so the virtual NIC can be configured statically.
But who knows, maybe there is some kind of interaction with systemd that I’m not aware of? Future will tell.
So it boils down to faking GRUB and using a recent kernel.
Debian 8 comes with GRUB version 0.97. Could we call that GRUB 1? I can already imagine the answer to my support ticket saying “please upgrade your system, as our KVM hypervisor doesn’t support old versions of GRUB”.
So I need a new one.
Unfortunately, the common way to install GRUB is with a couple of hocus-pocus tools that do the work well in the usual scenario.
As it turns out, there are two parts that need to be installed: The first part consists of the GRUB binary on the boot partition (GRUB partition or EFI, pick your choice), plus several files (modules and other) in /boot/grub/. The second part is a script file, grub.cfg, which is a textual file that can be edited manually.
To make a long story short, I installed the distribution on a virtual machine with the same layout, and made a copy of the grub.cfg file that was created. I then edited this file directly to fit into the new machine. As for installing GRUB binary, I did this from a Live ISO Ubuntu 24.04, so it’s genuine and legit.
For the full and explained story, I’ve written a separate post.
This way or another, a kernel and its modules must be added to the filesystem in order to convert it from a container to a KVM machine. This is the essential difference: With a container, one kernel runs all containers and gives them the illusion that they’re the only one. With KVM, the boot starts from the very beginning.
If there was something I didn’t worry about, it was the concept of running an ancient distribution with a very recent kernel. I have a lot of experience with compiling the hot-hot-latest-out kernel and run it with steam engine distributions, and very rarely have I seen any issue with that. The Linux kernel is backward compatible in a remarkable way.
My original idea was to grab the kernel image and the modules from a running installation of Ubuntu 24.04. However, the module format of this distro is incompatible with old Debian 8 (ZST compression seems to have been the crux), and as a result, no modules were loaded.
So I took config-6.8.0-36-generic from Ubuntu 24.04 and used it as the starting point for the .config file used for compiling the vanilla stable kernel with version v6.8.12.
And then there were a few modifications to .config:
The compilation took 32 minutes on a machine with 12 cores (6 hyperthreaded). By far, the longest and most difficult kernel compilation I can remember for a long time.
Based upon my own post, I created the Debian packages for the whole thing, using the bindeb-pkg make target.
That took additional 20 minutes, running on all cores. I used two of these packages in the installation of the KVM machine, as shown in the cookbook below.
So the deal with my web host was like this: They started a KVM machine (with a different IP address, of course). I prepared this KVM machine, and when that was ready, I sent a support ticket asking for swapping the IP addresses. This way, the KVM machine became the new server, and the old container machine went to the junkyard.
As this machine involved a mail server and web sites with user content (comments to my blog, for example), I decided to stop the active server, copy “all data”, and restart the server only after the IP swap. In other words, the net result should be as if the same server had been shut down for an hour, and then restarted. No discontinuities.
As it turned out, everything that is related to the web server and email, including the logs of everything, are in /var/ and /home/. So I could therefore copy all files from the old server to the new one for the sake of setting it up, and verify that everything is smooth as a first stage.
Then I shut down the services and copied /var/ and /home/. And then came the IP swap.
This simple command is handy for checking which files have changed during the past week. The first finds the directories, and the second the plain files.
# find / -xdev -ctime -7 -type d | sort # find / -xdev -ctime -7 -type f | sort
The purpose of the -xdev flag is to remain on one filesystem. Otherwise, a lot of files from /proc and such are printed out. If your system has several relevant filesystems, be sure to add them to “/” in this example.
The next few sections below are the cookbook I wrote for myself in order to get it done without messing around (and hence mess up).
In hindsight, I can say that except for dealing with GRUB and the kernel, most of the hassle had to with the NIC: Its name changed from venet0 to eth0, and it got its address through DHCP relatively late in the boot process. And that required some adaptations.
# mkfs.ext4 -I 128 /dev/vda3
# tune2fs -c 0 -i 0 /dev/vda3
# mkdir /mnt/new # mount /dev/vda3 /mnt/new
# tar --one-file-system -cz / | nc -q 0 185.250.251.160 1234 > /dev/null
and the other side goes (run this before the command above):
# nc -l 1234 < /dev/null | time tar -C /mnt/new/ -xzv
This took about 30 minutes. The purpose of the “-q 0″ flag and those /dev/null redirections is merely to make nc quit when the tar finishes.
Or, doing the same from a backup tarball:
$ cat myserver-all-24.07.08-08.22.tar.gz | nc -q 0 -l 1234 > /dev/null
and the other side goes
# nc 10.1.1.3 1234 < /dev/null | time tar -C /mnt/new/ -xzv
# rm -rf /mnt/new/lib/modules/ /mnt/new/boot/
# grub-install --root-directory=/mnt/new /dev/vda
# mount -o bind /dev /mnt/new/dev # mount -o bind /sys /mnt/new/sys # mount -t proc /proc /mnt/new/proc # mount -t tmpfs tmpfs /mnt/new/tmp # mount -t tmpfs tmpfs /mnt/new/run
# chroot /mnt/new/
# systemctl mask modules_dep.service
# dpkg -i linux-image-6.8.12-myserver_6.8.12-myserver-2_amd64.deb
# dpkg -i linux-headers-6.8.12-myserver_6.8.12-myserver-2_amd64.deb
[Match] Name=eth0 [Network] DHCP=yes
The NIC was a given in a container, but now it has to be raised explicitly and the IP address possibly obtained from the hypervisor via DHCP, as I’ve done here.
net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1
# apt install pciutils
blacklist evbug
/dev/vda3 / ext4 defaults 0 1
# systemctl mask proc-sys-fs-binfmt_misc.automount
# apt install dbus
Not only is it the right thing to do on a Linux system, but it also silences this warning:
Cannot add dependency job for unit dbus.socket, ignoring: Unit dbus.socket failed to load: No such file or directory.
# systemctl enable getty@tty1.service
The other tty’s got a login prompt when using Ctrl-Alt-Fn, but not the visible console. So this fixed it. Otherwise, one can be mislead into thinking that the boot process is stuck.
# mkdir /mnt/new # mount /dev/vda3 /mnt/new
# find / -xdev -ctime -7 -type d | sort > recently-changed-dirs.txt # find / -xdev -ctime -7 -type f | sort > recently-changed-files.txt
# mailq
# systemctl disable cron dovecot apache2 bind9 sendmail mysql xinetd
# netstat -n -a | less
# rm -rf /mnt/new/var /mnt/new/home
# nc -l 1234 < /dev/null | time tar -C /mnt/new/ -xzv
and on myserver:
# tar --one-file-system -cz /var /home | nc -q 0 185.250.251.160 1234 > /dev/null
Took 28 minutes.
# systemctl restart netfilter-persistent # iptables -vn -L
# systemctl start cron dovecot apache2 bind9 sendmail mysql xinetd
# systemctl enable cron dovecot apache2 bind9 sendmail mysql xinetd
$ nmap -v -A server $ sudo nmap -v -sU server
I knew very well why I left plenty of time free for after the IP swap. Something will always go wrong after a maneuver like this, and this time was no different. And for some odd reason, it was the bind9 DNS that played two different kinds of pranks.
I noted immediately that the server didn’t answer to DNS queries. As it turned out, there were two apparently independent reasons for it.
The first was that when I re-enabled the bind9 service (after disabling it for the sake of moving), systemctl went for the SYSV scripts instead of its own. So I got:
# systemctl enable bind9 Synchronizing state for bind9.service with sysvinit using update-rc.d... Executing /usr/sbin/update-rc.d bind9 defaults insserv: warning: current start runlevel(s) (empty) of script `bind9' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `bind9' overrides LSB defaults (0 1 6). Executing /usr/sbin/update-rc.d bind9 enable
This could have been harmless and gone unnoticed, had it not been that I’ve added a “-4″ flag to bind9′s command, or else it wouldn’t work. So by running the SYSV scripts, my change in /etc/systemd/system/bind9.service wasn’t in effect.
Solution: Delete all files related to bind9 in /etc/init.d/ and /etc/rc*.d/. Quite aggressive, but did the job.
Having that fixed, it still didn’t work. The problem now was that eth0 was configured through DHCP after the bind9 had begun running. As a result, the DNS didn’t listen to eth0.
I slapped myself for thinking about adding a “sleep” command before launching bind9, and went for the right way to do this. Namely:
$ cat /etc/systemd/system/bind9.service [Unit] Description=BIND Domain Name Server Documentation=man:named(8) After=network-online.target systemd-networkd-wait-online.service Wants=network-online.target systemd-networkd-wait-online.service [Service] ExecStart=/usr/sbin/named -4 -f -u bind ExecReload=/usr/sbin/rndc reload ExecStop=/usr/sbin/rndc stop [Install] WantedBy=multi-user.target
The systemd-networkd-wait-online.service is not there by coincidence. Without it, bind9 was launched before eth0 had received an address. With this, systemd consistently waited for the DHCP to finish, and then launched bind9. As it turned out, this also delayed the start of apache2 and sendmail.
If anything, network-online.target is most likely redundant.
And with this fix, the crucial row appeared in the log:
named[379]: listening on IPv4 interface eth0, 193.29.56.92#53
Another solution could have been to assign an address to eth0 statically. For some odd reason, I prefer to let DHCP do this, even though the firewall will block all traffic anyhow if the IP address changes.
Set Ubuntu 24.04 server amd64 as the CDROM image.
After the machine has booted, send a Ctrl-Alt-F2 to switch to the second console. Don’t go on with the installation wizard, as it will of course wipe the server.
In order to establish an ssh connection:
$ passwd
If you insist on a weak password, remember that you can do that only as root.
$ ssh ubuntu-server@185.250.251.160
Root login is forbidden (by default), so don’t even try.
Note that even though sshd apparently listens only to IPv6 ports, it’s actually accepting IPv4 connection by virtue of IPv4-mapped IPv6 addresses:
# lsof -n -P -i tcp 2>/dev/null COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd 1 root 143u IPv6 5323 0t0 TCP *:22 (LISTEN) systemd-r 911 systemd-resolve 15u IPv4 1766 0t0 TCP 127.0.0.53:53 (LISTEN) systemd-r 911 systemd-resolve 17u IPv4 1768 0t0 TCP 127.0.0.54:53 (LISTEN) sshd 1687 root 3u IPv6 5323 0t0 TCP *:22 (LISTEN) sshd 1847 root 4u IPv6 11147 0t0 TCP 185.250.251.160:22->85.64.140.6:57208 (ESTABLISHED) sshd 1902 ubuntu-server 4u IPv6 11147 0t0 TCP 185.250.251.160:22->85.64.140.6:57208 (ESTABLISHED)One can get the impression that sshd listens only to IPv6. But somehow, it also accepts
So don’t get confused by e.g. netstat and other similar utilities.
I wasn’t sure if I should run an NTP client inside a KVM virtual machine. So these are the notes I took.
On a working KVM machine, timesyncd tells about its presence in the log:
Jul 11 20:52:52 myserver systemd-timesyncd[197]: interval/delta/delay/jitter/drift 2048s/+0.001s/0.007s/0.003s/+0ppm Jul 11 21:27:00 myserver systemd-timesyncd[197]: interval/delta/delay/jitter/drift 2048s/-0.000s/0.007s/0.001s/+0ppm Jul 11 22:01:08 myserver systemd-timesyncd[197]: interval/delta/delay/jitter/drift 2048s/-0.002s/0.007s/0.001s/+0ppm Jul 11 22:35:17 myserver systemd-timesyncd[197]: interval/delta/delay/jitter/drift 2048s/-0.001s/0.007s/0.001s/+0ppm Jul 11 23:09:25 myserver systemd-timesyncd[197]: interval/delta/delay/jitter/drift 2048s/+0.007s/0.007s/0.003s/+0ppm Jul 11 23:43:33 myserver systemd-timesyncd[197]: interval/delta/delay/jitter/drift 2048s/-0.003s/0.007s/0.005s/+0ppm (ignored) Jul 12 00:17:41 myserver systemd-timesyncd[197]: interval/delta/delay/jitter/drift 2048s/-0.006s/0.007s/0.005s/-1ppm Jul 12 00:51:50 myserver systemd-timesyncd[197]: interval/delta/delay/jitter/drift 2048s/+0.001s/0.007s/0.005s/+0ppm Jul 12 01:25:58 myserver systemd-timesyncd[197]: interval/delta/delay/jitter/drift 2048s/+0.002s/0.007s/0.005s/+0ppm Jul 12 02:00:06 myserver systemd-timesyncd[197]: interval/delta/delay/jitter/drift 2048s/+0.002s/0.007s/0.005s/+0ppm Jul 12 02:34:14 myserver systemd-timesyncd[197]: interval/delta/delay/jitter/drift 2048s/-0.001s/0.007s/0.005s/+0ppm Jul 12 03:08:23 myserver systemd-timesyncd[197]: interval/delta/delay/jitter/drift 2048s/-0.000s/0.007s/0.005s/+0ppm Jul 12 03:42:31 myserver systemd-timesyncd[197]: interval/delta/delay/jitter/drift 2048s/-0.001s/0.007s/0.004s/+0ppm Jul 12 04:17:11 myserver systemd-timesyncd[197]: interval/delta/delay/jitter/drift 2048s/-0.000s/0.007s/0.003s/+0ppm
So a resync takes place every 2048 seconds (34 minutes and 8 seconds), like a clockwork. As apparent from the values, there’s no dispute about the time between Debian’s NTP server and the web host’s hypervisor.
Exactly like my previous post from 14 years ago, these are random jots that I took as I set up a QEMU/KVM-based virtual machine on my Linux Mint 19 computer. This time, the purpose was to prepare myself for moving a server from an OpenVZ container to KVM.
Other version details, for the record: libvirt version 4.0.0, QEMU version 2.11.1, Virtual Machine manager 1.5.1.
Install some relevant packages:
# apt install qemu-kvm qemu-utils libvirt-daemon-system libvirt-clients virt-manager virt-viewer ebtables ovmf
This clearly installed a few services: libvirt-bin, libvirtd, libvirt-guest, virtlogd, qemu-kvm, ebtables, and a couple of sockets: virtlockd.socket and virtlogd.socket with their attached services.
My regular username on the computer was added automatically to the “libvirt” group, however that doesn’t take effect until one logs out and and in again. Without belonging to this group, one gets the error message “Unable to connect to libvirt qemu:///system” when attempting to run the Virtual Machine Manager. Or in more detail: “libvirtError: Failed to connect socket to ‘/var/run/libvirt/libvirt-sock’: Permission denied”.
The lazy and temporary solution is to run the Virtual Machine Manager with “sg”. So instead of the usual command for starting the GUI tool (NOT as root):
$ virt-manager &
Use “sg” (or start a session with the “newgroup” command):
$ sg libvirt virt-manager &
This is necessary only until next time you log in to the console. I think. I didn’t get that far. Who logs out?
There’s also a command-line utility, virsh. For example, to list all running machines:
$ sudo virsh list
Or just “sudo virsh” for an interactive shell.
Note that without root permissions, the list is simply empty. This is really misleading.
Start the Virtual Manager. The GUI is good enough for my purposes.
$ sg libvirt virt-manager &
That is, use Linux’ paravirtualization drivers, rather than emulation of hardware.
To set up a machine’s settings, go View > Details.
This is lspci’s response with a default virtual machine:
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 VGA compatible controller: Red Hat, Inc. QXL paravirtual graphic card (rev 04) 00:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 20) 00:04.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 01) 00:05.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03) 00:05.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03) 00:05.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03) 00:05.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03) 00:06.0 Communication controller: Red Hat, Inc Virtio console 00:07.0 Unclassified device [00ff]: Red Hat, Inc Virtio memory balloon
Cute, but all interfaces are emulations of real hardware. In other words, this will run really slowly.
Testing link speed: On the host machine:
$ nc -l 1234 < /dev/null > /dev/null
And on the guest:
$ dd if=/dev/zero bs=128k count=4k | nc -q 0 10.1.1.3 1234 4096+0 records in 4096+0 records out 536870912 bytes (537 MB, 512 MiB) copied, 3.74558 s, 143 MB/s
Quite impressive for hardware emulation, I must admit. But it can get better.
Things to change from the default settings:
Note that it’s possible to use a VNC server instead of “Display spice”.
After making these changes:
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 VGA compatible controller: Red Hat, Inc Virtio GPU (rev 01) 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device 00:04.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 01) 00:05.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03) 00:05.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03) 00:05.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03) 00:05.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03) 00:06.0 Communication controller: Red Hat, Inc Virtio console 00:07.0 Unclassified device [00ff]: Red Hat, Inc Virtio memory balloon 00:08.0 SCSI storage controller: Red Hat, Inc Virtio block device
Try the speed test again?
$ dd if=/dev/zero bs=128k count=4k | nc -q 0 10.1.1.3 1234 4096+0 records in 4096+0 records out 536870912 bytes (537 MB, 512 MiB) copied, 0.426422 s, 1.3 GB/s
Almost ten times faster.
$ sudo su # apt install openssh-server # passwd ubuntu
In the installation of the openssh-server, there’s a question of which configuration files to use. Choose the package maintainer’s version.
This is a super-short post, but I have a feeling it will evolve with time.
Using ssh, pasting text with CTRL-V or the mouse’s middle button sometimes resulted in ~0 and ~1 around the pasted text. Super annoying.
As it turns out, this is called “bracketed paste” and its a way for the terminal application (say, Gnome terminal) to tell the receiver (say, bash) that the text is pasted, and not typed manually.
Why is this helpful? For example, if the text goes to an editor which responds with automatic indentation as a result of a newline, that can have a negative effect. Bracketed paste gives the editor to possibility to accept the text as is, assuming that it’s already correctly indented, since it’s pasted and not typed.
The reason for the ~0 and ~1 problem is probably that the bash version on the ssh’ed computer is really old, and my Gnome terminal is relatively new. So bash doesn’t understand the magic characters, and prints them out as they are.
This problem will probably go away by itself sooner or later.
There are all kinds of “bind” commands, but for some reason, I thought this solution was coolest.
Turning off bracketed paste, which adds ~0 and ~1 around the pasted text:
$ printf "\e[?2004l"
To re-enable bracketed paste:
$ printf "\e[?2004h"
These two commands were taken from this page. The effect of these commands seems to go beyond what one would expect. It seems like they don’t influence just the current terminal session, but I need to figure this out.
So what if you need to divide a \subsubsection{} into even lower subsections? LaTeX classes don’t usually support that, because if you need that feature, your document’s structure is wrong. Or so they say. You should have chopped the document with \part{} or \chapter{} at a higher level, and not cut down the sections into even smaller pieces.
But with technical documentation (say, outlining an API) it can be very handy with something below \subsubsection{}. As it turns out, LaTeX actually supports lower levels, but they aren’t numbered by default. So it goes:
That’s neat, isn’t it? In order to make the two last numbered, add this to the LaTeX document:
\setcounter{secnumdepth}{5}
\setcounter{tocdepth}{5}
\titleformat{\paragraph}
{\normalfont\normalsize\bfseries}{\theparagraph}{1em}{}
\titlespacing*{\paragraph}
{-15ex}{3.25ex plus 1ex minus .2ex}{1.5ex plus .2ex}
\titleformat{\subparagraph}
{\normalfont\normalsize\bfseries}{\thesubparagraph}{1em}{}
\titlespacing*{\subparagraph}
{-12ex}{3.25ex plus 1ex minus .2ex}{1.5ex plus .2ex}
After adding this, sub-sub-sub-section numbers appear with \paragraph{}, and even one more level down with \subparagraph{}.
\label{} works as expected (\ref{} correctly references \paragraph{} and \subparagraph{}), and the table of contents also lists these elements neatly.
This snippet works well with the Hitec class. I don’t know if it works with other classes. But even if it does, odds are that the result will look ugly, as this code defines the spacing so that it looks fairly nice with Hitec’s formatting.
So it’s not really \subsubsubsection{}, which is awkwardly long anyhow, but a more elegant solution.
I had a set of SRT files with pretty good subtitles, but with one annoying problem: When there was a song in the background, the translation of the song would pop up and interrupt of the dialogue’s subtitles, so it became impossible to understand what’s going on.
Luckily, those song-translating subtitles had all have a “{\a6}” string, which is an ASS tag meaning that the text should be shown at the top of the picture. mplayer ignores these tags, which explains why these subtitles make sense, but mess up things for me. So the simple solution is to remove these entries.
Why don’t I use VLC instead? Mainly because I’m used to mplayer, and I’m under the impression that mplayer gives much better and easier control of low-level issues such as adjusting the subtitles’ timing. But also the ability to run it with a lot of parameters from the command line and jumping back and forth in the displayed video, in particular through a keyboard remote control. But maybe it’s just a matter of habit.
Here’s a Perl script that reads an SRT file and removes all entries with such string. It fixes the numbering of the entries to make up for those that have been removed. Fun fact: The entries don’t need to appear in chronological order. In fact, most of the annoying subtitles appeared at the end of the file, even though they messed up things everywhere.
This can be a boilerplate for other needs as well, of course.
#!/usr/bin/perl
use warnings;
use strict;
my $fname = shift;
my $data = readfile($fname);
my ($name, $ext) = ($fname =~ /^(.*)\.(.*)$/);
die("No extension in file name \"$fname\"\n")
unless (defined $name);
# Regex for a newline, swallowing surrounding CR if such exist
my $nl = qr/\r*\n\r*/;
# Regex for a subtitle entry
my $tregex = qr/(?:\d+$nl.*?(?:$nl$nl|$))/s;
my ($pre, $chunk, $post) = ($data =~ /^(.*?)($tregex*)(.*)$/);
die("Input file doesn't look like an SRT file\n")
unless (defined $chunk);
my $lpre = length($pre);
my $lpost = length($post);
print "Warning: Passing through $lpre bytes at beginning of file untouched\n"
if ($lpre);
print "Warning: Passing through $lpost bytes at beginning of file untouched\n"
if ($lpost);
my @items = ($chunk =~ /($tregex)/g);
#### This is the mangling part
my @outitems;
my $removed = 0;
my $counter = 1;
foreach my $i (@items) {
if ($i =~ /\\a6/) {
$removed++;
} else {
$i =~ s/\d+/$counter/;
$counter++;
push @outitems, $i;
}
}
print "Removed $removed subtitle entries from $fname\n";
#### Mangling part ends here
writefile("$name-clean.$ext", join("", $pre, @outitems, $post));
exit(0); # Just to have this explicit
############ Simple file I/O subroutines ############
sub writefile {
my ($fname, $data) = @_;
open(my $out, ">:utf8", $fname)
or die "Can't open \"$fname\" for write: $!\n";
print $out $data;
close $out;
}
sub readfile {
my ($fname) = @_;
local $/; # Slurp mode
open(my $in, "<:utf8", $fname)
or die "Can't open $fname for read: $!\n";
my $input = <$in>;
close $in;
return $input;
}
This post is a spin-off from another post of mine. It’s the result of my wish to limit the battery’s charge level, so it doesn’t turn into a balloon again.
I’ve written this post in chronological order (i.e. in the order that I found out things). If you’re here for the “what do I do”, just jump to “The Google pixel way”.
I assume that you’re fine with adb and that your Pixel phone is rooted.
I installed Charge Control (version 3.5) which appears to be the only app of this sort available for my phone in Google Play. It’s a bit scary to install an app with root control, but without root it can’t possibly work. It’s a nice app, with only one drawback: It doesn’t work, at least not on my phone. The phone nevertheless went on charging up to 100% despite the (annoying) notification that charging is disabled. I also tried turning off the “Adaptive Battery” and “Adaptive Charging” features but that made no difference. So I gave this app the boot.
I first wanted Battery Charge Limit app at Google Play. This app is announced at XDA developers (which is a good sign, if 2.9k reviews isn’t good enough), and has a long trace of versions. Even better, this app’s source is published at Github, which is how I found out that it hasn’t been updated since 2020. It was kicked off in 2017, according to the same repo. Unfortunately, as this app isn’t maintained, so it doesn’t support recent phones. Not mine, for sure.
Based upon this post in XDA forums, I found the way to actually limit the charging level. This is based upon this kernel commit on a driver that is specific to Google devices. This driver, google_charger.c, is not part of the kernel itself, but is included as an external kernel module. I’m therefore not sure exactly which version of this driver is used on my phone. However, as I’ve identified the kernel as slightly before “12.0.0 r0.36″, I suppose the driver is more or less in that region too, as it appears in the msm git repo as drivers/power/supply/google/google_charger.c.
git clone https://android.googlesource.com/kernel/msm
Now to some hands-on: I do this directly with adb, as root (more about adb on my other post):
# cd /sys/devices/platform/google,charger # ls -F bd_clear bd_resume_temp bd_trigger_voltage of_node@ bd_drainto_soc bd_resume_time charge_start_level power/ bd_recharge_soc bd_temp_dry_run charge_stop_level subsystem@ bd_recharge_voltage bd_temp_enable driver@ uevent bd_resume_abs_temp bd_trigger_temp driver_override bd_resume_soc bd_trigger_time modalias # cat charge_start_level 0 # cat charge_stop_level 100
This sysfs directory belongs to the google_charger kernel module (i.e. it’s listed on lsmod).
As one would expect, charging is disabled when the battery’s level equals or is above charge_stop_level, and resumes when the battery level equals or is below charge_start_level. The driver ignores both values if they are 0 and 100, or else the phone would reach 0% before starting to charge.
The important point is: If you change charge_stop_level, don’t leave charge_start_level at zero, or the battery will be emptied.
For my own purposes, I went for charge levels between 70% and 80%:
# echo 70 > charge_start_level # echo 80 > charge_stop_level
When charging is disabled this way, the phone clearly gets confused about the situation, and the information on the screen is misleading.
What actually happens is that if the charging level is above the stop level (80% in my case), the phone will discharge the battery, as if the power supply isn’t connected at all.
When the level reaches the stop level from above, the phone behaves as if the power supply was just plugged in (with a graphic animation and sound) and then goes back and forth between “charging slowly/rapidly” or it just shows the percentage. But it doesn’t charge the battery. Judging by the very slow discharging rate, the external power is used to run the phone, and the battery is just left on its own. Which is ideal: It’s equivalent to storing the battery within its ideal charging percentage for that purpose.
So the charging level will not oscillate all the time. Rather, it will more or less dwell at a random level between 70% and 80% each time, with a very slow descent.
When disconnecting the phone from external power, the phone works on battery of course, and will discharge. If it reaches below 70%, it will go up to 80% on the next opportunity to charge. If it doesn’t reach that level, it sometimes remains where it was after connection to external power, and sometimes it goes up to 80% anyhow. Go figure.
The “Ampere” app that I use to get info about the battery gets confused as well, saying “Not charging” most of the time, but often contradicts itself. I don’t blame it.
As for the regular Android settings in relation to the battery: Battery saver off, Adaptive Battery off and Adaptive Charging off. Not that I think these matter.
The relevant driver emits messages to the kernel log, so it looked like this when the charging level was 66% and I set charge_stop_level to 67:
# dmesg | grep google_charger [ ... ] [14866.762578] google_charger: MSC_CHG lowerbd=0, upperbd=67, capacity=66, charging on [14866.771714] google_charger: usbchg=USB typec=null usbv=4725 usbc=882 usbMv=5000 usbMc=900 [14896.794038] google_charger: MSC_CHG lowerbd=0, upperbd=67, capacity=66, charging on [14896.799065] google_charger: usbchg=USB typec=null usbv=4725 usbc=872 usbMv=5000 usbMc=900 [14923.236443] google_charger: MSC_CHG lowerbd=0, upperbd=67, capacity=67, lowerdb_reached=1->0, charging off [14923.236543] google_charger: MSC_CHG disable_charging 0 -> 1 [14923.247057] google_charger: usbchg=USB typec=null usbv=4725 usbc=880 usbMv=5000 usbMc=900 [14923.286307] google_charger: MSC_CHG fv_uv=4200000->4200000 cc_max=4910000->0 rc=0 [14926.809992] google_charger: MSC_CHG lowerbd=0, upperbd=67, capacity=67, charging off [14926.811376] google_charger: usbchg=USB typec=null usbv=4975 usbc=0 usbMv=5000 usbMc=900 [14953.952837] google_charger: MSC_CHG lowerbd=0, upperbd=67, capacity=67, charging off [14953.954431] google_charger: usbchg=USB typec=null usbv=4725 usbc=0 usbMv=5000 usbMc=900 [15046.115042] google_charger: MSC_CHG lowerbd=0, upperbd=67, capacity=67, charging off [15046.117563] google_charger: usbchg=USB typec=null usbv=4975 usbc=0 usbMv=5000 usbMc=900
As with all settings in /sys/, this is temporary until next boot. A short script that runs on boot is necessary to make this permanent. I haven’t delved into this yet, and I’m not sure I really want it to be permanent. It’s actually a good idea to be able to restore normal behavior just by rebooting. Say, if I realize that I’m about to have a long day out with the phone, just reboot and charge to 100% in the car.
The Tasker app and a Magisk module have been mentioned as possible solutions. Haven’t looked into that. To me, it would be more natural to add a script that runs on system start, but I am yet to figure out how to do that.
And by the way, there’s also a google,battery directory, but with nothing interesting there.
Wanting to be sure I’m not messing up something, I read through google_charger.c as of tag android-12.0.0_r0.35 (commit ID 44d65f8296b034061d76efb5409c3bf4d7dc1272, to be accurate). I’m not 100% sure this is what is running on my phone, however the code that I related to has no changes for at least a year in either direction (according to the git repo).
I should mention that google_charger.c is a bit of a mess. The signs of hacking without cleaning up afterwards are there.
Anyhow, I noted that setting charge_start_level and/or charge_stop_level disables another mechanism, which is referred to as Battery Defender. This mechanism stops charging in response to a hot battery.
The thing is that if a battery becomes defective, the only thing that prevents it from burning is that charging stops in response to a high temperature reading. So can turning off Battery Defender have really unpleasant consequences?
After looking closely at chg_run_defender(), my conclusion is that Battery Defender only halts charging when the battery’s voltage exceeds bd_trigger_voltage and when the average temperature is above bd_trigger_temp. According the values in my sysfs, this is 4.27V (i.e. 100% full and beyond) and 35.0°C.
All other bd_* parameters set the condition for resumption of charging.
In other words, this mechanism wouldn’t kick in anyhow, because the battery voltage is lower than this. So limiting the battery’s charge this way poses no additional risk.
I surely hope there’s another mechanism that stops charging if the battery gets really hot. I didn’t find such (but didn’t really look much for one).
The rest of this post consists of really messy jots.
These are random notes that I took as I read through the code. Written as I went, so not necessarily fully accurate.
In conclusion, setting the charging levels disables the mechanism that disables charging based upon temperature. chg_run_defender() uses the charging levels instead of the mechanism that is based upon temperature.
More dissection of chg_run_defender():
/* not over vbat and !triggered, nothing to see here */
if (vbatt < bd_state->bd_trigger_voltage && !triggered)
return 0;
As bd_reset() has a crucial role, here it is. Note that the parameters are the same as published in /sys/devices/platform/google,charger/.
static void bd_reset(struct bd_data *bd_state)
{
bool can_resume = bd_state->bd_resume_abs_temp ||
bd_state->bd_resume_time ||
(bd_state->bd_resume_time == 0 &&
bd_state->bd_resume_soc == 0);
bd_state->time_sum = 0;
bd_state->temp_sum = 0;
bd_state->last_update = 0;
bd_state->last_voltage = 0;
bd_state->last_temp = 0;
bd_state->triggered = 0;
/* also disabled when externally triggered, resume_temp is optional */
bd_state->enabled = ((bd_state->bd_trigger_voltage &&
bd_state->bd_recharge_voltage) ||
(bd_state->bd_drainto_soc &&
bd_state->bd_recharge_soc)) &&
bd_state->bd_trigger_time &&
bd_state->bd_trigger_temp &&
bd_state->bd_temp_enable &&
can_resume;
}
As read from /sys/devices/platform/google,charger/:
bd_drainto_soc:80 bd_recharge_soc:79 bd_recharge_voltage:4250000 bd_resume_abs_temp:280 bd_resume_soc:50 bd_resume_temp:290 bd_resume_time:14400 bd_temp_dry_run:1 bd_temp_enable:1 bd_trigger_temp:350 bd_trigger_time:21600 bd_trigger_voltage:4270000 charge_start_level:70 charge_stop_level:80 driver_override:(null) modalias:of:Ngoogle,chargerT(null)Cgoogle,charger uevent:DRIVER=google,charger OF_NAME=google,charger OF_FULLNAME=/google,charger OF_COMPATIBLE_0=google,charger OF_COMPATIBLE_N=1