Re: HDD long-term data storage with ensured integrity
On 4/12/24 08:14, piorunz wrote: On 10/04/2024 12:10, David Christensen wrote: Those sound like some compelling features. I believe the last time I tried Btrfs was Debian 9 (?). I ran into problems because I did not do the required manual maintenance (rebalancing). Does the Btrfs in Debian 11 or Debian 12 still require manual maintenance? If so, what and how often? I don't do balance at all, it's not required. Scrub is recommended, because it will detect any bit-rot due to hardware errors on HDD media. It scans the entire surface of allocated sectors on all drives. I do scrub usually monthly. Thank you for the information. David
Re: inconsistency in the symlinks under /etc/systemd
On Wed 10 Apr 2024 at 14:36:20 (-0400), Jeffrey Walton wrote: > On Wed, Apr 10, 2024 at 7:00 AM Vincent Lefevre wrote: > > > > On one machine, I have > > > > lrwxrwxrwx 1 root root 35 2023-10-07 13:43:24 > > /etc/systemd/system/sockets.target.wants/dm-event.socket -> > > /lib/systemd/system/dm-event.socket > > > > and on another one, I have > > > > lrwxrwxrwx 1 root root 39 2024-01-05 16:54:09 > > /etc/systemd/system/sockets.target.wants/dm-event.socket -> > > /usr/lib/systemd/system/dm-event.socket > > > > These symlinks were created at Debian installation time, and in > > both cases, the dmeventd version is 2:1.02.196-1+b1. > > > > Shouldn't the system ensure that symlinks are consistent on different > > machines (even though the above symlinks are equivalent), for instance > > to ease the comparison of configurations between machines? > > > > For instance, shouldn't usr-is-merged convert the symlinks to a > > canonical path? > > Be careful of fiddling with the Systemd symlinks. If you convert the > relative ones to absolute ones, then the machine will fail to boot. I don't think there should be any relative systemd symlinks in /etc/systemd/ unless, for some peculiar reason, you've hand-crafted them yourself. Cheers, David.
Re: inconsistency in the symlinks under /etc/systemd
On Thu 11 Apr 2024 at 19:28:48 (+0200), Vincent Lefevre wrote: > On 2024-04-10 23:47:36 -0500, David Wright wrote: > > On Thu 11 Apr 2024 at 03:36:59 (+0200), Vincent Lefevre wrote: > > > On 2024-04-10 09:52:51 -0400, Dan Purgert wrote: > > > > I'd hazard it's a consequence of usrmerge being the "default state" in > > > > one installation and not the other. > > > > > > Both machines have always been usr-merged (i.e. from the Debian > > > installation). > > > > This is trixie, is it not, so perhaps bugs are being fixed > > in package installation support programs. You should be able > > to see the symlinks being created in /var/log/apt/term.log* > > if they haven't yet rotated away. > > On the first machine: > > Setting up dmeventd (2:1.02.185-2) ... > Created symlink /etc/systemd/system/sockets.target.wants/dm-event.socket → > /lib/systemd/system/dm-event.socket. > Setting up lvm2 (2.03.16-2) ... > Created symlink > /etc/systemd/system/sysinit.target.wants/blk-availability.service → > /lib/systemd/system/blk-availability.service. > Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-monitor.service > → /lib/systemd/system/lvm2-monitor.service. > Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-lvmpolld.socket > → /lib/systemd/system/lvm2-lvmpolld.socket. > > On the second machine: > > Setting up dmeventd (2:1.02.185-2) ... > Created symlink /etc/systemd/system/sockets.target.wants/dm-event.socket → > /usr/lib/systemd/system/dm-event.socket. > Setting up lvm2 (2.03.16-2) ... > Created symlink > /etc/systemd/system/sysinit.target.wants/blk-availability.service → > /usr/lib/systemd/system/blk-availability.service. > Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-monitor.service > → /usr/lib/systemd/system/lvm2-monitor.service. > Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-lvmpolld.socket > → /usr/lib/systemd/system/lvm2-lvmpolld.socket. > > > Or else, have you run systemctl on dmeventd, in order to change its > > status? > > I'm not sure what to do. I don't know anything about your machine, or the service provided by these symlinks. But my own experience is that systemd is not bothered about which of the two paths is the target, and renaming links with ln -sf doesn't affect running instances. But for easing the task of comparing configurations, you could just massage your listings so that any symlink targets listed as /lib… appear as /usr/lib…. Cheers, David.
Re: HDD long-term data storage with ensured integrity
On 10/04/2024 12:10, David Christensen wrote: Those sound like some compelling features. I believe the last time I tried Btrfs was Debian 9 (?). I ran into problems because I did not do the required manual maintenance (rebalancing). Does the Btrfs in Debian 11 or Debian 12 still require manual maintenance? If so, what and how often? I don't do balance at all, it's not required. Scrub is recommended, because it will detect any bit-rot due to hardware errors on HDD media. It scans the entire surface of allocated sectors on all drives. I do scrub usually monthly. -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
bluetooth keyboard done gone nuts
i use a logitech k270 keyboard and mouse for several years we had power outage for a couple of days now the keyboard is nuts the mouse works i get odd multiple sequences with a few, not all, keys if i type "ls" i get "l7s9u" space is "[ " there are a dozen or so other keys that are screwy this machine is running bullseye i plugged the dongle into a machine running bookworm and the same i got to a console via ctrl+alt+f1 and the same keyboard has fresh batteries
Re: Internet Access Problem
On 11/04/2024 20:53, Stephen P. Molnar wrote: I am running Bullseye and attempting to use QEMU/KVM virt-manager, on the computers on my LAN rather than Oracle VM VirtualBox. [...] However, when I pinged yahoo.com. I got the result: Reply from 169.234.75.136: Destination host unreachable. If the VM for some reason is configured with "user" network instead of vibr0 then it is expected: https://wiki.qemu.org/Documentation/Networking Note - if you are using the (default) SLiRP user networking, then ping (ICMP) will not work, though TCP and UDP will. Don't try to use ping to test your QEMU network configuration! Regular user running VM does not have enough privileges to send ICMP packets.
Logwatch does not report fail2ban on Debian 12
On Debian 10 and 11 hosts the e-mail logwatch generates has section like this: - fail2ban-messages Begin Banned services with Fail2Ban: Bans:Unbans postfix-sasl: [ 3:3 ] recidive: [ 88:155] sshd: [296:296] -- fail2ban-messages End - On Debian 12, that section does not appear. I have compared settings between hosts, I can not see difference. I tried to seem if fail2ban log format has changed, but they look the same to me. Troubleshooting on the Debian 12 host with # logwatch --debug High --service fail2ban shows logfile with the fail2ban info is read and the filter finds Ban, Unban etc. lines. With --debug High the resulting e-mail did have fail2ban-messages section, but still not the summary lines with numbers of Bans:Unbans. Is this a known issue, some configuration needs adjustment? My Debian 12 host is NOT upgraded from Debian 11, it is a fresh install. I did read Debian 12 Release notes, but can not find it mentioning logwatch or fail2ban. -- Tapio Lehtonen / Pori Sampolan ATK
