Viestialustana vianhallintajärjestelmät

Switched to 11.1 and tried updating those components again. No change unfortunately.

14. marraskuuta 2024 klo 12.05
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Home Assistant

Switched to 11.1 and tried updating those components again. No change unfortunately.

home-assistant_2024-11-14T09-59-20.244Z.log

Vastaa viestiin sen kontekstissa (Github)

Yes, the qemu solution seems simpler

12. marraskuuta 2024 klo 7.44
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: MongoDB, Unifi, Wekan

Yes, the qemu solution seems simpler and more future-proof than the custom Unifi repository.

Also, my guess would be that few people running Wekan on hardware old enough not to have AVX will have a massively large user base on their installation; most are probably small-time hobbyists like myself, so any negligible slowdowns being exacerbated by scale won’t be much of an issue.

Vastaa viestiin sen kontekstissa (Github)

Right, could be more trouble than it’s worth

11. marraskuuta 2024 klo 15.02
Sijainti: Vianhallintajärjestelmät
Avainsanat: MongoDB, Wekan

Right, could be more trouble than it’s worth.

I have been eyeing some slightly newer (used) hardware for my home server, but for now this AVX requirement from (the Wekan-integrated) MongoDB is the only real reason to upgrade; otherwise the old HP (from 2011!) is still chugging along just fine in what it’s used for. :)

Vastaa viestiin sen kontekstissa (Github)

Would it be possible for Wekan (installed as a snap) to use mongodb tools already installed on the host system?

11. marraskuuta 2024 klo 13.23
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: MongoDB, Snap, Unifi, Wekan

I can already guess the answer to this is ”no, because of how snap works”, but would it be possible for Wekan (installed as a snap) to use mongodb tools already installed on the host system? The reason I’m asking is that I’m running Unifi’s network application on the same non-AVX-capable host, and the installation script for it has added a mongodb repository patched to work without AVX, so that’s already covered.

Vastaa viestiin sen kontekstissa (Github)

Since installing 21.0-20241023-nightly, apps can no longer access Internet when Wireguard is connected

30. lokakuuta 2024 klo 11.00
Sijainti: Vianhallintajärjestelmät: Gitlab
Avainsanat: Android, Chrome, Firefox, LineageOS, Wireguard

Summary

Since installing 21.0-20241023-nightly, apps on my tablet can no longer access Internet when Wireguard is connected. This worked just fine right up until 20241023-nightly, and Wireguard’s app hasn’t been updated in over a year, so I’m pretty sure it’s the new build.

Looks like it’s DNS. (It’s always DNS.) There are a couple of conspicuously related-looking commits in this build: 406071 (VPN-covered DNS traffic may not fall through) and 406070 (Revert ”Prevent DNS traffic from bypassing lockdown VPNs”).

Expected Behavior

Apps should be able to connect to the Internet even when Wireguard is connected.

Current Behavior

Apps lose access to Internet immediately when Wireguard is connected. Curiously, Chrome is unaffected; all other apps that I’ve tested are affected, including Firefox, which says ”Address not found”, hinting at DNS.

Steps to Reproduce

  1. Install Wireguard
  2. Set up a connection that doesn’t route all traffic but just that interface’s address space. I’m including a screenshot of my Wireguard configuration below.
  3. Toggle the Wireguard interface on.
  4. Open Firefox and try to browse the web.

Device information

/codename gts4lvwifi /version 21 /date 2024-10-23 /kernel 4.9.337-g16026dfb9b4c #1 Wed Oct 23 13:53:22 UTC 2024 /baseband none /mods Google Apps

I have read the directions

Vastaa viestiin sen kontekstissa (Gitlab)

”terminology-tooltip” span elements break content in Atom feed

3. lokakuuta 2024 klo 16.35
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Home Assistant, Tiny Tiny RSS

A tooltip is used to render explanations for terminology when site content is viewed directly in a browser. But feed readers traditionally don’t support styles, and so the content is broken up by the <span class='terminology-tooltip'> elements’ content being shown mid-sentence. For instance, this paragraph in the 2024.10 release post

<p>We also introduce some small YAML automation syntax changes. If you are still a sucker for writing your automations
in <span class='terminology'>YAML<span class='terminology-tooltip'>YAML is a human-readable data serialization
language. It is used to store and transmit data in a structured format. In Home Assistant, YAML is used for configuration,
for example in the <code>configuration.yaml</code> or <code>automations.yaml</code>
files.<a class='terminology-link' href='/docs/configuration/yaml/'> [Learn more]</a></span></span> (like me), I’m sure
you’ll love these little tweaks that make it all feel more natural.</p>

is shown in my feed reader (Tiny Tiny RSS) as:

Screenshot from 2024-10-03 16-23-50

I’m not sure if this is a recent technical change, or just the first instance of these spans being used, or if I just haven’t been reading the posts that thoroughly, but the 2024.10 release post was the first I noticed this.

Vastaa viestiin sen kontekstissa (Github)

For me the icon is not missing, but it is replaced by what looks like perhaps a fallback, a cogwheel

22. syyskuuta 2024 klo 11.10
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: GIMP

For me the icon is not missing, but it is replaced in the dock by what looks like perhaps a fallback: a cogwheel icon. I’m attaching a screenshot.

Vastaa viestiin sen kontekstissa (Launchpad)

I’ll have to postpone further testing until the next time there’s an issue

5. syyskuuta 2024 klo 11.16
Sijainti: Vianhallintajärjestelmät: Launchpad

Hi Vinicius, thanks for looking into this!

I’ll have to postpone further testing until the next time there’s an issue, as my backups rely on the NAS (and it’s now back in operation with the nomodeset workaround). Taking it down is also physically fairly involved, as I prefer to unplug all the data drives, to spare them from repeated powercycling during testing.

However, I’m about 80 % sure I checked the journal for the failed suspends, and it just stopped there, resuming thereafter with just the boot messages from the next boot onward.

Also, I have TTY1 configured to display the journal ”live” (I’ll attach my /etc/systemd/system/getty@tty1.service.d/override.conf below), and I *did* try suspending with that TTY showing the journal (`sleep 5 && systemctl suspend` on TTY2, then switching to TTY1 before the timeout); I’ll attach a photo of that view when the suspend had resulted in this freezing issue.

Unfortunately I don’t have a cable to do debugging over a serial console.

Vastaa viestiin sen kontekstissa (Launchpad)

I was able to work around this by temporarily installing postgresql-14 from the PGDG repository

2. syyskuuta 2024 klo 18.55
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: PGDG, PostgreSQL, Ubuntu

I was able to work around this (in a test VM, after upgrading it from 20.04 to 24.04) with adapted instructions from a blogpost [1], by temporarily installing postgresql-14 from the PGDG repository for doing the 14 -> 16 upgrade:

# apt install postgresql-common
# /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh
# apt install postgresql-14
# pg_dropcluster 16 main –stop
# pg_upgradecluster 14 main
# pg_dropcluster 14 main
# apt purge postgresql-14 postgresql-client-14
# rm /etc/apt/sources.list.d/pgdg.sources
# apt update

I have yet to try this on my actual server with actual data. Please be careful if you attempt this with a production database.

*[1] https://www.directedignorance.com/blog/upgrading-postgresql-14-to-16-on-ubuntu

Vastaa viestiin sen kontekstissa (Launchpad)

(Nvidia) system freezes when called to suspend since Linux 6.7.0 on Nvidia hardware with modeset

31. elokuuta 2024 klo 14.25
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Nvidia, Ubuntu

== Summary ==
On my computer with an ancient Nvidia chipset (Geforce 7025/nForce 630a), running `sysctl suspend` (or suspending from the Gnome menu) causes the system to start suspending, but it freezes halfway, leaving fans and hard drives spinning. There’s no way to resume from this frozen state apart from forcing a reboot (with a hardware reset button/poweroff).

== Steps to reproduce ==
* boot with modeset enabled
* run `sysctl suspend`

== What I expect to happen ==
For the system to suspend, shutting down all fans and hard drives.

== What happens ==
The system begins to suspend, but freezes halfway, leaving the display on and fans and hard drives spinning, but the keyboard unresponsive.

== Workaround ==
Disable kernel modesetting by adding ”nomodeset” to the kernel commandline.

== Affected kernels ==
Prior to upgrades the system was running HWE kernel 5.15.0, so I tried the 5.15 series, and found that I could now suspend and wake the machine again just as before. I worked my way up the versions:

* 5.15.50: unaffected
* 5.15.165: unaffected
* 5.19.17: unaffected
* 6.4.0: unaffected
* 6.6.0: unaffected
* 6.6.48: unaffected
* 6.7.0: first to fail

I also tried the current newest mainline kernel 6.10.7, and the issue is still present there.

== Background ==
I have an old desktop machine now functioning as a NAS, and yesterday I upgraded it from Ubuntu 20.04 first to 22.04, and then all the way up to 24.04. The upgrade went smoothly, and this is the only issue I’ve come across since.

In the BIOS settings of the affected machine there are three ”suspend mode” alternatives to choose from: ”S1 (POS) only”, ”S3 only” and ”Auto”. I’ve always had it on ”Auto”, but with this issue I also tested both ”S1 only” and ”S3 only”, with no effect.

The issue is also present when booting from the installation media (USB) into a live environment.

I’ve previously upgraded my laptop to 24.04, and there suspending still works as it did before the ugprade, so this is probably hardware-specific; the laptop is a modern one with all-Intel hardware.

Googling around, I could smelled hints of this being once again related to the troublesome Nvidia chipset, so I tried nomodeset with the stock 6.8.0 kernel (6.8.0-41 currently) and voilà! Suspend and wake were working again.

Well, except for the display, which stayed black. But I couldn’t say if this was the way it was before, because the NAS is normally running headless.

Vastaa viestiin sen kontekstissa (Launchpad)

Vanhempia »