Bug#974123: Still wrong Bootloader installed at Banana Pi M2 Ultra
Hello, I repeated the test with current daily images: Directory: https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/ Concatenated the two files: - firmware.none.img.gz - partition.img.gz U-Boot Version: 2021.01~rc4+dfsg-2 Installation starts and the external SD-Card was selected for guided partitioning. At the end, there was the messagt: "GRUB installation failed" "The grub-pc package failed to install into /target/." "Without the GRUB boot loader, the installed system will not boot." Best regards and thank you for your support. Bernhard signature.asc Description: This is a digitally signed message part
mklibs is marked for autoremoval from testing
mklibs 0.1.44.1 is marked for autoremoval from testing on 2021-01-27 It is affected by these RC bugs: 937054: mklibs: Python2 removal in sid/bullseye https://bugs.debian.org/937054 This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
tasksel_3.63_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 13 Jan 2021 23:12:28 +0100 Source: tasksel Architecture: source Version: 3.63 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Holger Wansing Changes: tasksel (3.63) unstable; urgency=medium . * Team upload. . * Re-upload, to allow migration to testing. No source changings. Checksums-Sha1: 0802c18de8e7fc5d3cb7131d8612a9e551845b3d 17065 tasksel_3.63.dsc 19a710f2a50eaad360a2d9d662e57af04f5a35ea 294988 tasksel_3.63.tar.xz 2647a840dcc9ef1b1bd997a80b0c96567e490ebc 65624 tasksel_3.63_amd64.buildinfo Checksums-Sha256: 8d16d4d5a4f6a2a3a0f946f9bd4b197dfa98b99f7f5eeedb1aad53e284117959 17065 tasksel_3.63.dsc e607978422a633a3d2a8804994590dd8d8161896969dca133296894e31288bac 294988 tasksel_3.63.tar.xz 24fef90b9a7eaf31f899d5c226fc32b1370f182fd52965c0f654ad811c0e2205 65624 tasksel_3.63_amd64.buildinfo Files: a8b276f1ec1879492ffbdbd721465a63 17065 tasks optional tasksel_3.63.dsc c7ac451f914f47f0f3601f9d33d57159 294988 tasks optional tasksel_3.63.tar.xz dd137d02a0ba53369798d2ed22a09230 65624 tasks optional tasksel_3.63_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJJBAEBCgAzFiEESWrG6BRCSzSFCDUpWfGHyhVusHYFAl//c54VHGh3YW5zaW5n QG1haWxib3gub3JnAAoJEFnxh8oVbrB26U8P/1zPERyEJpEP2rl15sLtv7ESfCsM bUyTSodTlu+nVIB1lO8B0pwvmDXs9dC0/dd/GtdvBMSredOWm5KcVNU3QNwmvfOk q6quZ5+pKjxSjCGWAiuaL6H+FPfma2TTjZQaFcMFt7iGJFtxBQ0dPaJMNxK07juA a6EKDewJm7AL+OCqhATb8IKp70NI4KDimE0njpIxUCrKitIOXx6OmL6+iLuQyTwr VMXN46nGOGmXFDHa7KU2Xt2/hC0tuD1ylcrfeyLHNZJE1TjbacGhOc9uTH9fAsAL ju0LzOLLkkNXwNeCvTuqqLtAQb5JGo0Ir+2QRBeb/KPBNQWPHAGzKLAB1Tp25ygb u7770sR37Zyp21jrN/8trslPwEHz1CIWc0o3FgESzkC1fOtOc5WbjTAmTTgAg3po XDhTh+XVu/EB6UeV2khTi1HmFwrrLH70kEjiG3H5Nd5ncjaw+JSLX+7MtpmOD2Fm TqpVMLpkZRqd1GclE65h1eBRVr3xWIn8UgwAXMfY4YPXmKZI3vI3Kvh4xRGTNcts 8tsQK+F4KB7Q9zcU+p8vtoLS62B8Sj+TewKM5jJC3N3nXGqa/tOPeVmwjDd6gBDZ kmlIry0U9GXit7lGoAGDFwBdRVkRoa54MVSzs8ZGHNoUhw/U6tb21J3l3rPONmMf Z8wLxzikUlITzkd1 =Brji -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of tasksel_3.63_source.changes
tasksel_3.63_source.changes uploaded successfully to localhost along with the files: tasksel_3.63.dsc tasksel_3.63.tar.xz tasksel_3.63_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Re: Naming convention for udebs: -udeb/-installer suffix
> We don't ship udebs for firmware. So please discuss first how this > s[h]ould work I presumed a udeb was necessary for it to be usable during installation. If it's not needed, that's good to hear and I guess I'll hold off. If that's because the ordinary .deb is suitable (it conforms to udeb requirements), I wonder what my next steps are to see it incorporated in the installation images. signature.asc Description: This is a digitally signed message part.
Re: Naming convention for udebs: -udeb/-installer suffix
On Wed, Jan 13, 2021 at 03:49:40PM -0500, John Scott wrote:
> It's going to take a while for me to figure out how to incorporate it into
> the
> installer for Bookworm, but just because it's otherwise ready I'm thinking of
> doing an upload of firmware-ath9k-htc adding a udeb.
We don't ship udebs for firmware. So please discuss first how this
sould work
Bastian
--
There's a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
stardate unknown.
Bug#979104: installation-reports: Intel Wireless 8265 / 8275 has no firmware in nonfree iso
Hi, Ben Hutchings wrote: > > Holger Wansing wrote: > > > Yes, that works fine, using a netboot image, I am NOT asked to > > > provide > > > firmware for regulatory.db file, because it's already included in > > > the d-i > > > image. > > > > > > However, that's only true for netboot images! > > > > > > My wireless card (on an IBM Thinkpad T60) is also usable with > > > DVD/CD netinst images > > > (so related kernel modules seem to be included in those images; I > > > have explicitly > > > tested that with said images on that T60), so probably wireless- > > > regdb-udeb should just > > > be added to all Linux d-i images? > > > > I prepared a patch for this (includes removing it from the netboot/* files, > > since it's now added generally in pkg-lists/base). > > Will apply it, if noone objects. > > Oh, I see. What I did was to add it to every list that includes nic- > wireless-modules, forgetting that for "CD" images that's not present in > the initramfs and will get installed later. > > I think the cleanest solution, that I originally intended to implement, > is to make it a dependency of nic-wireless-modules, but that was going > to require changing kernel-wedge. But I don't have time to do that > now, so I'm happy with your change. The size increase will be > negligible. Now applied. So, the wireless-regdb part of this bug is now fixed in git. Thanks Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Naming convention for udebs: -udeb/-installer suffix
It's going to take a while for me to figure out how to incorporate it into the installer for Bookworm, but just because it's otherwise ready I'm thinking of doing an upload of firmware-ath9k-htc adding a udeb. I've seen in some places the docs mention adding a -udeb suffix, but other places the udeb package name being the same as the regular package. Does it matter? In this case the packages will provide the same core files and will not be co- installable. signature.asc Description: This is a digitally signed message part.
