Bug#980777: FIT-PC: Fails to find driver for Ethernet, Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI
On Sun, 24 Jan 2021 21:28:26 +0100 John Paul Adrian Glaubitz wrote: > Hi! > > On 1/24/21 4:50 PM, Andrew M.A. Cater wrote: > > OK. This might be a bug in the i386 iso - as you've seen, we can't > > test all i386 easily. This might just be a regression. Given that > > we're about to release 10.8 on Feb 6th, can I suggest that you send > > a mail into debian-boot (or debian cd) referencing the bug number > > and including the syslog entries above. > > FWIW, I recently installed the 10.7 i386 non-free netinst ISO on an > old JVC sub-notebook with a Pentium M CPU and Realtek 8139 ethernet > card and had no issues with that card during installation. > > What actually caused problems was establishing a WiFi connection > during installation with the Intel 2200BG wireless adapter - which is > why I used the ethernet network connection during install. > > After installation, everything worked correctly out of the box, > however (lspci below). Thanks for the report. I hit a similar situation with a Thinkpad R51. Same WiFi, different Ethernet NIC. See below. Even with the firmware-ipw2x00 package, I could not get a connection during installation either. We seem to have the same version of the Realtek (rev 10). Did you end up using firmware for the Realtek? There has been some question on that in the course of this bug. 02:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05) 02:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (MOB) Ethernet Controller (rev 81) Your report and some other things I have seen lead me to wonder if I am simply running out of memory on the FIT-PC and d-i is not telling me. A quick search of two syslogs didn't turn anything up. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Bug#980777: FIT-PC: Fails to find driver for Ethernet, Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI
Hi! On 1/24/21 4:50 PM, Andrew M.A. Cater wrote: > OK. This might be a bug in the i386 iso - as you've seen, we can't test all > i386 easily. This might just be a regression. Given that we're about to > release > 10.8 on Feb 6th, can I suggest that you send a mail into debian-boot > (or debian cd) referencing the bug number and including the syslog entries > above. FWIW, I recently installed the 10.7 i386 non-free netinst ISO on an old JVC sub-notebook with a Pentium M CPU and Realtek 8139 ethernet card and had no issues with that card during installation. What actually caused problems was establishing a WiFi connection during installation with the Intel 2200BG wireless adapter - which is why I used the ethernet network connection during install. After installation, everything worked correctly out of the box, however (lspci below). Adrian root@jvc-mini:~# lspci 00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) 00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) 00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) 00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) 00:1d.0 USB controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03) 00:1d.1 USB controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03) 00:1d.2 USB controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03) 00:1d.7 USB controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83) 00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03) 00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 03) 01:03.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac) 01:03.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac) 01:03.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 04) 01:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10) 01:05.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05) root@jvc-mini:~# -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#980777: FIT-PC: Fails to find driver for Ethernet, Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI
On Sun, 24 Jan 2021 15:50:54 + "Andrew M.A. Cater" wrote: > These are the machines with Geode but limited to 256M memory? As a > matter of interest, what are you using them for - what's the use case > - because 256M is marginal now, I think. It's actually 223M, the remainder used for the video memory. Use case is that I have four of them. Two, grissom and white, are for testing. I have a SOHO network here, with three computers that get daily use, and a few others, older ones, as spares. chaffee: apcupsd server for several computers, local mail collector for logwatch and other admin emails, gitolite server, apt-cacher-ng for ubuntu, dns (bind9) and dhcp server. freeman: firewall/router, apt-cacher-ng for debian, ntp server, openvpn server, failover DNS and DHCP servers. The gitolite server could be faster, otherwise they do just fine, and have been since 2007 or so. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Bug#980777: FIT-PC: Fails to find driver for Ethernet, Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI
On Sat, Jan 23, 2021 at 05:03:35PM -0700, Charles Curley wrote: > On Sat, 23 Jan 2021 20:07:22 + > "Andrew M.A. Cater" wrote: > > > > > 8.6 is old - I'd be surprised that 10.7 firmware iso wouldn't > > > > work. > > > > > > I didn't try 10.x. 8.6 was what I had handy, i.e. it came up first > > > in the midden. However, debian-10.4.0-i386-netinst.iso also fails > > > to detect the NIC and gives the shortened menu of drivers to try. > > > > > > -- > > > Does anybody read signatures any more? > > > > > > https://charlescurley.com > > > https://charlescurley.com/blog/ > > > > Firmware-linux-free is usually installed by default. I would > > sincerely suggest that you try 10.7 unless you want to wait until > > 10.8 comes out (scheduled for the weekend of 6th February 2021. > > > > I think you just hit a problematic install - I've had laptops with > > that particular Realtek Ethernet and they're normally just found. > > > > All best, as ever, > > > > Andy C. > > I tried 10.7. Same problem. > > This time I am attaching the syslog to this email. > > I then did a search on the syslog, and got this: > > root@hawk:/media/disk# grep 8139 syslog > Jan 23 23:11:36 kernel: [0.416093] pci :00:0d.0: [10ec:8139] type 00 > class 0x02 > Jan 23 23:11:36 kernel: [0.416722] pci :00:0e.0: [10ec:8139] type 00 > class 0x02 > Jan 23 23:11:36 kernel: [ 22.813925] usb 1-1.2: Product: DataTraveler 2.0 > root@hawk:/media/disk# > > On another FIT-PC which is running Bullseye: > > root@white:/var/log/apt# dmesg | grep 8139 > [ 10.897167] pci :00:0d.0: [10ec:8139] type 00 class 0x02 > [ 10.898147] pci :00:0e.0: [10ec:8139] type 00 class 0x02 > [ 44.971388] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) > [ 44.979230] 8139cp :00:0d.0: This (id 10ec:8139 rev 10) is not an > 8139C+ compatible chip, use 8139too > [ 45.141373] 8139cp :00:0e.0: This (id 10ec:8139 rev 10) is not an > 8139C+ compatible chip, use 8139too > [ 45.438841] 8139too: 8139too Fast Ethernet driver 0.9.28 > [ 45.534101] 8139too :00:0d.0 eth0: RealTek RTL8139 at 0xccfc2a96, > 00:01:c0:03:f4:11, IRQ 10 > [ 45.729725] 8139too :00:0e.0 eth1: RealTek RTL8139 at 0x2e6d8dc8, > 00:01:c0:03:d8:78, IRQ 5 > [ 48.858651] 8139too :00:0e.0 enp0s14: renamed from eth1 > [ 48.960869] 8139too :00:0d.0 enp0s13: renamed from eth0 > [ 56.400301] 8139too :00:0d.0 enp0s13: link up, 100Mbps, full-duplex, > lpa 0xC5E1 > root@white:/var/log/apt# > > Considerably different. > > OK. This might be a bug in the i386 iso - as you've seen, we can't test all i386 easily. This might just be a regression. Given that we're about to release 10.8 on Feb 6th, can I suggest that you send a mail into debian-boot (or debian cd) referencing the bug number and including the syslog entries above. These are the machines with Geode but limited to 256M memory? As a matter of interest, what are you using them for - what's the use case - because 256M is marginal now, I think. All best, Andy C. > > > -- > Does anybody read signatures any more? > > https://charlescurley.com > https://charlescurley.com/blog/
Bug#980929: reportbug and installation-report
Package: installation-report Severity: normal Tags: patch X-Debbugs-Cc: debian-report...@lists.debian.org What do you think about including the installation-report message template directly in reportbug? In reportbug's GTK interface, the output of bugscripts is not handed to the user for editing, since it is seen as additional information and not essential to the report. This view is incompatible with using the bug script to generate a message template, which is what the installation-report bug script is doing. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931438 So instead of changing the reportbug GTK ui, I'm proposing a pair of changes to the installation-report package: https://salsa.debian.org/installer-team/installation-report/-/merge_requests/1 and to reportbug: https://salsa.debian.org/reportbug-team/reportbug/-/commit/15d209f4cf899f76749200899218e37c48a8f5a7
Re: Bug#959469: buster-pu: package openssl/1.1.1g-1
On 2021-01-22 16:38:28 [+], Adam D. Barratt wrote: > Assuming that a patched m2crypto will also build fine against openssl > 1.1.1d, then there's no reason that the two shouldn't proceed in > parallel (i.e. feel free to file the m2crypto request already). Yes, it does. Bug filled. Thank you. > Regards, > > Adam Sebastian
Re: Bug#959469: buster-pu: package openssl/1.1.1g-1
On 2021-01-22 16:38:28 [+], Adam D. Barratt wrote:
> Both would be good, please.
here is the with the two additional patches.
Sebastian
diff --git a/debian/changelog b/debian/changelog
index 088c914a3dd4a..56a950734f01d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,8 +4,9 @@ openssl (1.1.1i-0+deb10u1) buster; urgency=medium
- CVE-2019-1551 (Overflow in the x64_64 Montgomery squaring procedure),
(Closes: #947949).
* Update symbol list.
+ * Apply two patches from upstream to address x509 related regressions.
- -- Sebastian Andrzej Siewior Wed, 06 Jan 2021 21:04:15 +0100
+ -- Sebastian Andrzej Siewior Sun, 24 Jan 2021 11:22:16 +0100
openssl (1.1.1d-0+deb10u4) buster-security; urgency=medium
diff --git a/debian/patches/X509_cmp-Fix-comparison-in-case-x509v3_cache_extensions-f.patch b/debian/patches/X509_cmp-Fix-comparison-in-case-x509v3_cache_extensions-f.patch
new file mode 100644
index 0..4e6a391da269d
--- /dev/null
+++ b/debian/patches/X509_cmp-Fix-comparison-in-case-x509v3_cache_extensions-f.patch
@@ -0,0 +1,232 @@
+From: "Dr. David von Oheimb"
+Date: Wed, 30 Dec 2020 09:57:49 +0100
+Subject: X509_cmp(): Fix comparison in case x509v3_cache_extensions() failed
+ to due to invalid cert
+
+This is the backport of #13755 to v1.1.1.
+Fixes #13698
+
+Reviewed-by: Tomas Mraz
+(Merged from https://github.com/openssl/openssl/pull/13756)
+---
+ crypto/x509/x509_cmp.c| 18 ++
+ crypto/x509/x_all.c | 2 +-
+ crypto/x509v3/v3_purp.c | 3 ++-
+ doc/man3/X509_get_extension_flags.pod | 9 +++--
+ include/openssl/x509v3.h | 5 +++--
+ test/certs/invalid-cert.pem | 19 +++
+ test/recipes/80-test_x509aux.t| 13 -
+ test/x509aux.c| 17 +++--
+ 8 files changed, 61 insertions(+), 25 deletions(-)
+ create mode 100644 test/certs/invalid-cert.pem
+
+diff --git a/crypto/x509/x509_cmp.c b/crypto/x509/x509_cmp.c
+index ad620af0aff4..c9d89336406f 100644
+--- a/crypto/x509/x509_cmp.c
b/crypto/x509/x509_cmp.c
+@@ -133,19 +133,21 @@ unsigned long X509_subject_name_hash_old(X509 *x)
+ */
+ int X509_cmp(const X509 *a, const X509 *b)
+ {
+-int rv;
++int rv = 0;
+
+ if (a == b) /* for efficiency */
+ return 0;
+-/* ensure hash is valid */
+-if (X509_check_purpose((X509 *)a, -1, 0) != 1)
+-return -2;
+-if (X509_check_purpose((X509 *)b, -1, 0) != 1)
+-return -2;
+
+-rv = memcmp(a->sha1_hash, b->sha1_hash, SHA_DIGEST_LENGTH);
+-if (rv)
++/* try to make sure hash is valid */
++(void)X509_check_purpose((X509 *)a, -1, 0);
++(void)X509_check_purpose((X509 *)b, -1, 0);
++
++if ((a->ex_flags & EXFLAG_NO_FINGERPRINT) == 0
++&& (b->ex_flags & EXFLAG_NO_FINGERPRINT) == 0)
++rv = memcmp(a->sha1_hash, b->sha1_hash, SHA_DIGEST_LENGTH);
++if (rv != 0)
+ return rv;
++
+ /* Check for match against stored encoding too */
+ if (!a->cert_info.enc.modified && !b->cert_info.enc.modified) {
+ if (a->cert_info.enc.len < b->cert_info.enc.len)
+diff --git a/crypto/x509/x_all.c b/crypto/x509/x_all.c
+index aa5ccba44899..bec850af5797 100644
+--- a/crypto/x509/x_all.c
b/crypto/x509/x_all.c
+@@ -363,7 +363,7 @@ int X509_digest(const X509 *data, const EVP_MD *type, unsigned char *md,
+ unsigned int *len)
+ {
+ if (type == EVP_sha1() && (data->ex_flags & EXFLAG_SET) != 0
+-&& (data->ex_flags & EXFLAG_INVALID) == 0) {
++&& (data->ex_flags & EXFLAG_NO_FINGERPRINT) == 0) {
+ /* Asking for SHA1 and we already computed it. */
+ if (len != NULL)
+ *len = sizeof(data->sha1_hash);
+diff --git a/crypto/x509v3/v3_purp.c b/crypto/x509v3/v3_purp.c
+index 2b06dba05398..93b5ca4d4283 100644
+--- a/crypto/x509v3/v3_purp.c
b/crypto/x509v3/v3_purp.c
+@@ -391,7 +391,8 @@ static void x509v3_cache_extensions(X509 *x)
+ }
+
+ if (!X509_digest(x, EVP_sha1(), x->sha1_hash, NULL))
+-x->ex_flags |= EXFLAG_INVALID;
++x->ex_flags |= (EXFLAG_NO_FINGERPRINT | EXFLAG_INVALID);
++
+ /* V1 should mean no extensions ... */
+ if (!X509_get_version(x))
+ x->ex_flags |= EXFLAG_V1;
+diff --git a/doc/man3/X509_get_extension_flags.pod b/doc/man3/X509_get_extension_flags.pod
+index 43c9c952c6b7..cca72c71fcab 100644
+--- a/doc/man3/X509_get_extension_flags.pod
b/doc/man3/X509_get_extension_flags.pod
+@@ -78,12 +78,17 @@ The certificate contains an unhandled critical extension.
+
+ =item B
+
+-Some certificate extension values are invalid or inconsistent. The
+-certificate should be rejected.
++Some certificate extension values are invalid or inconsistent.
++The certificate should be rejected.
+ This bit may also be raised after an out-of-memory error while
+ processing the X509 object, so it may not be related to the processed
+ ASN1 object
