Re: Installing Debian Bullseye on Cubox-i4 with eSATA drive... "No kernel modules found"
Hi, "Rick Thomas" wrote: > On Thu, Jan 28, 2021, at 6:21 PM, Rick Thomas wrote: > > > Next thing to test -- can I install bullseye the same way? > > So I tried installing bullseye from [1] which, incidentally is dated Dec 2, > 2020. Isn't this kinda old for a "current" Bullseye? That's from the latest alpha release. > It booted and the installer started, but when it got to "Download installer > components" I got a red error screen. I've attached a screenshot. > > I'm guessing that "kinda old" is the problem. The kernel on [1] is out of > date with respect to the kernel(s) available on deb.debian.org ? > > Where should I look for one that's more up-to-date? On https://www.debian.org/devel/debian-installer/ you should look under the daily snapshots. For armhf that would be https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/ Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#981328: flash-kernel: Please add support for Orange Pi One Plus
Package: flash-kernel Version: 3.103 Severity: normal Tags: d-i patch Dear Maintainers, Please would you add the Orange Pi One Plus to the flash-kernel database? It would allow kernel upgrades to work seamlessly on this board. I've provided a patch below. Thank you very much, Harold. --- db/all.db 2021-01-29 00:06:13.463905200 + +++ db/all.db.new 2021-01-29 00:10:22.503445685 + @@ -1235,6 +1235,13 @@ U-Boot-Script-Name: bootscr.sunxi Required-Packages: u-boot-tools +Machine: OrangePi One Plus +Kernel-Flavors: arm64 +DTB-Id: allwinner/sun50i-h6-orangepi-one-plus.dtb +Boot-Script-Path: /boot/boot.scr +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + Machine: PHICOMM N1 Kernel-Flavors: arm64 DTB-Id: amlogic/meson-gxl-s905d-phicomm-n1.dtb -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-2-arm64 (SMP w/4 CPU threads) Locale: LANG=en_PH.UTF-8, LC_CTYPE=en_PH.UTF-8 (charmap=UTF-8), LANGUAGE=en_PH:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages flash-kernel depends on: ii debconf [debconf-2.0] 1.5.74 ii devio 1.2-1.2+b1 ii initramfs-tools0.139 ii linux-base 4.6 ii mtd-utils 1:2.1.2-2 ii ucf3.0043 Versions of packages flash-kernel recommends: ii u-boot-tools 2021.01+dfsg-2 flash-kernel suggests no packages. -- debconf information excluded
Bug#971946: Linking bug with MR
Control: tag -1 patch Control: forwarded -1 https://salsa.debian.org/installer-team/libdebian-installer/-/merge_requests/2 signature.asc Description: This is a digitally signed message part.
Processed: Linking bug with MR
Processing control commands: > tag -1 patch Bug #971946 [libdebian-installer] libdebian-installer: READSIZE size insufficient for cdebootstrap to build sid/unstable from buster/stable environment Added tag(s) patch. > forwarded -1 > https://salsa.debian.org/installer-team/libdebian-installer/-/merge_requests/2 Bug #971946 [libdebian-installer] libdebian-installer: READSIZE size insufficient for cdebootstrap to build sid/unstable from buster/stable environment Set Bug forwarded-to-address to 'https://salsa.debian.org/installer-team/libdebian-installer/-/merge_requests/2'. -- 971946: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971946 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#700633: Why this eatmydata patch still not applied to debootstrap? My USB storage devices are slow
severity -1 normal thanks Hi. Why this bug ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700633 ) still is not fixed? I did some experiments and here are results: if I run debootstrap stage of d-i under eatmydata, then its time decreases from 755 s to 370 - 405 s. (I installed Debian to USB storage device). Please, fix this bug. Fix is simple, benefits for many users are big. (So I change severity.) I think eatmydata mode should be enabled by default in debootstrap. Both inside of d-i and outside of it. == Askar Safin https://github.com/safinaskar
Processed: s
Processing commands for cont...@bugs.debian.org: > severity 700633 normal Bug #700633 [debootstrap] Debootstrap is very slow. Please use eatmydata to fix this. Severity set to 'normal' from 'wishlist' > thanks Stopping processing here. Please contact me if you need assistance. -- 700633: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700633 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#981346: partman-base: partman still overwrites u-boot on some systems
Package: partman-base
Version: 214
Severity: important
Tags: d-i patch
Dear Debian Install System Team,
This is a follow-on from bug #770666 in which some systems had their firmware
overwritten by partman. The patch there provided a function to detect the
affected systems by looking for their manufacturer names in /proc/cpuinfo,
so that partman would know not to overwrite in those cases.
Unfortunately, affected arm64 systems don't contain a suitable string in
/proc/cpuinfo, so their firmware still ends up getting overwritten.
My suggestion is to use /proc/device-tree/compatible instead of /proc/cpuinfo.
By searching the list there for an entry beginning with "allwinner," or
"fsl,imx6" or "ti,am33xx", we will hopefully match the same systems as the
current search for "Allwinner", "Freescale" or "AM33XX" would have found.
I've included a suggested patch below.
Thank you for considering it,
Harold.
diff --git a/parted_server.c b/parted_server.c
index 41784b70..4e7a0ead 100644
--- a/parted_server.c
+++ b/parted_server.c
@@ -1334,30 +1334,51 @@ command_dump()
oprintf("OK\n");
}
-/* Check whether we are running on a sunxi-based, freescale-based, or
- AM33XX (beaglebone black) system. */
+/* Decide whether this system stores firmware on disk by looking up
+ * machine type in device tree. If Allwinner (bug #751704) or
+ * i.MX6 or AM33xx (bug #770666), assume yes, otherwise no.
+ */
-int
+bool
is_system_with_firmware_on_disk()
{
-int cpuinfo_handle;
-int result = 0;
+int dt_handle;
+int close_ret;
+char *cur;
char buf[4096];
int length;
-if ((cpuinfo_handle = open("/proc/cpuinfo", O_RDONLY)) != -1) {
-length = read(cpuinfo_handle, buf, sizeof(buf)-1);
-if (length > 0) {
-buf[length]='\0';
-if (strstr(buf, "Allwinner") != NULL)
-result = 1;
-else if (strstr(buf, "Freescale") != NULL)
-result = 1;
-else if (strstr(buf, "AM33XX") != NULL)
-result = 1;
-}
-close(cpuinfo_handle);
-}
-return result;
+dt_handle = open("/proc/device-tree/compatible", O_RDONLY);
+if (dt_handle == -1) {
+log("Error opening device-tree property: %s", strerror(errno));
+log("Assuming non-ARM system, with no firmware on disk");
+return false;
+}
+
+length = read(dt_handle, buf, sizeof(buf)-1);
+if (length == -1)
+log("Error reading device-tree property: %s", strerror(errno));
+
+close_ret = close(dt_handle);
+if (close_ret == -1)
+log("Error closing device-tree property: %s", strerror(errno));
+
+if (length == -1 || close_ret == -1) {
+log("Assuming no firmware on disk");
+return false;
+}
+
+buf[length] = '\0';
+for (cur = buf; cur < buf+length; cur += strlen(cur)+1) {
+if (0 == strncmp(cur, "allwinner,", 10)
+|| 0 == strncmp(cur, "fsl,imx6", 8)
+|| 0 == strncmp(cur, "ti,am33xx", 9)) {
+log("Machine type '%s'; stores firmware on disk", cur);
+return true;
+}
+}
+
+log("Machine type checked; assuming no firmware on disk");
+return false;
}
void
@@ -1368,15 +1389,15 @@ command_commit()
critical_error("The device %s is not opened.", device_name);
log("command_commit()");
-/* The boot device on sunxi-based systems needs special handling.
+/* The boot device on some systems needs special handling.
* By default partman calls ped_disk_clobber when writing the
- * partition table, but on sunxi-based systems this would overwrite
+ * partition table, but on some systems this would overwrite
* the firmware area, resulting in an unbootable system (see
* bug #751704).
*/
if (is_system_with_firmware_on_disk() && !strncmp(disk->dev->path,
"/dev/mmcblk", 11)) {
disk->needs_clobber = 0;
-log("Sunxi/Freescale/AM33XX detected. Disabling
ped_disk_clobber " \
+log("Disabling ped_disk_clobber " \
"for the boot device %s to protect the firmware " \
"area.", disk->dev->path);
}
Bug#981345: buster-pu: package systemd/241-7~deb10u6
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org, k...@debian.org,
debian-boot@lists.debian.org
Hi,
I'd like to make a stable upload for systemd fixing #975561:
journal: do not trigger assertion when journal_file_close() get NULL
The rest is autopkgtest updates, as the current state is a bit sad [1]
on stable.
The full (annotated) changelog is
systemd (241-7~deb10u6) buster; urgency=medium
* journal: do not trigger assertion when journal_file_close() get NULL
(Closes: #975561)
https://salsa.debian.org/systemd-team/systemd/-/commit/42f62d560748cf79353d0a66d1ccf49517f951d3
* test-bpf: skip test when run inside containers.
The test reliably fails inside LXC and Docker when run on a new enough
kernel. It's unclear whether this is a kernel, LXC/Docker or systemd
issue and apparently there is no real interest to get this fixed, so
let's skip this test.
https://salsa.debian.org/systemd-team/systemd/-/commit/de5350a0090a51ba391baf57e5d3e549bf126a6b
* autopkgtest: mark networkd-test.py as flaky.
See https://github.com/systemd/systemd/issues/18357
and https://github.com/systemd/systemd/issues/18196
https://salsa.debian.org/systemd-team/systemd/-/commit/996babe874059cc70f54f4edbd3e00a46a208bb7
CCed kibi/debian-boot, as usual.
The udev package should not be affected, as the above change only
affects the journal, which is not used in d-i.
The regression potential is rather low. The fix itself is a cherry-pick
from upstream and has been part of sid/testing since quite a while.
Regards,
Michael
[1] https://ci.debian.net/packages/s/systemd/
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 8c3b276..61dcee2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+systemd (241-7~deb10u6) buster; urgency=medium
+
+ * journal: do not trigger assertion when journal_file_close() get NULL
+(Closes: #975561)
+ * test-bpf: skip test when run inside containers.
+The test reliably fails inside LXC and Docker when run on a new enough
+kernel. It's unclear whether this is a kernel, LXC/Docker or systemd
+issue and apparently there is no real interest to get this fixed, so
+let's skip this test.
+ * autopkgtest: mark networkd-test.py as flaky.
+See https://github.com/systemd/systemd/issues/18357
+and https://github.com/systemd/systemd/issues/18196
+
+ -- Michael Biebl Fri, 29 Jan 2021 15:16:06 +0100
+
systemd (241-7~deb10u5) buster; urgency=medium
* basic/cap-list: parse/print numerical capabilities (Closes: #964926)
diff --git a/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch
b/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch
index 231158c..78c2d01 100644
--- a/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch
+++ b/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch
@@ -30,7 +30,7 @@ index 2791678..3a9e20a 100644
systemd.journald.forward_to_syslog,
systemd.journald.forward_to_kmsg,
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
-index 2a960eb..7fe0f82 100644
+index ba0b35d..cd45212 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -1835,6 +1835,7 @@ int server_init(Server *s) {
diff --git
a/debian/patches/journal-do-not-trigger-assertion-when-journal_file_close-.patch
b/debian/patches/journal-do-not-trigger-assertion-when-journal_file_close-.patch
new file mode 100644
index 000..9cb536b
--- /dev/null
+++
b/debian/patches/journal-do-not-trigger-assertion-when-journal_file_close-.patch
@@ -0,0 +1,46 @@
+From: Yu Watanabe
+Date: Tue, 28 May 2019 12:40:17 +0900
+Subject: journal: do not trigger assertion when journal_file_close() get NULL
+
+We generally expect destructors to not complain if a NULL argument is passed.
+
+Closes #12400.
+
+(cherry picked from commit c377a6f3ad3d9bed4ce7e873e8e9ec6b1650c57d)
+---
+ src/journal/journal-file.c| 3 ++-
+ src/journal/journald-server.c | 7 ++-
+ 2 files changed, 4 insertions(+), 6 deletions(-)
+
+diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
+index 56827f9..04cf1ef 100644
+--- a/src/journal/journal-file.c
b/src/journal/journal-file.c
+@@ -335,7 +335,8 @@ bool journal_file_is_offlining(JournalFile *f) {
+ }
+
+ JournalFile* journal_file_close(JournalFile *f) {
+-assert(f);
++if (!f)
++
Re: Bug#981345: buster-pu: package systemd/241-7~deb10u6
Control: tags -1 + confirmed d-i Hi, On Fri, 2021-01-29 at 17:47 +0100, Michael Biebl wrote: > I'd like to make a stable upload for systemd fixing #975561: > > journal: do not trigger assertion when journal_file_close() get > NULL > > The rest is autopkgtest updates, as the current state is a bit sad > [1] on stable. That looks fine to me, thanks. > > CCed kibi/debian-boot, as usual. > The udev package should not be affected, as the above change only > affects the journal, which is not used in d-i. CCed and tagged for completeness. Regards, Adam
Re: Bug#959469: buster-pu: package openssl/1.1.1g-1
On 2021-01-28 00:28:03 [+0100], Kurt Roeckx wrote: > On Thu, Jan 14, 2021 at 07:03:37PM +0100, Kurt Roeckx wrote: > > There are a whole bunch of other issues and pull requests related to > > this. I hope this is the end of the regressions in the X509 code. > > So there is something else now: > https://github.com/openssl/openssl/issues/13931 > https://github.com/openssl/openssl/pull/13982 So what is the plan here? Upload to unstable and prepare a pu once it migrate to testing or right away? > Kurt Sebastian
Daily netinst still fail with "No kernel modules found"
Hi, Holger Wansing wrote: > > "Rick Thomas" wrote: > > Where should I look for one that's more up-to-date? > > On https://www.debian.org/devel/debian-installer/ > you should look under the daily snapshots. > For armhf that would be > https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/ Hmm, that's curious! When trying images from today, the netboot ones are working, but the netinst images are still failing with "no kernel modules found" error. Interestingly, the netboot image has an linux kernel v5.10.0-2 running on it (that's ok), but on the netinst image I have a v5.9.0-4 !!! Some research with old netinst images show these kernel versions: 202011155.9.0-2 202011305.9.0-4 202012035.9.0-4 that's alpha3 release 202101155.9.0-4 202101295.9.0-4 So, there is something wrong with some of the dailys (netinst, maybe more...) Do we still get the alpha3 builds copied to daily, or something like that? Steve in CC Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Install Guide vs. Secure Boot
Hopefully this is already changed in the Bullseye install guide, but if not, I don't think I will learn how to make edits before Bullseye releases. The Buster install guide says in Section 3.6.3 https://www.debian.org/releases/stable/amd64/ch03s06.en.html#UEFI Another UEFI-related topic is the so-called “secure boot” mechanism. Secure boot means a function of UEFI implementations that allows the firmware to only load and execute code that is cryptographically signed with certain keys and thereby blocking any (potentially malicious) boot code that is unsigned or signed with unknown keys. In practice the only key accepted by default on most UEFI systems with secure boot is a key from Microsoft used for signing the Windows bootloader. As the boot code used by debian-installer is not signed by Microsoft, booting the installer requires prior deactivation of secure boot in case it is enabled. My test on a recent weekly-build testing netinst seems to show that the above is no longer correct -- it booted fine for me in UEFI/SecureBoot mode. I thought I remembered reading (somewhere) that all recent debian installers (and live systems??) can boot in legacy BIOS mode or UEFI mode with or without secure boot.
Re: Daily netinst still fail with "No kernel modules found"
Hey Holger! On Fri, Jan 29, 2021 at 11:30:21PM +0100, Holger Wansing wrote: >Holger Wansing wrote: >> >> "Rick Thomas" wrote: >> > Where should I look for one that's more up-to-date? >> >> On https://www.debian.org/devel/debian-installer/ >> you should look under the daily snapshots. >> For armhf that would be >> https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/ > >Hmm, that's curious! > >When trying images from today, the netboot ones are working, but the >netinst images are still failing with "no kernel modules found" error. > >Interestingly, the netboot image has an linux kernel v5.10.0-2 running >on it (that's ok), but on the netinst image I have a v5.9.0-4 !!! > >Some research with old netinst images show these kernel versions: > 202011155.9.0-2 > 20201130 5.9.0-4 > 202012035.9.0-4 that's alpha3 release > 202101155.9.0-4 > 202101295.9.0-4 > >So, there is something wrong with some of the dailys (netinst, maybe more...) >Do we still get the alpha3 builds copied to daily, or something like that? I think I've found the bug. I've been refactoring CD image builds and it looks like I missed a configuration setting. We were not picking up on the daily d-i builds, instead using the stuff from the archive. :-( I'm just about to trigger a daily build by hand now with the fix, and that should hopefully solve the problem. -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Processed: Bug#971946 marked as pending in libdebian-installer
Processing control commands: > tag -1 pending Bug #971946 [libdebian-installer] libdebian-installer: READSIZE size insufficient for cdebootstrap to build sid/unstable from buster/stable environment Added tag(s) pending. -- 971946: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971946 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#971946: marked as done (libdebian-installer: READSIZE size insufficient for cdebootstrap to build sid/unstable from buster/stable environment)
Your message dated Sat, 30 Jan 2021 01:18:34 +
with message-id
and subject line Bug#971946: fixed in libdebian-installer 0.121
has caused the Debian Bug report #971946,
regarding libdebian-installer: READSIZE size insufficient for cdebootstrap to
build sid/unstable from buster/stable environment
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.)
--
971946: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971946
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libdebian-installer
Version: 0.119
When using cdebootstrap from within buster/stable to create a rootfs for
sid/unstable, it will fail with:
W: parser_rfc822: Iek! Don't find end of value!
E: Internal error: download
Seems "64k ought to be enough for everyone" strikes again as this is
functionally a dupe of Bug#55 though it is now that a READSIZE of 65536
in libdebian-installer/src/parser_rfc822.c is now insufficient. I
downloaded the deb-src, updated READSIZE to 262144, debuild'ed it and
installed it, cdebootstrap would then complete successfully for
sid/unstable. My diff is:
diff --git a/src/parser_rfc822.c b/src/parser_rfc822.c
index afd336a..b14859e 100644
--- a/src/parser_rfc822.c
+++ b/src/parser_rfc822.c
@@ -35,7 +35,7 @@
#include
#include
-#define READSIZE 65536
+#define READSIZE 262144
int di_parser_rfc822_read (char *begin, size_t size, di_parser_info *info,
di_parser_read_entry_new entry_new, di_parser_read_entry_finish
entry_finish, void *user_data)
{
--- End Message ---
--- Begin Message ---
Source: libdebian-installer
Source-Version: 0.121
Done: Steve McIntyre <93...@debian.org>
We believe that the bug you reported is fixed in the latest version of
libdebian-installer, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 971...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Steve McIntyre <93...@debian.org> (supplier of updated libdebian-installer
package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sat, 30 Jan 2021 00:50:27 +
Source: libdebian-installer
Architecture: source
Version: 0.121
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team
Changed-By: Steve McIntyre <93...@debian.org>
Closes: 971946
Changes:
libdebian-installer (0.121) unstable; urgency=medium
.
[ Holger Wansing ]
* Remove trailing whitespaces from changelog and control file, to fix
lintian tag.
.
[ Debian Janitor ]
* Bump debhelper from deprecated 9 to 12.
* Set debhelper-compat version in Build-Depends.
* Drop unnecessary dependency on dh-autoreconf.
* Rely on pre-initialized dpkg-architecture variables.
.
[ Steve McIntyre ]
* Remove the arbitrary limitation on maximum line length in Packages
and Sources files - it's pointless and breaks things
periodically. Closes: #971946
* Update Standards-Version to 4.5.1
Checksums-Sha1:
5cbba2659d992b9c1d9a8d7ae0d9b91e6913f7b3 2213 libdebian-installer_0.121.dsc
69037a89edb587a880ee0e02212c5757e422e74f 72308 libdebian-installer_0.121.tar.xz
65a488ae098ffae667a09af25d133543cef0293d 5990
libdebian-installer_0.121_source.buildinfo
Checksums-Sha256:
8e0338f8df3f85eec0ead0339176d85aaffe5d083b7b477bd5a17f4320fd536f 2213
libdebian-installer_0.121.dsc
889370308ccb2107f0f1c211f3230018b10f146e0a274f7703fcd3c15f6e7fc0 72308
libdebian-installer_0.121.tar.xz
75626fed228f80ec33605226920a80078c09f9a78d21ec35addaec41d558f023 5990
libdebian-installer_0.121_source.buildinfo
Files:
5dd65192541f123c7ef586c20498d570 2213 libs optional
libdebian-installer_0.121.dsc
8bedbe82dedfdbf8daa3d76863af1a32 72308 libs optional
libdebian-installer_0.121.tar.xz
fb38b9b103d7e4cbc222ad848dc06cc8 5990 libs optional
libdebian-installer_0.121_source.buildinfo
-BEGIN PGP SIGNATURE-
iQJFBAEBCAAvFiEEzrtSMB1hfpEDkP4WWHl5VzRCaE4FAmAUr6ERHDkzc2FtQGRl
Ymlhbi5vcmcACgkQWHl5VzRCaE7Frw/8Dd4TlUVn1BncMA77vE5C/CvBQCZn2kLs
kFNkI2Vz1fvRIRLUHmIZ8M/C4yesqXOVOkCrhTWUD9qJNaNl/V+qnLMEW/WIsrYh
ymS5DW9ziCSk+O1UoSa09GHIxuftGZGiHUpvS0gPF7NEdrejgcsZ5xbILidu2rM9
VCnfdHpPYXcJwCGq7zH2YsXAmjVeIkkINJqsmgPJI3WcSemhlzqYWacAIgz1ECra
jo1pYY7xxtDOzTrQM739Ba9F1V2io81HYe
Processing of libdebian-installer_0.121_source.changes
libdebian-installer_0.121_source.changes uploaded successfully to localhost along with the files: libdebian-installer_0.121.dsc libdebian-installer_0.121.tar.xz libdebian-installer_0.121_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
libdebian-installer_0.121_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 30 Jan 2021 00:50:27 + Source: libdebian-installer Architecture: source Version: 0.121 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Steve McIntyre <93...@debian.org> Closes: 971946 Changes: libdebian-installer (0.121) unstable; urgency=medium . [ Holger Wansing ] * Remove trailing whitespaces from changelog and control file, to fix lintian tag. . [ Debian Janitor ] * Bump debhelper from deprecated 9 to 12. * Set debhelper-compat version in Build-Depends. * Drop unnecessary dependency on dh-autoreconf. * Rely on pre-initialized dpkg-architecture variables. . [ Steve McIntyre ] * Remove the arbitrary limitation on maximum line length in Packages and Sources files - it's pointless and breaks things periodically. Closes: #971946 * Update Standards-Version to 4.5.1 Checksums-Sha1: 5cbba2659d992b9c1d9a8d7ae0d9b91e6913f7b3 2213 libdebian-installer_0.121.dsc 69037a89edb587a880ee0e02212c5757e422e74f 72308 libdebian-installer_0.121.tar.xz 65a488ae098ffae667a09af25d133543cef0293d 5990 libdebian-installer_0.121_source.buildinfo Checksums-Sha256: 8e0338f8df3f85eec0ead0339176d85aaffe5d083b7b477bd5a17f4320fd536f 2213 libdebian-installer_0.121.dsc 889370308ccb2107f0f1c211f3230018b10f146e0a274f7703fcd3c15f6e7fc0 72308 libdebian-installer_0.121.tar.xz 75626fed228f80ec33605226920a80078c09f9a78d21ec35addaec41d558f023 5990 libdebian-installer_0.121_source.buildinfo Files: 5dd65192541f123c7ef586c20498d570 2213 libs optional libdebian-installer_0.121.dsc 8bedbe82dedfdbf8daa3d76863af1a32 72308 libs optional libdebian-installer_0.121.tar.xz fb38b9b103d7e4cbc222ad848dc06cc8 5990 libs optional libdebian-installer_0.121_source.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCAAvFiEEzrtSMB1hfpEDkP4WWHl5VzRCaE4FAmAUr6ERHDkzc2FtQGRl Ymlhbi5vcmcACgkQWHl5VzRCaE7Frw/8Dd4TlUVn1BncMA77vE5C/CvBQCZn2kLs kFNkI2Vz1fvRIRLUHmIZ8M/C4yesqXOVOkCrhTWUD9qJNaNl/V+qnLMEW/WIsrYh ymS5DW9ziCSk+O1UoSa09GHIxuftGZGiHUpvS0gPF7NEdrejgcsZ5xbILidu2rM9 VCnfdHpPYXcJwCGq7zH2YsXAmjVeIkkINJqsmgPJI3WcSemhlzqYWacAIgz1ECra jo1pYY7xxtDOzTrQM739Ba9F1V2io81HYeLaKTTTIKQWhqQptZ9Q6Zpd/BCk0QsK Ue1vr+D25xlQH6niOnrrHCxJ/p+660W4Lwa8BLXM/yYojpimA7qfjqRc0wrhedzC L8vWWJITIPNAmvdgZmkWZ1GR5MZqqitKybv4pt8ynh8AZneQXMorErOmjS0Wmld8 cFJduQdP2VejlaMprBRO8jAlGs7lAtBGJlrZ0ebTa40OHRtM7OfbsJflrtZZGPjr P+QR3OqSpSWGOXl8eMEt5WgvyWS0ohKvk9LHzvVWx3xAxiFZTRKJyCJ3n20FLxZV eVUeyXRlZlhI7FNWZj7Hay2KE/FgCmdAI9ywJI6sYyD/iY6rcxfwqft+Lb3hbz92 5RxtxZWZ75mZ+N9K/Iq+zz4x7YNBEAIKMkzCUeBTFpgoO8Ut2RVbYIHo7rg42RRC OJGvwJGPtZE= =kHZY -END PGP SIGNATURE- Thank you for your contribution to Debian.
Re: Installing Debian Bullseye on Cubox-i4 with eSATA drive... No ethernet detected
Hi! On Fri, Jan 29, 2021, at 1:03 AM, Holger Wansing wrote: > On https://www.debian.org/devel/debian-installer/ > you should look under the daily snapshots. > For armhf that would be > https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/ I downloaded the two-part image from [1] dated 2021-01-30 and tried to install it on my Cubox-i4. It booted fine but when it got to the "Detect network hardware" phase, it failed and said: No Ethernet card was detected. If you know the name of the driver needed by your Ethernet card, you can select it from the list. Driver needed by your Ethernet card: and gave a long list of available ethernet drivers. I couldn't find anything that looked like an Atheros 8035 driver, which seems to be the one in use when I boot with a working system. Any suggestions? Thanks! Rick [1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/ dated 2021-01-30
Re: Installing Debian Bullseye on Cubox-i4 with eSATA drive... No ethernet detected
On 2021-01-29, Rick Thomas wrote: > Hi! > > On Fri, Jan 29, 2021, at 1:03 AM, Holger Wansing wrote: >> On https://www.debian.org/devel/debian-installer/ >> you should look under the daily snapshots. >> For armhf that would be >> https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/ > > I downloaded the two-part image from [1] dated 2021-01-30 and tried to > install it on my Cubox-i4. > > It booted fine but when it got to the "Detect network hardware" phase, it > failed and said: > > No Ethernet card was detected. If you know the name of the driver > needed by your Ethernet card, you can select it from the list. > Driver needed by your Ethernet card: > and gave a long list of available ethernet drivers. I'm having a similar issue on a hummingboard-i2ex (which is kind of like a single-board-computer variant of the Cubox-i) on an already installed system running linux 5.10.x, while 5.9.x works fine on that system, so seems to be a regression in the kernel. > I couldn't find anything that looked like an Atheros 8035 driver, which seems > to be the one in use when I boot with a working system. Pretty sure it is not atheros, but handled by: drivers/net/ethernet/freescale/fec_main.c Not sure what exact module or built-in that ends up in. live well, vagrant signature.asc Description: PGP signature
