Viestialustana vianhallintajärjestelmät

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)

It’s working just fine after switching to 2024.7/candidate

19. heinäkuuta 2024 klo 14.33
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Home Assistant

I’m on amd64 too, and yep, it’s working just fine after switching to 2024.7/candidate. Excellent, thank you!

Vastaa viestiin sen kontekstissa (Github)

Yeah, still not working for me either

19. heinäkuuta 2024 klo 7.58
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Home Assistant, Snap, Ubuntu

Yeah, still not working for me either. Restarting HA snap just results in the same traceback getting logged as before.

Settings > Devices & services > HACS shows it’s up to date (or at least at that same version, 1.34.0). I can’t find a ”Configuration” or ”HACS update” view under the HACS service, only the one with related Service info, Automations and so on (possibly because HACS is ”Not loaded”, which is the issue).

I don’t know if the host system has any bearing on this, but mine is running Ubuntu 20.04, and I’ll happily provide any other info if needed.

Screenshot from 2024-07-19 07-34-58

Screenshot from 2024-07-19 07-36-46

Vastaa viestiin sen kontekstissa (Github)

The traceback I have refers to pydantic

5. heinäkuuta 2024 klo 15.37
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Home Assistant, Python

Here’s the full traceback I have, unfiltered. It refers to pydantic, and it looks like something people have worked around by forcing pydantic to version 1.10.16. I barely speak any Python at all though, so I wouldn’t know what other implications this has, if any, but I hope it’s at least a clue.

ha.log

Vastaa viestiin sen kontekstissa (Github)

As a workaround, adding –no-warnings seems to suppress this output.

12. huhtikuuta 2024 klo 10.21
Sijainti: Vianhallintajärjestelmät: Github

As a workaround, adding --no-warnings seems to suppress this output.

Vastaa viestiin sen kontekstissa (Github)

I can also confirm that v1.67.0-beta.7775.8cb7f28f8.fix-7673-dir-wrapping fixes this

14. maaliskuuta 2024 klo 12.07
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: rclone

Yup, I can also confirm that v1.67.0-beta.7775.8cb7f28f8.fix-7673-dir-wrapping fixes this!

Vastaa viestiin sen kontekstissa (Github)

I was confused by the wording

12. maaliskuuta 2024 klo 18.20
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Android, Mastodon, saavutettavuus

Ah, apparently ”Show content warnings” on the app is the opposite of what’s ”Always expand posts marked with content warnings” in the web UI. I was confused because the former refers to the warning, whereas the latter refers to the content. There may be minor usability issue there, but I’ll leave it out of this one.

Sorry for the noise. To make up for it, #290 looks like a duplicate of this one and thus could possibly also be closed.

Vastaa viestiin sen kontekstissa (Github)

”Always expand posts marked with content warnings” not honored

12. maaliskuuta 2024 klo 16.46
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Android, Mastodon

I have ”Always expand posts marked with content warnings” on in my settings, but CW-marked posts in the Android app still show as unexpanded.

I’m fairly sure this used to work until recently, and #87 being closed as ”completed” back in October would imply I wasn’t just imagining it.

Vastaa viestiin sen kontekstissa (Github)

”optional feature not implemented” with crypt-on-sftp in 1.66

12. maaliskuuta 2024 klo 14.36
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: rclone

What is the problem you are having with rclone?

I’m using a crypt-on-sftp remote, which was working just fine up until v1.65.2. With v1.66, attempts to sync to it now fail with ”optional feature not implemented”. I’ve not narrowed down whether it’s the crypt or the sftp layer, so I’m just reporting my (failing) test case below.

I did a bisect, and apparently this issue came in at f5f8678 (which was a fix for #6685).

What is your rclone version (output from rclone version)

1.66.0

Which OS you are using and how many bits (e.g. Windows 7, 64 bit)

Ubuntu 22.04 (64-bit)

Which cloud storage system are you using? (e.g. Google Drive)

sftp

The command you were trying to run (e.g. rclone copy /tmp remote:tmp)

rclone sync a/ C:

Steps to reproduce

  1. rclone --config test.conf config
  2. set up sftp (44) remote called S
    • for test purposes here I’m using localhost as the underlying remote server
    • set user & password
    • leave everything else at defaults
  3. set up crypt remote C, with
    • ”S:ftp” as the underlying remote
    • Very simple filename obfuscation (obfuscate)
    • Encrypt directory names (true)
    • set password, no password2
  4. mkdir -p ftp a/b # on the sftp remote; here I'm using localhost
  5. touch a/test1 # on the sftp remote
  6. rclone --config test.conf sync a/ C: -vv # no problems
  7. touch a/b/test2 # on the sftp remote
  8. rclone --config test.conf sync a/ C: -vv

A log from the command with the -vv flag (e.g. output from rclone -vv copy /tmp remote:tmp)

2024/03/12 14:33:36 DEBUG : rclone: Version "v1.66.0" starting with parameters ["rclone" "--config" "test.conf" "sync" "a/" "C:" "-vv"]
2024/03/12 14:33:36 DEBUG : Creating backend with remote "a/"
2024/03/12 14:33:36 DEBUG : Using config file from "/home/jani/test.conf"
2024/03/12 14:33:36 DEBUG : fs cache: renaming cache item "a/" to be canonical "/home/jani/a"
2024/03/12 14:33:36 DEBUG : Creating backend with remote "C:"
2024/03/12 14:33:37 DEBUG : Creating backend with remote "S:ftp"
2024/03/12 14:33:37 DEBUG : sftp://jani@localhost:22/ftp: New connection 127.0.0.1:48814->127.0.0.1:22 to "SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6"
2024/03/12 14:33:37 DEBUG : sftp://jani@localhost:22/ftp: Shell type "unix" from config
2024/03/12 14:33:37 DEBUG : sftp://jani@localhost:22/ftp: Relative path resolved to "/home/jani/ftp"
2024/03/12 14:33:37 DEBUG : sftp://jani@localhost:22/ftp: Using root directory "/home/jani/ftp"
2024/03/12 14:33:37 DEBUG : test1: Size and modification time the same (differ by -995.288851ms, within tolerance 1s)
2024/03/12 14:33:37 DEBUG : test1: Unchanged skipping
2024/03/12 14:33:37 DEBUG : b/test2: Need to transfer - File not found at Destination
2024/03/12 14:33:37 DEBUG : Encrypted drive 'C:': Waiting for checks to finish
2024/03/12 14:33:37 DEBUG : Encrypted drive 'C:': Waiting for transfers to finish
2024/03/12 14:33:37 DEBUG : sftp://jani@localhost:22/ftp: Shell path "/home/jani/ftp/98.g/149.zkyz4.EACoEuq1.vgxzogr"
2024/03/12 14:33:37 DEBUG : sftp://jani@localhost:22/ftp: Running remote command: md5sum /home/jani/ftp/98.g/149.zkyz4.EACoEuq1.vgxzogr
2024/03/12 14:33:37 DEBUG : sftp://jani@localhost:22/ftp: Remote command result: ac83867dee807f03ee4f8f307cda1257  /home/jani/ftp/98.g/149.zkyz4.EACoEuq1.vgxzogr
2024/03/12 14:33:37 DEBUG : 98.g/149.zkyz4.EACoEuq1.vgxzogr: Parsed hash: ac83867dee807f03ee4f8f307cda1257
2024/03/12 14:33:37 DEBUG : b/test2.yuwiyok9.partial: md5 = ac83867dee807f03ee4f8f307cda1257 OK
2024/03/12 14:33:37 DEBUG : b/test2.yuwiyok9.partial: renamed to: b/test2
2024/03/12 14:33:37 INFO  : b/test2: Copied (new)
2024/03/12 14:33:37 ERROR : Encrypted drive 'C:': not deleting files as there were IO errors
2024/03/12 14:33:37 ERROR : Encrypted drive 'C:': not deleting directories as there were IO errors
2024/03/12 14:33:37 ERROR : Attempt 1/3 failed with 1 errors and: optional feature not implemented
2024/03/12 14:33:37 DEBUG : test1: Size and modification time the same (differ by -995.288851ms, within tolerance 1s)
2024/03/12 14:33:37 DEBUG : test1: Unchanged skipping
2024/03/12 14:33:37 DEBUG : b/test2: Size and modification time the same (differ by -116.891668ms, within tolerance 1s)
2024/03/12 14:33:37 DEBUG : b/test2: Unchanged skipping
2024/03/12 14:33:37 DEBUG : Encrypted drive 'C:': Waiting for checks to finish
2024/03/12 14:33:37 DEBUG : Encrypted drive 'C:': Waiting for transfers to finish
2024/03/12 14:33:37 ERROR : Encrypted drive 'C:': not deleting files as there were IO errors
2024/03/12 14:33:37 ERROR : Encrypted drive 'C:': not deleting directories as there were IO errors
2024/03/12 14:33:37 ERROR : Attempt 2/3 failed with 1 errors and: optional feature not implemented
2024/03/12 14:33:37 DEBUG : test1: Size and modification time the same (differ by -995.288851ms, within tolerance 1s)
2024/03/12 14:33:37 DEBUG : test1: Unchanged skipping
2024/03/12 14:33:37 DEBUG : b/test2: Size and modification time the same (differ by -116.891668ms, within tolerance 1s)
2024/03/12 14:33:37 DEBUG : b/test2: Unchanged skipping
2024/03/12 14:33:37 DEBUG : Encrypted drive 'C:': Waiting for checks to finish
2024/03/12 14:33:37 DEBUG : Encrypted drive 'C:': Waiting for transfers to finish
2024/03/12 14:33:37 ERROR : Encrypted drive 'C:': not deleting files as there were IO errors
2024/03/12 14:33:37 ERROR : Encrypted drive 'C:': not deleting directories as there were IO errors
2024/03/12 14:33:37 ERROR : Attempt 3/3 failed with 1 errors and: optional feature not implemented
2024/03/12 14:33:37 INFO  : 
Transferred:   	         32 B / 32 B, 100%, 0 B/s, ETA -
Errors:                 1 (retrying may help)
Checks:                 5 / 5, 100%
Transferred:            1 / 1, 100%
Elapsed time:         0.3s

2024/03/12 14:33:37 DEBUG : 15 go routines active
2024/03/12 14:33:37 DEBUG : sftp://jani@localhost:22/ftp: Closing 1 unused connections
2024/03/12 14:33:37 Failed to sync: optional feature not implemented

How to use GitHub

  • Please use the 👍 reaction to show that you are affected by the same issue.
  • Please don’t comment if you have no relevant information to add. It’s just extra noise for everyone subscribed to this issue.
  • Subscribe to receive notifications on status change and new comments.

Vastaa viestiin sen kontekstissa (Github)

« Uudempia - Vanhempia »