Re: [DNG] Chimaera CPU stuck
On 9/14/22 14:54, Luciano Mannucci wrote: On Wed, 14 Sep 2022 12:37:41 -0500 Hector Gonzalez Jaime via Dng wrote: kernel:[ 7336.007287] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0] if I write to the disk via dd nothing wrong happens... Luciano. Check which scheduler you are using, for virtual machine loads you might want to use "deadline", assuming your disk is sda, the first command checks your scheduler, the second changes to deadline. cat /sys/block/sda/queue/scheduler echo "deadline" >/sys/block/sda/queue/schedule Well, the disk seems to be "vda". Issueing root@bobby:~# cat /sys/block/vda/queue/scheduler gives: [mq-deadline] none Is it wrong? It's as it should be. Did you check this on the hypervisor? The use of vda suggests this was checked on a VM, please check the physical host, which is the one doing the I/O for your VM. The physical host is also the one that needs to have a few dedicated processors to perform I/O for the VMs. Luciano. -- Hector Gonzalez ca...@genac.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Chimaera CPU stuck
On 9/14/22 10:02, Luciano Mannucci wrote: On Wed, 14 Sep 2022 12:49:19 +0200 Luciano Mannucci wrote: vm.dirty_background_bytes=67108864 vm.dirty_bytes=268435456 Maybe this additional information is helpful: https://forum.proxmox.com/threads/io-performance-tuning.15893/ https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/ Hope that helps, Yes, it does! Works like a charm! I've been to quick... Now only if the data comes from the local LAN (not drossing routers or firewalls) I still get kernel:[ 7336.007287] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0] if I write to the disk via dd nothing wrong happens... Luciano. Check which scheduler you are using, for virtual machine loads you might want to use "deadline", assuming your disk is sda, the first command checks your scheduler, the second changes to deadline. cat /sys/block/sda/queue/scheduler echo "deadline" >/sys/block/sda/queue/scheduler -- Hector Gonzalez ca...@genac.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenVPN 2.5.1-3+devuan1 packaging vs best practices
On 7/26/22 10:00, Ken Dibble wrote:
On 7/25/22 09:29, Ken Dibble wrote:
This is the first time I have seen this with any package.
I have no idea whether it has happened with packages not installed on
my systems.
It is my understanding that best practice is noexec on /tmp and that
this is a Debian recommendation.
Here is the relevant line from /etc/fstab.
tmpfs /tmp tmpfs defaults,noatime,mode=1777,nosuid,noexec,nodev
0 0
Here is the error message.
sudo apt-get dist-upgrade
.
.
Preconfiguring packages ...
Can't exec "/tmp/openvpn.config.NDxHMl": Permission denied at
/usr/lib/x86_64-linux-gnu/perl-base/IPC/Open3.pm line 178.
open2: exec of /tmp/openvpn.config.NDxHMl configure 2.5.1-3+devuan1
failed: Permission denied at /usr/share/perl5/Debconf/ConfModule.pm
line 59.
.
.
The (apparent) recommendation from bug report 129289 in 2002 is to set
APT::ExtractTemplates::TempDir
in apt.conf to some directory which is mounted with exec
and
As of version 0.5.8, apt supports TMPDIR for determining where
apt-extracttemplates puts its temporary files. If you have a noexec
/tmp, use this or other documented means to make apt-extracttemplates
use a directory that does accept executables
As of 2018 Bug #887099, merged with sundry other bug reports of the same type
Control: reassign -1 debconf 1.5.61
Control: forcemerge 566247 -1
This appears to be a generic issue in debconf, so I'm reassigning it to
debconf and merging it with the existing bugs tracking the same issue.
There doesn't seem to be any activity after that.
Is there a best practice for the method of selecting and setting this
directory?
Thanks,
Ken
Replying to my own message:
It appears that this problem with debconf has been around for 2
decades and
the maintainers are at odds with the debian position about "/tmp" and
noexec.
That being said I am going with
echo "APT::ExtractTemplates::TempDir \"/var/tmp\";"
>/etc/apt/apt.conf.d/50extracttemplates
unless someone has a better idea or a reason not to.
I am aware that Debian does not by default clean up /var/tmp and it
will be my responsibility to
check it for things left around.
This would just make /var/tmp the target for attacks instead of /tmp if
you protect /tmp with noexec, you should do the same with /var/tmp.
I think you could use any root writable dir, I don't see why it would
need to be writable by all users, if apt* is running as root.
If you think it's simpler, you can create a file, say
/etc/apt/apt.conf.d/99-remounttmp.conf with this:
DPkg {
// Auto re-mounting of a exec-only /tmp
Pre-Invoke { "mount -o remount,exec /tmp"; };
Post-Invoke { "test ${NO_APT_REMOUNT:-no} = yes || mount -o
remount,noexec /tmp || true"; };
};
I don't remember where I found this, but have used it for a while.
Thanks,
Ken
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
--
Hector Gonzalez
ca...@genac.org
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] moving to a new system
On 6/24/22 10:56, o1bigtenor via Dng wrote: On Fri, Jun 24, 2022 at 10:19 AM Dr. Nikolaus Klepp via Dng wrote: Anno domini 2022 Fri, 24 Jun 09:05:39 -0500 o1bigtenor via Dng scripsit: Greetings Hoping that I'm not asking too many questions. (moving from debian testing to devuan testing (daedalus) the old system is under 5.17.xx and the new one is on 5.18 if that makes for differences) (I've learnt the hard way that just winging things means a LOT more work and even a greater chance for issues.) My existing system has been a work in progress for over 10 years. So I've gotten things set up quite the way that I like them so things change slowly but in that there are also less 'terror' moments when everything has gone 'goofy'. Is there any way to move over things like settings (and all the other pamphernania) for browsers and libreoffice and the like? I was thinking of doing things by using scp from the old system to the new one. Dunno if that would create issues or not. Any better ideas - - - - well I'm all ears!!! Move your home directory to the new system ... and use rsync, not scp. That seems simple - - - - except I've never used rsync yet. Suggestions for a good recipe to follow- - - please? from the new system (this will overwrite /home files if you have them): rsync -avxKSH root@oldsystem:/home/ /home/ means make a backup, show what you do, don't change filesystems, keep dirlinks, use sparse files, and keep hard links, from root@oldsystem:/home/ to your local /home/ Just don't do this for the root filesystem, unless it is to put it somewhere else This will use ssh for authentication, either use a key for authenticating, (man ssh-keygen) or change the user to what it needs to be. man rsync explains the options in detail. You can interrupt this command and run it again, it will continue where it left. TIA ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Hector Gonzalez ca...@genac.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] trouble with rdiff-backup
On 4/24/22 12:17, Hendrik Boom wrote: Suddenly it cannot write on a file system. Presumably the backup drive? The one it has already filled with 215831712 iK blocks and has abother 1608278664 available? Then more complaints about banned unicode characters, and then another similar backtrace ending with OSError: [Errno 30] Read-only file system Is anyone else having problems like these? Is rdiff-backup busted? Or is my new backup drive or my USB interface busted? This might mean your system detected a format problem with your backup disk, have you tried to remount it? Check your kernel log, if there is such a problem it would remount the disk read only. You can verify with the mount command and no arguments. If that is the case, you should umount the disk, and run fsck on it before trying to mount the disk again. -- Hector Gonzalez ca...@genac.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] PHP 8.1 depends on systemd?
I has had that dependency for a while, you should try the php packages from tdrnetworks: deb https://pkgs.tdrnetworks.com/apt/devuan chimaera main On 1/29/22 05:47, Mathieu ROY via Dng wrote: Hello, Trying to upgrade to PHP 8.1, I found out it now depends on systemd or systemd-tmpfiles (no package available). https://packages.debian.org/bookworm/php8.1-fpm Is it a choice made on Debian side or is PHP now really depending on systemd? Regards, ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Hector Gonzalez ca...@genac.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] kernel-update: initramfs fails to find swap
On 1/21/22 11:03, Florian Zieboll via Dng wrote: On Fri, 21 Jan 2022 10:34:28 -0500 tempforever wrote: Something to check/verify: If swap is listed in /etc/fstab, then make sure it is listed by UUID rather than block-id. I mention this, since I have a (commented out) swap line in /etc/fstab Yes, in the fstab, the swap partition is active and defined by (the correct) UUID. You should try the kernel in backports, 5.10.x failed to find my root partition, removing -quiet made it work sometimes, and changing to 5.15 fixed it. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Refracta have a static IP
On 7/13/21 3:41 PM, Steve Litt wrote: Hi all, I'm trying to make my new Chimera based Refracta have a static IP address at 192.168.0.199/24, in order that every other computer on the 192.168.0.0/24 subnet can easily access it, and so I can put it on my LAN DNS. So I made my /etc/network/interfaces look like the following, which follows the guidelines of "man interfaces": === auto lo iface lo inet loopback allow-hotplug eth0 iface eth0 inet static address 192.168.0.199 gateway 192.168.0.1 === Unfortunately, instead of the IP address being 192.168.0.199, it's a DHCP supplied 192.168.0.204 . What additional steps must I take to get my desired 192.168.0.199? Steve, this happens when you still have a dhcp client running, Check if you have something like isc-dhcp-client running and stop it, then you can configure the interface on your own. Additional note: When I used 192.168.0.40, which I KNOW is not in my leased DHCP range, the result was the same. What must I do to get a static IP at 192.168.0.199/24 ? Thanks, SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Hector Gonzalez ca...@genac.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] routing tables.
On 5/17/21 1:35 PM, Hendrik Boom wrote: I have found several authoritative-looking web pages on instructions to display and edit the routing tables. But none of them explains what the routing tabe entries *mean*. The routing table entries show the way your host can find other networks, local or remote. Each entry describes how to reach every connected network, and what it considers to be local to your connection. A special route, the default route, shows how to reach networks outside of your local scope. Other routing table entries may show how to reach other networks. When you configure your interface ethv0, a route to its local network will be shown, for example: with "ip route": 192.168.1.0/24 dev ethv0 proto kernel scope link src 192.168.1.10 with "netstat -rn" : Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ethv0 They both describe the same route, to network 192.168.1.0, with a 24 bit netmask (meaning you have 8 bits left for hosts in your network, from 192.168.1.1 to 192.168.1.254, with 192.168.1.0 being used to reference the network itself, and 192.168.1.255 as the broadcast address, where you would send data meant for every host in your network). If you want to reach say network 192.168.90.0/24 which is reacheable via host 192.168.1.2, you could add a route like this: ip route add 192.168.90.0/24 via 192.168.1.2 A special route to network 0.0.0.0/0 is the default route, which is used to reach any network of which your host has no knowledge. With ip show it looks like this: default via 192.168.1.1 dev ethv0 onlink with netstat -rn it looks like this: Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 ethv0 With route it can be added as: route add -net default gw 192.168.1.1 once you have your interface configured. -- Hector Gonzalez ca...@genac.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: Distribution upgrade issue
On 2/22/21 3:30 PM, Antony Stone wrote: On Monday 22 February 2021 at 22:26:17, Hector Gonzalez Jaime via Dng wrote: I've seen your original problem frequently, mysql and mariadb both are turned off during upgrades, and then apt-get goes on to install other packages, which might require a database to be running and have no control over this. A workaround is, whenever you have mysql (or mariadb) present, update it first and alone, like this: apt-get update apt-get install default-mysql-server # this command depends on your version, just reinstall mysql's server first. apt-get upgrade apt-get dist-upgrade This way mysql gets updated first, and will be running for the rest of your system. I like that - it sounds like an excellent tip (hard to see how it might be included in an automated update process, but that would of course be even better). Have you ever mentioned this to the Debian project, to see whether they consider this either to be a bug in the upgrade process, or at least a workaround worth documenting for people doing the upgrade? I had only seen this with external packages, so, no, I've never mentioned it. I think if packages depend on a database of any kind to be updated, they should wait for it to be done before they run their scripts, but then again, the database might not even be configured to run in the same system. Antony. -- Hector Gonzalez ca...@genac.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: Distribution upgrade issue
On 2/22/21 1:59 PM, Curtis Maurand via Dng wrote: On 2/22/21 4:26 AM, Pontus Goffe via Dng wrote: Putting this back on list. I still think you are doing it wrong, after changing your sources.list(s) you should, at least apt-get update apt-get upgrade apt-get dist-upgrade Ah. you have an extra step. The following is from the website doc. Update the package lists from the Beowulf repository. |root@devuan:~# apt-get update| Devuan Jessie users should now upgrade the Devuan repository keyring, and update the package lists again so packages can be authenticated. |root@devuan:~# apt-get install devuan-keyring| |root@devuan:~# apt-get update| If xscreensaver is running you should kill it now as it needs to be stopped before it can be upgraded. |root@devuan:~# killall xscreensaver| Now you can perform the upgrade. |root@devuan:~# apt-get dist-upgrade| I've seen your original problem frequently, mysql and mariadb both are turned off during upgrades, and then apt-get goes on to install other packages, which might require a database to be running and have no control over this. A workaround is, whenever you have mysql (or mariadb) present, update it first and alone, like this: apt-get update apt-get install default-mysql-server # this command depends on your version, just reinstall mysql's server first. apt-get upgrade apt-get dist-upgrade This way mysql gets updated first, and will be running for the rest of your system. Hector Gonzalez ca...@genac.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
