Bug#771190: installation-reports: Screen refresh rate set wrong during installation, discovered on first boot. Do settings manually during installation, please
Package: installation-reports Severity: important Tags: d-i Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- Package-specific info: Boot method: cd Image version: 7.1.0 network installer Date: Machine: Microtel standard pc Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [0 ] Detect network card:[0 ] Configure network: [0 ] Detect CD: [0 ] Load installer modules: [0 ] Clock/timezone setup: [0 ] User/password setup:[0 ] Detect hard drives: [0 ] Partition hard drives: [0 ] Install base system:[0 ] Install tasks: [0 ] Install boot loader:[0 ] Overall install:[0 ] Comments/Problems: I am familiar with the detailed hardware and software setup used by Mandriva and would like that detail more closely followed in choices of desktops to install, software packages (office, development, etc), and hardware setup. Automatic screen setup is a very bad mistake. You need to give users the choice to test and choose screen setup (resolution, refresh, maybe choice of specific card/driver or generic driver. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="7 (wheezy) - installer build 20130613" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux unknown0010DC5A6DE8 3.2.0-4-486 #1 Debian 3.2.46-1 i686 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: VIA Technologies, Inc. VT8361 [KLE133] Host Bridge [1106:3112] lspci -knn: Kernel driver in use: agpgart-via lspci -knn: 00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT8361 [KLE133] AGP Bridge [1106:b112] lspci -knn: 00:07.0 ISA bridge [0601]: VIA Technologies, Inc. VT82C686 [Apollo Super South] [1106:0686] (rev 40) lspci -knn: Subsystem: VIA Technologies, Inc. Device [1106:] lspci -knn: Kernel driver in use: parport_pc lspci -knn: 00:07.1 IDE interface [0101]: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] (rev 06) lspci -knn: Subsystem: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] lspci -knn: Kernel driver in use: pata_via lspci -knn: 00:07.2 USB controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 1a) lspci -knn: Subsystem: VIA Technologies, Inc. (Wrong ID) Device [0925:1234] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:07.3 USB controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 1a) lspci -knn: Subsystem: VIA Technologies, Inc. (Wrong ID) Device [0925:1234] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:07.4 Bridge [0680]: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] [1106:3057] (rev 40) lspci -knn: Subsystem: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] [1106:3057] lspci -knn: 00:07.5 Multimedia audio controller [0401]: VIA Technologies, Inc. VT82C686 AC97 Audio Controller [1106:3058] (rev 50) lspci -knn: Subsystem: VIA Technologies, Inc. VT82C686 AC97 Audio Controller [1106:3058] lspci -knn: Kernel driver in use: snd_via82xx lspci -knn: 00:0f.0 Ethernet controller [0200]: ADMtek NC100 Network Everywhere Fast Ethernet 10/100 [1317:0985] (rev 11) lspci -knn: Subsystem: Accton Technology Corporation Device [1113:1216] lspci -knn: Kernel driver in use: tulip lspci -knn: 01:00.0 VGA compatible controller [0300]: Trident Microsystems CyberBlade/i1 [1023:8500] lspci -knn: Subsystem: Trident Microsystems CyberBlade/i1 [1023:8500] usb-list: usb-list: Bus 01 Device 01: UHCI Host Controller [1d6b:0001] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 3.2.0-4-486 uhci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 02 Device 01: UHCI Host Controller [1d6b:0001] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 3.2.0-4-486 uhci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 02 Device 02
Bug#770078: ifupdown: interfaces(5) falsely claims that interfaces.d is included by default on new installs
I'd really appreciate any comment on this from d-i maintainers. -- Cheers, Andrew -- 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/CACujMDNkR2U7=_Tke2JpqU=bsnesx79mkduefee00zewwqd...@mail.gmail.com
Bug#770078: ifupdown: interfaces(5) falsely claims that interfaces.d is included by default on new installs
Andrew Shadura (2014-11-22): > Hello, > > On Tue, 18 Nov 2014 11:15:00 -0700 > Peter Karbaliotis wrote: > > > The interfaces(5) man page claims: > > By default, on a freshly installed Debian system, the interfaces > > file includes a line to source /etc/network/interfaces.d directory. > > but on two new jessie installs there is no 'source-directory > > interfaces.d' stanza. > > I guess this is something that should be done by the Debian installer, > as there's a code in package's postinst which installs the > correct /etc/network/interfaces file if it doesn't exist, so I guess > it's never being run as the file has already been generated. You probably want to look at debcheckout netcfg; write_interface.c is most likely the interesting one, along with base-installer.d/40netcfg and finish-install.d/55netcfg-copy-config which you may want to check as well since they toy with/copy around /e/n/i. Mraw, KiBi. signature.asc Description: Digital signature
Bug#770078: ifupdown: interfaces(5) falsely claims that interfaces.d is included by default on new installs
Hello,
On 27 November 2014 at 15:26, Cyril Brulebois wrote:
> You probably want to look at debcheckout netcfg; write_interface.c is
> most likely the interesting one, along with base-installer.d/40netcfg
> and finish-install.d/55netcfg-copy-config which you may want to check
> as well since they toy with/copy around /e/n/i.
Thanks. It seems modifying write_interface.c alone should be enough.
--
Cheers,
Andrew
diff --git a/write_interface.c b/write_interface.c
index 1aa331a..2562acc 100644
--- a/write_interface.c
+++ b/write_interface.c
@@ -30,6 +30,7 @@ static int nc_wi_header(FILE *fd)
{
fprintf(fd, "# This file describes the network interfaces available on
your system\n");
fprintf(fd, "# and how to activate them. For more information, see
interfaces(5).\n");
+ fprintf(fd, "\nsource-directory interfaces.d\n");
return 1;
}
Bug#770078: ifupdown: interfaces(5) falsely claims that interfaces.d is included by default on new installs
Control: tag -1 patch Andrew Shadura (2014-11-27): > Hello, > > On 27 November 2014 at 15:26, Cyril Brulebois wrote: > > You probably want to look at debcheckout netcfg; write_interface.c is > > most likely the interesting one, along with base-installer.d/40netcfg > > and finish-install.d/55netcfg-copy-config which you may want to check > > as well since they toy with/copy around /e/n/i. > > Thanks. It seems modifying write_interface.c alone should be enough. That would have been my first guess indeed. Am I correct in assuming that such an /e/n/i file with an older ifupdown doesn't cause any issues? I'd also like to know whether it can cause any issues with other tools parsing/using/abusing /e/n/i (n-m notably). Why the first question: just in case we end up backporting netcfg at some point. Why the second question: we have code to do this or that depending on whether n-m is getting installed within d-i, but it could be installed afterwards, so I'd be nice if adding this line didn't cause any issues later. Mraw, KiBi. signature.asc Description: Digital signature
Processed: Re: Bug#770078: ifupdown: interfaces(5) falsely claims that interfaces.d is included by default on new installs
Processing control commands: > tag -1 patch Bug #770078 [debian-installer] ifupdown: interfaces(5) falsely claims that interfaces.d is included by default on new installs Added tag(s) patch. -- 770078: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770078 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.b770078.141710082812803.transcr...@bugs.debian.org
Processed: severity of 771190 is wishlist
Processing commands for cont...@bugs.debian.org: > severity 771190 wishlist Bug #771190 [installation-reports] installation-reports: Screen refresh rate set wrong during installation, discovered on first boot. Do settings manually during installation, please Severity set to 'wishlist' from 'important' > thanks Stopping processing here. Please contact me if you need assistance. -- 771190: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771190 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.141710148916929.transcr...@bugs.debian.org
Bug#770078: ifupdown: interfaces(5) falsely claims that interfaces.d is included by default on new installs
Hello, On 27 November 2014 at 16:07, Cyril Brulebois wrote: > Am I correct in assuming that such an /e/n/i file with an older ifupdown > doesn't cause any issues? I'd also like to know whether it can cause any > issues with other tools parsing/using/abusing /e/n/i (n-m notably). It does. Actually, I've just checked, both current n-m and ifupdown from wheezy support only 'source' directive. The difference between source and source-directory is that the second form doesn't need a glob mask to be specified, as it uses run-parts-style matching. In that case, maybe it's better to change this to: source /etc/network/interfaces.d/* (The other utility parsing interfaces is guessnet, it's current version also supports "source" keyword only.) > Why the first question: just in case we end up backporting netcfg at > some point. Why the second question: we have code to do this or that > depending on whether n-m is getting installed within d-i, but it could > be installed afterwards, so I'd be nice if adding this line didn't cause > any issues later. -- Cheers, Andrew -- 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/cacujmdntzmekv49t4yxets_lagdawqcp7egzatsh1xnjdwr...@mail.gmail.com
Bug#770078: ifupdown: interfaces(5) falsely claims that interfaces.d is included by default on new installs
Andrew Shadura (2014-11-27): > On 27 November 2014 at 16:07, Cyril Brulebois wrote: > > Am I correct in assuming that such an /e/n/i file with an older ifupdown > > doesn't cause any issues? I'd also like to know whether it can cause any > > issues with other tools parsing/using/abusing /e/n/i (n-m notably). > > It does. Actually, I've just checked, both current n-m and ifupdown > from wheezy support only 'source' directive. The difference between > source and source-directory is that the second form doesn't need a > glob mask to be specified, as it uses run-parts-style matching. In > that case, maybe it's better to change this to: Thanks for checking. > source /etc/network/interfaces.d/* This would probably be safer at this point of the release cycle indeed. We can think about switching it early during the stretch release cycle. That means the current documentation will still be slightly off though. Please tell us whether you want us to go ahead for a "source ../*" addition and a doc update on your side. Mraw, KiBi. signature.asc Description: Digital signature
Bug#770078: ifupdown: interfaces(5) falsely claims that interfaces.d is included by default on new installs
Hello, On 27 November 2014 at 16:28, Cyril Brulebois wrote: >> source /etc/network/interfaces.d/* > This would probably be safer at this point of the release cycle indeed. > We can think about switching it early during the stretch release cycle. > That means the current documentation will still be slightly off though. I will update the documentation on my side in the upload I'm going to do this weekend. I need to fix systemd interaction and loopback interface anyway. > Please tell us whether you want us to go ahead for a "source ../*" > addition and a doc update on your side. Yes please. Also, I think at this moment specifying an absolute path is safer as the ifupdown version in wheezy had a bug which led to an incorrect relative path interpretation in some cases. -- Cheers, Andrew -- 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/CACujMDPCd4P4-uCDkA0K561aeSY3JDY4tyGav=c51b+xbqj...@mail.gmail.com
unblock: busybox/1:1.22.0-14
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package busybox. Last upload has one security bugfix
(CVE-2014-4607, #768945), the fix is from upstream stable branch,
fixing an integer overflow in lzo decompressor; it adds a Built-Using
control field for busybox-static variant (#768926), and also arranges
build system to only produce binary or indep .debs (or both), depending
on the d/rules target (binary-all vs binary-indep vs binary) -- this
is a long-standing lintian bug which I overlooked previously.
The busybox-static fix turned out to be a fun case, because I needed
a way to build-conflict on a non-broken libc (because the original
prob is in libc due to #754813), and that turned out to be a not-so-
trivial task, which resulted in several iterations. Meanwhile I
discovered that current glibc is not able to produce working stati-
cally linked executables on hurd which uses nss functions --
statically linked executable on hurd just segfaults. So now,
after a fix for #768926, busybox package does not build on hurd,
while previously it silently produced failing busybox-static.
Hurd people are working on the fix.
(The Built-Using field generation is a bit fun here: I asked on IRC
how people identify which libc is in use, and got various somewhat-
incpmplete replies (the prob is that on different arches, libc package
is named differently). So I invented my own way for busybox, because
this package allows me to do that -- I took the contents of $shlibs:Depends
variable for the dynamically-linked version, and transformed it into
a list of sources required for Built-Using using dpkg-query.)
There's no code changes except the lzo decompression bugfix, only
packaging changes.
Since busybox is used in d-i too, I kindly request for a
udeb-unblock too.
Previously I submitted an unblock request for busybox 1.22.0-10,
as #769129, but that turned out to be a bit preliminary because
of the fun with libc versioned build dependency iterations.
Thank you!
/mjt
unblock busybox/1:1.22.0-14
diff -Nru busybox-1.22.0/debian/changelog busybox-1.22.0/debian/changelog
--- busybox-1.22.0/debian/changelog 2014-09-30 08:50:20.0 +0400
+++ busybox-1.22.0/debian/changelog 2014-11-14 12:53:24.0 +0300
@@ -1,3 +1,46 @@
+busybox (1:1.22.0-14) medium; urgency=low
+
+ * one more attempt to fix the glibc build-depend for #769190, now
+using versioned build-dependency on libc-dev-bin which is named
+this way on all architectures (unlike libc6|libc6.1|libc0.1|libc0.3)
+
+ -- Michael Tokarev Fri, 14 Nov 2014 12:52:18 +0300
+
+busybox (1:1.22.0-13) unstable; urgency=medium
+
+ * really fix #769190 the hard way, by build-conflicting with all
+arch-specific names of libc with version <2.19-12 (Closes: #769190)
+ * check if glibc can produce working statically linked binaries
+by performing a getpwnam("root") call before building (#754813)
+
+ -- Michael Tokarev Wed, 12 Nov 2014 23:59:30 +0300
+
+busybox (1:1.22.0-12) unstable; urgency=medium
+
+ * fix the previous changelog entry (wrong bug# was "fixed" and typos)
+ * ensure we build against non-broken glibc (>=2.19-12) (Closes: #769190)
+
+ -- Michael Tokarev Wed, 12 Nov 2014 12:37:11 +0300
+
+busybox (1:1.22.0-11) unstable; urgency=medium
+
+ * fix the built-using generation in the previous upload -- did not
+work correctly for != 1 dependency and #588505 in dpkg
+
+ -- Michael Tokarev Tue, 11 Nov 2014 19:24:21 +0300
+
+busybox (1:1.22.0-10) unstable; urgency=high
+
+ * lzop-add-overflow-check-CVE-2014-4607.patch (Closes: #768945)
+ * add Built-Using control field for -static, deriving it from
+regular build (this will be glibc) (Closes: #768876)
+ * install only arch/indep deb as requested by binary-arch or binary-indep
+target. This fixes a long-standing lintian error, when package build
+always produces busybox-syslogd package which is arch:all and should not
+be built on a buildd.
+
+ -- Michael Tokarev Tue, 11 Nov 2014 17:07:34 +0300
+
busybox (1:1.22.0-9) unstable; urgency=medium
* cherry-pick find /BITS patch from upstream (Closes: #760637)
diff -Nru busybox-1.22.0/debian/control busybox-1.22.0/debian/control
--- busybox-1.22.0/debian/control 2014-09-30 08:35:20.0 +0400
+++ busybox-1.22.0/debian/control 2014-11-14 12:52:17.0 +0300
@@ -5,7 +5,10 @@
Uploaders: Bastian Blank , Michael Tokarev
Build-Depends: debhelper (>= 9),
# needs for testsuite to run
- zip
+ zip,
+# glibc static-nss #754813, 2.19..2.19-11, -12 is ok. Depend on libc-dev-bin
+# as it is the package which is named the same on all architectures
+ libc-dev-bin (>> 2.19-12~) | libc-dev-bin (<< 2.19),
Standards-Version: 3.9.5
Vcs-Git: git://anonscm.debian.org/d-i/busybox.git
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=d-i/busybox.git
@@ -33,6 +36,7 @@
Package: busybox-static
Architecture: any
+Built-Using: ${built
Bug#770078: ifupdown: interfaces(5) falsely claims that interfaces.d is included by default on new installs
Control: reassign -1 netcfg 1.125
Andrew Shadura (2014-11-27):
> On 27 November 2014 at 16:28, Cyril Brulebois wrote:
> >> source /etc/network/interfaces.d/*
>
> > This would probably be safer at this point of the release cycle indeed.
> > We can think about switching it early during the stretch release cycle.
>
> > That means the current documentation will still be slightly off though.
>
> I will update the documentation on my side in the upload I'm going to
> do this weekend. I need to fix systemd interaction and loopback
> interface anyway.
>
> > Please tell us whether you want us to go ahead for a "source ../*"
> > addition and a doc update on your side.
>
> Yes please. Also, I think at this moment specifying an absolute path
> is safer as the ifupdown version in wheezy had a bug which led to an
> incorrect relative path interpretation in some cases.
I have the attached patch pending locally; not pushing right now to
avoid an accidental upload while I haven't got around to requesting a
few unblock/unblock-udeb (one of which is about netcfg).
Mraw,
KiBi.
From 648976eb4168abe27671ef5ccf38682d98ed535f Mon Sep 17 00:00:00 2001
From: Cyril Brulebois
Date: Thu, 27 Nov 2014 16:45:40 +0100
Subject: [PATCH] Add support for /etc/network/interfaces.d/ by adding a
"source" directive (Closes: #770078).
It can be replaced with a "source-directory" one during the next release cycle.
---
debian/changelog | 8
write_interface.c | 1 +
2 files changed, 9 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index fa68873..459ee42 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+netcfg (1.126) UNRELEASED; urgency=medium
+
+ * Add support for /etc/network/interfaces.d/ by adding a "source"
+directive (Closes: #770078). It can be replaced with a
+"source-directory" one during the next release cycle.
+
+ -- Cyril Brulebois Thu, 27 Nov 2014 16:41:41 +0100
+
netcfg (1.125) unstable; urgency=medium
* Re-upload without stray files.
diff --git a/write_interface.c b/write_interface.c
index 1aa331a..2ab1a34 100644
--- a/write_interface.c
+++ b/write_interface.c
@@ -30,6 +30,7 @@ static int nc_wi_header(FILE *fd)
{
fprintf(fd, "# This file describes the network interfaces available on your system\n");
fprintf(fd, "# and how to activate them. For more information, see interfaces(5).\n");
+ fprintf(fd, "\nsource /etc/network/interfaces.d/*\n");
return 1;
}
--
2.1.3
signature.asc
Description: Digital signature
Processed: Re: Bug#770078: ifupdown: interfaces(5) falsely claims that interfaces.d is included by default on new installs
Processing control commands: > reassign -1 netcfg 1.125 Bug #770078 [debian-installer] ifupdown: interfaces(5) falsely claims that interfaces.d is included by default on new installs Bug reassigned from package 'debian-installer' to 'netcfg'. Ignoring request to alter found versions of bug #770078 to the same values previously set Ignoring request to alter fixed versions of bug #770078 to the same values previously set Bug #770078 [netcfg] ifupdown: interfaces(5) falsely claims that interfaces.d is included by default on new installs Marked as found in versions netcfg/1.125. -- 770078: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770078 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.b770078.141710332430624.transcr...@bugs.debian.org
Bug#771209: netboot: recommended jessie beta2 fails due to kernel mismatch
Package: installation-reports Severity: important Tags: d-i Dear Maintainer, there seems to be no checks on the debian ftp servers which hinders disapearing of udeb kernel modules while still referenced from current netboot images. So the "recommended jessie beta2" (debian.org testing) netboot image fails due to not finding the now old udeb kernel modules any more. Workaround is to use a (not recommended) newer image, which contains the same kernel as the debian ftp servers. Proposed solutions: 1) short term: update the "recommended jessie beta2" image to contain the same kernel as the udebs on ftp 2) long term: implement some check which prohibits disappearing of still referenced kernel udebs OR a mechanism to keep only netboot images on the ftp servers which match the kernel udebs. For a failure of the same kind in stable see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757787 Thanks and greetings Hermann -- Package-specific info: Boot method: network Image version: http://ftp.nl.debian.org/debian/dists/testing/main/installer-amd64/current/images/netboot/netboot.tar.gz (20141002) Date: Machine: amd64 Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [ ] Load installer modules: [E] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="8 (jessie) - installer build 20141125-00:07" X_INSTALLATION_MEDIUM=netboot == Installer hardware-summary: == uname -a: Linux install5 3.16.0-4-amd64 #1 SMP Debian 3.16.7-2 (2014-11-06) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 82Q35 Express DRAM Controller [8086:29b0] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation 82Q35 Express PCI Express Root Port [8086:29b1] (rev 02) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:03.0 Communication controller [0780]: Intel Corporation 82Q35 Express MEI Controller [8086:29b4] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] lspci -knn: 00:03.2 IDE interface [0101]: Intel Corporation 82Q35 Express PT IDER Controller [8086:29b6] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] lspci -knn: Kernel driver in use: ata_generic lspci -knn: 00:03.3 Serial controller [0700]: Intel Corporation 82Q35 Express Serial KT Controller [8086:29b7] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] lspci -knn: Kernel driver in use: serial lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation 82566DM-2 Gigabit Network Connection [8086:10bd] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] lspci -knn: Kernel driver in use: e1000e lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1a.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] lspci -knn: Kernel driver in use: ehci-pci lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 02) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1d.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] ls
Re: Bug#771208: unblock: busybox/1:1.22.0-14
(Putting on my d-i RM fedora.) Michael Tokarev (2014-11-27): > Please unblock package busybox. Last upload has one security bugfix > (CVE-2014-4607, #768945), the fix is from upstream stable branch, > fixing an integer overflow in lzo decompressor; it adds a Built-Using > control field for busybox-static variant (#768926), and also arranges > build system to only produce binary or indep .debs (or both), depending > on the d/rules target (binary-all vs binary-indep vs binary) -- this > is a long-standing lintian bug which I overlooked previously. #768926 is still not #768876: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768926#28 > The busybox-static fix turned out to be a fun case, because I needed > a way to build-conflict on a non-broken libc (because the original > prob is in libc due to #754813), and that turned out to be a not-so- > trivial task, which resulted in several iterations. Meanwhile I > discovered that current glibc is not able to produce working stati- > cally linked executables on hurd which uses nss functions -- > statically linked executable on hurd just segfaults. So now, > after a fix for #768926, busybox package does not build on hurd, > while previously it silently produced failing busybox-static. > Hurd people are working on the fix. > > (The Built-Using field generation is a bit fun here: I asked on IRC > how people identify which libc is in use, and got various somewhat- > incpmplete replies (the prob is that on different arches, libc package > is named differently). So I invented my own way for busybox, because > this package allows me to do that -- I took the contents of $shlibs:Depends > variable for the dynamically-linked version, and transformed it into > a list of sources required for Built-Using using dpkg-query.) > > There's no code changes except the lzo decompression bugfix, only > packaging changes. > > Since busybox is used in d-i too, I kindly request for a > udeb-unblock too. > > Previously I submitted an unblock request for busybox 1.22.0-10, > as #769129, but that turned out to be a bit preliminary because > of the fun with libc versioned build dependency iterations. #768876 is tagged jessie-ignore so I'm really unconvinced by the debian/rules changes. At this stage, I'd rather see the security fix only. Release team people, what's your take on this? Mraw, KiBi. signature.asc Description: Digital signature
Bug#770078: ifupdown: interfaces(5) falsely claims that interfaces.d is included by default on new installs
Hello, On 27 November 2014 at 16:48, Cyril Brulebois wrote: > I have the attached patch pending locally; not pushing right now to > avoid an accidental upload while I haven't got around to requesting a > few unblock/unblock-udeb (one of which is about netcfg). Thanks. -- Cheers, Andrew -- 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/cacujmdoxqel68jc49ldstdt6tbdmt_vvngmijajpefhx4jj...@mail.gmail.com
Re: Bug#771208: unblock: busybox/1:1.22.0-14
27.11.2014 19:00, Cyril Brulebois wrote: > (Putting on my d-i RM fedora.) Thank you for your review. > Michael Tokarev (2014-11-27): >> Please unblock package busybox. Last upload has one security bugfix >> (CVE-2014-4607, #768945), the fix is from upstream stable branch, >> fixing an integer overflow in lzo decompressor; it adds a Built-Using >> control field for busybox-static variant (#768926), and also arranges >> build system to only produce binary or indep .debs (or both), depending >> on the d/rules target (binary-all vs binary-indep vs binary) -- this >> is a long-standing lintian bug which I overlooked previously. > > #768926 is still not #768876: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768926#28 Yes you're right. I fixed it in the changelog but not in this unblock request. Actual bug fixed here is #768876. [] > #768876 is tagged jessie-ignore so I'm really unconvinced by the > debian/rules changes. It is jessie-ignore just to be non-RC. The fun with static linking and bugs it discovered shows that proper Built-Using field is really necessary (it is what #768876 is about). However, bulk of d/rules changes are due to another build fix, to stop building arch-all package (busybox-syslogd) when building binary-arch. Plus one block of added lines to check whenever libc is able to produce working statically-linked executables. > At this stage, I'd rather see the security fix only. > > Release team people, what's your take on this? Thanks, /mjt -- 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/54774c91.9080...@msgid.tls.msk.ru
Bug#771209: marked as done (netboot: recommended jessie beta2 fails due to kernel mismatch)
Your message dated Thu, 27 Nov 2014 17:07:16 +0100 with message-id <20141127160716.gs6...@mraw.org> and subject line Re: Bug#771209: netboot: recommended jessie beta2 fails due to kernel mismatch has caused the Debian Bug report #771209, regarding netboot: recommended jessie beta2 fails due to kernel mismatch to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 771209: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771209 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: installation-reports Severity: important Tags: d-i Dear Maintainer, there seems to be no checks on the debian ftp servers which hinders disapearing of udeb kernel modules while still referenced from current netboot images. So the "recommended jessie beta2" (debian.org testing) netboot image fails due to not finding the now old udeb kernel modules any more. Workaround is to use a (not recommended) newer image, which contains the same kernel as the debian ftp servers. Proposed solutions: 1) short term: update the "recommended jessie beta2" image to contain the same kernel as the udebs on ftp 2) long term: implement some check which prohibits disappearing of still referenced kernel udebs OR a mechanism to keep only netboot images on the ftp servers which match the kernel udebs. For a failure of the same kind in stable see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757787 Thanks and greetings Hermann -- Package-specific info: Boot method: network Image version: http://ftp.nl.debian.org/debian/dists/testing/main/installer-amd64/current/images/netboot/netboot.tar.gz (20141002) Date: Machine: amd64 Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [ ] Load installer modules: [E] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="8 (jessie) - installer build 20141125-00:07" X_INSTALLATION_MEDIUM=netboot == Installer hardware-summary: == uname -a: Linux install5 3.16.0-4-amd64 #1 SMP Debian 3.16.7-2 (2014-11-06) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 82Q35 Express DRAM Controller [8086:29b0] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation 82Q35 Express PCI Express Root Port [8086:29b1] (rev 02) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:03.0 Communication controller [0780]: Intel Corporation 82Q35 Express MEI Controller [8086:29b4] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] lspci -knn: 00:03.2 IDE interface [0101]: Intel Corporation 82Q35 Express PT IDER Controller [8086:29b6] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] lspci -knn: Kernel driver in use: ata_generic lspci -knn: 00:03.3 Serial controller [0700]: Intel Corporation 82Q35 Express Serial KT Controller [8086:29b7] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] lspci -knn: Kernel driver in use: serial lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation 82566DM-2 Gigabit Network Connection [8086:10bd] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] lspci -knn: Kernel driver in use: e1000e lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 02) lspci -knn: Subsystem: Dell Device [1028:0211] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1a.7 USB controller [0c03]: Intel Corporation 82801I (
Bug#764587: installation-reports: After successful installation from usb stick the stick is not recognised on reboot.
Brian On Wed, 2014-11-26 at 11:00 +, Brian Potkin wrote: > Hello Philip, > > I'm assuming that since you did not CC the bug that this is intended to > be a private mail. A mistake on my part. > > I originally did something like this with the first eight CD images and > used apt-cdrom. The user user experience with having to mount and > unmount different images wasn't (IMO) the best, so I re-thought the > issue. > > I have a script, apt-usb. A user types 'apt-usb cups' and is prompted to > insert the stick. Re-issuing the command mounts the stick, installs the > packages and unmounts the stick. apt-usb is copied to /target during the > initial install. All it needs is for the script to be copied automatically to /target. It seem as though there a number of private hacks about. With luck we may get something official this time round. After all there is a slow drift away from optical discs to usb sticks and these are much more useful in the poorer parts of the world. Phil. -- Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand +64 3 488 2818Fax +64 3 488 2875Mobile 027 663 4453 phil...@copyleft.co.nz - personal.i...@copyleft.co.nz - business -- 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/1417126083.1643.11.ca...@copyleft.co.nz
Bug#764587: installation-reports: After successful installation from usb stick the stick is not recognised on reboot.
Hello Philip,
I'm assuming that since you did not CC the bug that this is intended to
be a private mail.
On Wed 26 Nov 2014 at 18:22:52 +1300, Philip Charles wrote:
>
> > I have a USB stick that is used for installing Wheezy and which is
> > recognised on reboot. Instead of writing DVD1 to the stick I do the
> > following:
> >
> > 1. Have a FAT16 partition spanning the whole stick. Format as vfat.
> >
> > 2. Install GRUB in the MBR and copy the hd-media vmlinuz and initrd.gz
> >to /boot and write a grub.cfg to boot from them. Copy DVD1 to /.
> >
> > 3. Copy the files in /pool on DVD1 to /debian on the stick. Create a
> >packages file in /debian. We now have a mirror which can be used
> >during and after the install.
> >
> > 4. Install, preseeding with a late_command for tasks. A few lines of
> >mine in that command are
> >
> > mkdir /target/media/usbmount; \
> > mount --bind /hd-media /target/media/usbmount; \
> > sed -i 's/^/#/' /target/etc/apt/sources.list; \
> > echo "deb [ trusted=yes ] file:/media/usbmount/debian wheezy main" >>
> > /target/etc/apt/sources.list
> >
> > 5. Install additional software after the install by mounting the mirror
> >on /media/usbmount.
>
> What I do is to hack /etc/apt/apt.conf.d/00CDMountPoint
> to read,
> Acquire::cdrom {
> mount "/media/usb";
> }
> Dir::Media::MountPath "/media/usb";
>
> where usb was cdrom. Then the the system looks for the installation
> media at the usb port.
I originally did something like this with the first eight CD images and
used apt-cdrom. The user user experience with having to mount and
unmount different images wasn't (IMO) the best, so I re-thought the
issue.
I have a script, apt-usb. A user types 'apt-usb cups' and is prompted to
insert the stick. Re-issuing the command mounts the stick, installs the
packages and unmounts the stick. apt-usb is copied to /target during the
initial install.
Regards,
Brian.
--
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/26112014104930.7571abec1...@desktop.copernicus.demon.co.uk
Bug#764587: installation-reports: After successful installation from usb stick the stick is not recognised on reboot.
> I have a USB stick that is used for installing Wheezy and which is
> recognised on reboot. Instead of writing DVD1 to the stick I do the
> following:
>
> 1. Have a FAT16 partition spanning the whole stick. Format as vfat.
>
> 2. Install GRUB in the MBR and copy the hd-media vmlinuz and initrd.gz
>to /boot and write a grub.cfg to boot from them. Copy DVD1 to /.
>
> 3. Copy the files in /pool on DVD1 to /debian on the stick. Create a
>packages file in /debian. We now have a mirror which can be used
>during and after the install.
>
> 4. Install, preseeding with a late_command for tasks. A few lines of
>mine in that command are
>
> mkdir /target/media/usbmount; \
> mount --bind /hd-media /target/media/usbmount; \
> sed -i 's/^/#/' /target/etc/apt/sources.list; \
> echo "deb [ trusted=yes ] file:/media/usbmount/debian wheezy main" >>
> /target/etc/apt/sources.list
>
> 5. Install additional software after the install by mounting the mirror
>on /media/usbmount.
What I do is to hack /etc/apt/apt.conf.d/00CDMountPoint
to read,
Acquire::cdrom {
mount "/media/usb";
}
Dir::Media::MountPath "/media/usb";
where usb was cdrom. Then the the system looks for the installation
media at the usb port.
Phil.
--
Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand
+64 3 488 2818Fax +64 3 488 2875Mobile 027 663 4453
phil...@copyleft.co.nz - personal.i...@copyleft.co.nz - business
--
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/1416979372.1644.1.ca...@copyleft.co.nz
