Re: Buster => Bullseye: doveadm now requires root privileges
Jesper Dybdal wrote: > Yesterday, I upgraded Buster => Bullseye. > I have a cron job that cleans up all old mail from the mailbox that I > use for my mobile phone by running "doveadm expunge" every night. > That worked fine in Buster, but now it fails: >> jdmobile@nuser:~$ doveadm expunge mailbox '*' before 25d >> doveconf: Fatal: Error in configuration file >> /etc/dovecot/conf.d/10-ssl.conf line 23: ssl_cert: Can't open file >> /etc/letsencrypt/live/nuser.dybdal.dk/fullchain.pem: Permission denied > Of course, doveadm cannot access the TLS key when running as a normal > user. But why should it try to access that key at all when I have just > asked it to clean up my own files in my own Maildir? Is there a way to > make it not try to access that key and do its job anyway? Or another > way to delete old mail? Solution is to move the contents of /etc/dovecot/conf.d/10-ssl.conf to another file in /etc/dovecot, like /etc/dovecot/ssl-keys.conf and then replace conf.d/10-ssl.conf with this: ,/etc/dovecot/conf.d/10-ssl.conf | ## | ## SSL settings | ## | | ssl = no | | !include_try /etc/dovecot/ssl-keys.conf ` That way it will not fail anymore for processes not having the correct permissions, like when being invoked by a normal user on the CLI. S° -- Sigmentation fault. Core dumped.
Re: Reboot required after updating firmware-amd-graphics?
local10 wrote: > Dec 7, 2022, 15:42 by to...@tuxteam.de: >> So a rough approximation to an answer would be "yes". > That was my thought as well but I was hoping maybe there was some > automagical way it could refresh itself in RAM. You can see firmware as kind-of an OS for the component. And just like the Linux Kernel can't refresh itself while running, (most of) the firmware running on a component can't do that, it (usually) needs to get reinitialized. This will happen during a reboot of the whole PC or (in many cases) by unloading and then reloading the Kernel module for that component. S° -- Sigmentation fault. Core dumped.
Re: OT: apache in shared environment
basti wrote: > my question is a bit OT but perhaps someone can help. > We use apache mpm_prefork and mod_itk in shared environment for > privilege separation. > Now we want to use http2. > As I understod: > - mod_itk need mpm_prefork > - mpm_prefork is not compatibe with mod_http2 > We have try to use mpm_event with PHP-fpm and different pools, but this > separate the php stack only. > Is there a way to get http2 work with mod_itk? If mod_itk *needs* preforking, then nothing can be done. Next step would probably be to investigate containerization, use something like Traefik to route requests for the different hosts or paths to a different container and create privilege separation that way. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Installing mysql-workbench on Debian Sid
Valerio wrote: > I need to install mysql-workbench package on debian sid, but i get > problems about missing dependencies. > The following packages have unmet dependencies: > mysql-workbench : Depends: libgdal29 (>= 3.3.0) but it is not > installable Depends: python3 (< 3.10) but 3.10.4-1+b1 is to be installed > Recommends: ttf-bitstream-vera but it is not installable > Recommends: mysql-utilities but it is not installable > Recommends: default-mysql-client is to be installed or > virtual-mysql-client > libgdal29 exists only for sh4 architecture. Is it possible to install > it in another way ? It looks like libgdal29 was never in any Debian release, so this package was probably created for Ubuntu. The Python-dependency (or more: conflict) also a problematic one here. Sid has moved on but the 3rd-party package mysql-workbench has not been updated and probably will not be updated until a released Debian version ships with python-3.10+. So with the missing libgdal29 and the python version being no longer available, you will not be able to install the package in Debian. See if there is an AppImage, Flatpak or Snap available or create a Ubuntu chroot and install it in there. Using a VM is also possible. Grüße, S° -- Sigmentation fault. Core dumped.
Re: Predictable Network Interface Names
Greg Wooledge wrote: > unicorn:~$ cat /etc/systemd/network/10-lan0.link > [Match] > MACAddress=18:60:24:77:5c:ec > [Link] > Name=lan0 Careful with that one. If you use VLANs then you suddenly get multiple interface with the same MAC and strange things will happen, because it matches for all of them. The failure-proof way of doing this is by adding "Type=ether" to the Match clause, which will only match the physical interfaces and not the subinterfaces. (Which will be of Type=vlan.): , | [Match] | MACAddress=18:60:24:77:5c:ec | Type=ether | | [Link] | Name=lan0 ` Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Authentication failed after su-
Stella Ashburne wrote: >> From: "Dan Ritter" >>> In a terminal, I typed: >>> >>> username@hostname:~$ su -l -c "wpa_passphrase JupiterRising 1234567890 > >>> /etc/wpa_supplicant/wpa_supplicant.conf" >>> Password: >>> su: Authentication failure >> That means that you failed to give the root password. > I disabled the root password during the process of installing Debian 11. > What should I do to resolve the issue? Use sudo. wpa_passphrase JupiterRising 1234567890 | sudo tee /etc/wpa_supplicant/wpa_supplicant.conf Grüße, S° -- Sigmentation fault. Core dumped.
Re: Ho to properly rebuild single module?
Grzesiek wrote: > I need to apply the following > https://lore.kernel.org/linux-rdma/1645106372-23004-1-git-send-email-mike.marcinis...@cornelisnetworks.com/T/#u > and rebuild ib_qib. The easiest way to ensure consistency would be to just rebuild the kernel package(s) as a whole: https://www.debian.org/doc/manuals/debian-kernel-handbook/ch-common-tasks.html#s4.2.3 S° -- Sigmentation fault. Core dumped.
Re: what to do with USB stick that gives badblocks errors
deloptes wrote: > I'm sure there are many ideas around, but I want to hear your opinion > so there is one USB stick that I noticed started mocking about errors when > booting off. > I ran badblocks (without options) and then with -s -n and this produced a > slightly different output. > Is the output resulting from the options or is something really wrong with > the USB > Should I throw it away? Yes. When even the lowly and beyond-cheap flash controller of a USB stick throws external errors, then it is time to just throw it away. > If no should I try reformat it No. S! -- Sigmentation fault. Core dumped.
Re: Job for apache2.service failed because the control process exited with error code.
William Torrez Corea wrote: > *How to fix this error?* > sep 28 21:26:24 apachectl[13245]: (98)Address already in use: AH00072: > make_sock: could not bind to address [::]:80 > sep 28 21:26:24 apachectl[13245]: (98)Address already in use: AH00072: > make_sock: could not bind to address 0.0.0.0: Something else is already listening on the IP (here the wildcard IP) and the port apache2 wants to bind to. Find out what this is (using ss or netstat) and switch it to a different port or get rid if it. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: debian-installer RAID question
Felix Natter wrote: > My question is: How does d-i know how the individual HDDs were combined > into a RAID1? For all that "sudo fdisk -l" shows, the disks are > "Linux raid autodetect". For all I see, it could be a RAIDX, X!=1 or > two different RAIDs Are there RAID headers on the partitions? Yes, there is metadata telling the code exactly what type of RAID it is and the IDs of the componenet devices it comprises of are. S° -- Sigmentation fault. Core dumped.
Re: how to forbid debhelper to modify /home ?
Roberto C. Sánchez wrote: > On Fri, Sep 03, 2021 at 08:03:23AM -0400, Greg Wooledge wrote: >> Out of curiosity, I checked my system to see if there were any system >> users with home directories under /home. The only one I found is "ntp". >> >> Then I looked at the ntp.postinst script, and it has this: >> >> adduser --system --quiet --ingroup ntp --no-create-home --home /nonexistent >> ntp >> >> So presumably my ntp user with /home/ntp as its home directory is from >> an older Debian release, and if it had been created under bullseye, it >> would look different. > How old is your system? I just checked a machine that I initially as a > Woody (3.0) system in 2001 and there is no ntp user directory under > /home. I have a system that was installed as either Slink (2.1) or Potato (2.2) and then kept on Unstable ever since. I *do* have sshd:x:104:65534::/home/sshd:/usr/sbin/nologin ntp:x:106:117::/home/ntp:/bin/false cupsys:x:130:106::/home/cupsys:/bin/false I don't have the directories, though. (Might have gotten lost over the years, though.) So there was a time in the past when system users home dirs were created in /home. Grüße, S° -- Sigmentation fault. Core dumped.
Re: nvme SSD and poor performance
Anssi Saari wrote: > Jochen Spieker writes: >> Stay away from the "discard" option and do not worry about SSD life. > What's the issue with the discard option? AFAIK, there may have been > issues with it in the decade before last but again AFAIK, today some > distros enable discard and some run fstrim on timer, both work. > But please share. This may be part cargo culting and part real problem. In the past it was shown that many SSD needed to flush their whole queue whenever a TRIM command was received and the Kernel was really zealos of sending those for every block freed. This basically neutered many SSD and even caused corruption issues on some especially shoddy ones. Some firmwares got fixed and newer drives don't suffer from the same problems, but even now end then you can find some devices on the lower end of the consumer spectrum behaving poorly when bombarded with TRIM commands. So in the end the consensous was to just play it safe and batch-TRIM once a week or day, because TRIMming on demand hasn't been shown to be a big win. It is far easier to fall back on that option than trying to good/bad-list specific drive or firmware versions and select the appropriate TRIM method. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Buster to Bullseye upgrade problem
Gareth Evans wrote: > So I would like to know if apt is not handling this properly, or if > the scenario of a file changing packages (see David's previous email) > is an expected exception to the (sort of) rule. > Shouldn't pitivi 0.999 be disregarded anyway as it's being upgraded? No, because Debian Policy says that partial upgrades are supported and must work. > It's not a conflict involving two Bullseye packages, nor with one from > Bullseye and one held/pinned etc, so I don't see why it should happen. This might be a genuine bug in one of the two packages here, where a Conflict/Breaks/Replaces dependendy was needed to move a file from one package to another. I think https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007 is part of that problem. Grüße, S° -- Sigmentation fault. Core dumped.
Re: Forbidden,,You are not allowed to access this!
Evelyn Pereira Souza wrote: > My guess is because I use a VPN. > Why Debian blocks VPNs? Because of repeated vandalism to the Wiki. At one point a decision had to be made to either restrict the access to certain IP ranges or make the whole Wiki read-only for everyone. Grüße, Sven (not a DD, just remembering stuff) -- Sigmentation fault. Core dumped.
Re: when will bullseye become stable?
Long Wind wrote: > it seems bullseye is somewhat behind scheduledo you have latest info about > release date? https://lists.debian.org/debian-devel-announce/2021/07/msg3.html "We plan to release on 2021-08-14." Grüße, S! -- Sigmentation fault. Core dumped.
Re: AppImages and Sandboxes
Richmond wrote: > I get this error. > ./Franz-5.7.0.AppImage > [3509:0807/163715.039384:FATAL:setuid_sandbox_host.cc(158)] The SUID > sandbox helper binary was found, but is not configured correctly. Rather > than run without sandboxing I'm aborting now. You need to make sure that > /tmp/.mount_Franz-jpX9Z2/chrome-sandbox is owned by root and has mode > 4755. Trace/breakpoint trap > How can I fix this error as the file is temporary? This problem is specific to any Electron-based app running from an Appimage. You can do two things: 1) Add "--no-sandbox" as a parameter when starting it. 2) Do "sudo sysctl -w kernel.unprivileged_userns_clone=1" to allow the necessary sandboxing to work. 2a) Create /etc/sysctl.d/00-local-userns.conf with kernel.unprivileged_userns_clone=1 in it to make this permanent. All other Distributions apart from Debian set this option by default and Debian 11 will follow suit. S° -- Sigmentation fault. Core dumped.
Re: Add btdu to debian repo
basti wrote: > what is the right way to get btdu (a ncdu like command line tool for > btrfs) to the debian repo? 1) File an RFP bug. Will probably result in nothing. 2) Package it yourself and file an ITP bug. mentors.debian.net for more information. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Missing some RAM?
local10 wrote: > BIOS-e820: [mem 0x-0x0009c7ff] usable > BIOS-e820: [mem 0x0009f800-0x0009] reserved > BIOS-e820: [mem 0x000f-0x000f] reserved > BIOS-e820: [mem 0x0010-0xafde] usable > BIOS-e820: [mem 0xafdf-0xafdf2fff] ACPI NVS > BIOS-e820: [mem 0xafdf3000-0xafdf] ACPI data > BIOS-e820: [mem 0xafe0-0xafef] reserved > BIOS-e820: [mem 0xe000-0xefff] reserved > BIOS-e820: [mem 0xfec0-0x] reserved > BIOS-e820: [mem 0x0001-0x00022fff] usable > e820: update [mem 0x-0x0fff] usable ==> reserved > e820: remove [mem 0x000a-0x000f] usable > e820: update [mem 0xafe0-0x] usable ==> reserved > e820: reserve RAM buffer [mem 0x0009c800-0x0009] > e820: reserve RAM buffer [mem 0xafdf-0xafff] Let's start from the back: > BIOS-e820: [mem 0x0001-0x00022fff] usable This is the memory region from 4GB to 8GB and a bit of remapped memory (or it would have ended at 0x0001). So we have 4GB plus 805306368 Bytes (768MN) or 4846MB beyond the 4GB 32bit area. Then we have this big reserved area: > BIOS-e820: [mem 0xafdf-0xafdf2fff] ACPI NVS > BIOS-e820: [mem 0xafdf3000-0xafdf] ACPI data > BIOS-e820: [mem 0xafe0-0xafef] reserved > BIOS-e820: [mem 0xe000-0xefff] reserved > BIOS-e820: [mem 0xfec0-0x] reserved 1344339968 Bytes or (roughly) 1282MB. The PCI memory area, ACPI tables, DMA stuff, etc. are located here. Some of the physical memory shadowed by this will be in the 768MB of memory from above. Then we have a bit of usable memory again: > BIOS-e820: [mem 0x0010-0xafde] usable 2949578752 Bytes or roughly 2812MB. And the rest is reserved or will be reserved, for example the lower 1MB for security reasons: > BIOS-e820: [mem 0x-0x0009c7ff] usable > BIOS-e820: [mem 0x0009f800-0x0009] reserved > BIOS-e820: [mem 0x000f-0x000f] reserved > e820: update [mem 0x-0x0fff] usable ==> reserved > e820: remove [mem 0x000a-0x000f] usable > e820: update [mem 0xafe0-0x] usable ==> reserved So in the end, we have 2812MB + 4846MB = 7658MB (approx) usable for the system as a whole. The Kernel and it data structures also take some of this, so to have ~7400MB as usable memory is not unreasonable. S° -- Sigmentation fault. Core dumped.
Re: Missing some RAM?
local10 wrote: > The "why 1G memory is missing?" thread got me thinking. My PC also > seems to be missing hundreds MB of RAM and that's how it's been for > years. I have 4*2GB RAM boards so, in theory, I should've had 8GB of > RAM but top shows only 7472.2MiB. Even after the MiB to MB conversion > there's still some RAM missing: 7472.2 MiB = 7835.169 MB. > Any ideas? Any way to get it back? Thanks The PCI memory area is probably to blame here. Also the kernel needs some memory for itself. Please reboot your system and then, as root do: dmesg | grep "e820" and post the output. That will tell us the memory map of your system and which regions are used or reserved. S° -- Sigmentation fault. Core dumped.
Re: exim4 as a smarthost with TLS
Reco wrote: > On Sat, Jul 31, 2021 at 02:45:34PM +0200, Sven Hartge wrote: >> Reco wrote: >> >> > Seems straightforward enough. >> > Edit /etc/exim4/exim4.conf.template, you'll need to comment out a block >> > similar to this: >> >> > .ifndef REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS >> > REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS = * >> > .endif >> >> > Do not touch second block (starting with .ifdef >> > REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS). >> >> > Execute /usr/sbin/update-exim4.conf. >> > Bounce exim4. >> >> > Smarthost certificate verification should be disabled after this. >> >> Wouldn't it be easier to just create /etc/exim4/exim4.conf.localmacros >> and put >> >> REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS = !* >> >> in it? > Could be. Will exim4.conf.localmacros apply to non-split exim config? It will *only* apply to a non-split config. For the split config you need to create a file like /etc/exim4/conf.d/main/000_localconfig instead. Documentation says: ,[ /usr/share/doc/exim4-base/README.Debian.gz |For split configuration, you can drop the local configuration file |anywhere in /etc/exim4/conf.d/main. Just make sure it gets read |before the macro is first used. 000_localmacros is a possible name, |guaranteeing first order. For a non-split configuration, |/etc/exim4/exim4.conf.localmacros gets read before |/etc/exim4/exim4.conf.template. ` S° -- Sigmentation fault. Core dumped.
Re: exim4 as a smarthost with TLS
Reco wrote: > Seems straightforward enough. > Edit /etc/exim4/exim4.conf.template, you'll need to comment out a block > similar to this: > .ifndef REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS > REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS = * > .endif > Do not touch second block (starting with .ifdef > REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS). > Execute /usr/sbin/update-exim4.conf. > Bounce exim4. > Smarthost certificate verification should be disabled after this. Wouldn't it be easier to just create /etc/exim4/exim4.conf.localmacros and put REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS = !* in it? That way you don't need to edit the template (causing a merge prompt on the next exim4 update). This is also the way the README.Debian suggest doing this. S° -- Sigmentation fault. Core dumped.
Re: removing modules
Hans wrote: > However, building an own kernel might improve security, i.e. on my > servers I removed the usbmodule and cdrom stuff, so that no one could > easy connect evil hardware to the servers (we sometimes got visitors > in the data processing center) Or you could just blacklist those modules to prevent them from being auto-loaded. Serves the same purpose without needing to manually build update Kernels. S° -- Sigmentation fault. Core dumped.
Re: bad fstab entry prevents ssh from starting [where do i file a bugreport?]
Horatiu Nimigean wrote: > if one entry in fstab fails, ssh fails to start and the vps/bare metal needs > rescue. > What causes this ? I suspect it's some systemd dependency, that's why I am > asking here. If an entry in /etc/fstab is not marked "nofail", then a failure to mount will cause the system to go into its rescue mode. This is expected and usually the right thing to do to prevent a partially constructed system from starting service which may try to read or write data from or to the wrong destinations. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: /run/user/1000 errors
Gary L. Roach wrote: > Thanks for the reply. Your suggestion to use the Ctl-Alt-F2 console > worked. Although it worked, it is a pain to use as a normal way of > installing software. Any suggestions as to how to fix the root cause? Quite simple: Don't use just "sudo", use "sudo -i" or "su -" to become root. Any other method will keep parts of your users environment active, causing the problems you noticed. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Ghost cronjob
Mart van de Wege wrote: > Nope, not ephemeral at all, it's PID 1. Since I don't have timers > running this job, apparently there's a zombie process somewhere? PID 1 hints at a systemd.timer, even if you have dismissed this previously. Also the start time of just after midnight hints at this. And when I look at the current btrbk package in Sid/Testing I do indeed see it ships a timer in /usr/lib/systtemd/ So, there is your answer then. Also check via "systemctl list-timers". S° -- Sigmentation fault. Core dumped.
Re: problem with debian
Andrei Nae wrote: > Hi, I have a debien OS installed on VMware. When i do the command nano > /etc/apt/sources.list, I don’t have the debian.map.fastlydns.net > written in the file but as soon as I try to do apt update it tells me > that debian.map.fastlydns.net can’t be reached. You will have deb.debian.org in there which is debian.map.fastlydns.net. Maybe your VM is using IPv6 and your IPv6 connectivity downstream is broken. Or something else related to the networking for you VM is not working correctly, hard to diagnose without further information. S° -- Sigmentation fault. Core dumped.
Re: Boot better have mounted on root or /boot ?
Greg Wooledge wrote: > On Thu, Apr 08, 2021 at 08:55:47AM +0800, Robbi Nespu wrote: >> Filesystem Size Used Avail Use% Mounted on >> /dev/sda1 110G 62G 43G 60% / >> >> What actually the best way for boot directory? put on same root directory >> like I have right now or it better to have it own partition? > The only time you *need* to make it a separate partition is when > you're doing certain flavors of disk encryption. Under those setups, > you need an unencrypted /boot so you can boot and mount your encrypted > root file system. Not even when doing FDE. GRUB2 is able to decipher LUKSv1 volumes. But, given that LUKSv1 has been superceded by the newer v2 format, I would still create a separate /boot, so only it needs to be encrypted using the potential weaker LUKSv1 format while the rest of the system can be on a LUKv2 volume. https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html S° -- Sigmentation fault. Core dumped.
Re: fail2ban Squawk
Martin McCormick wrote: > I was attempting to setup a systemd timer and checking the syntax of > that when I ran across a complaint from the fail2ban program which is > a bit confusing. It reads: > /lib/systemd/system/fail2ban.service:12: PIDFile= references path below > legacy directory /var/run/, updating /var/run/fail2ban/fail2ban.pid → > /run/fail2ban/fail2ban.pid; please update the unit file accordingly. > So I looked in to that file and the actual line they were > referring 2 is numbered 15 and points fail2ban.pid to > /var/run/fail2ban/fail2ban.pid where it certainly lives with a > recent date. What is the problem exactly? As already has been said, there is no problem here. It is just systemd being a bit too overly chatty and warning about things the package maintainer would need to address. You (and I) as mere users should do nothing here. Of course, you could create an override config file to system and point the PID file to the path directly under /run to silence the message but that may create a problem after an upgrade to a newer package version, for example when a PID file is no longer used but you addition still points to one. This is best left alone. Side note here: In systemd (247.3-2) the Debian maintainers patched systemd to no longer issue those warnings for unit files provided in /lib and /usr/lib (i.e. provided by a package) to stop annoying end-users about issues they can do nothing about. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Hardware failure?: Now what? Is this worth pursuing?
Charles Curley wrote: > On Mon, 22 Mar 2021 13:52:27 -0600 Charles Curley > wrote: >> I ran an amd64 VM for 24 hours, and no errors. I just fired up a 486 >> VM, and no errors. I will let that run 24 hours and see what that >> does. >> >> The i386 VM is "qemu32". I see a kvm32 in my list of options. I may >> try that as well. > I ran the VM as qemu32 for a few seconds, and got 7 more errors. I > then switched the VM to "kvm32". I have been running that for about an > hour and seen 27 more errors. Still, that strikes me as pretty > conclusive. > Is this even worth pursuing? Only as an amusing part-trick: "Look here folks, I can create an MCE on demand." Other than that: Intel has acknowledged the defect as an official erro^Werratum and documented it. So "case closed" in that regard. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Hardware failure?: Now what?
Charles Curley wrote: > Mar 20 13:58:29 hawk rasdaemon[892]: Calling ras_mc_event_opendb() > Mar 20 13:58:29 hawk rasdaemon[892]: cpu 03:rasdaemon: mce_record store: > 0x55c124c9b148 > Mar 20 13:58:29 hawk kernel: [ 300.407406] mce: [Hardware Error]: Machine > check events logged > Mar 20 13:58:29 hawk kernel: [ 300.407410] mce: [Hardware Error]: CPU 3: > Machine Check: 0 Bank 0: 904f0005 > Mar 20 13:58:29 hawk kernel: [ 300.407411] mce: [Hardware Error]: TSC > f442c87fda > Mar 20 13:58:29 hawk kernel: [ 300.407413] mce: [Hardware Error]: PROCESSOR > 0:306c3 TIME 1616270309 SOCKET 0 APIC 6 microcode 19 > Mar 20 13:58:29 hawk rasdaemon[892]: rasdaemon: register inserted at db > 1 2021-03-20 13:58:30 -0600 error: Internal parity error, mcg mcgstatus=0, > mci Corrected_error Error_enabled, mcgcap=0x0c09, > status=0x904f0005, tsc=0xf442c87fda, walltime=0x605653e5, > cpu=0x0003, cpuid=0x000306c3, apicid=0x0006 > 2 2021-03-20 14:07:07 -0600 error: Internal parity error, mcg mcgstatus=0, > mci Corrected_error Error_enabled, mcgcap=0x0c09, > status=0x904f0005, tsc=0x274d9e61020, walltime=0x605655ea, > cpu=0x0003, cpuid=0x000306c3, apicid=0x0006 > 3 2021-03-20 14:07:07 -0600 error: Internal parity error, mcg mcgstatus=0, > mci Corrected_error Error_enabled, mcgcap=0x0c09, > status=0x904f0005, tsc=0x27517a5dacb, walltime=0x605655eb, > cpu=0x0003, cpuid=0x000306c3, apicid=0x0006 > 4 2021-03-20 14:10:34 -0600 error: Internal parity error, mcg mcgstatus=0, > mci Corrected_error Error_enabled, mcgcap=0x0c09, > status=0x904f0005, tsc=0x30ea8517bee, walltime=0x605656b9, > cpuid=0x000306c3 > If I read that correctly, CPU 3 is seeing and correcting internal parity > errors. Correct. > The board is an ASUS H97M-E, bios date 05/15/2015. Processor is > Intel(R) Core(TM) i7-4790S CPU @ 3.20GHz, with eight processors. > Now what? Nothing really. Check if there is a BIOS/Firmware update available. Check if the voltages are set correctly in the BIOS/Firmware. (Usually by loading the defaults and setting everything to "auto".) Check temperature of the CPU. Check if the latest intel-microcode package from Debian is installed (3.20201118.1~deb10u1 at the moment) or grab the newest one from testing (3.20210216.1). Try running mprime95 in test mode for some time to see if it complains and if errors occur more often when under load. Also run memtest86+ for some time to verify the correctness of your RAM. In the end, if the error is something in one of the caches inside the CPU, there is nothing really you can do. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: [EVEN MORE OFFTOPIC] Re: [?] Why should Distros be called as i386 for a 32-bit PC, and as amd64 for a 64-bit PC, when Intel Core PCs are also 64bit systems
Christian Groessler wrote: > On 3/15/21 10:47 PM, Andrei POPESCU wrote: >> On Lu, 15 mar 21, 20:24:56, Sven Hartge wrote: >>> (I still vividly remember using memmaker and manual ordering the drivers >>> in config.sys and autoexec.bat to shave another 2KB from the lower >>> memory so the IPX driver would fit so Doom would run.) >> For me it was Warcraft :) >> And for some game (possibly also Warcraft) I had to pretend having a >> sound card by listing the driver in config.sys, otherwise it wouldn't >> even start. > For me it was "Worms". > And I was using QEMM and Quarterdeck Manifest to get maximal memory in > the lower 640k. Ooooh, look at Mr Fancy here, cheating with 3rd party products to get ahead :) I'll throw in the special "maximise XMS memory boot disk" I had for Comanche because that game just *hated* emm386.exe but without EMM, stuff like "LOADHIGH" to push drivers into the UMB was not available and I was too lazy to add another branch to my already convoluted config.sys boot menu. S° -- Sigmentation fault. Core dumped.
Re: [TOTALLY OFFTOPIC] Re: [?] Why should Distros be called as i386 for a 32-bit PC, and as amd64 for a 64-bit PC, when Intel Core PCs are also 64bit systems
Stefan Monnier wrote: > From a purely technical perspective, it's hard to understand how Intel > managed to pour so much energy into such an obviously bad idea. The > only explanations seem all to be linked to market strategies. This history repeats for Intel on several fronts: Look at the Netburst Pentium 4 desaster, which as scrapped as soon as the Israel division showed their improved concept based on the P3, which ran laps around the P4 while at the same time using far less power and had a bigger yield. Or the discussion about ECC for desktop devices. Intel argues "not needed", which is, if you follow the Rowhammer issues, not true. AMD just does it and it works. Then there was FB-DIMM back in the 2008s. Nice idea, just, again, too expensive and disconnected from the market in the end. And all in all the rather slow improvments on the CPU fronts, the piecemeal 5% increases sold as "big achievements" every year, while at the same time all improvements turned out to be major security problems. I personally am really glad that AMD got their stuff together again and with their ZenX-Architectures showed Intel how it is done. What AMD now needs is a hit in the low, lower and ultra-low power segment. Grüße, S° -- Sigmentation fault. Core dumped.
Re: [EVEN MORE OFFTOPIC] Re: [?] Why should Distros be called as i386 for a 32-bit PC, and as amd64 for a 64-bit PC, when Intel Core PCs are also 64bit systems
Joe wrote: > On Mon, 15 Mar 2021 12:34:42 +0100 Sven Hartge wrote: >> Imagine a PC with 4GB adressable memory space in 1980. > I can. It would have cost as much as a mainframe to make full use of it. I don't say to put it in, only to have a flat 32bit address range. Just like the current 64bit systems don't have 16 Exabyte of memory in them. (I still vividly remember using memmaker and manual ordering the drivers in config.sys and autoexec.bat to shave another 2KB from the lower memory so the IPX driver would fit so Doom would run.) S° -- Sigmentation fault. Core dumped.
Re: [EVEN MORE OFFTOPIC] Re: [?] Why should Distros be called as i386 for a 32-bit PC, and as amd64 for a 64-bit PC, when Intel Core PCs are also 64bit systems
to...@tuxteam.de wrote: > On Mon, Mar 15, 2021 at 11:09:35AM +0100, Sven Hartge wrote: >> Another rumor I read was that IBM, when developing the first IBM PC >> in 1980, opted to use the 8086/8088 CPU instead of the also availble >> M68k CPU because the Intel one was less powerful so it would not be >> in competition with the mainframes the PC was supposed to interface >> with primarily. > Too lazy to research now, but it sounds credible, yes. >> If this rumor is true and IBM had acted differently, the PC ecosystem >> today would also look quite differently. > Or the Z8000. Absolutely. 8086 was, architecturally, the worst possible > choice at that time. Having had a 68k would have been awesome. No stupid memory segmentation, 32bit instructions and internal address size, 24bit external address size. Imagine a PC with 4GB adressable memory space in 1980. S° -- Sigmentation fault. Core dumped.
Re: [EVEN MORE OFFTOPIC] Re: [?] Why should Distros be called as i386 for a 32-bit PC, and as amd64 for a 64-bit PC, when Intel Core PCs are also 64bit systems
to...@tuxteam.de wrote: > On Mon, Mar 15, 2021 at 09:15:10AM +0100, Sven Hartge wrote: >> For the others: they where either on board from the start (like HP), >> where already dead (like DEC/Compaq) or slipping into the embedded >> market (like MIPS). > MIPS had its chance to become the unified architecture for high-end > workstations [1]. Until it was bought up by Silicon Graphics (SGI). > Which, on the one hand was bitterly needed by MIPS, because they > needed that cash injection, and by SGI, because they depended on the > MIPS architecture. > On the other hand, though, all other workstation developers, in fierce > competition with SGI, didn't want /that/ dependency and went to look > for/make other architectures (Power, Alpha, PA, you name it). > So on the one hand, we might have, these days, been running on MIPS; > on that other hand, we wouldn't have ARM, and -- who knows, soon, > Risc-V. And Linus Torvalds wouldn't have had this cool stint at > Transmeta. But that is a totally different kettle of fish. Another rumor I read was that IBM, when developing the first IBM PC in 1980, opted to use the 8086/8088 CPU instead of the also availble M68k CPU because the Intel one was less powerful so it would not be in competition with the mainframes the PC was supposed to interface with primarily. If this rumor is true and IBM had acted differently, the PC ecosystem today would also look quite differently. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: [OFFTOPIC] Re: [?] Why should Distros be called as i386 for a 32-bit PC, and as amd64 for a 64-bit PC, when Intel Core PCs are also 64bit systems
Stefan Monnier wrote: >> Note: when IA64 was designed (starting in 1994 at HP) we where nowhere >> near the limits of the 32bit i386 architecture with RAM and frequency, >> so it made sense, somewhat. > Indeed. Also, they wanted to move away from the i386 instruction set > so as not to be bothered by pre-existing licensing agreements with > AMD, and thus making sure there'd be no competing implementation. The > IA64 architecture was quite complex, and there are reasons to believe > that complexity was seen as a virtue (makes it easier to get more > patents and keep competitors out). HP then also poured additional stuff into the architecture to make migration from PA-RISC easier. I imagine this also made stuff vastly more complex. >> But years passed and the i386 architecture got better and better, >> including stuff like MMX, SSE and AVX was incorporated, IA64 couldn't >> really keep up. > The IA64 architecture was a resounding success in one area tho: it > killed most of the competition that was coming from "above" (at least > DEC's Alpha, SGI's MIPS, HP's PA, and it likely sped up the demise of > Sun's SPARC, I don't think it had much impact on POWER or PowerPC, > OTOH) and thus helped open up the server (and supercomputer) market > for Intel (and AMD). I think, IBM is big enough and old enough and established enough with POWER that a "young whippersnapper" like Intel is no real danger to them in their own enclosed Mainframe walled garden. I believe Apple moving away from PowerPC did more damage to IBMs aspirations in that market. For the others: they where either on board from the start (like HP), where already dead (like DEC/Compaq) or slipping into the embedded market (like MIPS). And SPARC: after being bought by Oracle, the end was more or less directly clear. >> Dnd when AMD then presented their AMD64 architecture that could run >> legacy 8bit/16bit/32bit code as fast as the new code, allowing for a >> smooth transition, the nickname "Itanic" for IA64 became true: It had >> been dead on arrival. > To make matters worse, the IA64 arrived very late to the market (IIRC > something like 3 years later than planned). Indeed. The German computer magazine c't had many interesting articles about the IA64 architecture and also quite early painted its dark future, because of ever slipping sales figures, performance problems, the failure to deliver on made promises and the increasing pressure of the i386/amd64 architectures. Grüße, S° -- Sigmentation fault. Core dumped.
Re: [?] Why should Distros be called as i386 for a 32-bit PC, and as amd64 for a 64-bit PC, when Intel Core PCs are also 64bit systems
Andrei POPESCU wrote: > On Du, 14 mar 21, 07:19:25, The Wanderer wrote: >> When 64-bit came along, rather than extending the x86 line, Intel >> started from scratch and designed an entire new CPU architecture. >> That got called ia64, and it never caught on; it eventually failed in >> the marketplace, except possibly in very limited market segments. >> when Intel created a 64-bit architecture (called ia64), it turned out >> to be a developmental dead end and failed in the marketplace. > As far as I recall from articles at the time, there were good reasons > to use the opportunity of the transition from 32 to 64 bits to create > a completely new architecture. > Regardless of the merits (or not) of the ia64 architecture, Intel > simply tried to force the industry to follow its lead, at significant > additional costs (see RAMBUS), but the industry chose amd64 instead. IA64 (Itanium) was completely incompatible with the installed i386 base. The first CPUs had a (very slow) compatibility layer, assisted by software, so you could run your "legacy" 16bit/32bit applications. Also the CPU was designed so that many complexities where delegated into the compiler to create the most optimal code but the compilers at the time where not up to the task, greatly hampering the new architecture. Intel envisioned IA64 to be the go to processor for centralized server-based loads, whereas the i386 was for your on-the-desk PC. (Just like at the start of the IBM PC it was enivsioned as a kinda-smart terminal for the mainframe. The SysRq-Key is the last remnant of that legacy.) Note: when IA64 was designed (starting in 1994 at HP) we where nowhere near the limits of the 32bit i386 architecture with RAM and frequency, so it made sense, somewhat. But years passed and the i386 architecture got better and better, including stuff like MMX, SSE and AVX was incorporated, IA64 couldn't really keep up. Dnd when AMD then presented their AMD64 architecture that could run legacy 8bit/16bit/32bit code as fast as the new code, allowing for a smooth transition, the nickname "Itanic" for IA64 became true: It had been dead on arrival. S° -- Sigmentation fault. Core dumped.
Re: user unit file
Jim Popovitch wrote: > Please be gentle. Searching for this is proving futile. > How do I enable systemd user (--user) unit files that are maintained in > a user's home directory at /home/bob/.config/systemd/user/*.service ? What do you mean with "enable"? "Enable" as in "enable support"? Then everything is enabled. Or "enable" as in "enable the unit"? Then "systemctl --user enable unitname.service" does what you want. Or "enable" as in "start at boot"? Then you to enable lingering for the user via loginctl as root. S° -- Sigmentation fault. Core dumped.
Re: Firefox and Citrix on Debian Testing
Semih Ozlem wrote: > Just out of curiosity, does one have to be in an organization that has a > contract with citrix to be able to use citrix products or is it available > for individual use? If you are willing to pay the huge amount of money for a Citrix infrastructure, you can of course use it as an individual. S° -- Sigmentation fault. Core dumped.
Re: Tora 3 for Bullsey?
Harald Dunkel wrote: > how comes there is not Tora for Bullseye? It was removed from Sid and Testing in 2019 because it was not compatible with Qt5 and only available for Qt4 and was not reuploaded ever since: https://tracker.debian.org/pkg/tora https://tracker.debian.org/news/1057870/removed-213-4-from-unstable/ Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Looking for where to file a bug
Joshua Brickel wrote: > I am running debian testing (bullseye). But something happened in the > package manager such that I can no longer install packages. When I > try I keep getting the following message: > The following packages have unmet dependencies: > gsettings-desktop-schemas : Breaks: mutter (< 3.31.4) but 3.30.2-9~deb10u1 > is to be installed > E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused > by held packages. > Should I file this against dpkg or against a different package? There is no bug in any package here, all are behaving as they should. The problem is that some package dependencies are currently broken in Testing, as it seems. This will solve itself once this has been corrected by the DDs responsible for the packages involved. But you seem to have Buster in your sources.list (as seen by the version 3.30.2-9~deb10u1). Remove those lines and try again. Also check if you have any held packages. You can do so via apt-mark showhold Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Accessing raid from multiple hosts
Michael Howard wrote: > On 07/02/2021 15:44, Sven Hartge wrote: >> Michael Howard wrote: >>> On 07/02/2021 14:35, john doe wrote: >>>> I have a multiboot system (Buster and Stretch),, the raid was >>>> configured on Buster and works well. >>>> now, I need to access that same raid from Stretch. >>>> Has anyone been able to access a raid from multiple hosts, if yes, >>>> how did you do it? >>> iSCSI? >> Why? >> >> The RAID is on the same system. They clearly wrote "multiboot". > OP did indeed write multiboot but he also wrote 'multiple hosts' Hmm, indeed. > You have a problem? Only with OP not describing his setup and problem clearly enough. S° -- Sigmentation fault. Core dumped.
Re: Accessing raid from multiple hosts
john doe wrote: > Debians, > I have a multiboot system (Buster and Stretch),, the raid was configured > on Buster and works well. > now, I need to access that same raid from Stretch. > Has anyone been able to access a raid from multiple hosts, if yes, how > did you do it? That should work out of the box. Have you tried it and it didn't work? What errors did you get? S° -- Sigmentation fault. Core dumped.
Re: Accessing raid from multiple hosts
Michael Howard wrote: > On 07/02/2021 14:35, john doe wrote: >> I have a multiboot system (Buster and Stretch),, the raid was configured >> on Buster and works well. >> >> now, I need to access that same raid from Stretch. >> >> Has anyone been able to access a raid from multiple hosts, if yes, how >> did you do it? > iSCSI? Why? The RAID is on the same system. They clearly wrote "multiboot". S° -- Sigmentation fault. Core dumped.
Re: Download Pages are, Locked??!???
Stephen P. Molnar wrote: > Suddenly the download pages are forbidden? My guess is that this has to do with the Debian 10.8 point release ISO image preparation. S° -- Sigmentation fault. Core dumped.
Re: One network card many rj45 sockets
David Christensen wrote: > One feature of link aggregation is increased throughput -- two physical > connections can work together as one logical connection that is twice as > fast. With the caveat that this does not increase the throughput of a single flow. > But the killer feature is redundancy -- if every device is connected > to two different switches, you can do maintenance on one switch and > the network will remain up via the other switch. Noteworthy here: If you want to do 802.3ad (aka LACP) the switches need to be either stacked, use VSS/IRF or be compatible with MLAG/MC-LAG. If you don't have such switches, you are limited to active-backup or TLB/ALB-mode of the bonding code. S° -- Sigmentation fault. Core dumped.
Re: Some questions around needrestart utility
l0f...@tuta.io wrote: > Can someone explain me how needrestart (in interactive advanced mode) > preselects services to be restarted please? I mean when I launch it, > only some services are preselected while others are not.So according > to what criteria? Does it preselect those whose reboot has less > impact on the machine? All this is configured via /etc/needrestart/needrestart.conf. Services can be blacklisted and will never even show up and services can be overridden and will show up but will be deselected, for the admin to manually select them to be restarted should they so desire. The configuration provides a selection of pre-defined overrides, based on experience of the author(s), bug reports and input from users. You will find networking stuff like "NetworkManager" or display managers like "lightdm" in there to prevent you from sawing off the branch you are sitting on. All this can be of course tailored to your own liking. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: x2goagent: high CPU load with Xfce 4.16
Stefan Pietsch wrote: > I am experiencing problems with X2Go on a virtual server machine I am > connecting to. The process x2goagent on the server has high CPU usage > (nearly 100%) when connecting with x2goclient and selecting Xfce as > desktop environment. > CPU load of x2goagent on the server remains normal when selecting LXDE > or MATE in the x2goclient connection. > When I downgrade Xfce 4.16 back to Xfce 4.12 from stable, the CPU load > of x2goagent remains low, as expected. > I reproduced this with a newly created VM running Debian testing. > Currently I'm not sure if this is a bug in Xfce or X2Go. Changes in the compositor settings for Xfce maybe? S! -- Sigmentation fault. Core dumped.
Re: dpkg SquirrelMail on Jessie
hobie of RMN wrote: > Restating: I've installed the *.deb of Squirrelmail 1.4.23 SVN but don['t > see where to direct the browser in order to engage with it. Anyone > know...? The package should contain a configuration making it available via http(s)://server.name/squirrelmail But how and if this works depends solely on your local server configuration. Look into /etc/squirrelmail/apache.conf and where and how this is included into /etc/apache2 on your system. Other than that, without knowing your local setup, no more help can really be given. Please make sure to have version 1.4.23~svn20120406-2+deb8u4 installed, which was the last security update available. But, I must stress again: This version still has known security errors and if you intent to open this version on Jessie to the internet, the chances are very high your system will get hacked and compromised. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: dpkg SquirrelMail on Jessie
hobie of RMN wrote: > I have a server running Jessie (oldoldstable) that has had > Squirrelmail 1.4.2 (installed manually) on it for a very long time. > At some point, years ago, SM became confused by a change in > charactersets (UTC-8, is it?), leading to erratic dropping of lines of > text. I've just installed SM 1.4.3 from a Debian package - but I > don't see where it's to be accessed via browser. (??) Anyone know...? Jessie is no longer supported. You should not run any system or infrastructure on this Debian release. Furthermore, squirrelmail is also no longer developed or maintained, I strongly advise against using it. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: recommendations for supported, affordable hardware raid controller.
Nicholas Geovanis wrote: > On Sat, Jan 2, 2021, 5:49 AM Sven Hartge wrote: >> My advise: Don't bother "learning RAID controllers". > Im afraid I have to agree with this advice. In the presence of > software like ZFS (from Sun) and LVM (from IBM's AIX), with easy > availability of NAS, SAN and cloud storage, the arguments in favor of > hardware RAID local to a server become much thinner. What drives that > change is the evolution of hardware and networking, not so much the > software. Both ZFS and LVM are now 20 years old, very mature software. I see in my environment real RAID controllers only for special systems: 1) standalone ESX servers 2) standalone Windows servers For ESX servers, as soon as there are 2 or more, they usually are part of a VSAN (which wants direct access to the disks) or connected to a proper SAN (mainly NetApp) and boot off of a pair of SD cards or a BOSS-card containing 2 NVMe modules. (While the latter is kind-of a RAID controller, it is as simple as they get.) For Windows servers, the water gets a bit muddles by the existance of "Storage Spaces", which is more like LVM an Linux, allowing for a RAID-like usage for every volume created therein. In that case, the Windows server also gets a very simple RAID controller or a BOSS card to boot from. And that is mostly it. Everything else uses MD-RAID and ZFS or uses object storage provided by (for example) MinIO. RAID controllers served a purpose when the CPUs were slow, the bandwidth between the memory, the CPU and the storage was bottlenecked and you needed a special RAID CPU to offload the needed calculations. But today: No such thing anymore. My personal measurements using an LSI card in IR and in IT mode also confirm this: Using IT mode which just passes the disks through to the system and using ZFS in RAIDZ2 mode was leaps and bounds faster than the RAID6 mode native to the controller. Then add in the faster resilver in case of failure, the ability to checksum every block and guarantee the correctness of the data and ZFS wins by a large stretch. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: recommendations for supported, affordable hardware raid controller.
Steven Mainor wrote: > The idea was to create a large striped raid array(perhaps RAID6) of > spinning disks to use as a large storage area for extra VM backups and > large projects I'm working on. And in the process I could learn more > about RAID controllers. To be honest: RAID controllers are on their way out, a thing of the past. Performance-wise, MD-RAID or ZFS on Linux is faster than doing the same via a RAID controller, while at the same time having far less complexity and failure points. RAID controllers need a prioprietary tool to configure and maintain them, hide your disks behind a single block device and then often make it difficult or impossible to check them, for example via smartd. You have to rely on the proprietary tool to notify you of a disk failure and hope it works and keeps working. I have quite often seen these tools only be availble for ancient Red Hat versions and a pain to get to work on anything else. My advise: Don't bother "learning RAID controllers". Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: recommendations for supported, affordable hardware raid controller.
Dan Ritter wrote: > Steven Mainor wrote: >> I'm looking for recommendations for a 6 or 8 port SATA hardware raid >> controller that will hopefully be supported by the kernel and/or open >> source drivers to put in my desktop computer. Any input welcome, >> thanks. > Having used them for 20+ years now, I strongly recommend against > hardware RAID controllers. Hardware SAS/SATA interfaces with mdadm or > ZFS are better in every one of my use cases. I second that motion. Unless using Windows or ESXi outside VSAN you better avoid RAID controllers. More hassle than gain, IMHO. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Some recent update to unstable seems to have broken Xfce4 for me
Celejar wrote: > Some recent update to unstable seems to have broken Xfce4 for me: The Xfce team is uploading Xfce 4.16 at the moment. Because not all components can be uploaded in one go, this may cause some temporary problems or instability. I'd advise you to wait some days until all uploads have finished and then check back if the problem persists and file bugs if needed. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Electron apps in Debian with --no-sandbox
buckwheatpancake wrote: > So, Electron stuff in Debian comes with this annoying thing where it tells > you chrome-sandbox (in various applications) needs to be owned by root and > have mode 4755. If you set that, it just tells you the same, with another > file. I've taken to running these things with the --no-sandbox option, > because I don't know what the solution is... is this safe or recommended? You are hitting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446 and the fact that the Debian Kernel is patched to disable creation of user namespaces from non-privileged process. The canonically correct solution here is to do the following, as root: echo 'kernel.unprivileged_userns_clone=1' > /etc/sysctl.d/00-local-userns.conf service procps restart That should resolve this problem for now, until Debian concludes their discussion in the linked bug and enables this feature per default, as most other distributions already do. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Missing SATA Drives on ROMED8-2T Motherboard
Scott Colby wrote: > Well, I spent some more time reading dmesg logs and messing around in > the BIOS. I enabled SR-IOV [1] and the drives appeared! I'm not > entirely sure _why_ this worked, Yes, me neither. Maybe that option also changed something in the background as well. > but at this point (it's been over a week of messing with this), I'm a > bit tired of looking. If anyone has thoughts on why this change fixed > my problem, I'd love to hear them. No idea. Firmware/BIOS and its inner working is a deep black hole I try to stay away from. A former collegue of mine used to work on this stuff and told stories of how quirky and spaghetty-codey that stuff is, sometimes resembling first-year CS students code. S° -- Sigmentation fault. Core dumped.
Re: Missing SATA Drives on ROMED8-2T Motherboard
Scott Colby wrote: > On Tue, Nov 24, 2020, at 02:40, Sven Hartge wrote: >> Which would mean that the Kernel does not have a driver for the chip >> driving SATA0_3 as it seems. > Makes sense. >> Can you provide more information, for example a lspci listing? > No problem, here you go, with apologies for the linewidth: > 48:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA > Controller [AHCI mode] (rev 51) > 49:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA > Controller [AHCI mode] (rev 51) > 83:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA > Controller [AHCI mode] (rev 51) > 84:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA > Controller [AHCI mode] (rev 51) > Here also are what seem to be the relevant lines from my dmesg output, which > is from `dmesg | grep -i ata` with a few lines removed: > [9.902740] ahci :83:00.0: AHCI 0001.0301 32 slots 8 ports 6 Gbps 0xff > impl SATA mode > [9.905132] ahci :84:00.0: AHCI 0001.0301 32 slots 8 ports 6 Gbps 0xff > impl SATA mode > [9.911701] ahci :48:00.0: AHCI 0001.0301 32 slots 8 ports 6 Gbps 0xff > impl SATA mode Hmm. The controller at 49:00.0 is missing here. Could it be hosting the missing drives? Other than that: No idea. I don't see anything obvious, any glaring errors. S! -- Sigmentation fault. Core dumped.
Re: Missing SATA Drives on ROMED8-2T Motherboard
Scott Colby wrote:
> In all cases, the behavior was the same: all expected drives are
> reported in the firmware, and the drives attached to SATA4_7 show
> up in the OS (sd{a,b,c,d}), but the others are absent.
Which would mean that the Kernel does not have a driver for the chip
driving SATA0_3 as it seems.
Can you provide more information, for example a lspci listing?
What Kernel where you using? Did you try the one from backports?
Grüße,
Sven.
--
Sigmentation fault. Core dumped.
Re: Problem with /var/mail file > 2GB with pop3
Didar Hossain wrote: > Dovecot has "single instance attachment storage" (SIS) as well as its > own native mdbox binary format (multiple emails per file indexed > efficiently). > The SIS is a feature that I am really excited about since we have > multiple user receiveing the same email - it really saves on storage > space. Be careful with SIS in Dovecot. There be dragons! There are some yet-to-be-solved problems with it, mostly in the "remove attachments no longer needed" region. Scour the list archives before using it. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: initrd inspection
to...@tuxteam.de wrote: > On Mon, Nov 23, 2020 at 01:36:05AM -0500, Felix Miata wrote: >> Tomas composed on 2020-11-21 22:46 (UTC+0100): >>> You can inspect it like so: >> >>> gunzip < /boot/initrd.img-4.19.0-10-amd64 | cpio -it | less >> That was shortened to 'lsinitrd | less' in 2008 in openSUSE[1], >> which >> Mandriva already had, eventually upstream'd to dracut, I'm guessing well >> over 5 >> years ago, since I can't figure out how to find dracut's changelog. I wonder >> why >> Debian's dracut doesn't have it? > Hm. Apt-file search says (Buster) that /usr/bin/lsinitrd is in package > dracut-core (not installed in my box, so I can't double check now). Try initramfs-tools-core: /usr/bin/lsinitramfs Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Problem with /var/mail file > 2GB with pop3
Joe wrote: > That's why we have IMAP, which doesn't use mbox. The IMAP protocal and the backend storage have no connection. You can for example use mbox with Dovecot just fine. (Not that anyone would *want* to, but that is a different story.) Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Redundancy for EFI System Partition: what do people do in 2020?
Andy Smith wrote: > c) Manually sync the ESP to another partition which can be used if >the first device dies. >An identical partition can be created on the second device and an >arrangement made to copy the real ESP to the secondary partition >every time grub-install would be run. >You would have to be sure that this is as automated and foolproof >as possible, to avoid being lulled into a false sense of security >and then have a problem at the worst time. I choose c) for the systems here, including the syncing into our normal package upgrade scripts, making sure that /boot/efi and /boot/efi2 are in sync after every package update. Code looks like this: if [ -d /boot/efi/EFI/debian/ -a -d /boot/efi2/EFI/debian/ ]; then echo 'Multiple UEFI ESP found' if ! diff -rq /boot/efi/EFI/debian/ /boot/efi2/EFI/debian/; then echo 'ESP differ, need to rsync' rsync -rv /boot/efi/EFI/debian/ /boot/efi2/EFI/debian/ fi fi Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: MariaDB database under /home
Tony van der Hoff wrote: > It is known that the maintainers of MariaDB deprecate the database > files residing under /home, in fact going so far as making it an > error, unless /usr/lib/systemd/system/mariadb.service has > ProtectHome=true commented out. > Now, this is all very well, and I'm sure there are good reasons for > it, but I want my databases to reside in /home. Unfortunately, each > time there's an upgrade to the package my preferred setting gets > overwritten, resulting in MariaDB failing to start, and my having to > edit the service file on a number of machines. > I'd consider this a bug, but is there at least any way of making my > change more permanent? I hope you don't just edit /lib/systemd/system/mariadb.service as that will be overwritten on every package update. The correct way to do this is to use "systemctl edit mariadb.service" (or manually create /etc/systemd/servic/mariadb.service.d/foobar.conf) and put something like , | [Service] | ProtectHome=false ` into it. This will be kept on upgrades. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Stretch => Buster: iptables
Jesper Dybdal wrote: > * The CT target, to add the ftp helper. I fixed that by adding a bit of > native nft with the nft command after all the iptables(-nft) commands. For the sake of the archive and people looking at this thread hoping for some insight, please post your native nft rules you created. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Stretch => Buster: obsolete packages
Jesper Dybdal wrote: > I use squirrelmail, and squirrelmail uses php5. > Somehow both of those survived the upgrade from Jessie to Stretch (at > a time when I was not aware of the potential problem), and > squirrelmail still works fine. > Can I expect that they will also survive the upgrade to Buster? Expect? No. Unless you keep all the old and insecure packages and work around possible package conflicts. Besides: Squirrelmail is more or less dead. There is one lone sole comitting to the code base and trying to keep it updated but I would not trust any security on this. My advise: Scrap Squirrelmail and migrate to Roundcube. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: PATH nfg after su
Tixy wrote: > On Fri, 2020-10-23 at 08:19 -0400, Greg Wooledge wrote >> Using "sudo su -" is a new one to me. Not only are you wastefully >> running two programs when you only need one. > It's useful (essential?) if you want a root shell when there's no root > password set like on Ubuntu (and optionally on Debian). No. "sudo -i" does exactly that: Run a shell as "root" and ask for the password of the user calling it. S! -- Sigmentation fault. Core dumped.
Re: Zoom.
to...@tuxteam.de wrote: > On Sun, Oct 18, 2020 at 05:40:04PM +0200, Sven Hartge wrote: >> Stefan Monnier wrote: >>>> Does anyone have Zoom working in Debian 10? >>> Don't know, but I use and recommend Jitsi as a Free Software >>> alternative. >> If The Powers That Be[tm] have decided to use Zoom, then it is >> irrelevant that there might be a better (Open Source) alternative. > Isn't it funny that we consider ourselves "liberal democracies", but > when crossing our $COMPANY's doorstep, we leave our convictions at the > wardrobe? In an ideal world one could just refuse to do so and quit the job. But this isn't an ideal world, is it? S! -- Sigmentation fault. Core dumped.
Re: Zoom.
Stefan Monnier wrote: >> Does anyone have Zoom working in Debian 10? > Don't know, but I use and recommend Jitsi as a Free Software > alternative. If The Powers That Be[tm] have decided to use Zoom, then it is irrelevant that there might be a better (Open Source) alternative. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: dosemu : DOS emulator program
ellanios82 wrote: > - please , how to find Repository with "dosemu" ? > [ while dosbox is available , really would prefer dosemu ] for MXlinux dosemu was removed from Debian with Debian 10 (Buster). There is no repository that contains dosemu for a current Debian release anymore. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Problems with Opera browser
Mick Ab wrote: > In the last few days, a couple of problems have arisen with using the > Opera browser on a Debian Jessie system. > Firstly, black rectangles appear on many webpages. > Secondly, it is no longer possible to attach files to an email - > nothing happens when the Browse button is clicked to find the file > that is required to be attached to an email. > Opera version is 64.0.3417.73 Since Opera is not a Debian package but a 3rd-party one, you need to ask Opera about that. Also Jessie is out of Long Term Support since June 30th 2020 and you really shouldn't use it any longer, because there are not security updates coming any more. Please update to a supported Debian release to keep your data secure. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Question: SSD speed
Jeremy Nicoll wrote: > On Wed, 7 Oct 2020, at 09:39, Hans wrote: >> I have a little question. Smartctl is telling me, that my ssd drive >> is 6Gb/sec capable, but the actual speed is only 1,5GB/sec. > If your SATA (presumably) connection from the machine to the SSD is a > 6 Gbps one, the maximum data transfer speed in bytes across that > connection would be one eighth of that (as there's 8 bits per byte), > so about 760 MBps. > That's about half of your "1,5GBps". That makes me wonder if your SSD > uses two SATA channels at once - is that even possible? Only with SAS drives. And usually only for redudancy and not for concurrency. I question the benchmark Hans did. Something tells me he either used "hdparm -tT", which is known to misrepresent the speeds on modern drives, or wrote too little data so he was benchmarking the Kernel cache and not the drive. S! -- Sigmentation fault. Core dumped.
Re: crc not installed but rsync using it? ...
Albretch Mueller wrote: >>> How do I get all packages to be locally installed using dpkg from a >>> public Windows machine? >> >> I'm not sure I understand this question or how it relates to the >> previous one. > How do I get the deb files in order to install locally (via dpkg > --install) the necessary utilities to run CRC32 and/or CRC64 Why do you think you need to do this? What do you hope to achieve by doing this? Grüße, Sven -- Sigmentation fault. Core dumped.
Re: SSI Apache2 Buster not working
john doe wrote: > I just installed apache2 on Debian Buster. > I'm trying to use SSI in an html page: > $ cat try.shtml > > This file last modified > When accessing the page through my web browser, I only get 'This file > last modified' without the date being displayed. > the command 'a2enmod mime' tells me that mod_mime.c is enabled and in > /etc/apache2/apache2.conf I have the 'Options' line '+includes' present > for '/var/www/html'. > What am I missing? Is mod_include enabled as well? S! -- Sigmentation fault. Core dumped.
Re: ssl handshake problem with bugs.debian.org?
Harald Dunkel wrote: > [-- text/plain, encoding 7bit, charset: utf-8, 60 lines --] > On 2020-07-27 13:49, Sven Hartge wrote: >> >> Does your MTA present a client certificate? Maybe buxtehude does not >> like that? >> > Yes, it has a certificate. Whether buxtehude likes it I cannot say, > but it looks OK to me. Its a wildcard certificate, though: > Certificate: > Subject: C=DE, ST=Nordrhein-Westfalen, L=Aachen, O=aixigo AG, > OU=Internet, CN=*.aixigo.de Wildcard or not shouldn't matter. What matters if the Server uses that certificate as a client certificate. > BTW, the problem showed up first on June 17th. >> When diagnosing SSL errors I also find it helpful to wireshark the >> connection to see which side exactly triggers the SSL Alert. That may >> help highlight the culprit here. >> > See attachment. AFAICT this is all encrypted. Yes, but with TLS1.0 to TLS1.2 you could see the Alert and the rejection of the connection unencrypted. But your server and buxtehude switch to TLS1.3 and that prevents that kind of information from showing, IIRC, including the handshake with the certificate exchange. So, unfortunately this seems to be a dead end. S° -- Sigmentation fault. Core dumped.
Re: ssl handshake problem with bugs.debian.org?
Harald Dunkel wrote: > On 2020-07-27 11:17, Sven Hartge wrote: >> Debian uses their own CA to sign this certificate, which is fine for >> SMTP, which normally only uses opportunistic encryption. >> >> But if the client SMTP-Server is set to *verify* the certificate, it >> will fail. > Certificate verification is optional on my MTA. See the log file. > AFAICT it ignored the failed certificate check and continued with the > ssl handshake. *Then* it failed. Right. > It would be interesting to know whats written in the log files on > buxtehude. Are there other similar incidents? Does your MTA present a client certificate? Maybe buxtehude does not like that? When diagnosing SSL errors I also find it helpful to wireshark the connection to see which side exactly triggers the SSL Alert. That may help highlight the culprit here. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: ssl handshake problem with bugs.debian.org?
Reco wrote: > On Mon, Jul 27, 2020 at 10:43:11AM +0200, Harald Dunkel wrote: >> I've got a ssl handshake problem with bugs.debian.org on sending an EMail. >> My mta (OpenBSD 6.7, i.e. libressl) in the office says in its logfile >> >> : >> Jul 27 10:23:39 gate5a smtpd[67056]: d4df9298d18e1596 mta tls >> ciphers=TLSv1.3:AEAD-AES256-GCM-SHA384:256 >> Jul 27 10:23:39 gate5a smtpd[67056]: d4df9298d18e1596 mta server-cert-check >> result="failure" > This tells me that buxtehude does not support TLSv1.3 at all. > $ nmap -6 -p 25 -sV --script ssl-enum-ciphers buxtehude.debian.org Interesting. nmap shows the same for me, but testssl.sh does not: , | Testing protocols via sockets | | SSLv2 not offered (OK) | SSLv3 not offered (OK) | TLS 1 offered (deprecated) | TLS 1.1offered (deprecated) | TLS 1.2offered (OK) | TLS 1.3offered (OK): final | | Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC) | - | SSLv2 | - | SSLv3 | - | TLSv1 (no server order, thus listed by strength) | xc014 ECDHE-RSA-AES256-SHA ECDH 521 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | x39 DHE-RSA-AES256-SHADH 2048AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA | x35 AES256-SHARSAAES 256 TLS_RSA_WITH_AES_256_CBC_SHA | xc013 ECDHE-RSA-AES128-SHA ECDH 521 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | x33 DHE-RSA-AES128-SHADH 2048AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA | x2f AES128-SHARSAAES 128 TLS_RSA_WITH_AES_128_CBC_SHA | TLSv1.1 (no server order, thus listed by strength) | xc014 ECDHE-RSA-AES256-SHA ECDH 521 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | x39 DHE-RSA-AES256-SHADH 2048AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA | x35 AES256-SHARSAAES 256 TLS_RSA_WITH_AES_256_CBC_SHA | xc013 ECDHE-RSA-AES128-SHA ECDH 521 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | x33 DHE-RSA-AES128-SHADH 2048AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA | x2f AES128-SHARSAAES 128 TLS_RSA_WITH_AES_128_CBC_SHA | TLSv1.2 (no server order, thus listed by strength) | xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 521 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | xc014 ECDHE-RSA-AES256-SHA ECDH 521 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | x9f DHE-RSA-AES256-GCM-SHA384 DH 2048AESGCM 256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | xcca8 ECDHE-RSA-CHACHA20-POLY1305 ECDH 521 ChaCha20256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | xccaa DHE-RSA-CHACHA20-POLY1305 DH 2048ChaCha20256 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | xc09f DHE-RSA-AES256-CCMDH 2048AESCCM 256 TLS_DHE_RSA_WITH_AES_256_CCM | x39 DHE-RSA-AES256-SHADH 2048AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA | x9d AES256-GCM-SHA384 RSAAESGCM 256 TLS_RSA_WITH_AES_256_GCM_SHA384 | xc09d AES256-CCMRSAAESCCM 256 TLS_RSA_WITH_AES_256_CCM | x35 AES256-SHARSAAES 256 TLS_RSA_WITH_AES_256_CBC_SHA | xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 521 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | xc013 ECDHE-RSA-AES128-SHA ECDH 521 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | x9e DHE-RSA-AES128-GCM-SHA256 DH 2048AESGCM 128 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | xc09e DHE-RSA-AES128-CCMDH 2048AESCCM 128 TLS_DHE_RSA_WITH_AES_128_CCM | xc09c AES128-CCMRSAAESCCM 128 TLS_RSA_WITH_AES_128_CCM | x33 DHE-RSA-AES128-SHADH 2048AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA | x9c AES128-GCM-SHA256
Re: node.js updates processor microcode?
Carl Fink wrote: > I just installed npm on a Stable (Buster) system with apt. It brought > in dozens of other packages. Then I worked on other stuff while it > downloaded and installed. When I came back, a curses prompt was > informing me that it had already updated my kernel microcode. Is that > something node.js is really supposed to do. That wasn't a confirmation > prompt, it was, "I already did this, do you want to restart services?" I guess, you have the package "needrestart" installed. This program warns you about services that need to be restarted after a library they use has been changed. It also warns if a new microcode-package was installed *sometime* in the past and the system hasn't rebooted yet. If you don't regulary install packages or use unattended-upgrades, the installation of the new microcode-package may have been days or weeks ago and you just didn't remember it, seeing the reminder from needrestart surprised you. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: IP traffic counter
basti wrote: > Hello, I need some kind of software for ip accounting and record my > traffic rx and tx. I need to know how much Gigabyte I used over a > month. vnstat S! -- Sigmentation fault. Core dumped.
Re: Buster boot messages
Klaus Jantzen wrote: > On 7/10/20 11:48 AM, Sven Hartge wrote: >> Klaus Jantzen wrote: >>> the first messages that appear on the screen during the boot process >>> seem to be messages from the BIOS; >>> they have a different format than the subsequent messages from buster >>> and they begin with 'ACPI '. >>> As they disappear so fast, I cannot read them. >>> Where are these messages logged or what should I do to log these messages? >> "journalctl -b" will have the messages from the most recent boot. > Thanks for the pointer. > These are the messages I was looking for: > = > AMD-Vi: Unable to write to IOMMU perf counter. > ACPI BIOS Error (bug): Could not resolve [\_SB.PCI0.GPP0.VGA.LCD._BCM.AFN7], > AE_NOT_FOUND (201810/psargs-330) > ACPI Error: Method parse/execution failed \_SB.PCI0.GPP0.VGA.LCD._BCM, > AE_NOT_FOUND (20180810/psparse-516) > ACPI Error: Evaluating _BCM failed (20180810/video-370) > Failed to start Show Plymouth Boot Screen. > == > Do I have a problem with my system? No. The ACPI tables in PCs are usually shoddy and produce many warnings by the strict parser in the Kernel. Windows also often experiences the same parse errors, but decides to hide them deep in the Event Log. Both operations system work around the these errors, anticipating the bad craftsmanship of the mainboard/system manufacturers. Unless you have very specific problems which you explicitly can link to such errors, I would not worry. Sometimes a BIOS/Firmware update fixes some errors, but don't get your hopes up. Grüße Sven. -- Sigmentation fault. Core dumped.
Re: Buster boot messages
Klaus Jantzen wrote: > the first messages that appear on the screen during the boot process > seem to be messages from the BIOS; > they have a different format than the subsequent messages from buster > and they begin with 'ACPI '. > As they disappear so fast, I cannot read them. > Where are these messages logged or what should I do to log these messages? "journalctl -b" will have the messages from the most recent boot. S! -- Sigmentation fault. Core dumped.
Re: security.debian.org is slow
Georgi Naplatanov wrote: > does anybody know why http://security.debian.org is so slow. > Today and yesterday I downloaded security updates and download speed > was about 700-800 Kbytes/s. security.debian.org is provided through the Fastly CDN, so the slowness really depends on the network you are on and the connection of it to the nearest Fastly location. S! -- Sigmentation fault. Core dumped.
Re: how to stop reboot from delete'n directory
gru...@mailfence.com wrote: > On Wed, 1 Jul 2020, Greg Wooledge wrote: >> On Wed, Jul 01, 2020 at 02:33:07PM +0200, gru...@mailfence.com wrote: >>> i create a directory /run/foo to hold sockets for my application >>> when i reboot the directory gets deleted >>> is set'n the immutable flag the way to go >> If you want to re-create something in /run at boot time, you'll need to >> set up a task to do so, either by creating a systemd unit, or perhaps by >> using rc.local (since this is a ridiculously small and simple one-shot >> task, where a whole systemd unit would be overkill, rc.local is fine). >> >> Or, if you prefer, you could add "create the directory in /run" to >> your application's start-up code. > rc.local it is rc.local maybe far too late to do this. The generic and correct mechanism when running under systemd is to create your directory via /etc/tmpfiles.d or if using a systemd.unit via "RuntimeDirectory=foobar" directory to get /run/foobar created upon startup of the unit. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: LXC container update fail
Gokan Atmaca wrote: > Container is not updating. Why could it be ? > ---> Error is as follows: > root@debWeb0:~# apt update > Ign:1 http://deb.debian.org/debian buster InRelease > Ign:2 http://security.debian.org/debian-security buster/updates InRelease > Err:3 http://security.debian.org/debian-security buster/updates Release > 404 Not Found [IP: 151.101.12.204 80] > Err:4 http://deb.debian.org/debian buster Release > 404 Not Found [IP: 151.101.12.204 80] Mirror is out of date. Wait an hour and try again. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Buster install using debootstrap.
Greg Wooledge wrote: > On Fri, Jun 05, 2020 at 08:30:16AM +0200, Sven Hartge wrote: >> Marc Shapiro wrote: >>> I also don't understand why it says that it could not create temporary >>> files in /tmp. I am running this as root and /tmp is owned by root. >>> What am I missing? >> >> /tmp (and /var/tmp/) should have the following permissions and rights: >> >> root:root 1777/drwxrwxrwt >> >> apt runs its I/O processes as a different user "_apt" and if /tmp does >> not have the sticky bit set, then it cannot create any files there, >> causing the error. > To be completely clear, it's the world-write bit that allows _apt to > create files/subdirectories there. The sticky bit prevents other > users from removing or renaming said files/subdirectories while _apt > is using them. Eh, yes, of course. Was ahead in my thoughts and mixed both facts together. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Buster install using debootstrap.
Marc Shapiro wrote: > I also don't understand why it says that it could not create temporary > files in /tmp. I am running this as root and /tmp is owned by root. > What am I missing? /tmp (and /var/tmp/) should have the following permissions and rights: root:root 1777/drwxrwxrwt apt runs its I/O processes as a different user "_apt" and if /tmp does not have the sticky bit set, then it cannot create any files there, causing the error. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: OT: Using a USB hub with 3 computers, 1 printer, 1 external drive (for backup for any of the three PCs)
rhkra...@gmail.com wrote: > In a way, the subject covers most of it: " Using a USB hub with 3 computers, > 1 > printer, 1 external drive (for backup for any of the three PCs)". > I don't know much about USB hubs, I guess all of the ports are two way. No. This is even enforced in the way the cables and connectors are designed. > To clarify, if needed, I'd like to buy a 5 (or more) port USB (3.0) hub to > connect 3 PCs, 1 printer, and 1 external drive such that I can print or > backup > from any of the 3 pcs. No. USB is a tree, there can only be ever one root. You can't connect three PCs to a USB hub and expect this to work. > I suppose there are two questions: >1. Should I expect any problem "hardware wise"? Yes, because it will not work. There are very special USB sharing devices which allow more than one computer use connected devices, but those are a) rate and b) expensive. Grüße. Sven. -- Sigmentation fault. Core dumped.
Re: exim4 stopped delivering local mail after upgrade (sid)
m s wrote: > I haven't had a single problem on my system in so long, and this has > me stumped. I appreciate anyone's help - I'd like to get my mail back > asap! As first measure downgrade the exim4 packages to the ones in Testing. Then look at the paniclog, I suspect there will be more meaningful log-messages in there. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Qt4 and Bullseye
Gary L. Roach wrote: > I am using Bullseye (testing) because some of the software I use need > some of the newer libraries. Unfortunately Bullseye no longer includes > the Qt4 libraries and some of my packages still need Qt4. How can I > get Qt4 packages for Bullseye. There is probably a backport for this > but I have not used backport in the past. I will need a step by step > procedure if backporting is needed. Since Qt4 has been removed from all future releases there will be no such thing as a backport in this case, because there is nothing to backport *from*. (It would be a forward-port, but there is no such thing for Debian.) But you normally can just install the old library DEBs, for example by getting them from snapshot.debian.org. You won't get any security or other support for them. Or you can create a chroot from an older Debian release still containing Qt4 to run the old software. Unless the kernel changes in an incompatible way, this should work for some time. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Sid: /sbin/ifenslave missing??
Sven Hartge wrote: > Temporary solution: downgrade to 2.9 again, hold the package and monitor > the bug report I linked. Sorry, the correct bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959236 Unfortunately it has only "normal" severity, "grave" would be better here, since it not only breaks the function of the package, it breaks the whole system. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Sid: /sbin/ifenslave missing??
Grzesiek Sójka wrote: > On 5/17/20 12:34 PM, Sven Hartge wrote: >> Mind doing a "ifup -v bond0" to really see what is called how and where >> it fails in what way? > after "ifup -v bond0" I get a larg number of following messages > (probably 1000?): > + [ -n ] > + return 0 > + setup_master > + add_master > + [ -f /sys/class/net/bond0/bonding/slaves ] > + return > + early_setup_master > + sysfs fail_over_mac > + [ -n ] > + return 0 > + setup_master > + add_master > + [ -f /sys/class/net/bond0/bonding/slaves ] > + return > + early_setup_master > + sysfs fail_over_mac > /etc/network/if-pre-up.d/ifenslave: 67: Maximum function recursion depth > (1000) reached > run-parts: /etc/network/if-pre-up.d/ifenslave exited with return code 2 > ifup: failed to bring up bond0 Interesting. Yes, this seems like a genuine bug in the package but not caused by the removal of the ifenslave shell script but by some bug in the ifup-(pre)scripts provided by the package. Temporary solution: downgrade to 2.9 again, hold the package and monitor the bug report I linked. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Sid: /sbin/ifenslave missing??
Grzesiek Sójka wrote: > On 5/17/20 12:13 PM, Sven Hartge wrote: >> How does your /etc/network/interfaces look like? Usally all the work is >> done via if-pre-up.d and if-up.d scripts provided by the ifenslave >> package. > # cat /etc/network/interfaces > source-directory /etc/network/interfaces.d > auto bond0 > iface bond0 inet static > address 192.168.0.130 > netmask 255.255.255.252 > gateway 192.168.0.129 > slaves eth0 eth1 > mtu 9000 > So I need to "adjust" network configuration to bond using iproute2 instead? No, that should work, my configurations look similar (but they are all on Buster and thus on 2.9, so I have not seen this bug myself). Mind doing a "ifup -v bond0" to really see what is called how and where it fails in what way? Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Sid: /sbin/ifenslave missing??
Grzesiek Sójka wrote: > After upgrading ifenslave from 2.9 to 2.10 i found that there if no > /sbin/ifenslave binary. To restore network connectivity I had to > manually downgrade to 2.9. Is it on purpose? If so, then how to > properly configure link aggregation? It seems you hit https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959075 But NEWS.Debian says: , | ifenslave (2.10) UNRELEASED; urgency=medium | | This version of the ifenslave package no longer provides /sbin/ifenslave. The | /sbin/ip command from the iproute2 package supports creating bonding masters | and enslaving other interfaces to it. | | -- Guus Sliepen Tue, 08 May 2018 22:47:07 +0200 ` How does your /etc/network/interfaces look like? Usally all the work is done via if-pre-up.d and if-up.d scripts provided by the ifenslave package. S! -- Sigmentation fault. Core dumped.
Re: Smallest Usable EFI Partition?
Patrick Bartek wrote: > On Wed, 13 May 2020 07:38:00 +0200 Sven Hartge wrote: >> Also Firmware/BIOS update are often put onto there nowadays to be >> installed on next reboot. > Aren't such updates stored still in /boot? Or has that changed with > efi? For my Dell Precision 7520 I can either put them on a USB-key and manually initiate the upgrade during boot (how barbaric) or put the update file on the ESP and have it done automatically. fwupd also does it this way. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Smallest Usable EFI Partition?
Rick Thomas wrote: > On Tue, May 12, 2020, at 3:37 PM, Andrea Borgia wrote: >> Il 13/05/20 00:21, Patrick Bartek ha scritto: >> > I can't find anything definitive on this question. Some say, 100MB >> > is fine; others 215 or 550 is a safe choice. It all seems to be >> > just opinions. >> I had the same doubts about a year ago and went with the >> recommendation of a larger partition, about 500MB... of which only 6% >> is used. My office laptop with Windows10 has something in the region >> of 100MB but it is not dualboot. Debian uses about 6MB, MS about >> 26MB, plus a couple of megs for boot. If space is really tight you >> might want to stick with 100MB in total. > One thing to keep in mind is that, when the contents are being > updated, the EFI partition and the /boot partition if you have one, > will need space for two (or even more) copies of stuff. So don't be > too stingy! Also Firmware/BIOS update are often put onto there nowadays to be installed on next reboot. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: ACPI Errors
Jonathan Oshita wrote: > I've been having the following error messages about 'ACPI' in my > 'kern.log' and haven't been able to figure out how to resolve them. > The system boots successfully after displaying the errors, but any > error message is usually a concern of mine. ACPI errors usually can only be solved by a BIOS/firmware update. But even then it is more than possible that nothing will change as BIOS vendors are notoriously bad at creating correct ACPI tables. > Is this something I should be worried about? No. > Is there any way I can eliminate these errors? Probably not. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: stretch -> buster upgrade fails
Tony van der Hoff wrote: > E: Problem executing scripts APT::Update::Post-Invoke-Success 'if > /usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli; then > appstreamcli refresh-cache > /dev/null; fi' > E: Sub-process returned an error code > I don't know where to find a verbose log. Any suggestions as to how tp > proceed please? What happens when you run appstreamcli refresh-cache manually as root? Grüße, S! -- Sigmentation fault. Core dumped.
Re: Hmmm... /boot is too small. what's the best way to increase it's size?
David Wright wrote: > If the answer is many, you could shrink some of them by rebuilding > their initrd.img files with MODULES=dep, which could reduce each > kernel's size from ~40M to <10M. While this will reduce this initrd size, you should also mention the consequences of doing this: It only includes the modules update-initramfs thinks are needed to boot the system. But this also results in two important consequences: 1) You lose portability of the system. By only including the modules needed to boot in the current hardware this may limit your ability to boot the system on different hardware. 2) MODULES=dep is a codepath less tested. In my experience this can lead to modules missing which are needed for successful boot, resulting in a failed or incomplete boot. Grüße, Sven -- Sigmentation fault. Core dumped.
Re: Should I enable "testing"
J.Arun Mani wrote: > The question is, shall I revert back to "stable"? At this point, the only sure way to downgrade to stable is via a reinstall, because downgrading a package is not supported (in general). Why is this? While many programs don't store anything on disk that is version dependent, this does not hold true for every one. Image a tool "foobar-1.1.0", which stores some data in a file. Now a new version is installed, "foobar-2.0.4" and during upgrade or the first time it is run, it converts the data in the file into a new format that the old version 1.1.0 cannot understand. If you now dowgrade the package, you will get errors or worse, lose or corrupt your data. Similarly with some packages moving directories and files around during the upgrade process. Downgrading them will not revert that move and the older package will either operate as if no data exists or throw errors. And even *if* after the downgrade of the installed packages the system seems to work normally, you never know if there wasn't some subtle error introduced which will catch up to you later. During my now over 20 years of using and administering Debian and Debian-derived systems unclean downgrades sometime during the lifetime of a system was among the most reasons for future failures during operation or upgrades. TL,DR: So my advise is: Keep it as it is, just change "testing" to "bullseye" so you will stay on the new stable release once it is released. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Groovy 2.4.16 + Java 11 is broken in debian buster stable
Liam O'Toole wrote: > On Thu, 23 Apr, 2020 at 11:08:27 +0200, Sven Hartge wrote: >> Backports must not be used to fix bugs in Stable. If groovy from >> Stable does not work with the openjdk-11 from Stable, then this is a >> bug in Stable and has to be fixed in Stable. > This is indeed a bug in stable. However, any package in testing > becomes a candidate for stable-backports. Sure. But the official stance of Debian is the one I lined out above, by both the SRMs and the Backports-RMs. You must not be forced to install packages from backports just to get a bug fixed. In this case one could argue that the bug in groovy is indeed release-critical, since it does not work at all. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Groovy 2.4.16 + Java 11 is broken in debian buster stable
Liam O'Toole wrote: > On Wed, 22 Apr, 2020 at 22:15:09 +0530, Jayant Tripathi wrote: >>[1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929460 >>Is there a way to download patched groovy version in debian buster >>through apt? >>As default groovy version in Buster stable is: Groovy Version: 2.4.16 >>JVM: 11.0.6 Vendor: Debian OS: Linux >>Regards >>Jayant Tripathi >> >> References >> >>1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929460 > Groovy 2.4.17 is available in bullseye (testing). Try requesting a > backport on the debian-backports list. Backports must not be used to fix bugs in Stable. If groovy from Stable does not work with the openjdk-11 from Stable, then this is a bug in Stable and has to be fixed in Stable. Grüße, Sven. -- Sigmentation fault. Core dumped.
