Bug#983912: grub2: consider renaming signed source packages to grub2-signed-*
On Sun, 20 Nov 2022, Salvatore Bonaccorso wrote: On Wed, Mar 03, 2021 at 10:52:39AM +0100, Ansgar wrote: Source: grub2 Version: 2.04-16 Severity: normal X-Debbugs-Cc: ftpmas...@debian.org, debian-rele...@lists.debian.org grub2 currently uses grub-efi-signed-* as source package names for the Secure Boot signed packages. While releasing the last security update we found a small issue with these names: dak processes source packages in lexiographic order, so it would process grub-efi-signed-* before grub2 when accepting all packages at once from the "embargoed" policy queue. But the grub-efi-signed-* binary packages have Built-Using: grub2; as grub2 is not accepted from embargoed at this point in time, the /binary/ uploads will be rejected in this case. (This problem exists in principle with all Built-Using relations.) How hard would it be to enhance dak to not require any specific ordering? One way could be to process the same list repeatedly, until no additional packages have been accepted for an entire pass. Regards, Anne Bezemer
Bug#969224: cdimage.debian.org: Error installing Debian 10.5 from flash stick with Extlinux
retitle 969224 Archive main/installer-*/current/ has outdated kernels? severity 969224 normal thanks Hi, So the real problem is that the archive seems outdated w.r.t. DVD images. The DVD images themselves are consistent (since you report they work fine). I'm doing customized usb sticks regularly, e.g. putting i386 and amd64 installer DVD iso's plus several Live systems onto one big usb stick, with bootloader options to choose between them. So I've bumped into this exact issue before, and I learned to always get everything from the same source. Specifically, get kernel and initrd directly from the .iso file that you use, by mounting it (-o loop), or extract them using isoinfo command (hint: -R option), or probably 7z will work too. While you're there, also study what the "official" bootloader is passing to the kernel commandline, and do something similar in your own bootloader config. Best regards, Anne Bezemer On Sun, 30 Aug 2020, wrote: [..] I think the problem is that the kernel versions for DVD and installer-amd64/current/images/hd-media/ or installer-amd64/current/images/hd-media/gtk/ ÿÿ initrd.gz for Debian 10.4 and Debian 10.5 don't match. for Debian 10.5 4.19.0-10 - the kernel versions for DVD 4.19.0-5 - the kernel versions for http://ftp.nl.debian.org/debian/dists/Debian10.5/main/installer-amd64/current/images/hd-media/ or (for GTK) http://ftp.nl.debian.org/debian/dists/Debian10.5/main/installer-amd64/current/images/hd-media/gtk/ ÿÿ Debian 10.4 4.19.0-9 - the kernel versions for ÿÿ DVD 4.19.0-5 - the kernel versions for http://ftp.nl.debian.org/debian/dists/Debian10.4/main/installer-amd64/current/images/hd-media/ or (for GTK) http://ftp.nl.debian.org/debian/dists/Debian10.4/main/installer-amd64/current/images/hd-media/gtk/ ÿÿ Debian 10.3 4.19.0-8 - the kernel versions for ÿÿ DVD 4.19.0-8 - the kernel versions for http://ftp.nl.debian.org/debian/dists/Debian10.3/main/installer-amd64/current/images/hd-media/ or (for GTK) http://ftp.nl.debian.org/debian/dists/Debian10.3/main/installer-amd64/current/images/hd-media/gtk/ For Debian 10.3 everything was established without problems.
Bug#677428: psmisc: killall can do max 32 (33) names, undocumented
Package: psmisc Version: 22.11-1 Severity: minor Squeeze system, up-to-date as of 5 minutes ago (but issue is present since at least Debian 3.0, psmisc 20.2-2.1) $ killall xx1 xx2 xx3 xx4 xx5 xx6 xx7 xx8 xx9 xx10 xx11 xx12 xx13 xx14 \ xx15 xx16 xx17 xx18 xx19 xx20 xx21 xx22 xx23 xx24 xx25 xx26 xx27 xx28 \ xx29 xx30 xx31 xx32 xx33 xx1: no process found xx2: no process found xx3: no process found xx4: no process found xx5: no process found xx6: no process found xx7: no process found xx8: no process found xx9: no process found xx10: no process found xx11: no process found xx12: no process found xx13: no process found xx14: no process found xx15: no process found xx16: no process found xx17: no process found xx18: no process found xx19: no process found xx20: no process found xx21: no process found xx22: no process found xx23: no process found xx24: no process found xx25: no process found xx26: no process found xx27: no process found xx28: no process found xx29: no process found xx30: no process found xx31: no process found xx32: no process found xx33: no process found $ killall xx1 xx2 xx3 xx4 xx5 xx6 xx7 xx8 xx9 xx10 xx11 xx12 xx13 xx14 \ xx15 xx16 xx17 xx18 xx19 xx20 xx21 xx22 xx23 xx24 xx25 xx26 xx27 xx28 \ xx29 xx30 xx31 xx32 xx33 xx34 Maximum number of names is 32 While this could preferably be converted to a neatly limitless operation, I would suggest at least: 1) a clear note in the manpage; and 2) prefix of error message with killall: so people know what exactly their long script is doing wrong; and 3) fixing the off-by-one. Best regards, Anne Bezemer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673576: s390 DVD-1 Release file broken
# since this is actually about the program, not the website: reassign 673576 debian-cd thanks Hi Steve, It appears you've been doing some debian-cd hacking today; hopefully the incorrect Release file for s390 is also on your radar. If/when you manage to resolve that, would it be possible to generate a new 6.0.5 s390 DVD-1 so that Alain may test it? (..which, from a private message, he seems quite eager to do.) Best regards, Anne Bezemer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673576: cdimage.debian.org for S390
On Sat, 26 May 2012, Alain Benvéniste wrote: Anne, Can you tell me if you need more infos, if this issue is in progress ? Sorry, I seem to have completely missed your message last monday... So there is a bug on the DVD. In particular, your Release file contains: MD5Sum: 717fa13404f85f1f04a2067a902d5fba 95 main/binary-s390/Release 440e09b2690f0f01412a023e0aedb66e 4671806 main/binary-s390/Packages b8ae7f01c26aa9d9e9ea084a04bbb5db 1382145 main/binary-s390/Packages.gz 717fa13404f85f1f04a2067a902d5fba 95 main/debian-installer/binary-s390/Release 8ff038c20762247cbf0b2d1f905cb989 98 contrib/binary-s390/Release 415fae5f90760d87d09bcfd14876db2f 2442 contrib/binary-s390/Packages 9d0506d9159cf6772c58673ca541957f 1229 contrib/binary-s390/Packages.gz [idem SHA* sections] while the i386 DVD's Release file contains: MD5Sum: d13b81318834d02b0d98b242f7a9bd54 95 main/binary-i386/Release 6d3dcac69d656e4d29e250752d4c60f7 4491124 main/binary-i386/Packages 533dc7d61de165dd3396fccae1fb7b0f 1312112 main/binary-i386/Packages.gz d13b81318834d02b0d98b242f7a9bd54 95 main/debian-installer/binary-i386/Release 131ce2ead608557e8cb8c6454081b86b 121810 main/debian-installer/binary-i386/Packages bceb60db78d6cc22e6215b4696622ebe33477 main/debian-installer/binary-i386/Packages.gz 82496e277c857d132498fcf0f1873c88 98 contrib/binary-i386/Release 3354320f6f7e0affb399ea2be023703c 6397 contrib/binary-i386/Packages 6d5175848929b21cccfe73d3ad709524 2761 contrib/binary-i386/Packages.gz Note that on the s390 DVD, there is no line for main/debian-installer/binary-s390/Packages or .gz . The installer is looking for such a line, which will of course break if it isn't there... So plase check that you actually have the main/debian-installer/binary-s390/Packages and Packages.gz files on your DVD. If you have them and you're feeling adventurous, you can try adding the checksum of these files to the Release file, only the MD5Sum section is used. In the mean time, I'll let the debian-cd developers investigate why this happens and how to fix this in the image generation. Best regards, Anne Bezemer
Bug#673576: cdimage.debian.org for S390
On Sun, 20 May 2012, Alain Benvéniste wrote: Here is the FTP log Thanks, that's quite helpful. Can you please mail me a zipped copy (winzip is fine) of the dists/squeeze/Release file from your CD/DVD? And in the installer, after it fails, can you start a shell and report the result of the command: udpkg --print-architecture Also, is there any chance that you can try the install over an HTTP server instead of FTP? That might avoid some of the FTP intricacies that could possibly be affecting your results. = My notes so far: The combined installer + FTP server log looks like this: * = FTP Server (time skew is +2h -17sec) May 20 10:43:51 main-menu[258]: (process:657): wget: bad response to RETR: 550 /c:/debian/dists/oldstable/Release: No such file or directory. * [2] Sun 20May12 12:43:34 - (72) RETR debian//dists/testing/Release * file not found May 20 10:43:51 main-menu[258]: (process:657): wget: bad response to RETR: 550 /c:/debian/dists/testing/Release: No such file or directory. * [2] Sun 20May12 12:43:34 - (73) RETR debian//dists/unstable/Release * file not found May 20 10:43:51 main-menu[258]: (process:657): wget: bad response to RETR: 550 /c:/debian/dists/unstable/Release: No such file or directory. May 20 10:43:51 main-menu[258]: DEBUG: resolver (libc6-udeb): package doesn't exist (ignored) May 20 10:43:54 main-menu[258]: INFO: Menu item 'download-installer' selected * [2] Sun 20May12 12:43:38 - (74) RETR debian//dists/squeeze/main/binary-s390/Release * ok 95 bytes May 20 10:43:55 net-retriever: Not verifying Release signature: unauthenticated mode enabled (This should actually come _before_ the unauthenticated line) * [2] Sun 20May12 12:43:41 - (75) RETR debian//dists/squeeze/Release * ok 3234 bytes May 20 10:43:57 anna[706]: WARNING **: bad d-i Packages file May 20 10:43:57 net-retriever: Not verifying Release signature: unauthenticated mode enabled (Following timestamps do not match any more??) * [2] Sun 20May12 12:43:44 - (76) RETR debian//dists/squeeze/Release * ok 3234 bytes May 20 10:46:40 anna[706]: WARNING **: bad d-i Packages file May 20 10:46:41 main-menu[258]: INFO: Menu item 'download-installer' succeeded but requested to be left unconfigured. May 20 10:46:41 main-menu[258]: DEBUG: resolver (libc6-udeb): package doesn't exist (ignored) May 20 10:46:43 main-menu[258]: INFO: Menu item 'di-utils-shell' selected The WARNING **: bad d-i Packages file message comes from http://anonscm.debian.org/gitweb/?p=d-i/anna.git;a=summary which calls http://anonscm.debian.org/gitweb/?p=d-i/net-retriever.git;a=summary starting from case $cmd in packages) This downloads dists/squeeze/Release, skips gpg verification with log message, but then does not appear to try downloading any Packages file at all. There is a check line=`grep $pkgfile\$ $Release 2/dev/null` (result is not used) which will fail on \r\n line endings and then block anything else. Note that on the FTP connection, TYPE I is actually used just fine. Hmm, on i386, dists/squeeze/main/binary-i386/Release is 95 bytes with six \n line endings, which matches result above. But i386's dists/squeeze/Release is 4210 bytes... Another reason could be that $ARCH is incorrect. [I also noticed that net-retriever will only try Packages.gz and Packages, so no .bz2 as I assumed earlier. Though the .bz2 may still be used for the main (non-debian-installer) Packages files.]
Bug#673576: cdimage.debian.org for S390
On Sat, 19 May 2012, Alain Benvéniste wrote: Description: S390 install from local mode I am trying to install the 6.0.5 DVD iso without any access to the web. Installer fails A complete description of the problem is shown here: http://lists.debian.org/debian-cd/2012/05/msg00096.html So this ends you up with the same team; no problem, we just got a nice bug number to track this issue. Contact me if you need any more infos As already stated, we need relevant parts from your FTP server log file. Best regards, Anne Bezemer
Bug#662932: general: USB devices, mass storage, and printer cause system fail, and report a lot of log problems
On Wed, 7 Mar 2012, dacer wrote: Dear Maintainer, I have some problem with USB, mass storage devices and printer (it detect some component as storage device), sometimes it send a lot of logs to /var/log/syslog, like these: Mar 7 08:02:20 dacer kernel: [668285.604061] usb 1-8: reset high-speed USB device number 7 using ehci_hcd [..] I've seen similar problems occur when USB devices did not get enough power via the USB cable. And also when using long cables in USB2 (ehci) mode. So try a short, thick-wired low-resistance cable, and try USB1.1 (non-ehci) mode. Also try inserting a powered USB hub between computer and device. Best regards, Anne Bezemer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652459: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Tue, 20 Dec 2011, Roger Leigh wrote: On Tue, Dec 20, 2011 at 12:11:39AM +0100, J.A. Bezemer wrote: On Mon, 19 Dec 2011, Roger Leigh wrote: [..] Regarding the objections above, which are primarily concerned with the creation of a non-generic initramfs, how does this alternative suggestion sound: - The addition of usr= options analogous to the root= options which permit the bootloader to specify the /usr filesystem to mount. By default would do nothing, but grub could be updated to generate such options on systems with a separate /usr. Nonsense, should come from /etc/fstab. Of course. In case it wasn't implicit from the above, this information would necessarily need to be taken from /etc/fstab by update-grub or its equivalent for other bootloaders when generating grub.cfg (or its equivalent). Apologies for not being clear enough: there should not be a usr= parameter at all. Not in grub.cfg, and not anywhere else. The initramfs itself can (i.e. should) easily read it directly from /etc/fstab. (As I remember seeing elsewhere in this discussion: you could define a mount option mount-in-initramfs in /etc/fstab that the initramfs should look for to find out which filesystems it has to fsck mount.) Best regards, Anne Bezemer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652459: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Mon, 19 Dec 2011, Roger Leigh wrote: [..] Regarding the objections above, which are primarily concerned with the creation of a non-generic initramfs, how does this alternative suggestion sound: - The addition of usr= options analogous to the root= options which permit the bootloader to specify the /usr filesystem to mount. By default would do nothing, but grub could be updated to generate such options on systems with a separate /usr. Nonsense, should come from /etc/fstab. - We could also add an additional etc= option with the same semantics. Something like this would be necessary to support separately mounted /etc, but I see that as a completely separate discussion. Also note that you would need to patch _all_ existing bootloaders for _all_ arches to automatically include that option in any generated config file (namely by parsing the oneonly main config location which is /etc/fstab or possibly /etc/fstab.d). Related issue: how to specify desired fsck options (such as FSCKFIX) for / and /etc, while /etc is not yet mounted. Next, you'll be arguing that /etc/fstab should be moved to /. And /etc/default/rcS too. Oh, and now that I'm at it, do we also have initramfs support for bootlogd? and keyboard-setup? and hwclockfirst? (Last two could be required for proper fsck on various arches.) Plus their config files. Best regards, Anne Bezemer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Wed, 14 Dec 2011, Roger Leigh wrote: [..] The same argument applies to encryption. / and /usr both contain a selection of programs, libraries etc. If you're encrypting one, why would you not encrypt all of it? Speed. On one of my relatively low-power portable systems, I have everything encrypted except /boot and /usr. /boot for obvious reasons; /usr because decryption is heavily CPU-bound, making encrypted /usr unworkably slow. Since encryption is for privacy reasons, I need encrypted / because of /etc. (And encrypted /home and /var of course.) Indeed, this means that programs in /bin and libs in /lib are also encrypted. But this actually does _not_ slow things down: the Linux disk cache is sensibly caching the decrypted data, so often-used stuff from /bin and /lib happily remains in already-decrypted cache. The interesting stuff from /usr is generally too large and too seldomly used to remain cached. So I'd say preferably not move /bin and /lib to /usr; but I'd say absolutely definitely not move /usr/bin and /usr/lib to /. (Well, in the latter case: unless you make sure that /bin and /lib are actually mountable separately. But that would really defeat the purpose.) Best regards, Anne Bezemer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622697: Denyhosts default sync leaves 90% unprotected / Server design
Package: denyhosts Version: 2.6-7 Also reported upstream as http://sourceforge.net/tracker/?func=detailaid=3286240group_id=131204atid=720419 Since I have no idea how stable findable the sourceforge tracker will be in some far future, I thought I'd include the entire report below. There are some things Debian can do pending an upstream solution. (Warning: long report) First of all: THANKS for this very useful piece of software! Having run denyhosts in cron mode for a couple of years now, I was happy and never bothered to check its inner workings. But just now I have installed a few new boxes with denyhosts in daemon mode (Debian package), which gives very nice /var/log/denyhosts output. So I noticed that denyhosts will only receive max 50 new hosts from the central database during any sync run. I'd guess that's a hardcoded limit to prevent overloading the central server. The problem is that I get 50 new blocked hosts _every_ sync run, which made me think that I'm not receiving quite enough. Indeed, the denyhosts stats page shows an average of 14624 new hosts per day (though that page hasn't been updated for more than a month now). Default sync interval is 1 hour, so any denyhosts client will by default receive at most 24*50=1200 new hosts per day. That is 1200/14624 = just 8.2% of all new active crackers of that day. In other words, any given client will _never_ know of 91.8% of all active crackers. That's bad, since it renders the whole sync stuff mostly useless. So, I tried to tweak the sync settings a bit. If I can receive only a limited maximum number of new hosts per day, I might well opt to receive the hosts that are most likely to attack me, i.e. the hosts that have already attacked the most other clients. Let's say SYNC_DOWNLOAD_THRESHOLD=10. And quick botnet cracks would be handy to catch early, so SYNC_DOWNLOAD_RESILIENCY=3h. And to keep up with it all, SYNC_INTERVAL=8m. This seems a quite more useful setting, with the client mostly receiving some 30-40 new crackers during each sync run, but sometimes still the maximum amount of 50 (once every few hours). Conclusion 1: Please adjust the default sync settings which are _way_ wrong. Yet, there's still another problem. During any given sync run with the above settings, only 5-10 hosts get added to hosts.deny. Indeed, most of the hosts returned by the sync are _already_ in the hosts.deny file. They have been put in at previous sync runs. Quick checking shows that the central server will happily re-send crackers at least 10-20 times (once 37 repeats). This means the sync run is not working as advertised. Okay, syncing is hard. A syncing client defines a set of qualifying crackers, namely those that have been reported at least N times over a resiliency period of at least T hours. From that set, any given sync run wants exactly those crackers that _started_ to qualify between time S1 and S2 (S1=previous sync, S2=now). [Sidenote: S1 = WORK_DIR/sync-timestamp should be _server_ time, since client clocks can be way off. I didn't check if this file is indeed filled with a server-provided value.] I'd expect that the _started_ to qualify idea is the big problem. But the denyhosts central database design is closed-source (Boohoo!), so I can't check what is going wrong. That's the problem with closed-source. Yet I couldn't stop myself thinking about this problem, and ended up designing a denyhosts central-server idea myself. This design should work as intended, but I leave the implementation and verification as an excercise to the reader. (WARNING: This message is licensed under GNU GPL=3. Other licensing available on request payment.) It's probably easiest to use simple C types to make my point. Actually, it could be a C implementation, given enough RAM (currently ~10M crackers, max ~3k reports per cracker). cracker_t: addr_tipaddress time_tfirsttime time_tlatesttime time_tresiliency (= .latesttime - .firsttime) int totalreports(= all reports including cleaned-up ones) int currentreports (= length of current reports list) report_t *reports report_t: addr_treportingipaddress time_tfirstreporttime time_tlatestreporttime time_tlatesttotalresiliency (=report.latestreporttime - cracker.firsttime) report_t *next (linked list, or somesuch) Sync upload, reporter sends in some cracker: make sure reporter itself isn't reliably listed as cracker (if so, then drop the report entirely) if reported cracker already registered: if reportingipaddress already in reports list (*Note 1*): update report.latestreporttime and .latesttotalresiliency update cracker.latesttime and .resiliency else add new report at end of reports list (must stay sorted for condition (c) below) update cracker.* stuff else add new cracker at end of crackers list
Bug#420716: Still present
On Tue, 8 Feb 2011, Mark Weyer wrote: I originally reported this bug against the Etch images. The situation is still the same with the Lenny ones. ... and with Squeeze head --bytes=`isosize /dev/cdrom` /dev/cdrom | md5sum Best regards, Anne Bezemer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536312: Our stable release
Hi all, We haven't had a properly installable stable release for a full month now, #536312. Applies to both CD/DVD and network installs. I don't see much activity to resolve this. Are we so busy with squeeze and sid, that we don't care about lenny any more? Best regards, Anne Bezemer P.S. Just for the record, here is a condensed list of what's broken, based on Otavio's re-generated overrides (#536312 msg#25) --- task.good 2009-07-20 15:09:11.0 +0200 +++ task.now2009-07-29 10:56:03.166433439 +0200 -gksu Taskgnome-desktop +gnome-accessibilityTaskgnome-desktop -gpartedTaskgnome-desktop -gstreamer0.10-ffmpeg Taskgnome-desktop -gthumb Taskgnome-desktop -hal-cups-utils Taskgnome-desktop -hardinfo Taskgnome-desktop -hibernate Tasklaptop -kdeTaskkde-desktop -kde-core Taskkde-desktop -kdeadmin Taskkde-desktop -kdeartwork Taskkde-desktop -kdegraphicsTaskkde-desktop -kdemultimedia Taskkde-desktop -kdenetwork Taskkde-desktop -kdepim Taskkde-desktop +kde-standard Taskkde-desktop-not in lenny -kdeutils Taskkde-desktop -kpackage Taskkde-desktop -kpowersave Taskkde-desktop -lifereaTaskgnome-desktop -menu-xdg Taskgnome-desktop, kde-desktop +menu-xdg Taskkde-desktop -network-manager-gnome Taskgnome-desktop -nvclockTasklaptop +openoffice.org-help-fi Taskfinnish-desktop -not in lenny -openoffice.org-kde Taskkde-desktop -pidgin Taskgnome-desktop +pm-utils Taskdesktop, laptop -toshsetTasklaptop -tsclient Taskgnome-desktop -update-notifierTaskgnome-desktop -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#332782: Your contribution to the Debian release notes
I allow that my contribution to the Debian GNU/Linux release notes can be distributed under any DFSG-free license. Best regards, Anne Bezemer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
