Nuudelisoppa

Category: Uncategorized

  • Slow resume from suspend in Ubuntu 26.04, caused by slow hard drives

    After upgrading Ubuntu on my desktop computer from 24.04 to 26.04, it became very slow to wake up after being put to sleep: in 24.04 it came up almost instantly (apart from wired network, which has always been slow), but in 26.04 it took long enough that my displays (which I usually power off after suspending the computer) decided there was no signal coming, and went to sleep. In all, it now took almost a minute from my pressing a key till GDM’s login screen came up.

    My first suspicion was that something had changed in Systemd’s sleep hooks (under /lib/systemd/system-sleep/), but there weren’t any obvious culprits. I had one of my own scripts there (to turn the annoying LEDs on an external USB hub on and off), and although it’s not fast, it’s not that slow either. Still, I eliminated it by removing it temporarily, which had no effect.

    The only other possible culprit was a script from hdparm (/lib/systemd/system-sleep/hdparm):

    #!/bin/sh

case $1 in
  post)
    /usr/lib/pm-utils/power.d/95hdparm-apm resume
    ;;
esac

    I added a couple of echo lines to it, one above and one below the call to 95hdparm-apm resume, and this (or rather, viewing journalctl‘s output after the next suspend+resume) revealed that it took 17 seconds for it to complete. I have a couple of hard disk drives that have always been sluggish to spin up, and apparently Systemd now no longer considers the wakeup done until the script is finished. (This script was there already back in 24.04, and the current hdparm package in 26.04 is only a no-change rebuild of the same version that is in 24.04, so the script content also hasn’t changed.)

    I moved /lib/systemd/system-sleep/hdparm temporarily elsewhere, and that restored the almost instantaneous wakeup.

    hdparm -B for the drives after this wakeup showed that they’re using APM level 164 by default. Journal logs from before disabling the hdparm script showed that the script sets the APM level to 254 for both drives.

    164 is above what hdparm‘s man page documents as allowing spin-down (1—127), but ChatGPT distilled the rest as “the 128–254 range controls things such as how aggressively the drive may enter other power-saving states, head parking, interface power management, etc. The higher the number, the more aggressively the drive is biased toward performance and away from power saving.”

    Of these, besides performance, I mostly care about things that may affect the drives’ longevity, such as head parking. So I’m now monitoring smartctl‘s view into their Load_Cycle_Count to see if they do excessive parking at the default level. If they do, or if the performance hit from the lower level turns out to be too much, I’ll have to reinstate the hdparm script and find a workaround for it holding the wakeup hostage.

  • ERROR : Daemon timed out. Failed to terminate daemon pid 38391: os: process already finished

    Helping out search engines once again, because this anonymous error is from rclone, and none of the existing resources I found mentioned what turned out to be the cause/solution: I had tried resetting (unsetting) user_allow_other in /etc/fuse.conf (after updating Ubuntu from 24.04 to 26.04, and not remembering why I’d set it before), and that was what the complete non sequitur error message was about.

    So: try uncommenting user_allow_other in /etc/fuse.conf to fix this. (The setting takes effect immediately, without needing to reboot or anything.)

  • A possible fix for Nautilus being slow as molasses (in Ubuntu 24.04)

    As per title. A post on NixOS users’ Discourse implicated XDG_TEMPLATES_DIR, although that one was about a bug in Glib newer than what’s in Ubuntu 24.04, involving trailing slashes. But I had mine pointed to $HOME/tmp, and apparently Nautilus tries to read all the garbage files I have therein, almost choking to death while doing so.

    I made a separate, new (empty) directory, pointed XDG_TEMPLATES_DIR to it, killed all existing Nautilus processes and hallelujah! It’s no longer slow.

  • Systemd and top-level drop-ins for user units

    (This post is just a bit of good old-fashioned search engine fodder. Systemd terminology is frustratingly generic, making it hard to find solutions to specific problems related to it.)

    I’m trying out per-user units for the first time, and immediately wanted to also use top-level drop-ins. I couldn’t find solid documentation for it, but logically, I assumed they would go under ~/.config/systemd/user/service.d/.

    This didn’t seem to work though: systemctl --user cat $unitname still only listed the contents of $unitname.service without what I had in ~/.config/systemd/user/service.d/override.conf.

    After flailing around for a while, I realized I just had to do a systemctl daemon-reload --user to make it work.

    (I don’t know if the support for top-level drop-ins in per-user units was already there when user units themselves arrived, but at least it’s working for me in Ubuntu 24.04 with systemd version 255.)

  • How to have email status from ~/Maildir under motd (Ubuntu 24.04)

    I recently set up my local mail to go into ~/Maildir. But when logging in on a console, the mail notification under motd still seemed to assume my mail being somewhere else (under /var/mail maybe), as it only ever said

    You do not have any new mail.

    I figured out that this message is generated by pam_mail, and it’s possible to configure it to use ~/Maildir with the dir= parameter. There’s separate configuration for each of (local) login, ssh and su in /etc/pam.d/login, /etc/pam.d/sshd and /etc/pam.d/su respectively. For instance, /etc/pam.d/login has this line:

    session    optional   pam_mail.so standard

    which I changed to

    session    optional   pam_mail.so dir=~/Maildir standard

    and now the note under motd reflects what’s in my ~/Maildir.

  • How to have Mutt thread together messages with the same subject, even without Re:

    Mutt settings are mostly inscrutable to me, so I’ll just dump the ones I found (through trial and error) that do what I want below. Besides having these:

    set sort=threads
set sort_browser=reverse-date
set sort_aux=reverse-last-date-received

    I needed to add these:

    set sort_re=no
unset strict_threads

    For convenience, I also added these:

    # Collapse threads at startup
exec collapse-all

# Set the keys for un-/collapsing all threads/one thread
bind index _ collapse-all
bind index - collapse-thread

    (I’m using Mutt version 2.2.12 in Ubuntu 24.04.)

  • Crossgrading Ubuntu 18.04 to Debian 10

    After upgrading all Ubuntu 18.04 packages to their latest releases, I adapted eudoxos‘ recipe:

    1. Rebooted and selected the stock 18.04 kernel instead of HWE, which I was using
    2. Downloaded debian-keyring and debian-archive-keyring .debs and installed them with dpkg -i debian*.deb
    3. Created /etc/apt/preferences.d/10-no-ubuntu to pin down Ubuntu packages: 
      Package: *
Pin: release o=Ubuntu
Pin-Priority: -1000
    4. Added Debian sources for buster to the end of /etc/apt/sources.list: 
      deb http://deb.debian.org/debian buster main contrib non-free
deb http://deb.debian.org/debian-security/ buster/updates main contrib non-free
deb http://deb.debian.org/debian buster-updates main contrib non-free
    5. apt update && apt-get dist-upgrade
    6. Answered “no” to all configuration changes questions (I’ll update them later)
    7. Post-install, networking was non-functional. Apparently this was caused by Apparmor, so I disabled it (systemctl disable apparmor.service) and rebooted.
    8. Deleted /etc/apt/preferences.d/10-no-ubuntu
    9. Then it was time for manual package surgery. Lots and lots of it. Searching for remaining Ubuntu packages is easy enough, with 
      dpkg -l | grep ubuntu

      and

      aptitude search '?narrow(?installed, ?not(?origin(Debian)))'

      Many of the matching packages can be removed/downgraded to their Debian versions without issue, but a bunch of gcc and python packages turned out to be tricky, and had to be downgraded all together. I did make notes, but following them blindly would most likely just do more harm than good, so I won’t post them here; you’ll need to hack’n’slash your own way anyway.

  • Kuinka kalibroin vanhan Android-tabletin akun varausilmaisimen

    XDA-foorumin anandmoren ohjeen mukaisesti:

    1. Irrotin laitteen laturista.
    2. Käytin laitetta niin kauan, että se sammui itsestään akun varauksen loputtua. Ensimmäisellä syklillä tämä tapahtui varausilmaisimen näyttäessä 86 %.
    3. Käynnistelin laitetta uudestaan niin kauan, että se ei enää päässyt käynnistyslatainruutua (laitteen valmistajan logo) pitemmälle ilman että sammuu. Pari kertaa pääsin kotinäytölle asti, ja kerran ennätin käynnistää videosovelluksenkin.
    4. Kytkin laitteen sammutettuna laturiin.
    5. Annoin (edelleen sammutettuna olevan laitteen) latautua niin kauan, että varausilmaisin näytti akun olevan (100 %) täynnä. (Virtakytkimen lyhyt painallus näyttää varausilmaisimen ilman että laite käynnistyy.) Tässä kesti useita tunteja, vaikka lähtötilanne oli (ensimmäisellä syklillä) varausilmaisimen mielestä noin 75—80 % (josta huolimatta laite ei siis enää kyennyt käynnistymään).
    6. Irrotin laitteen laturista.
    7. Käynnistin laitteen.
    8. Varausilmaisin näytti käynnistymisen jälkeen 98 %. Kytkin laitteen laturiin.
    9. Annoin latautua niin kauan, että (nyt käynnissä olevan laitteen) varausilmaisin näytti akun olevan (100 %) täynnä, joskaan tällä ensimmäisellä syklillä se ei päässyt tuosta 98 %:sta ylemmäs.
    10. Sammutin laitteen.
    11. Irrotin laitteen laturista.
    12. Käynnistin laitteen.
    13. Toistin vaiheet 2—12 vielä kaksi kertaa. Vasta sen jälkeen laitetta pystyi käyttämään niin, että akun varaus tyhjeni 100 %:sta (käytön myötä, vähitellen) alle 10 %:iin ilman automaattista sammumista.

  • “Copy” disabled in Firefox’s context menu

    Just a note for myself about this: Bug 1863246: Copy and Paste context menu entries are sometimes disabled when they should not be

    And a workaround lower down, from lexlexlex:

    “I noticed that an easy workaround when this happens is to click the address bar to change selection focus, then interact with the page again. After that, the “Copy” entry in the context menu works again without reopening the tab.”

  • Notes as I go: my attempt to develop a Home Assistant integration, part 3

    One thing that was confusing to me from the start was the seemingly overlapping functionality in __init__.py and config_flow.py, but I think I figured it out: async_step_*() in config_flow.py is for when a component is first set up, whereas async_setup_entry() in __init__.py is for when a config entry for the component has already previously been set up, and so an object can be instantiated for that entry.

    As for “my API”, my impression (from both core and non-core integrations) is that if I had a published Python package for the device, I’d just import it (like, for instance, RuuviTag integration imports ruuvitag-ble), but if/as I don’t, I should create the API in a subdirectory of my integration and import it using dot notation.

    Hence, naming the files inside the API directory is more a question of general Python convention, rather than something HA has opinions about.

    Anyway, while I understand all the complications I keep stumbling over make HA component development scalable, it also makes my tiny button project way more complicated than it should be. There appears to be no way to build a minuscule MVP with just a few lines of code, to be then extended with all the bells and whistles that would make it look and play nice.

    Instead it seems easier to just hack some existing code to work with my device (which I’ve already done, semi-successfully). But that means then having to clean up tons of someone else’s code, or, what’s more likely, just leave it all as an ugly hack, never to be published anywhere.