Bug#1029185: AW: Bug#1029185: moreinfo
Hallo Thomas, yes, we use "alien" to make it and it works. But ist a manual task we have to watch for, not an magically Repository ;-) Reiner -Ursprüngliche Nachricht- Von: Thomas Lange Gesendet: Dienstag, 28. November 2023 14:16 An: 1029...@bugs.debian.org; 1029185-submit...@bugs.debian.org Betreff: Bug#1029185: moreinfo Hi Reiner, did you tried to convert the .deb to .rpm? Does it work for you? -- Thomas
Bug#1033040: AW: Bug#1033040: very simple to create a different format
Hi Thomas, ok, this is so simple that I didnt expect it Reiner -Ursprüngliche Nachricht- Von: Thomas Lange Gesendet: Dienstag, 28. November 2023 14:05 An: 1033...@bugs.debian.org; 1033040-submit...@bugs.debian.org Betreff: Bug#1033040: very simple to create a different format Hi, if you want to create a .vdi image just call # fai-diskimage . image.vdi What else is needed as an example? -- regards Thomas
Bug#996460: AW: Bug#996460: tang: "Input/output error" after update libhttp-parser2.8 to 2.8.1-1+deb10u1
yes, it was kind of mixed. At setup time there where no nagios check in the Buster repos, so ich used the Sid repos and pinned all packages from sid to "50" Reiner Schulz > -Ursprüngliche Nachricht- > Von: Christoph Biedl [mailto:debian.a...@manchmal.in-ulm.de] > Gesendet: Mittwoch, 20. Oktober 2021 09:30 > An: Schulz, Reiner ; 996...@bugs.debian.org > Betreff: Re: Bug#996460: tang: "Input/output error" after update libhttp- > parser2.8 to 2.8.1-1+deb10u1 > > Control: tags 996460 confirmed > > Reiner Schulz wrote... > > > After regulary patch day tang dosent work anymore. > > a second Server which is not patched works as normal > > Thanks to the instructions you've provided, I was able to reproduce your > problem. > > (...) > > > dpkg -l libhttp-parser* tang* > > +++-===-===-- > == > > ii libhttp-parser2.8:amd64 2.8.1-1+deb10u1 amd64parser for HTTP > messages written in C > > ii libhttp-parser2.9:amd64 2.9.4-4 amd64parser for HTTP > > messages > written in C > > ii tang7-1+deb10u1 amd64network-based > > cryptographic > binding server > > ii tang-nagios 7-2 amd64monitoring plugin > > to check the > tang server > > Hmm, seems you're running a mixed buster/bullseye setup here. This might > be related, I'll check more in details tonight. > > Christoph
Bug#985771: AW: Bug#985771: AW: Bug#985771: apt-auto-removal isn't run by kernel update
> -Ursprüngliche Nachricht- > Von: Julian Andres Klode [mailto:julian.kl...@gmail.com] Im Auftrag von > Julian Andres Klode > Gesendet: Dienstag, 23. März 2021 19:09 > An: Schulz, Reiner ; 985...@bugs.debian.org > Betreff: Re: Bug#985771: AW: Bug#985771: apt-auto-removal isn't run by > kernel update > > On Tue, Mar 23, 2021 at 03:10:31PM +, Schulz, Reiner wrote: > > > This file includes: > > > […] > > > | /* Debug information: > > > | # dpkg list: > > > | rc linux-image-4.19.0-10-amd64 4.19.132-1 > > > amd64Linux > > > 4.19 for 64-bit PCs (signed) > > > | rc linux-image-4.19.0-11-amd64 4.19.146-1 > > > amd64Linux > > > 4.19 for 64-bit PCs (signed) > > > | rc linux-image-4.19.0-12-amd64 4.19.152-1 > > > amd64Linux > > > 4.19 for 64-bit PCs (signed) > > > | ii linux-image-4.19.0-13-amd64 4.19.160-2 > > > amd64Linux > > > 4.19 for 64-bit PCs (signed) > > > | ii linux-image-4.19.0-14-amd64 4.19.171-2 > > > amd64Linux > > > 4.19 for 64-bit PCs (signed) > > > | rc linux-image-4.19.0-8-amd644.19.98-1+deb10u1 > > > amd64 > > > Linux 4.19 for 64-bit PCs (signed) > > > | rc linux-image-4.19.0-9-amd644.19.118-2+deb10u1 > > > amd64 > > > Linux 4.19 for 64-bit PCs (signed) > > > | rc linux-image-4.9.0-12-amd644.9.210-1 > > > amd64Linux > > > 4.9 for 64-bit PCs > > > | rc linux-image-4.9.0-8-amd64 4.9.144-3.1 > > > amd64Linux > > > 4.9 for 64-bit PCs > > > | ii linux-image-amd64 4.19+105+deb10u9 > > > amd64Linux > > > for 64-bit PCs (meta-package) > > > > > > so only the last two kernel 4.19.0-13 & -14 are installed, as it should > > > be. The rest are removed and only config files remain (= "rc"). These > > > remaining bits shouldn't take up too much space & you can remove them > > > by calling "apt purge linux-image-…" on those rc packages. > > > > > > > > > > It looks for me more like something depends/recommends those kernel > > > > > packages though. Out of tree modules perhaps? Try "apt remove -s > > > > > linux-image-4.19.0-13-amd64" perhaps that already shows something > > > > > although a bit unlikely (as that would only react on hard > > > > > dependencies, > > > > > while recommends, or-groups and virtual packages are more likely). > > > > > > > > [RS] 18 of the 23 Servers are virtual machines > > > > And all have the some problem > > > > > > Are the kernel packages on those servers in 'rc' state, too? Or are they > > > shown as ii (fully installed), hi (installed, but on hold) or i and some > > > uppercase letter (various forms of partly installed) ? > > > > On one oft hem it looks like this: > > ra1183:~# dpkg -l 'linux-image-*' > > Desired=Unknown/Install/Remove/Purge/Hold > > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig- > pend > > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > > ||/ Name VersionArchitecture > > Description > > +++--==- > -=== > > rc linux-image-3.16.0-4-amd64 3.16.51-3 amd64 > > Linux 3.16 for > 64-bit PCs > > ii linux-image-4.19.0-10-amd64 4.19.132-1 amd64 > > Linux 4.19 for > 64-bit PCs (signed) > > un linux-image-4.19.0-10-amd64-unsigned (no > description available) > > ii linux-image-4.19.0-11-amd64 4.19.146-1 amd64 > > Linux 4.19 for > 64-bit PCs (signed) > > un linux-image-4.19.0-11-amd64-unsigned (no > description available) > > ii linux-image-4.19.0-12-amd64 4.19.152-1 amd64 > > Linux 4.19 for > 64-bit PCs (signed) > > un linux-image-4.19.0-12-amd64-unsigned (no > description available) > > ii linux-image-4.19.0-13-amd64 4.19.160-2 amd64 > > Linux 4.19 for > 64-bit PCs (signed) > > un linux-image-4.19.0-13-amd64-unsig
Bug#985771: AW: Bug#985771: apt-auto-removal isn't run by kernel update
> This file includes: > […] > | /* Debug information: > | # dpkg list: > | rc linux-image-4.19.0-10-amd64 4.19.132-1amd64 > Linux > 4.19 for 64-bit PCs (signed) > | rc linux-image-4.19.0-11-amd64 4.19.146-1amd64 > Linux > 4.19 for 64-bit PCs (signed) > | rc linux-image-4.19.0-12-amd64 4.19.152-1amd64 > Linux > 4.19 for 64-bit PCs (signed) > | ii linux-image-4.19.0-13-amd64 4.19.160-2amd64 > Linux > 4.19 for 64-bit PCs (signed) > | ii linux-image-4.19.0-14-amd64 4.19.171-2amd64 > Linux > 4.19 for 64-bit PCs (signed) > | rc linux-image-4.19.0-8-amd644.19.98-1+deb10u1 amd64 > Linux 4.19 for 64-bit PCs (signed) > | rc linux-image-4.19.0-9-amd644.19.118-2+deb10u1amd64 > Linux 4.19 for 64-bit PCs (signed) > | rc linux-image-4.9.0-12-amd644.9.210-1 amd64 > Linux > 4.9 for 64-bit PCs > | rc linux-image-4.9.0-8-amd64 4.9.144-3.1 amd64 > Linux > 4.9 for 64-bit PCs > | ii linux-image-amd64 4.19+105+deb10u9 amd64 > Linux > for 64-bit PCs (meta-package) > > so only the last two kernel 4.19.0-13 & -14 are installed, as it should > be. The rest are removed and only config files remain (= "rc"). These > remaining bits shouldn't take up too much space & you can remove them > by calling "apt purge linux-image-…" on those rc packages. > > > > It looks for me more like something depends/recommends those kernel > > > packages though. Out of tree modules perhaps? Try "apt remove -s > > > linux-image-4.19.0-13-amd64" perhaps that already shows something > > > although a bit unlikely (as that would only react on hard dependencies, > > > while recommends, or-groups and virtual packages are more likely). > > > > [RS] 18 of the 23 Servers are virtual machines > > And all have the some problem > > Are the kernel packages on those servers in 'rc' state, too? Or are they > shown as ii (fully installed), hi (installed, but on hold) or i and some > uppercase letter (various forms of partly installed) ? On one oft hem it looks like this: ra1183:~# dpkg -l 'linux-image-*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name VersionArchitecture Description +++--==--=== rc linux-image-3.16.0-4-amd64 3.16.51-3 amd64Linux 3.16 for 64-bit PCs ii linux-image-4.19.0-10-amd64 4.19.132-1 amd64Linux 4.19 for 64-bit PCs (signed) un linux-image-4.19.0-10-amd64-unsigned (no description available) ii linux-image-4.19.0-11-amd64 4.19.146-1 amd64Linux 4.19 for 64-bit PCs (signed) un linux-image-4.19.0-11-amd64-unsigned (no description available) ii linux-image-4.19.0-12-amd64 4.19.152-1 amd64Linux 4.19 for 64-bit PCs (signed) un linux-image-4.19.0-12-amd64-unsigned (no description available) ii linux-image-4.19.0-13-amd64 4.19.160-2 amd64Linux 4.19 for 64-bit PCs (signed) un linux-image-4.19.0-13-amd64-unsigned (no description available) ii linux-image-4.19.0-14-amd64 4.19.171-2 amd64Linux 4.19 for 64-bit PCs (signed) un linux-image-4.19.0-14-amd64-unsigned (no description available) ii linux-image-4.19.0-6-amd64 4.19.67-2+deb10u2 amd64Linux 4.19 for 64-bit PCs (signed) un linux-image-4.19.0-6-amd64-unsigned (no description available) ii linux-image-4.19.0-8-amd64 4.19.98-1+deb10u1 amd64Linux 4.19 for 64-bit PCs (signed) un linux-image-4.19.0-8-amd64-unsigned (no description available) ii linux-image-4.19.0-9-amd64 4.19.118-2+deb10u1 amd64Linux 4.19 for 64-bit PCs (signed) un linux-image-4.19.0-9-amd64-unsigned (no description available) ii linux-image-4.9.0-7-amd644.9.110-3+deb9u2 amd64Linux 4.9 for 64-bit PCs ii linux-image-amd644.19+105+deb10u9 amd64Linux for 64-bit PCs (meta-package) I attached the removal scripts from this server ra1183:~# apt-get -s autoremove Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: linux-image-4.19.0-6-amd64 linux-image-4.19.0-8-amd64 linux-image-4.9.0-7-amd64 0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded. Remv linux-image-4.19.0-6-amd64 [4.19.67-2+deb10u2] Remv
Bug#985771: AW: [SPAM] AW: Bug#985771: apt-auto-removal isn't run by kernel update
> Don't include that (also starting every paragraph with [RS] is annoying; > and your email server is in a rspamd uribl bl.rspamd.com - what's going > on there, someone sending spam like crazy?) I'm sorry > > > On Tue, Mar 23, 2021 at 10:18:34AM +0100, Reiner Schulz wrote: > > > > Package: apt > > > > Version: 1.8.2.2 > > > > Severity: normal > > > > > > > > Dear Maintainer, > > > > > > > > On 5 of our Debian 10 Server the separate /boot Partition filled up with > old > > > kernels > > > > on a few Server without separate /boot partition are up to 10 old kernel > left > > > > > > > > I check if linux-image\* was marked "manual", there where a few on > some > > > Server, but not on all. > > > > > > > > /etc/kernel/postinst.d/apt-auto-removal should remove all old kernels > > > > but > the > > > last two > > > > > > No... it creates a config file telling apt which kernels to remove > > > > [RS] yes, correct, i describe it in a very short way > > > > > _when you run autoremove_. > > > > > > apt 2.2 automatically removes kernels during apt dist-upgrade / apt > > > full-upgrade (not using apt-get). > > > > > > Did you run autoremove? > > > > [RS] Do i have to run autoremove regulary? To remove old kernels? > > You have to run autoremove to remove old kernels, yes. Until you use apt > 2.2, where apt(8) can autoremove them during dist-upgrade, then you can > use that. > > You need to be careful running autoremove, though, so it's not > something you can run automatically. OK, i dont know that, thank you for the hint It this behavior dscribed in a man page? > > > > I greped over 23 Debian 10 Server: > > > > ansible DEBIAN_10 -b -m shell -a 'zgrep 'postinst.d' > /var/log/apt/term.log* ' > > > >> grep_term.log 2>&1 > > > > > > > > grep -c -E 'zz-update-grub' grep_term.log > > > > 115 > > > > grep -c -E 'initramfs-tools' grep_term.log > > > > 138 > > > > grep -c -E 'apt-auto-removal' grep_term.log > > > > 2 > > > > > > > > i will attach grep_term.log > > > > > > I'm not sure what this is supposed to tell us, the hook is (usually) > > > silent, so it's not going to appear in the terminal output. > > > > [RS] if a new kernel is to setting up, the scripts from > > /etc/kernel/postinst.d/ > are noted: > > Sometimes yes, but seemingly only when they do output stuff. OK, thank you for you help. Please close this bug now
Bug#985771: AW: Bug#985771: apt-auto-removal isn't run by kernel update
> -Ursprüngliche Nachricht- > Von: Julian Andres Klode [mailto:julian.kl...@gmail.com] Im Auftrag von Julian > Andres Klode > Gesendet: Dienstag, 23. März 2021 11:55 > An: Schulz, Reiner ; 985...@bugs.debian.org > Betreff: Re: Bug#985771: apt-auto-removal isn't run by kernel update > > On Tue, Mar 23, 2021 at 10:18:34AM +0100, Reiner Schulz wrote: > > Package: apt > > Version: 1.8.2.2 > > Severity: normal > > > > Dear Maintainer, > > > > On 5 of our Debian 10 Server the separate /boot Partition filled up with old > kernels > > on a few Server without separate /boot partition are up to 10 old kernel > > left > > > > I check if linux-image\* was marked "manual", there where a few on some > Server, but not on all. > > > > /etc/kernel/postinst.d/apt-auto-removal should remove all old kernels but > > the > last two > > No... it creates a config file telling apt which kernels to remove [RS] yes, correct, i describe it in a very short way > _when you run autoremove_. > > apt 2.2 automatically removes kernels during apt dist-upgrade / apt > full-upgrade (not using apt-get). > > Did you run autoremove? [RS] Do i have to run autoremove regulary? To remove old kernels? > > I greped over 23 Debian 10 Server: > > ansible DEBIAN_10 -b -m shell -a 'zgrep 'postinst.d' /var/log/apt/term.log* > > ' > >> grep_term.log 2>&1 > > > > grep -c -E 'zz-update-grub' grep_term.log > > 115 > > grep -c -E 'initramfs-tools' grep_term.log > > 138 > > grep -c -E 'apt-auto-removal' grep_term.log > > 2 > > > > i will attach grep_term.log > > I'm not sure what this is supposed to tell us, the hook is (usually) > silent, so it's not going to appear in the terminal output. [RS] if a new kernel is to setting up, the scripts from /etc/kernel/postinst.d/ are noted: Setting up linux-image-4.19.0-14-amd64 (4.19.171-2) ... ... /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-4.19.0-14-amd64 ... /etc/kernel/postinst.d/zz-update-grub: Generating grub configuration file ... So i expected to see there a note for /etc/kernel/postinst.d/apt-auto-removal > > /etc/kernel/postinst.d/apt-auto-removal isn't run after kernel updates > > I don't believe that. [RS] i believe you that. I only want to find my mistake, as i deployed all this servers
Bug#985771: AW: Bug#985771: apt-auto-removal isn't run by kernel update
Hi David, thank you for you fast answer > -Ursprüngliche Nachricht- > Von: David Kalnischkies [mailto:da...@kalnischkies.de] > Gesendet: Dienstag, 23. März 2021 11:19 > An: Schulz, Reiner ; 985...@bugs.debian.org > Betreff: Re: Bug#985771: apt-auto-removal isn't run by kernel update > > On Tue, Mar 23, 2021 at 10:18:34AM +0100, Reiner Schulz wrote: > > On 5 of our Debian 10 Server the separate /boot Partition filled up with old > kernels > > on a few Server without separate /boot partition are up to 10 old kernel > > left > > > > I check if linux-image\* was marked "manual", there where a few on some > Server, but not on all. > > (Those marked manual will never be removed) [RS] I know, so i did: apt-mark auto linux-image\* > > /etc/kernel/postinst.d/apt-auto-removal should remove all old kernels but > > the > last two > > (the logic is slightly more complex than this) [RS] its looks like. > > /etc/kernel/postinst.d/apt-auto-removal isn't run after kernel updates > > > > How can i check why? > > It probably is, but as it is not producing any output to the console > there is also no indication given that it was run (technical hint: That > is a choice being made by the kernel packages, which run the scripts > with "run-parts --report", which is documented to behave that way). [RS] but starting the other scripts is noted in term.log: Setting up linux-image-4.19.0-14-amd64 (4.19.171-2) ... ... /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-4.19.0-14-amd64 ... /etc/kernel/postinst.d/zz-update-grub: Generating grub configuration file ... Scripts from /etc/kernel/postrm.d/ are also noted > > -- Package-specific info: > […] > > APT::NeverAutoRemove:: "^linux-image-4\.19\.0-13-amd64$"; > > APT::NeverAutoRemove:: "^linux-image-4\.19\.0-14-amd64$"; > […] > > Kernel: Linux 4.19.0-14-amd64 (SMP w/2 CPU cores) > > This looks correct and shows its indeed run as expected. [RS] indeed, i run /etc/apt/apt.conf.d/01autoremove-kernels by hand and all looks good > Can you perhaps attach the /etc/apt/apt.conf.d/01autoremove-kernels > file? It it generated by the script and should contain a bunch of debug > information at the end which could help if the generated config is > otherwise wrong (but it doesn't look like that). [RS] I do > It looks for me more like something depends/recommends those kernel > packages though. Out of tree modules perhaps? Try "apt remove -s > linux-image-4.19.0-13-amd64" perhaps that already shows something > although a bit unlikely (as that would only react on hard dependencies, > while recommends, or-groups and virtual packages are more likely). [RS] 18 of the 23 Servers are virtual machines And all have the some problem > On a sidenote: Debian 11 will ship with a rework of this kernel removing > more tightly integrated into apt directly. I am inclined to declare this > "fixed" in >= 2.1.16 hence, but lets see first if that is something > which could affect those versions, too (and is something not working "as > designed"). [RS] it would good to find a way to handle this, as we need months to upgrade to Debain 11 01autoremove-kernels Description: 01autoremove-kernels
Bug#981093: AW: Bug#981093: fai-client: install_packages -L use hardcoded '-s'
I think '--assumeno' can used to simulate. I tried: yum -y install --assumeno yum-plugin-versionlock And the is not installed -- Reiner Schulz -Ursprüngliche Nachricht- Von: Thomas Lange [mailto:la...@cs.uni-koeln.de] Gesendet: Dienstag, 26. Januar 2021 10:07 An: Schulz, Reiner ; 981...@bugs.debian.org Betreff: Re: Bug#981093: fai-client: install_packages -L use hardcoded '-s' >>>>> On Tue, 26 Jan 2021 09:35:27 +0100, Reiner Schulz >>>>> said: > At line 203 in https://github.com/faiproject/fai/blob/master/bin/install_packages > a '-s' is used to '--simulate' the package install, which is only for apt-get > but give an error for other package management tool, like yum. Do you know if there's a similar option for yum or dnf? -- regards Thomas
Bug#977536: AW: Bug#977536 closed by Debian FTP Masters (reply to Christoph Biedl ) (Bug#977536: fixed in nagios-tang 7-1)
Happy New Year Christoph. Do i have to be worried about that the architectur of the package ist "armel"? Reiner Schulz -Ursprüngliche Nachricht- Von: Debian Bug Tracking System [mailto:ow...@bugs.debian.org] Gesendet: Sonntag, 10. Januar 2021 00:03 An: Schulz, Reiner Betreff: Bug#977536 closed by Debian FTP Masters (reply to Christoph Biedl ) (Bug#977536: fixed in nagios-tang 7-1) This is an automatic notification regarding your Bug report which was filed against the wnpp package: #977536: ITP: nagios-tang -- A Nagios plugin to check the health of the Tang server It has been closed by Debian FTP Masters (reply to Christoph Biedl ). Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Debian FTP Masters (reply to Christoph Biedl ) by replying to this email. -- 977536: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977536 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#901508: AW: Bug#901508: it works now
Now, i use "export" and it works. Sorry, my fault. Reiner -Ursprüngliche Nachricht- Von: Thomas Lange [mailto:la...@informatik.uni-koeln.de] Gesendet: Donnerstag, 18. Juli 2019 20:48 An: 901...@bugs.debian.org; 901508-submit...@bugs.debian.org Betreff: Bug#901508: try this Did you try adding export? > export http_proxy=. > rinse .. -- regards Thomas
