Bug#745082: fakechroot: chfn in a fakechroot environment
control: reassign -1 src:fakechroot
This was thought to be a debootstrap bug for a while, but it
originates in fakechroot.
I applied upstream's recent fix, patch attached, and tested that
debootstrap now works with the modified fakechroot:
$ sudo dpkg -i sudo dpkg -i fakechroot_2.17.2-1.1_all.deb
libfakechroot_2.17.2-1.1_amd64.deb
$ fakechroot fakeroot debootstrap --variant=fakechroot unstable
[...]
I: Base system installed successfully.
Best wishes,
Mike
diff -Nru fakechroot-2.17.2/debian/changelog fakechroot-2.17.2/debian/changelog
--- fakechroot-2.17.2/debian/changelog 2013-12-24 20:04:16.0 +
+++ fakechroot-2.17.2/debian/changelog 2015-10-18 03:51:18.0 +
@@ -1,3 +1,10 @@
+fakechroot (2.17.2-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add empty audit_log_acct_message (closes: #745082).
+
+ -- Michael Gilbert <mgilb...@debian.org> Sun, 18 Oct 2015 03:46:22 +
+
fakechroot (2.17.2-1) unstable; urgency=low
* New upstream release.
diff -Nru fakechroot-2.17.2/debian/patches/audit.patch fakechroot-2.17.2/debian/patches/audit.patch
--- fakechroot-2.17.2/debian/patches/audit.patch 1970-01-01 00:00:00.0 +
+++ fakechroot-2.17.2/debian/patches/audit.patch 2015-10-18 03:50:40.0 +
@@ -0,0 +1,32 @@
+description: add empty audit_log_acct_message
+bug-debian: http://bugs.debian.org/745082
+
+--- /dev/null
b/src/audit_log_acct_message.c
+@@ -0,0 +1,16 @@
++/*
++ * Copyright (C) 2015 JH Chatenet <jhcha54...@free.fr>
++ *
++ * Licensed under the LGPL v2.1.
++*/
++
++
++#include
++
++#include "libfakechroot.h"
++
++
++wrapper(audit_log_acct_message, int, (int audit_fd, int type, const char *pgname, const char *op, const char *name, unsigned int id, const char *host, const char *addr, const char *tty, int result))
++{
++return 0;
++}
+--- a/src/Makefile.am
b/src/Makefile.am
+@@ -28,6 +28,7 @@ libfakechroot_la_SOURCES = \
+ _xftw64.c \
+ access.c \
+ acct.c \
++audit_log_acct_message.c \
+ bind.c \
+ bindtextdomain.c \
+ canonicalize_file_name.c \
diff -Nru fakechroot-2.17.2/debian/patches/series fakechroot-2.17.2/debian/patches/series
--- fakechroot-2.17.2/debian/patches/series 2013-12-24 17:56:39.0 +
+++ fakechroot-2.17.2/debian/patches/series 2015-10-18 03:36:33.0 +
@@ -1,2 +1,3 @@
# series file
Export-V-variable-so-it-can-be-changed-with-config.patch
+audit.patch
Bug#797340: choose-mirror: use httpredir.debian.org by default
On Sun, Aug 30, 2015 at 4:49 AM, Philipp Kern wrote: I have seen issues with this. It might be good for the general case of apt where you see what the failure is and can retry if needed. But in the US it caused me some aborted installations because there was some mirror in the rotation that was broken. debian-installer - I guess in this case debootstrap - does not retry a broken file. (apt also doesn't do that but it's harder to figure out in d-i what's going on.) I helped improve this problem a couple years ago [0]. I guess that's not totally solved, or maybe httpredir causes different behavior. That is not something I've yet looked at, but I should. debootstrap's current design is to retry package downloads up to 10 times, and then give up entirely on bootstrapping. That seems like it should be robust, but maybe not. Relatedly apt 1.1~exp9 will often run into problems with httpredir as source, so it is you could have run into that once past debootstrap. Best wishes, Mike [0] https://bugs.debian.org/618920
Bug#797340: choose-mirror: use httpredir.debian.org by default
package: choose-mirror severity: wishlist version: 2.65 This article [0] had some extensive complaints about Debian, one of which is that the installer has too many screens (apparently 20 in their case). Setting a default mirror without user intervention would nicely save 3 of those steps, and httpredir.debian.org is in many ways the ideal mirror selection anyway. Obviously expert mode would want to retain the full 3 screen mirror selection process. Best wishes, Mike [0]http://www.everydaylinuxuser.com/2015/06/3-ways-to-improve-debian-and-i-havent.html
Bug#788173: rescue-mode: kfreebsd rescue fails with can't create /dev/md
package: rescue-mode version: 1.51 severity: important x-debbugs-cc: debian-...@lists.debian.org Adding the line set kFreeBSD.rescue/enable=true in a grub entry and booting the kfreebsd installer fails when executing rescue-mode. The error is: mkdir: can't create directory '/dev/md': Operation not supported /dev is mounted rw and also doing mkdir manually fails the same. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mngrvovmzq0vet+4o9u--o8iteriqhllcvxar9cz5j...@mail.gmail.com
Re: Bug#778492: unblock: ndisc6/1.0.1-2
control: tag -1 - moreinfo On Mon, Mar 30, 2015 at 12:58 AM, Cyril Brulebois wrote: Thanks for trying, but no, that's not sufficient. I really would like having a real use case where the bug gets reproduced without “cheating” (for the lack of a better wording), so that we can actually check that the change isn't worse than the bug it's supposed to fix. It turns out the difficulty getting rdnssd automatically installed is a bug: http://bugs.debian.org/782299 Steve will be uploading a debian-cd fix soon, but in the meantime I tested a mini.iso (since it configures networking sufficiently early to be able to fetch the package) for a sid gnome install. Here is the installer syslog relevant to rdnssd; netcfg[1369]: rdnssd started; PID: 1384 [...] apt-install: Queueing package rdnssd for later installation netcfg[1369]: DEBUG: Stopping rdnssd, PID 1384 [...] in-target: The following NEW packages will be installed: in-target: rdnssd [...] in-target: Unpacking rdnssd (1.0.1-2) [...] in-target: Setting up rdnssd (1.0.1-2) [...] in-target: pkgsel: starting tasksel [selected gnome as the desktop environment] [...] in-target: The following packages will be REMOVED: in-target: rdnssd [...] in-target: Removing rdnssd (1.0.1-2) [...] in-target: Setting up network-manager-gnome (0.9.10.0-2) In conclusion again everything works entirely as expected. Is this now sufficient? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MOT3OVGaZcDJVejLwu10G466tsMMir=1vvlt63n-th...@mail.gmail.com
Re: Bug#778492: unblock: ndisc6/1.0.1-2
control: tag -1 - moreinfo On Wed, Feb 25, 2015 at 11:23 PM, Cyril Brulebois wrote: It would be nice to compare what happens when one installs gnome/jessie vs. gnome/sid. I really wouldn't want this conflict to trigger having rdnssd installed and network-manager/gnome not… Everything seems to turn out fine. I couldn't get netcfg to trigger rdnssd installation with my set up, so here is what I did to mimic the process: boot from jessie RC2 nothing special up through pkgsel before pkgsel, manually install rdnssd 1.0.1-2 from sid proceed with pkgsel (making sure to select gnome in tasksel) To resolve the rdnssd/nm conflict, apt concludes that nm should be installed and rdnssd removed, which then happens. Afterwards: $ dpkg -l | grep -e network-manager -e rdnssd | cut -d' ' -f1,2,3 ii network-manager ii network-manager-gnome rc rdnssd On reboot, networking with nm works correctly. This effectively mimics the configurations where netcfg automatically adds in rdnssd. Is this sufficient? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mmryvzhubwjcn+7ivy2k9jfwteou9_r4-xafehs+pf...@mail.gmail.com
Re: Hints for d-i jessie RC2, part 1
On Thu, Mar 5, 2015 at 1:07 AM, Cyril Brulebois wrote: Hi people, here's a first round of unblock/unblock-udeb hints for the upcoming d-i jessie RC2. Don't hesitate to ask questions if anything looks fishy. Cyril, Would it be possible also to unblock ndisc6 in time for RC2? I saw no problems in my test installs (bug #778492), but I guess it could be good to get wider testing before the final jessie d-i. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mn3uasvke2kiz5bn65-+atgwxev1zp3u_nfrghromn...@mail.gmail.com
Re: Bug#778492: unblock: ndisc6/1.0.1-2
On Sun, Mar 1, 2015 at 12:32 AM, Michael Gilbert wrote: It would be nice to compare what happens when one installs gnome/jessie vs. gnome/sid. I really wouldn't want this conflict to trigger having rdnssd installed and network-manager/gnome not… After a successful jessie gnome install over ipv6 $ dpkg -l | grep rdnssd $ dpkg -l | grep network-manager network-manager network-manager-gnome After a successful sid gnome install over ipv6 $ dpkg -l | grep rdnssd $ dpkg -l | grep network-manager network-manager network-manager-gnome I had retyped that in from another computer, and I just now noticed the commands are incorrect for the shown output. For completeness, the actual commands were $ dpkg -l | grep package | cut -d' ' -f3 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MMF0�wr6zkwlhfz8nc+roqzrxl39ofwhripcyf...@mail.gmail.com
Bug#779466: unblock: e2fsprogs/1.42.12-1.1
package: release.debian.org
user: release.debian@packages.debian.org
usertags: unblock
severity: normal
x-debbugs-cc: debian-boot@lists.debian.org
Please consider unblocking e2fsprogs. A security issue is fixed.
unblock e2fsprogs/1.42.12-1.1
unblock-udeb e2fsprogs/1.42.12-1.1
diff -Nru e2fsprogs-1.42.12/debian/changelog e2fsprogs-1.42.12/debian/changelog
--- e2fsprogs-1.42.12/debian/changelog 2014-08-29 12:51:13.0 +
+++ e2fsprogs-1.42.12/debian/changelog 2015-02-22 02:18:20.0 +
@@ -1,3 +1,10 @@
+e2fsprogs (1.42.12-1.1) unstable; urgency=high
+
+ * Non-maintainer upload by the Security Team.
+ * Fix CVE-2015-1572: incomplete fix for CVE-2015-0247 (closes: #778948).
+
+ -- Michael Gilbert mgilb...@debian.org Sun, 22 Feb 2015 01:50:57 +
+
e2fsprogs (1.42.12-1) unstable; urgency=low
* New upstream version
diff -Nru e2fsprogs-1.42.12/debian/patches/CVE-2015-1572.patch e2fsprogs-1.42.12/debian/patches/CVE-2015-1572.patch
--- e2fsprogs-1.42.12/debian/patches/CVE-2015-1572.patch 1970-01-01 00:00:00.0 +
+++ e2fsprogs-1.42.12/debian/patches/CVE-2015-1572.patch 2015-02-22 02:18:20.0 +
@@ -0,0 +1,48 @@
+From 49d0fe2a14f2a23da2fe299643379b8c1d37df73
+From: Theodore Ts'o ty...@mit.edu
+Date: Fri, 6 Feb 2015 12:46:39 -0500
+Subject: libext2fs: fix potential buffer overflow in closefs()
+
+The bug fix in f66e6ce4446: libext2fs: avoid buffer overflow if
+s_first_meta_bg is too big had a typo in the fix for
+ext2fs_closefs(). In practice most of the security exposure was from
+the openfs path, since this meant if there was a carefully crafted
+file system, buffer overrun would be triggered when the file system was
+opened.
+
+However, if corrupted file system didn't trip over some corruption
+check, and then the file system was modified via tune2fs or debugfs,
+such that the superblock was marked dirty and then written out via the
+closefs() path, it's possible that the buffer overrun could be
+triggered when the file system is closed.
+
+Also clear up a signed vs unsigned warning while we're at it.
+
+Thanks to Nick Kralevich n...@google.com for asking me to look at
+compiler warning in the code in question, which led me to notice the
+bug in f66e6ce4446.
+
+Addresses: CVE-2015-1572
+
+Signed-off-by: Theodore Ts'o ty...@mit.edu
+
+--- a/lib/ext2fs/closefs.c
b/lib/ext2fs/closefs.c
+@@ -287,7 +287,7 @@ errcode_t ext2fs_flush2(ext2_filsys fs, int flags)
+ dgrp_t j;
+ #endif
+ char *group_ptr;
+- int old_desc_blocks;
++ blk64_t old_desc_blocks;
+ struct ext2fs_numeric_progress_struct progress;
+
+ EXT2_CHECK_MAGIC(fs, EXT2_ET_MAGIC_EXT2FS_FILSYS);
+@@ -346,7 +346,7 @@ errcode_t ext2fs_flush2(ext2_filsys fs, int flags)
+ group_ptr = (char *) group_shadow;
+ if (fs-super-s_feature_incompat EXT2_FEATURE_INCOMPAT_META_BG) {
+ old_desc_blocks = fs-super-s_first_meta_bg;
+- if (old_desc_blocks fs-super-s_first_meta_bg)
++ if (old_desc_blocks fs-desc_blocks)
+ old_desc_blocks = fs-desc_blocks;
+ } else
+ old_desc_blocks = fs-desc_blocks;
diff -Nru e2fsprogs-1.42.12/debian/patches/series e2fsprogs-1.42.12/debian/patches/series
--- e2fsprogs-1.42.12/debian/patches/series 1970-01-01 00:00:00.0 +
+++ e2fsprogs-1.42.12/debian/patches/series 2015-02-22 02:18:20.0 +
@@ -0,0 +1 @@
+CVE-2015-1572.patch
Re: Bug#778492: unblock: ndisc6/1.0.1-2
It would be nice to compare what happens when one installs gnome/jessie vs. gnome/sid. I really wouldn't want this conflict to trigger having rdnssd installed and network-manager/gnome not… After a successful jessie gnome install over ipv6 $ dpkg -l | grep rdnssd $ dpkg -l | grep network-manager network-manager network-manager-gnome After a successful sid gnome install over ipv6 $ dpkg -l | grep rdnssd $ dpkg -l | grep network-manager network-manager network-manager-gnome Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MNJN7RUa5o=udsy8ah1ofsoxnjkmqqy9f7iq3lb_pk...@mail.gmail.com
Bug#778734: unblock: bind9/9.9.5.dfsg-9
package: release.debian.org
user: release.debian@packages.debian.org
usertags: unblock
severity: normal
x-debbugs-cc: debian-boot@lists.debian.org
Please consider unblocking bind9. It fixes a new security issue.
unblock bind9/9.9.5.dfsg-9
unblock-udeb bind9/9.9.5.dfsg-9
diff -u bind9-9.9.5.dfsg/debian/changelog bind9-9.9.5.dfsg/debian/changelog
--- bind9-9.9.5.dfsg/debian/changelog
+++ bind9-9.9.5.dfsg/debian/changelog
@@ -1,3 +1,10 @@
+bind9 (1:9.9.5.dfsg-9) unstable; urgency=high
+
+ * Fix CVE-2015-1349: named crash due to managed key rollover, primarily only
+affecting setups using DNSSEC (closes: #778733).
+
+ -- Michael Gilbert mgilb...@debian.org Thu, 19 Feb 2015 03:42:21 +
+
bind9 (1:9.9.5.dfsg-8) unstable; urgency=medium
* Launch rndc command in the background in networking scripts to avoid a
only in patch2:
unchanged:
--- bind9-9.9.5.dfsg.orig/lib/dns/zone.c
+++ bind9-9.9.5.dfsg/lib/dns/zone.c
@@ -8496,6 +8496,12 @@
namebuf, tag);
trustkey = ISC_TRUE;
}
+ } else {
+ /*
+ * No previously known key, and the key is not
+ * secure, so skip it.
+ */
+ continue;
}
/* Delete old version */
@@ -8544,7 +8550,7 @@
trust_key(zone, keyname, dnskey, mctx);
}
- if (!deletekey)
+ if (secure !deletekey)
set_refreshkeytimer(zone, keydata, now);
}
Bug#778492: unblock: ndisc6/1.0.1-2
package: release.debian.org
user: release.debian@packages.debian.org
usertags: unblock
severity: normal
x-debbugs-cc: debian-boot@lists.debian.org
Please consider unblocking ndisc6. I did a QA upload to fix bug #740998.
The kfreebsd builds are missing because of #764692, which sounds
unlikely to be fixed for jessie.
unblock ndisc6/1.0.1-2
unblock-udeb ndisc6/1.0.1-2
diff -u ndisc6-1.0.1/debian/control ndisc6-1.0.1/debian/control
--- ndisc6-1.0.1/debian/control
+++ ndisc6-1.0.1/debian/control
@@ -1,7 +1,7 @@
Source: ndisc6
Section: net
Priority: optional
-Maintainer: Rémi Denis-Courmont r...@remlab.net
+Maintainer: Debian QA Group packa...@qa.debian.org
Build-Depends: cdbs, debhelper (= 7), autotools-dev, gettext
Standards-Version: 3.9.1
Homepage: http://www.remlab.net/ndisc6/
@@ -40,6 +40,7 @@
Depends: ${shlibs:Depends}, ${perl:Depends}, ${misc:Depends}
Recommends: resolvconf
Suggests: ndisc6
+Conflicts: network-manager
Description: IPv6 recursive DNS server discovery daemon
rdnssd autoconfigures recursive DNS servers on IPv6 networks
using ICMPv6 Neighbor Discovery (RFC 5006), and can update the
diff -u ndisc6-1.0.1/debian/changelog ndisc6-1.0.1/debian/changelog
--- ndisc6-1.0.1/debian/changelog
+++ ndisc6-1.0.1/debian/changelog
@@ -1,3 +1,11 @@
+ndisc6 (1.0.1-2) unstable; urgency=medium
+
+ * QA upload.
+ * Set maintainer to the Debian QA Group (see #713004).
+ * Add conflicts between rdnssd and network-manager (closes: #740998).
+
+ -- Michael Gilbert mgilb...@debian.org Sat, 14 Feb 2015 01:16:37 +
+
ndisc6 (1.0.1-1) unstable; urgency=low
* New upstream release:
Bug#778351: unblock: isc-dhcp/4.3.1-6
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal x-debbugs-cc: debian-boot@lists.debian.org Please consider unblocking isc-dhcp. It fixes a regression in init script error handling (bug #755834, unfortunate bug # typo in the changelog). There are no changes to the udebs. unblock isc-dhcp/4.3.1-6 unblock-udeb isc-dhcp/4.3.1-6 diff --git a/debian/changelog b/debian/changelog index 4fd1f35..5f5c568 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +isc-dhcp (4.3.1-6) unstable; urgency=medium + + * Fix a regression in error handling for the server's init script +(closes: #775834). +- Thanks to François-Régis Vuillemin. + + -- Michael Gilbert mgilb...@debian.org Fri, 13 Feb 2015 05:13:19 + + isc-dhcp (4.3.1-5) unstable; urgency=medium * Dynamically link against system bind libraries. diff --git a/debian/rules b/debian/rules index be0317e..780bc4a 100755 --- a/debian/rules +++ b/debian/rules @@ -62,6 +62,10 @@ override_dh_install: cp contrib/dhcp-lease-list.pl \ debian/isc-dhcp-server/usr/sbin/dhcp-lease-list +override_dh_installinit: + dh_installinit -Nisc-dhcp-server + dh_installinit -pisc-dhcp-server --error-handler=init_script_error_handler + override_dh_strip: dh_strip --dbg-package=isc-dhcp-dbg
Bug#778364: unblock: glibc/2.19-15
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal x-debbugs-cc: debian-boot@lists.debian.org Please consider unblocking glibc. It fixes 5 security issues: https://security-tracker.debian.org/tracker/source-package/glibc unblock glibc/2.19-15 unblock-udeb glibc/2.19-15 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MPTyhd=riPdP=_yhfoueqe0lk8fs2vjoxdj_kqvzh5...@mail.gmail.com
Bug#778366: unblock: kfreebsd-10/10.1~svn274115-2
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal x-debbugs-cc: debian-boot@lists.debian.org Please consider unblocking kfreebsd-10. It fixes 2 security issues: https://security-tracker.debian.org/kfreebsd-10 unblock kfreebsd-10/10.1~svn274115-2 unblock-udeb kfreebsd-10/10.1~svn274115-2 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MNj5zAqn8SsLZUAS_9VHfqVr05shefViaG=q=9VsRD=j...@mail.gmail.com
Bug#776186: busybox: CVE-2014-9645
control: tag -1 patch, pending
Hi,
I uploaded an nmu fixing this issue to delayed/15. Please let me know
if I can shorten or if you want to do a maintainer upload instead.
See proposed patch attached.
Best wishes,
Mike
diff -Nru busybox-1.22.0/debian/changelog busybox-1.22.0/debian/changelog
--- busybox-1.22.0/debian/changelog 2014-11-14 09:53:24.0 +
+++ busybox-1.22.0/debian/changelog 2015-01-26 03:21:32.0 +
@@ -1,3 +1,10 @@
+busybox (1:1.22.0-14.1) unstable; urgency=medium
+
+ * Non-maintainer upload by the Security Team.
+ * Fix CVE-2014-9645: modeprobe accepts paths as modules (closes: #776186).
+
+ -- Michael Gilbert mgilb...@debian.org Mon, 26 Jan 2015 03:18:37 +
+
busybox (1:1.22.0-14) medium; urgency=low
* one more attempt to fix the glibc build-depend for #769190, now
diff -Nru busybox-1.22.0/debian/patches/CVE-2014-9645.patch busybox-1.22.0/debian/patches/CVE-2014-9645.patch
--- busybox-1.22.0/debian/patches/CVE-2014-9645.patch 1970-01-01 00:00:00.0 +
+++ busybox-1.22.0/debian/patches/CVE-2014-9645.patch 2015-01-26 03:24:58.0 +
@@ -0,0 +1,25 @@
+From 4e314faa0aecb66717418e9a47a4451aec59262b
+From: Denys Vlasenko vda.li...@googlemail.com
+Date: Thu, 20 Nov 2014 17:24:33 +
+Subject: modprobe,rmmod: reject module names with slashes
+
+--- a/modutils/modprobe.c
b/modutils/modprobe.c
+@@ -239,6 +239,17 @@ static void add_probe(const char *name)
+ {
+ struct module_entry *m;
+
++ /*
++ * get_or_add_modentry() strips path from name and works
++ * on remaining basename.
++ * This would make rmmod dir/name and modprobe dir/name
++ * to work like rmmod name and modprobe name,
++ * which is wrong, and can be abused via implicit modprobing:
++ * ifconfig /usbserial up tries to modprobe netdev-/usbserial.
++ */
++ if (strchr(name, '/'))
++ bb_error_msg_and_die(malformed module name '%s', name);
++
+ m = get_or_add_modentry(name);
+ if (!(option_mask32 (OPT_REMOVE | OPT_SHOW_DEPS))
+ (m-flags (MODULE_FLAG_LOADED | MODULE_FLAG_BUILTIN))
diff -Nru busybox-1.22.0/debian/patches/series busybox-1.22.0/debian/patches/series
--- busybox-1.22.0/debian/patches/series 2014-11-10 12:06:53.0 +
+++ busybox-1.22.0/debian/patches/series 2015-01-26 03:24:54.0 +
@@ -27,3 +27,5 @@
stop-checking-ancient-kernel-version.patch
iproute-support-onelink-route-option-and-print-route-flags.patch
update-deb-format-support.patch
+
+CVE-2014-9645.patch
Bug#776186: busybox: CVE-2014-9645
On Sun, Jan 25, 2015 at 10:49 PM, Cyril Brulebois wrote: I uploaded an nmu fixing this issue to delayed/15. Please let me know if I can shorten or if you want to do a maintainer upload instead. See proposed patch attached. NACK, it won't make it into testing this way. Ok, cancelled. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mpmysijb+-mky-x_swpjiagy6f-bz3u4ssxkoytndn...@mail.gmail.com
unblock: bind9/1:9.9.5.dfsg-8
Please unblock bind9. It fixes an issue where a hang in named could bring down the entire network #760555. The changes only affect the bind9 binary package, so nothing in the udebs has chaned. unblock bind9/1:9.9.5.dfsg-8 unblock-udeb bind9/1:9.9.5.dfsg-8 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MNxYu1Wsj=B=D0zWEsU8aZ1dvWEuab6vn3pELgbn-nZ=a...@mail.gmail.com
unblock: bind9/1:9.9.5.dfsg-8
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Please unblock bind9. It fixes an issue where a hang in named could bring down the entire network #760555. This only touches files in the bind9 binary package, so nothing in the udebs has changed. unblock bind9/1:9.9.5.dfsg-8 unblock-udeb bind9/1:9.9.5.dfsg-8 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MMwuKXytrKOc8O0YF-S=oz9f3w6kryqonyl1if17xb...@mail.gmail.com
Re: Bug#762762: Updating isc-dhcp udeb to dynamically link bind
On Fri, Oct 31, 2014 at 9:57 AM, Steven Chamberlain wrote: On 31/10/14 10:44, Michael Tokarev wrote: Is it on kfreebsd, or on linux kernel too? I wonder maybe we should switch to isc-dhcp on all variants/arches, and ditch udhcpc... Linux d-i only uses udhcpc at the moment. (Ubuntu uses isc-dhcp though IIRC). We did discuss converging on a single DHCP client across all Debian architectures, but: * it's way too late to do this for jessie, I doubt KiBi would even hear of it! d-i can be very sensitive to changes and this might break in non-obvious use cases that don't get tested much Is it possibly a one or two line diff to change back to isc-dhcp? If so, it is possible that it may be considered. Is that set in netcfg? Since isc-dhcp was the wheezy default and there are quite a few issues (including RC ones) stemming from udhcpc, it probably makes a lot of sense to go back to what's known to work well. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MOdvF8=1wwvt0v2fyyh_bwkv_abcmj2crtwjpw_omr...@mail.gmail.com
Re: Bug#762762: Updating isc-dhcp udeb to dynamically link bind (was: Bug#762762: nmu fixing bind issues)
On Mon, Oct 6, 2014 at 9:11 PM, Steven Chamberlain wrote: On 00:52, Steven Chamberlain wrote: Michael Gilbert wrote: Would it be ok to stage the changes in unstable to make it somewhat easy for porters to test? I don't particularly need that as I can build the udebs and d-i image from them myself. But doing so would allow others to be testing it meanwhile, so I'm okay with it. Did you already make a new version of the isc-dhcp package based on these new export udebs? If so, where can I find it? Hi Steven, The new isc-dhcp is now uploaded. Please let me know how your testing goes. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mpbb25ndu4q1udfxrh2cph3vfxhorfo6xk-jcxg3sa...@mail.gmail.com
Re: Bug#762762: Updating isc-dhcp udeb to dynamically link bind (was: Bug#762762: nmu fixing bind issues)
On Mon, Oct 6, 2014 at 9:11 PM, Steven Chamberlain wrote: On 00:52, Steven Chamberlain wrote: Michael Gilbert wrote: Would it be ok to stage the changes in unstable to make it somewhat easy for porters to test? I don't particularly need that as I can build the udebs and d-i image from them myself. But doing so would allow others to be testing it meanwhile, so I'm okay with it. Did you already make a new version of the isc-dhcp package based on these new export udebs? If so, where can I find it? No, not yet. Will probably get to that tomorrow. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MNmqCSH4fnnXCE80=f1Z3B1A+Y2F=1idn-tzifb9+x...@mail.gmail.com
Re: Updating isc-dhcp udeb to dynamically link bind (was: Bug#762762: nmu fixing bind issues)
On Thu, Oct 2, 2014 at 11:05 PM, Cyril Brulebois wrote:
AFAICT isc-dhcp is only used on non-linux archs, through that part of
Depends:
isc-dhcp-client-udeb [kfreebsd-any hurd-any]
You definitely want to get porters involved in checking the resulting
udebs, and I've therefore added them in Cc.
Dear hurd and kfreebsd porters. I plan to upload the attached patch,
which along with the previous upload introduces a bind udeb, which
will be dynamically linked by the dhcp udeb. Please let me know if
this looks ok.
Have you checked possible impact on the installed size? At least
kfreebsd has been having regular size-related issues, so it might be
worth checking this point (even if the ramfs tweaks introduced in the
past few weeks should avoid further issues).
The install size for dhcp+bind linked isn't much different from the
existing size of dhcp+bind embed, which is about 1.8 MB uncompressed.
Best wishes,
Mike
diff -u bind9-9.9.5.dfsg/debian/changelog bind9-9.9.5.dfsg/debian/changelog
--- bind9-9.9.5.dfsg/debian/changelog
+++ bind9-9.9.5.dfsg/debian/changelog
@@ -1,3 +1,13 @@
+bind9 (1:9.9.5.dfsg-4.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Disable parallel build. Closes: #762766
+ * Set -fno-delete-null-pointer-checks. Closes: #750760
+ * Fix dependencies for libbind-export-udeb. Closes: #762762
+ * Don't install configuration files to /usr. Closes: #762948
+
+ -- Michael Gilbert mgilb...@debian.org Sun, 28 Sep 2014 02:56:44 +
+
bind9 (1:9.9.5.dfsg-4.1) unstable; urgency=low
* Non-maintainer upload.
diff -u bind9-9.9.5.dfsg/debian/control bind9-9.9.5.dfsg/debian/control
--- bind9-9.9.5.dfsg/debian/control
+++ bind9-9.9.5.dfsg/debian/control
@@ -187,9 +187,8 @@
Architecture: any
Priority: extra
Depends: ${shlibs:Depends}
-XC-Package-Type: udeb
+Package-Type: udeb
Description: Exported BIND libraries for debian-installer
- libbind-export-udeb is a minimal bind package used by the debian-installer.
Package: libdns-export100
Section: libs
diff -u bind9-9.9.5.dfsg/debian/rules bind9-9.9.5.dfsg/debian/rules
--- bind9-9.9.5.dfsg/debian/rules
+++ bind9-9.9.5.dfsg/debian/rules
@@ -23,12 +23,13 @@
OPT = -O2
endif
-ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
-NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
-export MAKEFLAGS += -j$(NUMJOBS)
-endif
+# parallel build options disabled for #762766
+#ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
+#NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
+#export MAKEFLAGS += -j$(NUMJOBS)
+#endif
-export CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE $(DEBUG) $(OPT)
+export CFLAGS=-fno-strict-aliasing -fno-delete-null-pointer-checks -DDIG_SIGCHASE $(DEBUG) $(OPT)
ifeq ($(DEB_HOST_ARCH_OS),kfreebsd)
EXTRA_FEATURES=--disable-linux-caps --disable-threads
@@ -126,6 +127,7 @@
dh_installdirs
$(MAKE) -C export install DESTDIR=`pwd`/debian/bind9
$(MAKE) install DESTDIR=`pwd`/debian/bind9
+ rm -rf debian/bind9/usr/etc
rm -f debian/bind9/usr/lib/*.la
install -c -o bin -g bin -m 444 debian/db.0 ${ETCBIND}/db.0
install -c -o bin -g bin -m 444 debian/db.0 ${ETCBIND}/db.255
@@ -201,6 +203,7 @@
dh_fixperms -a
dh_makeshlibs -a
dh_installdeb -a
+ sed 's/[^ ]*/libbind-export-udeb/'3 debian/*-export*/DEBIAN/shlibs debian/libbind-export-udeb/DEBIAN/shlibs
dh_shlibdeps -a
for i in $$(sed -n '/^Package:/s/^.* //p' debian/control); do cat debian/vars.in debian/$$i.substvars; done
cat debian/vars.in debian/substvars
Re: Updating isc-dhcp udeb to dynamically link bind (was: Bug#762762: nmu fixing bind issues)
On Sun, Oct 5, 2014 at 7:02 PM, Cyril Brulebois wrote:
Michael Gilbert mgilb...@debian.org (2014-10-05):
Dear hurd and kfreebsd porters. I plan to upload the attached patch,
which along with the previous upload introduces a bind udeb, which
will be dynamically linked by the dhcp udeb. Please let me know if
this looks ok.
NAK.
+bind9 (1:9.9.5.dfsg-4.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Disable parallel build. Closes: #762766
If parallel building worked before you changed things, you get to fix
the issues rather than working around them. bind9 is a pain to build,
so having to deal with a forced -j1 is a nasty regression.
It's a rarely used path through the build system (--enable-exportlib),
so it's sort of unsurprising that there was a lurking issue.
Anyway, in the meantime I fixed the problem. Thanks for the prodding.
+ * Set -fno-delete-null-pointer-checks. Closes: #750760
+ * Fix dependencies for libbind-export-udeb. Closes: #762762
This udeb doesn't make any sense to me.
$ cat ./debian/libbind-export-udeb/DEBIAN/shlibs
libdns-export 100 libbind-export-udeb
libirs-export 91 libbind-export-udeb
libisc-export 95 libbind-export-udeb
libisccfg-export 90 libbind-export-udeb
The udeb is unversioned. ABI is going to be broken as usual in later
uploads, meaning the udeb shipping these shared objects will break
reverse dependencies:
/usr/lib/libisccfg-export.so.90.1.0
/usr/lib/libdns-export.so.100.2.2
/usr/lib/libirs-export.so.91.0.0
/usr/lib/libisc-export.so.95.5.0
/usr/lib/libdns-export.so.100 - libdns-export.so.100.2.2
/usr/lib/libisccfg-export.so.90 - libisccfg-export.so.90.1.0
/usr/lib/libirs-export.so.91 - libirs-export.so.91.0.0
/usr/lib/libisc-export.so.95 - libisc-export.so.95.5.0
I really fail to see how you could possibly imagine anything could work.
I was trying to avoid an explosion in the number of udebs, but I get
your point now that won't work. I've split up the udebs now so things
can be properly versioned.
Since we're late in the D-I release cycle, since we're late in the
release cycle in general (window for transitions closed past month),
since there was no coordination whatsoever, and since there is
apparently no well thought through plan, I think I'll oppose isc-dhcp's
using such a udeb.
Maybe I've addressed your concerns, maybe not, but please consider the
revised changes attached.
Best wishes,
Mike
diff -u bind9-9.9.5.dfsg/debian/changelog bind9-9.9.5.dfsg/debian/changelog
--- bind9-9.9.5.dfsg/debian/changelog
+++ bind9-9.9.5.dfsg/debian/changelog
@@ -1,3 +1,13 @@
+bind9 (1:9.9.5.dfsg-4.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix intermittent parallel build failure. Closes: #762766
+ * Set -fno-delete-null-pointer-checks. Closes: #750760
+ * Use separate packages for the udebs. Closes: #762762
+ * Don't install configuration files to /usr. Closes: #762948
+
+ -- Michael Gilbert mgilb...@debian.org Mon, 06 Oct 2014 01:23:57 +
+
bind9 (1:9.9.5.dfsg-4.1) unstable; urgency=low
* Non-maintainer upload.
diff -u bind9-9.9.5.dfsg/debian/control bind9-9.9.5.dfsg/debian/control
--- bind9-9.9.5.dfsg/debian/control
+++ bind9-9.9.5.dfsg/debian/control
@@ -182,15 +182,6 @@
.
This package delivers development files for the exported BIND libraries.
-Package: libbind-export-udeb
-Section: debian-installer
-Architecture: any
-Priority: extra
-Depends: ${shlibs:Depends}
-XC-Package-Type: udeb
-Description: Exported BIND libraries for debian-installer
- libbind-export-udeb is a minimal bind package used by the debian-installer.
-
Package: libdns-export100
Section: libs
Architecture: any
@@ -200,6 +191,13 @@
.
This package delivers the exported libdns shared library.
+Package: libdns-export100-udeb
+Section: debian-installer
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+XC-Package-Type: udeb
+Description: Exported DNS library for debian-installer
+
Package: libisc-export95
Section: libs
Architecture: any
@@ -209,6 +207,13 @@
.
This package delivers the exported libisc shared library.
+Package: libisc-export95-udeb
+Section: debian-installer
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+XC-Package-Type: udeb
+Description: Exported ISC library for debian-installer
+
Package: libisccfg-export90
Section: libs
Architecture: any
@@ -218,6 +223,13 @@
.
This package delivers the exported libisccfg shared library.
+Package: libisccfg-export90-udeb
+Section: debian-installer
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+XC-Package-Type: udeb
+Description: Exported ISC CFG library for debian-installer
+
Package: libirs-export91
Section: libs
Architecture: any
@@ -228,0 +241,7 @@
+
+Package: libirs-export91-udeb
+Section: debian-installer
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+XC-Package-Type: udeb
+Description: Exported IRS library for debian-installer
diff -u bind9
Re: Bug#762762: Updating isc-dhcp udeb to dynamically link bind (was: Bug#762762: nmu fixing bind issues)
On Sun, Oct 5, 2014 at 9:59 PM, Cyril Brulebois wrote: I'm not going to go through building this on a kfreebsd porterbox to try and figure out how isc-dhcp would look if rebuilt against such packages, but that looks a saner base for porters to build upon. That doesn't make the timing issues I've mentioned disappear though. I'm OK with thinking about it again if porters endorse/welcome/successfully test the resulting packages and installation images. Thanks for the feedback. Would it be ok to stage the changes in unstable to make it somewhat easy for porters to test? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mpb5cgpq1oe6d_vpsoggyk6o3y2bqrrxwba_ozlh6m...@mail.gmail.com
Updating isc-dhcp udeb to dynamically link bind (was: Bug#762762: nmu fixing bind issues)
On Mon, Sep 29, 2014 at 6:34 PM, Cyril Brulebois wrote: I've uploaded an nmu fixing the issues revealed by the previous nmu to delayed/5. Please let me know if I should delay longer. See attached patch. The udeb handling is crazy. Please clearly describe what is actually wrong and I'll fix it. The upload was cancelled in the meantime. Also, please explain why you're still keeping the submitter and debian-boot@ out of the loop while messing around with udebs (#762762). I simply hadn't gotten around to that until just now, and d-i shouldn't be affected by anything yet. Dear installer team, I would like to upload an isc-dhcp package that use bind as a shared library (libbind-export-udeb) instead of its internal code copy. Please let me know when it would be ok to do the isc-dhcp upload that will least impact d-i beta preparation. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mpra+gtgxuypuje8fq9o-djk9nfobruuczgu0sst-e...@mail.gmail.com
Re: new tasksel
On Sun, Sep 7, 2014 at 10:52 PM, Joey Hess wrote: I have made some significant changes to tasksel, that will need changes elsewhere. I plan to upload this to unstable pretty soon, feedback permitting. [...] │[*] Desktop environment │ │[*] ... Xfce│ │[ ] ... GNOME │ │[ ] ... KDE │ This looks pretty awesome. Those options aren't very understandable to users as yet unfamiliar with open source desktops. I would like to suggest (stuff in parenthesis not meant to be shown) [*] Desktop environment [ ] ... Minimal Desktop (task-xfce-desktop --no-install-recommends) [*] ... Standard/default Desktop (task-xfce-desktop) [ ] ... Comprehensive Desktop (task-gnome-desktop) This excludes kde, but it's not clear to me how to describe the difference between kde and gnome succinctly without using the (meaningless to some users) acronyms. A note about Minimal Desktop, task-xfce-desktop is about 1500 MB installed with a lot of stuff I don't really want or need. So, at least on my machines, I always unselect Desktop Environment during installation, then later apt-get install task-xfce-desktop --no-install-recommends, which results in about a 400 MB installation and more like 150 MB download. I think a lot of users prefer this kind of minimalism, so it would be nice to make that easily available. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=modfol1ydlsziyy6zbcdzl4eoiah2uusm19baxuvrx...@mail.gmail.com
Bug#760778: [Pkg-xfce-devel] Bug#760778: xfce4-session: Please depend on gnome-orca
I sympathise with a11y, but forcing gnome-orca on everyone won't happen. Well, that is actually precisely our goal: to have gnome-orca installed on all systems, ready to be started in case one needs it. Then it's unrelated to Xfce, and you want to include that in the base system. Not in the base system, since the base system doesn't have X. But in all graphical tasks where it makes sense, yes (it doesn't make sense for KDE yet for instance, since qt is still completely inaccessible). There is desktop-base, which currently only depends librsvg2-common, but if the goal is to include orca with all desktops that would be one way to do it (probably as a recommends, rather than a depends). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mnevow58jkmjfbogkop5dasz+don7gnnophxjwdddu...@mail.gmail.com
Bug#757711: Bug#757988: kfreebsd: troubles with dhcp (configuration going away)
On Tue, Aug 19, 2014 at 8:10 PM, Cyril Brulebois wrote: Steven Chamberlain ste...@pyro.eu.org (2014-08-20): On 14/08/14 18:32, Cyril Brulebois wrote: Now, I think there are several questions to answer: 1. What were the reasons for having arch-dependent dhcp clients? I'd speculate because udhcpc from busybox is very small, and isc-dhcp-client-udeb was about 2 MiB. It targets (currently only builds on) Linux; there is a bug open somewhere about porting it to kfreebsd; it's infeasible before the jessie freeze, and IMHO I think I prefer to keep the ISC version (mostly from a security POV). 2MiB looks like a candidate for huge savings, which might make some sense since we're repeatedly hitting ENOSPC with kfreebsd-*, don't you think? Not trying to impose any decision, just a bit shocked while discovering its size. dhclient in the udeb is around 1.7 MiB because of embedded bind, which was introduced in isc-dhcp 4.2. I plan to spend some time to switch that to dynamically link, which will reduce size since only the parts of bind actually used will be needed rather than the whole thing. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=monxvufootejlzc2n0p16uvu8xy+lt1mi1sgnu-nqm...@mail.gmail.com
Re: Reverting to GNOME for jessie's default desktop
On Fri, Aug 8, 2014 at 1:52 AM, Michael Gilbert wrote: The better question is whether the xfce switch had or has any influence on slowing the general debian growth rate [0]? Is the slight downtick over the last few months due to the default desktop, or some other change that users aren't liking (maybe systemd), or just a random fluctuation? Here's a really interesting view showing the downward trend starting somewhere in April [0]. Note that the xfce trend was consistently growing prior to and past January (when the default was changed), but slowed a lot in April. At the same time, gnome and base-files started losing users. I've chosen to highlight April 26th, which is the date systemd 204-9 was uploaded to unstable [1]. It was around that time that the systemd packages introduced dependency changes that casual users were forced to think about. Anyway, nothing conclusive since correlation != causation, but something definitely worth pondering about systemd's potential cause and effect. Best wishes, Mike [0] https://qa.debian.org/popcon-graph.php?packages=base-files+task-gnome-desktop+task-xfce-desktop+gnome+xfce4show_installed=onwant_legend=onwant_ticks=onfrom_date=to_date=hlght_date=2014-04-26date_fmt=%25Y-%25mbeenhere=1 [1] https://packages.qa.debian.org/s/systemd/news/20140426T230007Z.html -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MPm7-Dms7Qnw+rQ0Tn_7uJ-x1D8gFuVQG3-D60=acm...@mail.gmail.com
Re: Reverting to GNOME for jessie's default desktop
On Fri, Aug 8, 2014 at 12:41 AM, Joey Hess wrote: Hardware: GNOME 3.12 will be one of the few desktop environments to support HiDPI displays, now very common on some laptop models. Lack of support for HiDPI means non-technical users will get an unreadable desktop by default, and no hints on how to fix that. I think the above are fairly big points. It would be helpful to see a pointer to a bug report about how xfce fails when the DPI is higher than usual. (Also, perhaps worth noting that 3.12 is quite a few versions ahead of the gnome currently in unstable..) This is a pretty common misconception and also pretty easy to workaround. xsettings-Xft can be set to a large value like 180 in xfce4-settings-editor (xfce's gconf). That's a usability issue and could definitely be improved with a widget in one of the more user-oriented xfce settings tools. Another one I've become aware of, but not investigated is that xfce's compositor may not do as good a job at eliminating tearing (with eg, Intel graphics) as gnome's does. (Also, I think xfce doesn't enable compositing by default.) Further investigation of this would be appreciated. Popularity: One of the metrics discussed by the tasksel change proponents mentioned popcon numbers. 8 months after the desktop change, Xfce does not seem to have made a dent on install numbers. fwiw https://qa.debian.org/popcon-graph.php?packages=task-gnome-desktop+task-xfce-desktop+gnome+xfce4show_installed=onwant_legend=onwant_ticks=onfrom_date=to_date=hlght_date=2014-01-25date_fmt=%25Y-%25mbeenhere=1 Popcon data is actually very useful when interpreted relatively. Those curves pretty clearly show user desktop selections going toward whatever the default is, and growth in desktop installs continuing to increase overall at a pretty similar rate to the historical trend. It would be reasonable to conclude that the default actually doesn't matter much, and the majority of users will just adapt to whatever it is (and those that don't are capable of installing task-gnome-desktop). The better question is whether the xfce switch had or has any influence on slowing the general debian growth rate [0]? Is the slight downtick over the last few months due to the default desktop, or some other change that users aren't liking (maybe systemd), or just a random fluctuation? Best wishes, Mike [0] https://qa.debian.org/popcon.php?package=base-files -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=moyyck-isvrpg1v0gqse1q+kt5prt5yg7nscvbgwsv...@mail.gmail.com
Bug#734324: debootstrap: unavoidable keyring warning in second-stage
package: debootstrap version: 1.0.56 severity: normal The second stage always presents the keyring warning. This, I think, is unnecessary since all of the package verification is done during the first stage. One may think that this could be worked around by using --keyring /debian-archive-keyring.gpg (after moving it there), but that makes it worse since gpgv is not yet installed in the chroot. Anyway, maybe it makes sense to disable all of the keyring stuff when --second-stage is used. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MPTT_aoYihPhyKGsTCS4beuCZcY66xbE7kLSV=6t3s...@mail.gmail.com
Re: init-select
On Thu, Jan 2, 2014 at 8:31 PM, Michael Gilbert wrote: Now, I certainly don't want all that weight solely on my shoulders, so I would very much prefer this choice to be team-maintained, and I think the installer/boot team has the expertise and clout to make the right choice when the time is really right to change the default Debian init. Based on the direction the discussion went yesterday and a night to sleep on it, I've decided that I am going to maintain this myself. Thanks a lot for all of the constructive feedback. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mosbqafwb0p1cjby5cn7eef5o9qktokwog4skfe-u3...@mail.gmail.com
Re: init-select
On Fri, Jan 3, 2014 at 4:43 AM, Andreas Cadhalpun wrote: Hi, On 03.01.2014 10:16, Gaudenz Steinlin wrote: Michael Gilbert mgilb...@debian.org writes: So, today I wrote init-select. It's a small tool that empowers users to freely and simply choose among all of the available init systems. It also empowers Debian contributors to devote their energy toward their favorite init knowing that users can easily swap inits to try the new features they are working on. IMO you are solving the wrong problem. Or how would you ensure that while the user can easily switch the init system, when doing so half of the daemons installed won't start because they don't support the alternative. And if he switches back, the other half does not start because the only support the other alternative. IMO the hard problem is mostly about which systems must be supported by all packages. init-select does not help to solve this. I think this would not be a problem (at least until jessie+1), because both systemd and upstart have a compatibility layer for sysvinit scripts, which all daemons have to provide according to policy. But I fail to see, why initsel would be better than: sudo apt-get install systemd-sysv/upstart/sysvinit-core Because it makes it possible for all of them to coexist peacefully. Right now all of those packages conflict with one-another. Thus, currently switching init systems that way can be a scary process for the average user. Finally, there is no way to select anything other than the default init in during the installation process (note that init-select doesn't currently implement that yet, but will be rather straightforward). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mpqxdkgkadzi3tegwgad8rrouy8z-3rgahdtmjp4hn...@mail.gmail.com
Re: init-select
On Fri, Jan 3, 2014 at 4:40 AM, Cyril Brulebois wrote: Michael Gilbert mgilb...@debian.org (2014-01-02): So, I suppose this isn't immediately obvious, but there is another solved problem here. Say the TC ultimately does not choose systemd as the default, and one day gnome entirely drops compatibility with the other inits. The gnome maintainers can take advantage of init-select to automatically move their users from whatever that default is to systemd. That is simply # init-select /bin/systemd # update-grub somewhere appropriate in their maintainer scripts. TC is supposed to take decisions with rationales, and suggesting a path forward for everyone involved. I suppose they're going to have a plan for Gnome vs. systemd if systemd isn't chosen. I'm not sure why just waiting for a decision wouldn't be the right thing to do right now. It is often far more ideal when the TC chooses to not act. TC action means that the project is somehow dysfunctional. init-select is a very simple technical solution to a very large social problem. Why would we not solve the problem here and totally diffuse the political fallout and unhappiness that the TC mandate is going to cause? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MNUirDGbHp55xzzzGr-7epMUU=20rq-14kqyhtdjen...@mail.gmail.com
Re: init-select
On Fri, Jan 3, 2014 at 4:16 AM, Gaudenz Steinlin wrote: Or how would you ensure that while the user can easily switch the init system, when doing so half of the daemons installed won't start because they don't support the alternative. And if he switches back, the other half does not start because the only support the other alternative. IMO the hard problem is mostly about which systems must be supported by all packages. init-select does not help to solve this. I completely agree that is entirely outside the scope of the problem init-select is meant to solve. Getting the individual init systems into a fully usable state is ultimately the responsibility of the various teams working on their favorite init. I've set the maintainer to debian-boot now in the hope that this proposal sounds reasonable. There is of course more work to do, which is documented in a TODO file in the source, which will make the package better, but the existing functionality, I think, is already useful. I can switch inits on a whim in seconds now. I don't see why the installer team should be in any better position to choose the default init system for Debian than any other team. At least since I'm involved (~ 10 years) the mailinglist name for the installer was a bit of a misnomer. The team has nothing to do with everyday booting of the system. It probably comes from the fact that the installer before d-i was called boot-floppies. For the same reason that the installer team reluctantly chooses the default desktop environment: that is the first path which the user actually needs to make a choice (or non-choice of course). Plus I think the project very much respects the unbiased decision-making process of the d-i team. This is why the TC decision will be troublesome: there was no way to keep bias and politicization out of the process, so a lot of the project will ultimately not respect the decision. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MP2K=1jinroch6adc4wt0z4lghtxd_wmndw6ft8fan...@mail.gmail.com
Re: init-select
On Fri, Jan 3, 2014 at 11:00 AM, Cyril Brulebois k...@debian.org wrote: Michael Gilbert mgilb...@debian.org (2014-01-03): It is often far more ideal when the TC chooses to not act. TC action means that the project is somehow dysfunctional. init-select is a very simple technical solution to a very large social problem. Having to pick an init system is *not* a social problem. All TC decisions are attempts at the resolution of social problems. They only consider issues that involve the social disagreement between at least two people. The fact that the disagreement is happens to be over a technical topic does not eliminate the social aspect. Trying to support several init systems is *not* in the best interest of a distribution. Having a fully functional one (and a transition from the former if it's different) is what we need to work on. Following that logic, supporting multiple packaging helpers, desktop environments, text editors, compilers, kernels, so on and so on are also *not* in the best interest of a distribution. Let's pick the most functional ones, that is what we need to work on. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=moaqfsm+toh6eh5b7jqb5pg807wwftne62ofufrjxk...@mail.gmail.com
Re: init-select
On Fri, Jan 3, 2014 at 11:19 AM, Cyril Brulebois k...@debian.org wrote: Michael Gilbert mgilb...@debian.org (2014-01-03): On Fri, Jan 3, 2014 at 11:00 AM, Cyril Brulebois k...@debian.org wrote: Michael Gilbert mgilb...@debian.org (2014-01-03): It is often far more ideal when the TC chooses to not act. TC action means that the project is somehow dysfunctional. init-select is a very simple technical solution to a very large social problem. Having to pick an init system is *not* a social problem. All TC decisions are attempts at the resolution of social problems. They only consider issues that involve the social disagreement between at least two people. The fact that the disagreement is happens to be over a technical topic does not eliminate the social aspect. Having a social aspect doesn't mean it's primarily a social problem. Trying to support several init systems is *not* in the best interest of a distribution. Having a fully functional one (and a transition from the former if it's different) is what we need to work on. Following that logic, supporting multiple packaging helpers, desktop environments, text editors, compilers, kernels, so on and so on are also *not* in the best interest of a distribution. Let's pick the most functional ones, that is what we need to work on. False analogy. Evidence and/or logic would be nice, otherwise there is no reason to conclude this. Anyway, not going to play on words because there are so many efforts wasted with this topic already. Again, my position on the topic: No, this doesn't belong to the installer. Thanks for taking the time to think about it. I very much respect your opinion. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MOpZUmS-b=bzdX0=h_+wu-9pwptrcmzatnmyblhk0-...@mail.gmail.com
Re: init-select
On Fri, Jan 3, 2014 at 11:44 AM, Michael Gilbert wrote: On Fri, Jan 3, 2014 at 11:19 AM, Cyril Brulebois wrote: Anyway, not going to play on words because there are so many efforts wasted with this topic already. Again, my position on the topic: No, this doesn't belong to the installer. Thanks for taking the time to think about it. I very much respect your opinion. I should clarify. I very much respect your opinion, but I do disagree, so it would be nice to hear thoughts from other d-i people than outright abandoning the idea. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MNhythfieDqNyKgiQJMC9Lsp_iB=bszampashnntqw...@mail.gmail.com
Re: init-select
On Fri, Jan 3, 2014 at 1:29 PM, Gaudenz Steinlin wrote: Michael Gilbert mgilb...@debian.org writes: On Fri, Jan 3, 2014 at 11:00 AM, Cyril Brulebois k...@debian.org wrote: Michael Gilbert mgilb...@debian.org (2014-01-03): It is often far more ideal when the TC chooses to not act. TC action means that the project is somehow dysfunctional. init-select is a very simple technical solution to a very large social problem. Having to pick an init system is *not* a social problem. All TC decisions are attempts at the resolution of social problems. They only consider issues that involve the social disagreement between at least two people. The fact that the disagreement is happens to be over a technical topic does not eliminate the social aspect. Trying to support several init systems is *not* in the best interest of a distribution. Having a fully functional one (and a transition from the former if it's different) is what we need to work on. Following that logic, supporting multiple packaging helpers, desktop environments, text editors, compilers, kernels, so on and so on are also *not* in the best interest of a distribution. Let's pick the most functional ones, that is what we need to work on. As Cyril already said these are false analogies. Supporting multiple packageing helpers does not place a burden on maintainers that only use one of them. It's also invisible to users. Similar arguments can be made for your other examples. On the other hand supporting several init systems places a burden onto every daemon maintainer. Every init system is only usefull if it's supported by all packages. So, somehow I think this keeps getting misunderstood, or maybe not contemplated at a deeper level. Support for multiple inits means each island in debian gets to choose the init that suites them best. gnome and kde lands can choose systemd since it enables them to be closest to upstream. kfreebsd, hurd, xfce, and whatever else lands can choose upstart due to is portability, so on and so forth. Ultimately, debian is going to have multiple inits. It is simple matter of fact. gnome will need systemd. kfreebsd needs something more portable. Let's think about how we get to the state where we support that dynamism in a user-friendly manner. The option of just useing the init script compatibility layer that most (all) init systems currently provide is IMO just not an option because it does not let us use most of the benefits of the newer systems. It's just sysv-init in new cloths. My arguments have never been for that. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mppbdslo41pdsmp7hbddtek8jvppwhn9cne5hnp0rf...@mail.gmail.com
init-select
Hi :) The TC init discussion has diverged significantly from Debian's usual ideals of freedom and meritocracy, so I decided to do something about it. So, today I wrote init-select. It's a small tool that empowers users to freely and simply choose among all of the available init systems. It also empowers Debian contributors to devote their energy toward their favorite init knowing that users can easily swap inits to try the new features they are working on. But most importantly, it provides a path for eliminating the politicization of the init system problem. That would be achieved if Debian's default init were to simply become init-select's default. Now, I certainly don't want all that weight solely on my shoulders, so I would very much prefer this choice to be team-maintained, and I think the installer/boot team has the expertise and clout to make the right choice when the time is really right to change the default Debian init. The initial package is up for review at: http://people.debian.org/~mgilbert/other I've set the maintainer to debian-boot now in the hope that this proposal sounds reasonable. There is of course more work to do, which is documented in a TODO file in the source, which will make the package better, but the existing functionality, I think, is already useful. I can switch inits on a whim in seconds now. Anyway, that is my modest proposal. I hope this doesn't sound too overly idealistic, intrusive, or I suppose out of the blue :) Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MPLNu6-ss4uOtv+kSF8bPyGOvBC4FjeNYaOVr=pf6g...@mail.gmail.com
Re: init-select
On Thu, Jan 2, 2014 at 8:39 PM, Cyril Brulebois wrote: Even if what's happening on tech-ctte isn't exactly ideal, I don't think letting users choose their init system is a service to them. Editing a kernel command line is enough for those who want to play. Others don't need to bother. So, I suppose this isn't immediately obvious, but there is another solved problem here. Say the TC ultimately does not choose systemd as the default, and one day gnome entirely drops compatibility with the other inits. The gnome maintainers can take advantage of init-select to automatically move their users from whatever that default is to systemd. That is simply # init-select /bin/systemd # update-grub somewhere appropriate in their maintainer scripts. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mo99nvxycbcp6gubqfzl484wk3rn8bav0hhgizsgrb...@mail.gmail.com
Bug#721869: install appropriate linux-headers
On Fri, Sep 6, 2013 at 4:58 AM, Bjørn Mork bj...@mork.no wrote: Dmitrijs Ledkovs x...@debian.org writes: On 5 September 2013 20:58, Bjørn Mork bj...@mork.no wrote: Christian PERRIER bubu...@debian.org writes: Quoting Bjørn Mork (bj...@mork.no): So, it's probably less overkill than it may seem at first glance to imagine that installing headers by default may help in some cases. I hope and expect most Linux users never needing kernel headers. And if they do need them, then the headers should be pulled in by one of the -dkms packages. I do not think it is a good idea to encourage users or driver authors to keep drivers out of Debian. How does the dependency look like to get headers for the _currently_ running kernel and not the latest one available/installed? Considering I can upgrade to the new kernel packages a few times before rebooting. This is way outside what you can expect to be supported. I wouldn't worry about that. Users likely want to be using the latest kernel anyway, and if they for some reason aren't and submit a bug report about modules not working, they can be instructed to either reboot or install the linux-headers for their specific kernel version. Sitting on the outside here, I am puzzled to see this belief that Debian should support all sorts of user modifications to the kernel package. This isn't at all about modifying the kernel package itself. It is about building kernel modules available in many separate packages. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mnajdj2n95iv27e58-6nomvoakxz67pt4waptzpgbh...@mail.gmail.com
Re: task-desktop: default desktop environment for Jessie
On Thu, May 30, 2013 at 3:44 AM, Cyril Brulebois wrote: There's no final decision, it simply never was discussed at all. It would probably be good to get that discussion started early during this cycle to reduce the surprise factor. Since it was rather difficult to fit gnome onto 1 cd in wheezy (and I think some pieces were left off anyway), I think it makes sense now to start moving toward something like xfce as the default that's small, and mostly capable, and 4.10 (now making its way into unstable) brings much needed accessibility features. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MPBNrMbx0h+d-m=avjrswrrzu7xyeapgg1fe9fq6n7...@mail.gmail.com
Re: task-desktop: default desktop environment for Jessie
On Fri, May 31, 2013 at 3:06 PM, Cyril Brulebois wrote: Michael Gilbert mgilb...@debian.org (31/05/2013): It would probably be good to get that discussion started early during this cycle to reduce the surprise factor. Since it was rather difficult to fit gnome onto 1 cd in wheezy (and I think some pieces were left off anyway), I think it makes sense now to start moving toward something like xfce as the default that's small, and mostly capable, and 4.10 (now making its way into unstable) brings much needed accessibility features. A somewhat related question is whether we're going to keep trying to fit stuff onto CD#1, as opposed to moving to supporting various “USB key sizes”. If I'm not mistaken, Steve has expressed such a wish (or intent) during the last wheezy preparation steps. As a point of reference, I still have (and use every now and then) an old laptop that has a cd-rom but no dvd-rom, and its bios does not support usb booting. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mnypyhyb_htg5jgjh5mneiekbrfaybszysx-uodt8d...@mail.gmail.com
Bug#693839: debian-installer: kernel install fails on armel buffalo linkstation pro, missing uboot-mkimage
control: tag -1 patch On Sun, Mar 17, 2013 at 2:33 PM, Michael Gilbert wrote: Martin Michlmayr wrote: I disagree. flash-kernel maintains a database with information about each device, including a list of required packages. It will install those required packages. u-boot-tools is listed for the Linkstation, so the real question is why it's not being installed. Looking at db/all.db, all of the machines have Required-packages: u-boot-tools, so in a way its already a universal dependency, I wonder if it wouldn't make more sense to make it a real dependency (as was done with the 3.4 upload)? Since the release is getting close, I've gone ahead with an nmu adding u-boot-tools as a real dependency. Uploaded to delayed/5 to give you a chance to do a maintainer upload if desired. Please see attached patch. Best wishes, Mike flash-kernel.patch Description: Binary data
Bug#693839: debian-installer: kernel install fails on armel buffalo linkstation pro, missing uboot-mkimage
control: tag -1 -patch On Mon, Mar 25, 2013 at 6:02 AM, Julien Cristau wrote: Since the release is getting close, I've gone ahead with an nmu adding u-boot-tools as a real dependency. Uploaded to delayed/5 to give you a chance to do a maintainer upload if desired. Please see attached patch. Please cancel that nmu. Or I'll do it. You don't get to upload changes over the maintainer's specific objections. Done. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MM04869D0ASQGum5VkTPyWahvTNGt+3h0n9Z=ia4tv...@mail.gmail.com
Bug#693839: debian-installer: kernel install fails on armel buffalo linkstation pro, missing uboot-mkimage
Martin Michlmayr wrote: I disagree. flash-kernel maintains a database with information about each device, including a list of required packages. It will install those required packages. u-boot-tools is listed for the Linkstation, so the real question is why it's not being installed. Looking at db/all.db, all of the machines have Required-packages: u-boot-tools, so in a way its already a universal dependency, I wonder if it wouldn't make more sense to make it a real dependency (as was done with the 3.4 upload)? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mpldue5ruqmu1skc_1angptt1_wwl7n6wahzosg43c...@mail.gmail.com
Please lift udeb-block from isc-dhcp
Hi, Please remove the udeb-block from isc-dhcp so wheezy can get the RC bug fixes uploaded to tpu a couple weeks ago. Thanks, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mm7+93h5vlkspawcm_g90k+qcp8jcfp-yebj5bvhk+...@mail.gmail.com
Re: Please lift udeb-block from isc-dhcp
On Sun, Mar 3, 2013 at 5:57 AM, Michael Gilbert wrote: Hi, Please remove the udeb-block from isc-dhcp so wheezy can get the RC bug fixes uploaded to tpu a couple weeks ago. Sorry, wrong terminology. Please consider approving a udeb-unblock for isc-dhcp. Thanks, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mnge4fljs+srx3acdp4-1ytqs9sppg344qyf164ckr...@mail.gmail.com
Bug#642031: should debootstrap workaround libc6 kernel uname parsing bug
Joey Hess wrote: I'm unsure about trying to work around this in debootstrap, despite https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/802985 having a LD_PRELOAD hack to do so. There is also setarch or uname26: http://mirror.linux.org.au/linux/kernel/people/ak/uname26/uname26.c See bug #700884. With an experimental (two-number version) kernel debootstrap fails: # debootstrap lenny lenny http://archive.debian.org/debian But with uname26, it succeeds: # uname26 debootstrap lenny lenny http://archive.debian.org/debian Or setarch: # setarch x86_64 --uname-2.6 debootstrap lenny lenny http://archive.debian.org/debian It would be nice if debootsrap automatically used one of those for older known broken releases. Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MPccCTvO1rauHEPxfYWZmmLWbcR1tE9=l7iv3ywcm6...@mail.gmail.com
Re: Trying to install Wheezy on an Asus Zenbook UX32VD
On Sun, Nov 25, 2012 at 11:47 AM, Bart-Jan Vrielink wrote: Now I'm trying with the disk1 iso copied to another USB disk. This time it manages to complete the installation without any issues, but fails to boot. After grub, I do get the following at bootup: Loading Linux 3.2.0-4-amd64 ... Loading initial ramdisk ... error: no suitable mode found. Booting however That is grub bug #661789. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mmdhbg52inxa9jipwnoekdswq364l4cidepd6srvxc...@mail.gmail.com
Re: Trying to install Wheezy on an Asus Zenbook UX32VD
On Sun, Nov 25, 2012 at 1:02 PM, Bart-Jan Vrielink wrote: That is grub bug #661789. Looks like it is. Anyone knows a workaround? Yes. Take a look at the merged bug reports. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MP7xUqP1MRTnh8DLn1T13ncEUaRpM2oZkvt=tY_Jkga=w...@mail.gmail.com
Re: netinst + uefi (was Re: netinst install-time compilation of network drier)
On Sun, Nov 25, 2012 at 12:13 AM, Keith Moyer wrote: On 11/24/2012 4:53 PM, Steve McIntyre wrote: No, you're doing the right thing. dd to the raw device is the right way to use the image, I was just checking that was what you'd done. Hmmm. Another machine that doesn't like the UEFI stuff we've got, it seems. :-( I think it was just the fault of a cheap USB key. I reflashed the netinst image onto a better one, and it is UEFI bootable. Is there anything of interest about that USB drive? What brand/model was it? Which USB standard does it conform to? What does dmesg say when you plug it in? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MNzKLa2QRz6BGVYew6Vv=gqtyjeg9jkvghbv+6uqjj...@mail.gmail.com
Re: Trying to install Wheezy on an Asus Zenbook UX32VD
On Sat, Nov 24, 2012 at 9:17 AM, Bart-Jan Vrielink wrote: Hello, I'm trying to use the latest beta of the Wheezy installer to get an OS on my new Zenbook. I also have a zenbook, so I ran into similar issues, but this was before EFI support was added. I did this by DD'ing the netboot iso to an USB stick. This seems to work, I can boot from this USB stick and start the installer. The first challenge I get is that my Wifi needs to load some firmware files. There is a partition labeled Firmware that supposedly is for that, but no matter what I try (either the .deb files, or the firmware files itself), they do not get picked up. I've worked around this problem by using a wired Ethernet connection instead. You actually have to copy the firmware files onto that partition yourself: http://wiki.debian.org/Firmware The second challenge is getting a boot loader to work. I cannot find an option in the BIOS to set it to classic mode, so it looks like I have to go the EFI route. However, the installer only offers me to install grub-pc and not grub-efi. Has anyone getting the installer to work with EFI? Exactly what partitions should I have for this? At the end of the install (after grub-pc installed), I used one of the virtual consoles to install grub-efi-amd64, and essentially followed these steps: http://womble.decadent.org.uk/blog/installing-debian-gnulinux-and-windows-dual-boot-under-uefi.html Again, this was pre-EFI, so if these things aren't working in an automated fashion, you should really submit a bug report. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mmzzubudxf7h2uizvkrbk-+3+1gfhfoh4pdgmqgurt...@mail.gmail.com
Bug#680084: nmu
Hi, I've uploaded an nmu fixing this issue to delayed/7. The extra time is to give you a chance to do a maintainer upload instead. Please see attached patch. Best wishes, Mike os-prober.patch Description: Binary data
Bug#680084: nmu
On Mon, Nov 12, 2012 at 6:30 PM, Julien Cristau wrote: On Mon, Nov 12, 2012 at 16:57:30 -0500, Michael Gilbert wrote: Hi, I've uploaded an nmu fixing this issue to delayed/7. The extra time is to give you a chance to do a maintainer upload instead. Please see attached patch. Isn't this bug just a dupe of 684293, in which case it doesn't need an os-prober change? Possibly. I've never been able to reproduce the issue myself, so deferring to Integeri: #684293 is fixed in kernels 3.2.29, was your testing done on an earlier version than this and if so can you test with a newer kernel? In the meantime, I've canceled the nmu since it may not be needed. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MO0dTmdFP79Bapui=qdaf+ih0h1c7dyaph0gauesvs...@mail.gmail.com
Bug#690594: tasksel: execution aborted due to compilation errors
On Sun, Oct 28, 2012 at 6:28 PM, Cyril Brulebois wrote: Michael Gilbert mgilb...@debian.org (25/10/2012): I've uploaded an nmu fixing this issue to delayed/7. The extra time is in case you want to do a maintainer upload instead. See attached patch. The changelog entry really should be more descriptive IMVHO. Reading it gives no clue as to which problem is getting fixed. I've expanded the changelog note and re-upload to delayed/4. Please see new patch. Best wishes, Mike tasksel.patch Description: Binary data
Bug#690594: tasksel: execution aborted due to compilation errors
control: tag -1 patch Hi, I've uploaded an nmu fixing this issue to delayed/7. The extra time is in case you want to do a maintainer upload instead. See attached patch. Best wishes, Mike tasksel.patch Description: Binary data
Bug#680084: os-prober: postinst script gets stuck
Maybe some information about the disk layout helps, too: /dev/sda is the only disk installed. /dev/sda1 /boot ext4 /dev/sda2 encrypted physical volume for lvm2: /dev/mapper/pv00physical volume /dev/mapper/vg00-root / filesystem ext4 /dev/mapper/vg00-swap swap /dev/mapper/vg00-root2 empty ext4 /dev/mapper/vg00-export empty ext4 Is this the contents of your /etc/fstab? If so, using empty as the mount point could be part of the problem. If this is the case, could you try changing empty to a real mount point? Thanks, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MPZ9SmH9Y8Ay0BoczrO=-5EYSgx=5q4y5pqrgodg9b...@mail.gmail.com
Bug#680084: os-prober: postinst script gets stuck
I see processes such as: grub-mount /dev/mapper/vg1-SomeLogicalVolume /var/lib/os-prober/mount Can you all see if you have anything in common with these vg partitions? Also, can you analyze the output from manually running the seemingly hanging process? # grub-mount /dev/mapper/vgwhatever mount-point Also, what does /dev/mapper/vgwhatever actually point to? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mpzsdzj73yuqg9glrcn82px-lrgs6mt+2fnffpqjaz...@mail.gmail.com
Bug#685499: closed by Michael Gilbert mgilb...@debian.org (Re: Bug#685499: debian-installer: Include firmware-linux)
On Tue, Aug 21, 2012 at 12:41 PM, borish wrote: Well, I know how to solve my problem, but this doesn't help the unexperienced user who might ditch Debian if wifi doesn't work and install Ubuntu instead. Ubuntu supports non-free firmware during install. Presumably inexperienced (but proactive) users will come across bug reports like this one, and eventually gain the autonomy to solve their own problems. Choice is important. Debian and Ubuntu have different directions and adhere to different ideals. For some users convenience is of the utmost importance. For them Ubuntu is simply the better choice, and that's ok. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mp7+oaf+pxmqyxekxp1zce42fvwt_s+mkghtulw65q...@mail.gmail.com
Re: [pkg-dhcp-devel] Bug#685268: unblock: isc-dhcp/4.2.4-1
On Sun, Aug 19, 2012 at 6:25 AM, Cyril Brulebois wrote: Michael Gilbert mgilb...@debian.org (18/08/2012): Andrew hasn't yet made it clear which version he's been planning to support in wheezy [0], but he did upload this one well before the freeze. Nice try: [2012-07-01] Accepted 4.2.4-1 in unstable (low) (Andrew Pollock) Anyway, it was close. I don't know whether 0330 UTC July 1 is before the exact time of the freeze or not, but I do recall the packaging having an automatic unblock (and a block-udeb) during the month of July. Regardless, I don't really care which way the call on this goes, I just need the call made so I can fix the right version. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mnpovgskln6edzdri4o0xzeyyejhra4vps5jlzqwqc...@mail.gmail.com
Re: [pkg-dhcp-devel] Bug#685268: unblock: isc-dhcp/4.2.4-1
On Sun, Aug 19, 2012 at 12:23 PM, Cyril Brulebois wrote: Anyway, it was close. “close” isn't exactly “well before” as you previously claimed. Wording mistake. Sorry. I don't see any reasons why the version currently sitting in testing would not be the version in wheezy. Which should answer your question I think. Thank you. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mo0ndhwyy70padg7vvtj09ez0tkscfkmoq6i8waxiz...@mail.gmail.com
unblock: isc-dhcp/4.2.4-1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Please unblock package isc-dhcp Andrew hasn't yet made it clear which version he's been planning to support in wheezy [0], but he did upload this one well before the freeze. Unfortunately it was udeb blocked, so it didn't go in during the grace period. I'm going forward with this unblock request because there are a set of security issues that need to be backported to whichever version is shipping with wheezy. If this one can go in, it will involve fewer patches, and I won't need to use TPU or testing-security. The differences between this version and testing's are primarily that its two upstream point releases newer. The debian changes include an RFC compatibility fix and a corection for a kfreebsd subnet issue. CCing -boot since this involves a udeb unblock. I understand d-i beta2 is coming (soon?), so its likely a please wait from that perspective. unblock isc-dhcp/4.2.4-1 [0] http://lists.alioth.debian.org/pipermail/pkg-dhcp-devel/2012-August/001435.html -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mnhkfv9fgtne8ezak4rzswzxnslh2yk0yylo-vxekp...@mail.gmail.com
Bug#684968: debian-installer: requests non-free firmware for a device that works just as well without it
On Thu, Aug 16, 2012 at 12:03 AM, Christian PERRIER wrote: This recently came up on the fsf-collab list. Here are my thoughts on appropriate wording: http://lists.alioth.debian.org/pipermail/fsf-collab-discuss/2012-August/000200.html Obviously that's rather long given character constraints in the installer's debconf messages. But it could be a starting point for discussion. Post-wheezy, of course..:-) Certainly :) All of the potential FSF-freeness stuff will need to wait until after wheezy's release. And by shortening the text quite strongly (I think the first two paragraphs are enough: the rest belongs to freeness zealotism -no offense intended, I happen to be a zealot, too). Well, the goal with that wording was to concurrently try to meet the FSF's requirements to be on their free distributions list (the requirement that non-free dialog's need to contain information on why it should be avoided if possible) while being intellectually honest with the user about their real options (i.e giving them enough information to be able to reach their own freeness conclusions). I think providing a well-rounded perspective is good in that includes the zealot perspective as well as the pragmatists, and leaves it up to the user to reach their own well-informed decision. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mpn82xmt4el6m9sygml8xgujn2fwovqhbiesktnbvw...@mail.gmail.com
Bug#684968: debian-installer: requests non-free firmware for a device that works just as well without it
On Wed, Aug 15, 2012 at 6:05 PM, Stefan Nagy wrote: Debian (installer) should enable users to make a decision here. Instead right now it seems like the safe way in each and every case is to install proprietary firmware – and everyone who decides not to install it is on his/her own. This is just my opinion (and that's why I reported this bug with severity: wishlist). This recently came up on the fsf-collab list. Here are my thoughts on appropriate wording: http://lists.alioth.debian.org/pipermail/fsf-collab-discuss/2012-August/000200.html Obviously that's rather long given character constraints in the installer's debconf messages. But it could be a starting point for discussion. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mofklh-rjoqhczotdy14wkucc3gcixrzfnoq-xeq8k...@mail.gmail.com
Bug#684946: debian-installer: CD install iso does not install ndiswrapper correctly.
On Tue, Aug 14, 2012 at 6:06 PM, zac newton wrote: Package: debian-installer Version: debian-6.0.5-i386-cd1.iso Severity: important The cd iso installer does not install ndiswrapper correctly. One problem (there may be more) is that the ndiswrapper.ko file is not installed. The problem is only with the full cd installer. Using a netinstall version e.g. debian-6.0.5-i386-netinst.iso where ndiswrapper is downloaded over a wired internet connection installs ndiswrapper successfully. The problem seems to extend to other distributions which rely heavily on debian e.g. Linux Mint Debian Edition (linuxmint-201204-mate-cinnamon-dvd-32bit.iso) which also fails to install ndiswrapper.ko. The problem seems to have existed for a long time. I first encountered it several months ago and, then, I found several references to the problem on the internet. I gave up on debian in frustration because I could not get ndiswrapper to work and I needed a network connection to download ndiswrapper - which is what I needed ndiswrapper for!! It looks to be not included in squeeze's cd1: http://cdimage.debian.org/cdimage/release/6.0.5/i386/list-cd/debian-6.0.5-i386-CD-1.list.gz Unfortunately its also not on wheezy's beta1 cd1 either: http://cdimage.debian.org/cdimage/wheezy_di_beta1/i386/list-cd/debian-wheezy-DI-b1-i386-CD-1.list.gz But it does look like that will change once the new tasks are implemented: http://cdimage.debian.org/cdimage/tmp/new-tasks/2012-07-08 Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mork0fpvvjb1dympvemhstt6ka+5eniopaounqdhrm...@mail.gmail.com
Re: Wheezy release: CDs are not big enough any more...
On Sat, May 12, 2012 at 12:04 PM, Steve McIntyre wrote: Hey folks, Remembering the fun that we had during the Squeeze release with trying to make single-CD installations work well, it's time to consider what we're going to *claim* to support in Wheezy. We've had a history of supporting the following single-CD installations: * Gnome desktop from CD#1 * KDE desktop from KDE CD#1 * XFCE desktop from light CD#1 * LXDE desktop from light CD#1 * base system only from netinst CD At this point, I'm skeptical that either of the first two are going to work acceptably with Wheezy. If that's the case, then we should warn people that they will need to use at least one of: * more CDs * a DVD * a network mirror to get a useful/useable installation. What about supporting only the smaller/lighter desktop environments (maybe even making one of the the default environment)? Then there wouldn't be the need for multiple CD #1's. Anyone that wants gnome/kde after installation will need to grab those from the mirrors (or use DVD or greater media). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mp7zmd16g325awdxrxvdzfetz_zxjfwhqg+zviqj2j...@mail.gmail.com
Bug#649146:
forcemerge 650234 649146 reassign 650234 eglibc retitle 650234 eglibc: libc-2.11.x.so segfaults when used with ld-2.13.so thanks Hi, this seems more of an eglibc issue, so I am reassigning. Daniel Kahn Gillmor did a lot of useful tinkering in http://bugs.debian.org/650234. Thanks, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MMPfaWPVZJ=cq_yuznvsjg5y6e9zwmjrd5daxmsufd...@mail.gmail.com
Bug#269656: Bug#618920: debootstrap: needs more robust download error handling
On Tue, Mar 13, 2012 at 1:06 PM, Colin Watson wrote: I've committed my improved version, which you're welcome to review: Cool! Thanks for looking into this. This problem has reared its head on me too many times to count over the past few years ;) Thanks again! Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MMbHx+zma5Vxz5wZq_Vwif=ml9u4_zm-8v9vogfqnr...@mail.gmail.com
Bug#655841: Please remove Gnash from default Debian install, as it crashes
On Sat, Jan 14, 2012 at 8:42 AM, Alexey Eromenko wrote: gnash is not only installed with KDE, from what I see as its installation is triggerred by the desktop task, that's common to KDE and GNOME, at least. It is triggerred by browser-plugin-gnash. What do you suggest as alternative? I don't think it is a good idea to not provide any flash-enabled web browser. Unfortunately the Free Software community has not yet developed stable flash player, therefore I suggest to avoid installing _unstable_ software by default. lightspark is an alternative. Of course, it's also experimental, but who knows, it may be a bit more stable/complet at this point? I haven't really looked into it. Just something worth considering... Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MMv5wMCPOK_zhhYNMxEyn0qNDvSJ4206ZOZ25e=e9_...@mail.gmail.com
Re: daily build 12/12/11 amd64
On Fri, Dec 16, 2011 at 3:45 AM, richard wrote: On Thu, 15 Dec 2011 19:01:38 -0500 Michael Gilbert michael.s.gilb...@gmail.com wrote: On Tue, Dec 13, 2011 at 9:08 AM, Richard wrote: Hi I used the daily build 12/12/11 for a clean install on a amd64 machine, the network dchp problem is fixed, but the graphical install still freezes on the first page, or could be no response to mouse or keyboard. Hi, I'm still having trouble understanding exactly where you're trying to say this problem happens. But anyway, it would be better to submit this as a bug against the debian-installer package. Make sure to describe exactly the menu items you're selecting (text install, graphic, expert?), and even describe the screens that do work so we can get a feel for where this happens. Best wishes, Mike Uhmmm, I seem to have a problem, with my native language. Sorry, I hope my response didn't seem rude. I didn't intend it that way. Bug reports are good, and don't worry about your english, we'll work through it. try selecting graphical install goes to the first page and does nothing,. Is that the same thing that happens with the text install? no response to anything apart from the power switch. Its a waste of time putting in a bug report if that cant be understood, I give up :( On the Installer boot menu screen, you can get to advanced features by pressing ESC first (you can type help to get info there, then press the F1-F10 keys to get help). Since it's a display issue, the vga and fb (framebuffer) options may be useful. For example, you could try: install vga=771 fb=false Anyway, lots of stuff to fiddle with. If you find something that works, let us know what it is and what the exact hardware is that you're using. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mprf8gt_-a5keznwpmrtxrp6pyp_75ess+rnuor-c6...@mail.gmail.com
Re: daily build 12/12/11 amd64
On Tue, Dec 13, 2011 at 9:08 AM, Richard wrote: Hi I used the daily build 12/12/11 for a clean install on a amd64 machine, the network dchp problem is fixed, but the graphical install still freezes on the first page, or could be no response to mouse or keyboard. Hi, I'm still having trouble understanding exactly where you're trying to say this problem happens. But anyway, it would be better to submit this as a bug against the debian-installer package. Make sure to describe exactly the menu items you're selecting (text install, graphic, expert?), and even describe the screens that do work so we can get a feel for where this happens. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MPfo2FJ=_jhpawxoa_nbv4-rrqv-zcdli7qdyrwba6...@mail.gmail.com
Bug#649146: debootstrap: bootstrapping squeeze with the fakechroot variant leads to nested fakeroot usage
package: debootstrap version: 1.0.37 severity: important Hi, debootstrapping squeeze with the fakechroot variant leads to a nested usage of fakeroot. For example $ fakeroot fakechroot /usr/sbin/debootstrap --variant=fakechroot squeeze --verbose ./squeeze-fakechroot [...] I: Extracting xz-utils... I: Extracting zlib1g... I: Installing core packages... W: Failure trying to run: chroot /media/newhd/chroots/squeeze-fakechroot dpkg --force-depends --install /var/cache/apt/archives/base-files_6.0squeeze3_amd64.deb /var/cache/apt/archives/base-passwd_3.5.22_amd64.deb The tail of squeeze-fakechroot/debootstrap/debootstrap.log contains the following: fakeroot: FAKEROOTKEY set to 1661226400 fakeroot: nested operation not yet supported Note that bootstrapping sid seems to be ok with the same command $ fakeroot fakechroot /usr/sbin/debootstrap --variant=fakechroot sid --verbose ./sid-fakechroot [ok] Thanks for looking into this. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mpywrdpgyxszraxygtzrs1qrnp0omroeisbmid9-uo...@mail.gmail.com
Bug#649146: debootstrap: bootstrapping squeeze with the fakechroot variant leads to nested fakeroot usage
On Fri, Nov 18, 2011 at 3:06 AM, Michael Gilbert wrote: package: debootstrap version: 1.0.37 severity: important Hi, debootstrapping squeeze with the fakechroot variant leads to a nested usage of fakeroot. It may be that the fix for #588773 wasn't quite right as the following gets a segfault instead of the nested fakeroot error: $ export PATH=/sbin:/usr/sbin:/bin:/usr/bin $ fakeroot fakechroot /usr/sbin/debootstrap --variant=fakechroot --verbose squeeze ./squeeze [...] I: Installing core packages... W: Failure trying to run: chroot /home/zero79/tmp/squeeze dpkg --force-depends --install /var/cache/apt/archives/base-files_6.0squeeze3_amd64.deb /var/cache/apt/archives/base-passwd_3.5.22_amd64.deb Tail of debootstrap.log: Segmentation fault -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MP33JTXfMjogJ2teXEpnkFrWZPky=y4yb29wqup510...@mail.gmail.com
Re: Debian testing netinst checksums do not match!
On Fri, 23 Sep 2011 00:11:18 +0200 Matthijs Wensveen wrote: Hi, I've just downloaded the debian-testing-amd64-netinst.iso file from http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/ The checksums in MD5SUMS.small and SHA512SUMS.small do not match with the downloaded file! This either means I'm the target of a man-in-the-middle attack (which seems unlikely) or that the sums in the checksum files are incorrect. Did you try downloading it a second time? There are innumerous conditions that could lead to an incomplete download, which will of course fail any checksum. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110922181931.ebd2c0b6.michael.s.gilb...@gmail.com
Bug#642183: debian-installer: hybrid iso sizing issue for unstable build
package: debian-installer
version: 20110106
severity: important
tags: patch
d-i fails to build unstable x86 netboot images (see below), which
will become a problem as d-i development moves forward with newer
kernels/packages coming in from unstable. I've attached a patch
that fixes this by using the default last sector for the msdos
partition instead of a size offset. This certainly works, but I'm
not sure if its an ideal solution.
Best wishes,
Mike
$ cd build USE_UDEBS_FROM=unstable make build_netboot
geniso_hybrid_plus_firmware_partition ./tmp/netboot/mini.iso
mkfs.msdos 3.0.9 (31 Jan 2010)
Command (m for help): Command action
e extended
p primary partition (1-4)
Partition number (1-4, default 2): First sector (24576-36863, default 24576):
Using default value 24576
Last sector, +sectors or +size{K,M,G} (24576-36863, default 36863): Value out
of range.
Last sector, +sectors or +size{K,M,G} (24576-36863, default 36863): Last
sector, +sectors or +size{K,M,G} (24576-36863, default 36863): Value out of
range.
Last sector, +sectors or +size{K,M,G} (24576-36863, default 36863): Value out
of range.
Last sector, +sectors or +size{K,M,G} (24576-36863, default 36863): Last
sector, +sectors or +size{K,M,G} (24576-36863, default 36863):
make[2]: *** [arch_miniiso] Error 1
make[1]: *** [_build] Error 2
make: *** [build_netboot] Error 2
--- util/geniso_hybrid_plus_firmware_partition.orig 2011-09-19 23:27:56.0 -0400
+++ util/geniso_hybrid_plus_firmware_partition 2011-09-19 23:28:06.0 -0400
@@ -49,7 +49,7 @@
echo p
echo 2
echo
-echo +$firmware_volume_size_MM
+echo
# Pedantically, set partition type to 1: FAT 16
echo t
Bug#617943: debian-installer: isolated make build_netboot fails due to missing 2.6.32 modules
Otavio Salvador wrote: The installer itself, sometimes, need modifications or fixes to be able to handle newer kernel versions so the version that is hard-coded on those is the version that is supported by the installer. It is not only a matter of recompile installer against the new kernel (sometimes this works by this is not guaranteed). Another important point is that there are architectures that use different kernels depending on the subarch (e.g armel uses iop32x, kirkwood and others) and dynamically it is more difficult to handle this. Specifically about the patch it is incomplete since it doesn't handle all the architectures thus we can't take it. Hi, Sorry I haven't had time to get back to this until just now. So, I don't have any of the subarch's to test this, but I believe they are already handled appropriately in the UDEBS = line in my patch. I'm concluding this based on the .cfg files, for example iop32x.cfg would produce 2.6.32-5 for the KERNELIMAGEVERSION var, and that is what I would automatically return from the automatic processing of the Packages file. Will it ever be the case that the kernel version as stated in the debian-installer_binary-ARCH_Packages file will differ from the hard-coded value in the cfg files? It seems like they would have to be the same, otherwise d-i would fail trying to download non-existent files, but I may be missing something. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011092313.27e767e7ade48b285bee5...@gmail.com
Bug#617943: debian-installer: isolated make build_netboot fails due to missing 2.6.32 modules
retitle 617943 debian-installer: should dynamically populate KERNELIMAGEVERSION thanks On Mon, Mar 14, 2011 at 11:39 AM, Otavio Salvador wrote: By default the building system gets the udebs from unstable. This is configurated on debian/rules using the building system variable (that you ought to take a look at). Another alternative is to use a local sources.list.udeb.local file to set it to use the stable suite. Hi, various regressions have happened lately. make build_all doesn't get around this issue any more. Also, changing udeb sources doesn't work anymore, USE_UDEBS_FROM=unstable make build_netboot. I've ended up having to implement a couple different ugly workarounds to keep my testing snapshot builds going while various things change. I've had enough frustration dealing with those that I've decided to come up with a real solution. The core issue is that KERNELIMAGEVERSION is a hardcoded value in the arch config files, so its currently stuck at squeeze's version. Thus, the solution is simply to parse that value from known package info instead. Attached is a patch that does that for review/feedback. Best wishes, Mike --- Makefile.orig 2011-07-24 19:34:16.0 -0400 +++ Makefile 2011-07-24 19:33:02.0 -0400 @@ -588,7 +588,8 @@ # Get the list of udebs to install. # HACK Alert: pkg-lists/ is still sorted by TYPE instead of a dir hierarchy. -UDEBS = $(shell set -e; get-packages udeb update 2; pkg-list $(TYPE) $(DRIVER_FOR) $(KERNEL_FLAVOUR) $(KERNELMAJOR) $(SUBARCH) $(KERNELIMAGEVERSION)) $(EXTRAS) +KERNELIMAGEVERSION = $(shell set -e; get-packages udeb update 2; grep Kernel-Version apt.udeb/state/lists/*_debian_dists_$(USE_UDEBS_FROM)_main_debian-installer_binary-$(ARCH)_Packages | head -1 | cut -d' ' -f2) +UDEBS = $(shell set -e; pkg-list $(TYPE) $(DRIVER_FOR) $(KERNEL_FLAVOUR) $(KERNELMAJOR) $(SUBARCH) $(KERNELIMAGEVERSION)) $(EXTRAS) # Get all required udebs and put them in UDEBDIR. $(STAMPS)get_udebs-$(targetstring)-stamp: sources.list.udeb
Re: d-i fails at base install
Ernest Sales wrote: I tried a netinst for testing build 24-04-2011, MD5 OK, but it fails at the 'install base system' step. I couldn't investigate further as I am in a hurry, but an older build netinst is working fine. It's not going to work without a newer = 1.116 base-installer. Try the snapshot installer, which has this automatically worked around: http://lists.debian.org/debian-devel/2011/04/msg00397.html Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110424131623.ebaf3929.michael.s.gilb...@gmail.com
Bug#620569: usbkey install wheezy i386 doesn't work
Lorenzo Bernardi wrote: On 04/07/2011 01:36 PM, Michael Gilbert wrote: There is no guarantee that the testing installer will work at any given time. You can try the testing snapshot release, which has certain known problems already, has been tested, and is known to work: That should say certain known problems already *fixed*. I have tried to is the iso image on the page you gave me and when I tried to install using the USB key I have the following message in the log: Apr 08 09:08:01 iso-scan:./debian-testing-snapshot-2011.04-i386-mini.iso not a Debian iso So, it looks like you're using the old method of copying the iso onto an already bootable usb stick? That isn't necessary anymore since you can just copy the iso directly to usb now (i.e. dd if=file.iso of=/dev/sdc if sdc is your usb device enumeration). I think that it may not be considered a debian iso since it's using local udebs, but I'm not really sure what iso-scan is looking for in particular. The snapshots are unofficial right now anyway. I have looked at the image by mounting them: mount -o loop ./debian-testing-snapshot-2011.04-i386-mini.iso /tmp/dd ls /tmp/dd/ adtxt.cfg dtmenu.cfg f10.txt f2.txt f4.txt f6.txt f8.txt g2ldr initrd.gz isolinux.cfg linuxmenu.cfgrqtxt.cfg splash.png txt.cfg win32-loader.ini boot.cat exithelp.cfg f1.txt f3.txt f5.txt f7.txt f9.txt g2ldr.mbr isolinux.bin kde lxdeprompt.cfg setup.exe stdmenu.cfg vesamenu.c32 xfce and the daily build iso image gives something different. mount -o loop ~/OLD/debian-testing-i386-netinst.iso /tmp/dd ls /tmp/dd/ autorun.inf debian doc g2ldr install isolinuxpics README.html README.mirrors.txt README.txt tools css dists firmware g2ldr.mbr install.386 md5sum.txt pool README.mirrors.html README.source setup.exe win32-loader.ini They should be different. The snapshots are the mini iso version, which is different than the netinst. I should say that using the daily build image burn on a CD works perfectly it is only the usb key installation setup that causes me problems. When I try to do the installation with the daily build I have these two lines in the log Apr 3 09:08:35 anna[1914]: grep: /cdrom/dists/stable/Release: No such file or directory Apr 3 09:08:35 cdrom-retriever: error: No components listed in /cdrom/dists/stable/Release. Yes, that will not work because you need the newer base-installer from sid that hasn't transitioned yet. That is fixed automatically with the snapshot release. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110409143342.e9de1b52.michael.s.gilb...@gmail.com
Bug#620569: usbkey install wheezy i386 doesn't work
Lorenzo Bernardi wrote: Dear Stefano, Lorenzo, could you kindly provide us the detailed URLs where did you download vmlinuz, initrd.gz and iso file? Bye Stefano The url for the downloads are: http://people.debian.org/~joeyh/d-i/images/daily/hd-media/vmlinuz http://people.debian.org/~joeyh/d-i/images/daily/hd-media/initrd.gz http://caesar.acc.umu.se/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/debian-testing-i386-netinst.iso this is for the i386 arch and the downloads where done saturday 2 of april 2011. There is no guarantee that the testing installer will work at any given time. You can try the testing snapshot release, which has certain known problems already, has been tested, and is known to work: http://lists.debian.org/debian-devel/2011/04/msg00397.html Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110407073435.03bf5be3.michael.s.gilb...@gmail.com
Bug#620569: usbkey install wheezy i386 doesn't work
There is no guarantee that the testing installer will work at any given time. You can try the testing snapshot release, which has certain known problems already, has been tested, and is known to work: That should say certain known problems already *fixed*. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110407073606.93c37804.michael.s.gilb...@gmail.com
Bug#618920: debootstrap: needs more robust download error handling
package: debootstrap
version: 1.0.28
severity: important
tags: patch
debootstrap's current download error handling isn't very robust. It
declares success just for the presence of a downloaded file, which may
be a partial download, or one for which the checksum doesn't match.
Eventually those conditions will lead to unhandled failures elsewhere
within debootstrap.
This can make d-i very rocky on certain mirrors since one bad package
download ultimately lead to a complete failure of the debootstrap
process, and thus a failed install. An expert can recover from this,
but an average user will get rather frustrated (especially since the
dialogs for debootstrap errors are rather confusing).
It may also be useful to expand a bit on these d-i debootstrap error
messages: when an error happens, the right answer that the user wants is
to hit 'go back' twice in a row to start the debootstrap all over again,
but the dialogs are confusing, and 'continue' seems to be the obvious
choice, but that will lead to the broken debootstrap continuing to
completion with various brokenness. Anyway, that maybe should be
submitted as another bug.
So, back to the original issue, I've created a patch that will retry
downloads whenever anything in the get routine fails, which I
believe is much more robust than the current situation. Please see
attached patch.
Best wishes,
Mike
--- newhd/source/debootstrap-1.0.28/functions 2011-02-21 19:25:08.0 -0500
+++ /usr/share/debootstrap/functions 2011-03-19 10:58:57.0 -0400
@@ -1,3 +1,5 @@
+MAXATTEMPTS=10
+
### smallutils
smallyes() {
@@ -241,6 +243,13 @@
}
get () {
+ for iters in $(seq 1 $MAXATTEMPTS); do
+ if single_get $@; then break; fi
+ warning RETRYING Retrying failed download.
+ done
+}
+
+single_get () {
# args: from dest 'nocache'
# args: from dest [checksum size] [alt {checksum size type}]
local displayname
@@ -331,13 +340,6 @@
# http/ftp mirror
if wgetprogress -O $dest $from; then
return 0
- elif [ -s $dest ]; then
- local iters=0
- while [ $iters -lt 3 ]; do
-warning RETRYING Retrying failed download of %s $from
-if wgetprogress -c -O $dest $from; then break; fi
-iters=$(($iters + 1))
- done
else
rm -f $dest
return 1
@@ -346,13 +348,6 @@
# http/ftp mirror
if wgetprogress $CHECKCERTIF $CERTIFICATE $PRIVATEKEY -O $dest $from; then
return 0
- elif [ -s $dest ]; then
- local iters=0
- while [ $iters -lt 3 ]; do
-warning RETRYING Retrying failed download of %s $from
-if wgetprogress $CHECKCERTIF $CERTIFICATE $PRIVATEKEY -c -O $dest $from; then break; fi
-iters=$(($iters + 1))
- done
else
rm -f $dest
return 1
Bug#618920: debootstrap: needs more robust download error handling
I probably should have mentioned that these errors are much more likely within d-i for some reason. The best way to reproduce this is to do an installation up through partitioning, then do: $ debootstrap wheezy /target/wheezy-chroot http://snapshot.debian.org/archive/debian/20110318T093210Z At least a few package downloads should fail from that mirror, and they'll be different every time. Executing the same command in a full system seems to work fine for that exact same mirror, so maybe its some other variability within d-i that is the cause of this issue. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTinic9TK-G7pu+=a5aafaboifjhzhwhirebns...@mail.gmail.com
Bug#618927: busybox-udeb: provide seq
package: busybox-udeb version: 1.18.4-1 severity: normal It would be nice if busybox-udeb provided seq for use in d-i scripts. See bug #618920 for one particular case where I would like to use it. That code of course could be rewritten to avoid the use of seq, but its so much cleaner with it. Thanks, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110319123935.7c5d7e60.michael.s.gilb...@gmail.com
Bug#618839: debootstrap-udeb: restore stable/testing/unstable scripts
package: debootstrap-udeb version: 1.0.28 severity: normal tags: patch It can actually be useful to have the various statically named scripts available in the installer. In particular, for working on snapshots, its more useful for me to be able to use the term testing everywhere, rather than hardcoding wheezy specifically just for debootstrap. Attached is a patch for this. Thanks, Mike diff -Nru debootstrap-1.0.28/debian/changelog debootstrap-1.0.28gilbert1/debian/changelog --- debootstrap-1.0.28/debian/changelog 2011-02-21 19:51:19.0 -0500 +++ debootstrap-1.0.28gilbert1/debian/changelog 2011-03-18 16:25:11.0 -0400 @@ -1,3 +1,9 @@ +debootstrap (1.0.28gilbert1) unstable; urgency=low + + * Don't remove convienience links in debootstrab-udeb. + + -- Michael Gilbert michael.s.gilb...@gmail.com Fri, 18 Mar 2011 16:24:43 -0400 + debootstrap (1.0.28) unstable; urgency=low [ Miguel Figueiredo ] diff -Nru debootstrap-1.0.28/debian/rules debootstrap-1.0.28gilbert1/debian/rules --- debootstrap-1.0.28/debian/rules 2011-01-18 12:16:05.0 -0500 +++ debootstrap-1.0.28gilbert1/debian/rules 2011-03-18 16:24:36.0 -0400 @@ -23,7 +23,4 @@ debian/debootstrap-udeb/usr/share/debootstrap/scripts/edgy \ debian/debootstrap-udeb/usr/share/debootstrap/scripts/feisty \ debian/debootstrap-udeb/usr/share/debootstrap/scripts/*.buildd \ - debian/debootstrap-udeb/usr/share/debootstrap/scripts/*.fakechroot \ - debian/debootstrap-udeb/usr/share/debootstrap/scripts/stable \ - debian/debootstrap-udeb/usr/share/debootstrap/scripts/testing \ - debian/debootstrap-udeb/usr/share/debootstrap/scripts/unstable + debian/debootstrap-udeb/usr/share/debootstrap/scripts/*.fakechroot
Bug#617943: debian-installer: isolated make build_netboot fails due to missing 2.6.32 modules
package: debian-installer version: 20110106 severity: important d-i's make build_netboot currently fails due to absent 2.6.32 module udebs. Strangely enough, the netboot build seems to go fine when using debuild instead of the isolated make build_netboot. Thanks for looking into this. Best wishes, Mike Failed build log: $ apt-get source debian-installer Reading package lists... Done Building dependency tree Reading state information... Done NOTICE: 'debian-installer' packaging is maintained in the 'Svn' version control system at: svn://svn.debian.org/d-i/trunk/installer Need to get 13.6 MB of source archives. Get:1 http://ftp.us.debian.org/debian/ sid/main debian-installer 20110106 (dsc) [3,248 B] Get:2 http://ftp.us.debian.org/debian/ sid/main debian-installer 20110106 (tar) [13.6 MB] Fetched 13.6 MB in 19s (696 kB/s) dpkg-source: info: extracting debian-installer in debian-installer-20110106 dpkg-source: info: unpacking debian-installer_20110106.tar.gz $ cd debian-installer-20110106/build $ make build_netboot Using generated sources.list.udeb: deb copy:/media/newhd/source/debian-installer-20110106/build/ localudebs/ deb http://ftp.us.debian.org/debian unstable main/debian-installer make[2]: `sources.list.udeb' is up to date. Ign copy: localudebs/ InRelease Ign copy: localudebs/ Release.gpg Ign copy: localudebs/ Release Get:1 copy: localudebs/ Packages [20 B] Ign copy: localudebs/ Translation-en_US Ign copy: localudebs/ Translation-en Get:2 http://ftp.us.debian.org unstable InRelease [147 kB] Get:3 http://ftp.us.debian.org unstable/main/debian-installer amd64 Packages [52.8 kB] Ign http://ftp.us.debian.org unstable/main/debian-installer TranslationIndex Ign http://ftp.us.debian.org unstable/main/debian-installer Translation-en_US Ign http://ftp.us.debian.org unstable/main/debian-installer Translation-en Fetched 200 kB in 1s (108 kB/s) Reading package lists... Done Reading package lists... Done Building dependency tree... Done dh_testroot get-packages udeb acpi-modules-2.6.32-5-amd64-di anna archdetect bogl-bterm-udeb brltty-udeb busybox-udeb cdebconf-newt-terminal cdebconf-newt-udeb cdebconf-priority cdebconf-text-udeb cdebconf-udeb choose-mirror choose-mirror-bin console-keymaps-at debian-archive-keyring-udeb di-utils di-utils-reboot di-utils-shell di-utils-terminfo download-installer env-preseed ethdetect fat-modules-2.6.32-5-amd64-di fb-modules-2.6.32-5-amd64-di floppy-modules-2.6.32-5-amd64-di gpgv-udeb hw-detect initrd-preseed input-modules-2.6.32-5-amd64-di installation-locale kbd-chooser kernel-image-2.6.32-5-amd64-di libblkid1-udeb libdebconfclient0-udeb libdebian-installer4-udeb libfribidi0-udeb libiw30-udeb libnss-dns-udeb libsysfs2-udeb libtextwrap1-udeb libuuid1-udeb localechooser lowmemcheck main-menu media-retriever module-init-tools-udeb mountmedia nano-udeb net-retriever netcfg network-preseed nic-extra-modules-2.6.32-5-amd64-di nic-modules-2.6.32-5-amd64-di nic-pcmcia-modules-2.6.32-5-amd64-d i nic-usb-modules-2.6.32-5-amd64-di nic-wireless-modules-2.6.32-5-amd64-di pciutils-udeb pcmcia-modules-2.6.32-5-amd64-di pcmciautils-udeb preseed-common rescue-check rootskel save-logs udev-udeb udpkg usb-modules-2.6.32-5-amd64-di usb-storage-modules-2.6.32-5-amd64-di util-linux-udeb virtio-modules-2.6.32-5-amd64-di zlib1g-udeb make[3]: `sources.list.udeb' is up to date. Ign copy: localudebs/ InRelease Ign copy: localudebs/ Release.gpg Ign copy: localudebs/ Release Ign copy: localudebs/ Packages/DiffIndex Get:1 copy: localudebs/ Packages [20 B] Ign copy: localudebs/ Translation-en_US Ign copy: localudebs/ Translation-en Hit http://ftp.us.debian.org unstable InRelease Hit http://ftp.us.debian.org unstable/main/debian-installer amd64 Packages Ign http://ftp.us.debian.org unstable/main/debian-installer TranslationIndex Ign http://ftp.us.debian.org unstable/main/debian-installer Translation-en_US Ign http://ftp.us.debian.org unstable/main/debian-installer Translation-en Fetched 20 B in 0s (24 B/s) Reading package lists... Done Reading package lists... Done Building dependency tree... Done Need to download: acpi-modules-2.6.32-5-amd64-di anna archdetect bogl-bterm-udeb brltty-udeb busybox-udeb cdebconf-newt-terminal cdebconf-newt-udeb cdebconf-priority cdebconf-text-udeb cdebconf-udeb choose-mirror choose-mirror-bin console-keymaps-at debian-archive-keyring-udeb di-utils di-utils-reboot di-utils-shell di-utils-terminfo download-installer env-preseed ethdetect fat-modules-2.6.32-5-amd64-di fb-modules-2.6.32-5-amd64-di floppy-modules-2.6.32-5-amd64-di gpgv-udeb hw-detect initrd-preseed input-modules-2.6.32-5-amd64-di installation-locale kbd-chooser kernel-image-2.6.32-5-amd64-di libblkid1-udeb libdebconfclient0-udeb libdebian-installer4-udeb libfribidi0-udeb libiw30-udeb libnss-dns-udeb libsysfs2-udeb libtextwrap1-udeb
Bug#617204: installation-report: /usr/sbin/debootstrap reports sha1sum: not found
On Mon, 7 Mar 2011 18:25:14 -0500 Rick Thomas wrote: On Mar 7, 2011, at 3:08 PM, Adam D. Barratt wrote: On Mon, 2011-03-07 at 19:17 +0100, Christian PERRIER wrote: Quoting Rick Thomas (rbtho...@pobox.com): Package: installation-reports Version: 2.44 Severity: grave Tags: d-i Justification: renders package unusable That should be fixed once busybox providing sha256sum reaches testing. fwiw, that won't happen automagically, as busybox is on britney's needs approval from d-i RM list. Regards, Adam Well, in the mean-time, there's no way to test new d-i businesscard or netinst CDs beyond the disk partition step. Or, to put it more bluntly: Testing grinds to a halt until this is fixed. You can try the unofficial testing snapshot release in the meantime [0]. There are no guarantees of a constantly working testing installer right now. Best wishes, Mike [0] http://lists.debian.org/debian-devel/2011/03/msg00347.html -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110308074112.2cc948b1.michael.s.gilb...@gmail.com
Bug#615926: busybox-udeb: missing shaXYZsum binaries
found 615926 1:1.17.1-8 notfound 615926 1:1.17.1-10 thanks On Tue, 1 Mar 2011 12:17:18 -0400 Joey Hess wrote: Thijs Kinkhorst wrote: On Tue, March 1, 2011 05:21, Michael Gilbert wrote: package: busybox-udeb version: 1:1.17.1-10 severity: grave Hi, testing is currently uninstallable since debootstrap (as of 1.0.28) no longer uses md5 for integrity checks. It can make use of various shaXYZsum instead. I think providing sha1sum should be sufficient, but it may make sense to provide more than that. The version you quote (which is not yet in testing) provides sha256sum. Is that not sufficient then? Downgrading this bug as it'll be preventing the fix from reaching testing. If this version of busybox-udeb actually does not work, I second Thijs's request for details. I was busy working on other things and blindly accepted the version number from my unstable box where I generated the bug report, not the actual vm where I ran into the issue. Having sha256sum available may be enough, but I haven't looked at that. Note that base-installer 1.116 is also needed, and also not yet in testing. Really, it's fairly pointless to be using wheezy_d-i CD images at this point in the development cycle. Perhaps the fix for this is just to point the CD symlinks at the sid_d-i images. I'm generating nightly testing snapshots, and those are incapable of completing an installation right now due to this issue, which is why I submitted this. This may be a bit premature, but my monthly snapshots may be a better resource to direct users to that want a reliable testing installer. Well, at least that's the goal anyway ;) Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110301193316.85384796.michael.s.gilb...@gmail.com
Bug#615926: busybox-udeb: missing shaXYZsum binaries
package: busybox-udeb version: 1:1.17.1-10 severity: grave Hi, testing is currently uninstallable since debootstrap (as of 1.0.28) no longer uses md5 for integrity checks. It can make use of various shaXYZsum instead. I think providing sha1sum should be sufficient, but it may make sense to provide more than that. Thanks, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110228232146.78ffe010.michael.s.gilb...@gmail.com
Bug#614511: debootstrap: can't cope with md5-less release files
package: debootstrap version: 1.0.26 severity: serious this is already in discussion on -devel, but i figure its worth a bug report for tracking purposes. sid and wheezy can't be bootstrapped anymore since their release files lack md5sums. best wishes, mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim8ow8oqxgpza386y1yqthzcvj863qjqcdwj...@mail.gmail.com
Bug#493065: debootstrap fakechroot variant fails
forcemerge 493065 588773 retitle 493065 debootstrap fakechroot variant fails due to missing PATH tag 493065 patch thanks this fails because chroot is in /usr/sbin, which isn't in PATH for normal users by default anymore. i've attached a preliminary patch that fixes this in debootstrap, but i wonder if it wouldn't be more appropriate to change fakeroot instead? it seems like any fakeroot environment should include /usr/sbin and /sbin in the path, but that isn't currently the case. mike diff -Nru debootstrap-1.0.25/debootstrap debootstrap-1.0.25+nmu1/debootstrap --- debootstrap-1.0.25/debootstrap 2010-09-20 13:22:26.0 -0400 +++ debootstrap-1.0.25+nmu1/debootstrap 2010-10-25 23:19:58.0 -0400 @@ -289,6 +289,9 @@ else error 1 NEEDARG option requires an argument %s $1 fi + if [ $VARIANT = fakechroot ]; then + export PATH=/usr/sbin:/sbin:$PATH + fi ;; --keyring|--keyring=?*) if ! gpgv --version /dev/null 21; then
Bug#558016: debian-installer: UTC question is unnecessary when using NTP
package: debian-installer severity: normal suppose that at the beginning of the installation the user says yes to whether they want their clock to be autamically configured with NTP, then (ideally) they should never have to worry about the clock ever again. however, as the installer finishes up, it asks whether or not the clock is set to UTC, which can be information overload to many users. since he/she has already told the clock to sync itself automatically, this question is not really necessary. i would recommend disabling that prompt if the user chooses NTP. note that this is in regard to the latest testing netinst image: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/ thanks! mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558016: debian-installer: UTC question is unnecessary when using NTP
On Thu, 26 Nov 2009 00:39:41 +0100 Frans Pop wrote: reassign 558016 clock-setup thanks On Wednesday 25 November 2009, Michael Gilbert wrote: suppose that at the beginning of the installation the user says yes to whether they want their clock to be autamically configured with NTP, then (ideally) they should never have to worry about the clock ever again. however, as the installer finishes up, it asks whether or not the clock is set to UTC, which can be information overload to many users. since he/she has already told the clock to sync itself automatically, this question is not really necessary. i would recommend disabling that prompt if the user chooses NTP. The functionality behind the question is more complex. It is how the clock *should* be set. Up to that point the hardware clock has not yet been set. The update from NTP only sets the system clock, not the hardware clock. You are correct in so far that the wording of the template should be changed to better reflect this. would it be possible for the installer to automatically determine the correct UTC setting based on info retrieved from the NTP clock? i.e. if the internal clock differs from the NTP clock by 6 hours and the user said that they are in the Eastern US timezone, then you can assume they are using local time and not UTC. similarly, if the clocks are the same, then you can assume that they are using UTC. if the clocks differ by some strange value, then maybe bring up an are you sure about your time zone dialog. i would hope that this dialog can be done away with (unless the user chooses to not configure NTP). mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517018: debian-installer: no-root option in expert installer exposes locally exploitable security flaw
package: debian-installer severity: important tags: security there is now an option in the expert mode of the debian-installer that allows the user to install their system without a root account (replacing it with sudo priviledges for the default user). this exposes a loophole that enables local attackers to easily obtain root access. details: since there is no root password set up during installation, a local attacker can simply boot into the root account (without being prompted for a password) via single user mode (single kernel option). then, he/she can do all kinds of malicious things, but the easiest would be to simply change the root password...thus owning the machine. and since the user never logs in with the root password him/herself, he/she would never realize that an attacker had gotten in (unless he/she diligently reviews logs). [1] discusses the details of the method for password recovery, but the same can be used for malicious purposes, of course. potential solutions: 1. always create a root password (e.g. set up a random root password, rather than no password, during the no root debian-installer setup page). note that this may currently be done since su itself asks for a password. 2. drop the user to a full login prompt when booting into single user mode; thus requiring a valid user account and sudo to perform administrative actions. note that it may be possible to circumvent this via the init kernel option, for example init=/bin/bash. 3. disable the no-root setup page in debian-installer. the third option may be the easiest to implement immediately -- especially since it's an experimental option in the expert mode of the installer. the second option is probably the most robust, but might be easily circumvented, and would require changes in single user mode such as automatically mounting /home, which may make single user mode harder to use (one use case for this mode is to recover or scan /home, and if it's mounted, that's more difficult). justification for why a fix for this problem is necessary: there are levels of vulnerability/security. at the lowest level are pure software vulnerabilities (such as this issue), which require absolutely no effort for a local attacker. however, for a hardware-assisted exploit, it requires surrepticious entry, more time, and more preparedness (and it looks suspicious, and can be somewhat prevented by limiting access to areas via locks, valid users only, etc). the user can also increase their security by disabling boot from media in the bios, which would force the attacker to spend more time to crack open the machine, which is even more suspicious. at each level, it takes more and more time for the attacker to exploit the vulnerability, thus increasing the chance of detecting them. less than a minute for the software exploit, 10s of minutes for hardware assisted and longer for resetting the bios. severity: note that the severity of this problem is fairly low right now since no-root is a non-default option in the expert installer. hence, few debian systems are likely exposed; but regardless, this problem should be fixed asap. note that no-root has been the default installer behavior for ubuntu (since at least dapper i think), so it is a much more severe issue for them. [1] http://linuxwave.blogspot.com/2008/09/ubuntu-forgotten-password.html -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517018: debian-installer: no-root option in expert installer exposes locally exploitable security flaw
On Tue, 24 Feb 2009 22:12:52 -0800 Steve Langasek wrote: since there is no root password set up during installation, a local attacker can simply boot into the root account (without being prompted for a password) via single user mode (single kernel option). Have you tested that this is actually the case? yes. no password != empty password. right, i certainly appreciate that there is a huge difference. i'm not entirely sure what the installer is doing (i assume that it generates a random password since su itself still requires a password), but the easiest way i could think to describe the problem was by the term no-root. if there is better terminology that i can use, please let me know. Booting in single user mode should not allow you to bypass the password prompt, and if it does, that's a bug in the sulogin program. this is exactly what happens. there is no password prompt for single user mode. it may indeed be more of an issue related to sulogin than the installer, but the (non-default) no-root feature in the expert installer exposes the problem. the current behavior may have been a conscious choice (probably made by someone on the ubuntu team) to allow users admin their systems even though they never set up a root password. [1] discusses the details of the method for password recovery, but the same can be used for malicious purposes, of course. [1] http://linuxwave.blogspot.com/2008/09/ubuntu-forgotten-password.html This link explicitly shows overriding the init value in the bootloader. That doesn't appear to have anything to do with vulnerabilities with how the root account is set up. regardless of what the article says, the init=/bin/bash option isn't actually necessary. all you need is single, and a boot entry for that is automatically set up by the installer by default. mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#382889: for users that install a lot of systems
On 4/15/07, Geert Stappers wrote: For those users there is preseeding. See the preseeding section in the manual for details. ok, so if that's the case, why can't the prompts be upfront and store the user choices to the preseed file? mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382889: closed by Christian Perrier [EMAIL PROTECTED] (Closing bug as we don't intend to change the order of questions)
reopen 382889 thanks Subject: Closing bug as we don't intend to change the order of questions After the discussion that happened in this bug's log, it is clear that the D-I team has no intent to change the order of questions in the installation process. The user setup comes after the partitioning step, and moving its questions elsewhere would mean moving the clock setup questions as well, which is technically not possible before the disk is partitioned. why can't this information be stored in ram until disk partitioning finishes, then transfered to the right location on disk? mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
