Bug#982273: libbsd0-udeb: depends on libmd0
Source: libbsd0-udeb Version: 0.11.1-1 Severity: serious Justification: makes debian-installer FTBFS Hello, The "new upstream" upload of libbsd builds a udeb that depends on a non-udeb: The following packages have unmet dependencies: libbsd0-udeb : Depends: libmd0 (>= 1.0.3) but it is not installable Please avoid linking against libmd0, or else add a libmd0-udeb package to libmd. Samuel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Samuel c> ah (on trouve fluide glacial sur le net, ou il faut aller dans le monde reel ?) s> dans le monde reel c> zut
Bug#982270: installation-reports: Installing Debian Bullseye on Cubox-i4 - installer finds no ethernet
Package: installation-reports Severity: important Dear Maintainer, *** Reporter, 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 template lines *** -- Package-specific info: Boot method: Followed the instruction in the README file Image version: https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/ dated 2021-01-30 (also tried 2021-02-06) Date: 2021-02-06 Machine: Cubox-i4P Partitions: Didn't get that far in the installation Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [ok] Detect network card:[failed] could not proceed Overall install:[failed ] Comments/Problems: 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, none of which seemed to be relevant. I tried it again, this time with the components dated 2021-02-06. I was hoping that the problem was transient and might have been fixed in the intervening week, but I still got the same result: "No Ethernet card was detected." Vagrant says: > Pretty sure it is a kernel bug, since I can make it go away on a similar > system by downgrading to linux 5.9.x. Please CC me on the report and > I'll try to contribute what I can! -- Log files attached to this report are from a successful Buster installation on the same hardware, in hopes they might be some help... 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="10 (buster) - installer build 20190702+deb10u7" X_INSTALLATION_MEDIUM=netboot == Installer hardware-summary: == uname -a: Linux cube 4.19.0-13-armmp #1 SMP Debian 4.19.160-2 (2020-11-28) armv7l GNU/Linux usb-list: usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 01 usb-list:Manufacturer: Linux 4.19.0-13-armmp ehci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 02 Device 01: EHCI Host Controller [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 01 usb-list:Manufacturer: Linux 4.19.0-13-armmp ehci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub lsmod: Module Size Used by lsmod: dm_mod122880 9 lsmod: md_mod143360 0 lsmod: jfs 184320 0 lsmod: btrfs1241088 0 lsmod: libcrc32c 16384 1 btrfs lsmod: xor16384 1 btrfs lsmod: zstd_decompress61440 1 btrfs lsmod: zstd_compress 159744 1 btrfs lsmod: xxhash 20480 2 zstd_compress,zstd_decompress lsmod: zlib_deflate 28672 1 btrfs lsmod: raid6_pq 98304 1 btrfs lsmod: vfat 24576 0 lsmod: fat73728 1 vfat lsmod: ext4 618496 3 lsmod: crc16 16384 1 ext4 lsmod: mbcache16384 1 ext4 lsmod: jbd2 102400 1 ext4 lsmod: crc32c_generic 16384 6 lsmod: fscrypto 28672 1 ext4 lsmod: ecb16384 0 lsmod: brcmfmac 253952 0 lsmod: brcmutil 16384 1 brcmfmac lsmod: cfg80211 548864 1 brcmfmac lsmod: rfkill 28672 1 cfg80211 lsmod: usb_storage53248 0 lsmod: sd_mod 49152 3 lsmod: ahci_imx 20480 2 lsmod: libahci_platform 20480 1 ahci_imx lsmod: libahci32768 2 libahci_platform,ahci_imx lsmod: libata208896 3 libahci_platform,libahci,ahci_imx lsmod: scsi_mod 196608 3 sd_mod,usb_storage,libata lsmod: sdhci_esdhc_imx24576 0 lsmod: sdhci_pltfm16384 1 sdhci_esdhc_imx lsmod: sdhci 53248 2 sdhci_pltfm,sdhci_esdhc_imx lsmod: ci_hdrc_imx16384 0 lsmod: ci_hdrc45056 1 ci_hdrc_imx lsmod: ulpi 16384 1 ci_hdrc lsmod: ehci_hcd 77824 1 ci_hdrc lsmod: udc_core 36864
Bug#982244: debian-installer: please stop using genisoimage
* John Paul Adrian Glaubitz [210207 17:24]: > On 2/7/21 5:18 PM, Chris Hofstaedtler wrote: > > Untested patch below: > > An untested change to debian-installer isn't really something we can commit. I didn't suggest for you to commit it untested. Chris
Bug#982244: debian-installer: please stop using genisoimage
On 2/7/21 5:18 PM, Chris Hofstaedtler wrote: > Control: tags -1 + patch > > * Chris Hofstaedtler [210207 16:17]: >> As far as I can tell, debian-installer uses genisoimage only for >> alpha and hppa. It _looks_ like the genisoimage invocations could >> be trivially replaced with xorriso, but I do not have any systems to >> test this. > > Untested patch below: An untested change to debian-installer isn't really something we can commit. Adrian -- .''`. 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
Processed: Re: Bug#982244: debian-installer: please stop using genisoimage
Processing control commands: > tags -1 + patch Bug #982244 [src:debian-installer] debian-installer: please stop using genisoimage Added tag(s) patch. -- 982244: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982244 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#982244: debian-installer: please stop using genisoimage
Control: tags -1 + patch * Chris Hofstaedtler [210207 16:17]: > As far as I can tell, debian-installer uses genisoimage only for > alpha and hppa. It _looks_ like the genisoimage invocations could > be trivially replaced with xorriso, but I do not have any systems to > test this. Untested patch below: >From 63dc1eea2e458c79dbe8439f3f437dbb4f72f92d Mon Sep 17 00:00:00 2001 From: Chris Hofstaedtler Date: Sun, 7 Feb 2021 16:16:18 + Subject: [PATCH] Replace genisoimage with xorriso --- build/config/alpha/miniiso.cfg | 2 +- build/config/hppa/miniiso.cfg | 3 +-- debian/changelog | 3 +++ debian/control | 2 -- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/build/config/alpha/miniiso.cfg b/build/config/alpha/miniiso.cfg index d53a64da9..740c92e10 100644 --- a/build/config/alpha/miniiso.cfg +++ b/build/config/alpha/miniiso.cfg @@ -20,7 +20,7 @@ arch_miniiso: ln -f $(BASE_TMP)netboot/initrd.gz $(TEMP_CD_TREE)/boot/root.bin cp boot/alpha/aboot.conf $(TEMP_CD_TREE)/etc/ cp /boot/bootlx $(TEMP_CD_TREE)/boot - genisoimage -r -J -o $(TEMP_MINIISO) $(TEMP_CD_TREE) + xorriso -as mkisofs -r -J -o $(TEMP_MINIISO) $(TEMP_CD_TREE) # make bootable for SRM isomarkboot $(TEMP_MINIISO) /boot/bootlx diff --git a/build/config/hppa/miniiso.cfg b/build/config/hppa/miniiso.cfg index 5c6cde9d2..25502e6f3 100644 --- a/build/config/hppa/miniiso.cfg +++ b/build/config/hppa/miniiso.cfg @@ -14,8 +14,7 @@ arch_miniiso: install -m 644 -D $(BASE_TMP)miniiso/vmlinuz*parisc $(TEMP_CD_TREE)/boot/vmlinux-parisc install -m 644 -D $(BASE_TMP)miniiso/vmlinuz*parisc64 $(TEMP_CD_TREE)/boot/vmlinux-parisc64 install -m 644 -D /usr/share/palo/iplboot $(TEMP_CD_TREE)/boot/iplboot - - genisoimage -r -J -o $(TEMP_MINIISO) $(TEMP_CD_TREE) + xorriso -as mkisofs -r -J -o $(TEMP_MINIISO) $(TEMP_CD_TREE) palo -f /dev/null $(foreach kern,$(TEMP_KERNEL),-k $(kern) ) \ -r $(TEMP_INITRD) -b $(TEMP_CD_TREE)/boot/iplboot \ -c "0/linux initrd=0/ramdisk" \ diff --git a/debian/changelog b/debian/changelog index 3ce445fac..bb835f531 100644 --- a/debian/changelog +++ b/debian/changelog @@ -19,6 +19,9 @@ debian-installer (20201203) UNRELEASED; urgency=medium * On hurd-i386, mips, and powerpc, add debian-ports-archive-keyring-udeb also in the monolithic images for bootstraping from debian-ports' unreleased. + [ Chris Hofstaedtler ] + * Replace genisoimage with xorriso + -- Shawn Guo Sat, 12 Dec 2020 12:11:26 + debian-installer (20201202) unstable; urgency=medium diff --git a/debian/control b/debian/control index e58e6cdd9..a153d5ddb 100644 --- a/debian/control +++ b/debian/control @@ -44,8 +44,6 @@ Build-Depends: # them. # Lintian: Yes, we know it's essential. We prefer not to # count on it remaining so. - genisoimage [!s390 !s390x], -# For making mini isos. genromfs [sparc sparc64], # Used for creating sparc floppies (which are not built by # default.) -- 2.30.0
Bug#982244: debian-installer: please stop using genisoimage
Hello Christian! On 2/7/21 5:11 PM, Chris Hofstaedtler wrote: > the debian-installer package depends on genisoimage, which as you > know, comes from cdrkit. This causes cdrkit to be marked as a key > package for the release. > > As far as I can tell, debian-installer uses genisoimage only for > alpha and hppa. It _looks_ like the genisoimage invocations could > be trivially replaced with xorriso, but I do not have any systems to > test this. > > Please consider doing the replacements, or at least marking > genisoimage [alpha hppa]. > > I think we all agree that cdrkit should better go away except for > cases where there are no replacements yet. As discussed in the bug report, I am working on this issue. I am on the debian-installer team. I have access to the systems in question. I just can't do hyper-tasking and fix 1000 issues at once. Adrian -- .''`. 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#982244: debian-installer: please stop using genisoimage
Source: debian-installer Version: 20201202 Severity: important Dear Debian Installer Maintainers, the debian-installer package depends on genisoimage, which as you know, comes from cdrkit. This causes cdrkit to be marked as a key package for the release. As far as I can tell, debian-installer uses genisoimage only for alpha and hppa. It _looks_ like the genisoimage invocations could be trivially replaced with xorriso, but I do not have any systems to test this. Please consider doing the replacements, or at least marking genisoimage [alpha hppa]. I think we all agree that cdrkit should better go away except for cases where there are no replacements yet. Many thanks, Chris
Re: Problem installing Debian on Dell XPS 13 9360 laptop
On 06/02/2021 16:42, Lou Poppler wrote: On Fri, 2021-02-05 at 20:05 +, Bernard McNeill wrote: This machine does not have either CD or DVD drive. Does have internal SSD. This machine normally runs Windows-10. Objective is to have Debian on external HDD (Toshiba), connected to laptop via USB3. Events: Under Windows, downloaded iso to SSD. Win32diskimage from SSD to HDD. Restarted, F12, picked out HDD from bootlist, booted, got into Debian installer. Does a few steps (language etc). Gets stuck at 'No common CD-ROM drive was detected'. Ideas? I suggest writing the installer iso to a USB stick, and booting from that to install. Win32diskimager should be fine for that purpose. If you still have difficulty, please also say exactly which iso image. Good luck. Thank you for this. Followed your suggestion using debian-10.6.0-amd64-DVD-1.iso The whole installation seemed to run to completion, but: 1. When laptop rebooted with external HDD unplugged (indeed nothing in either USB socket) Windows-10 booted up (expected behaviour). 2. When laptop rebooted with external HDD plugged in, and F12 pressed repeatedly, went into one-time boot showing both 'Debian' and 'Windows Boot Manager' (expected behaviour). Unexpected behaviour was that, on taking 'Debian' option, screen showed (in tiny letters) 'Press F1 key to retry boot. Press F2 key to reboot into setup. Press F5 key to run onboard diagnostics.' Expected behaviour was to boot into Debian. Best regards
Bug#982194: choose-mirror: Rename mirror.netcologne.de to debian.netcologne.de
Package: choose-mirror Version: 2.109 Severity: normal Dear Maintainer, I noticed the following change in Git commit d51997a5: -Site: debian.netcologne.de +Site: mirror.netcologne.de +Alias: debian.netcologne.de This wasn't a very good idea, since I'd like to train users to use debian.netcologne.de as their mirror name. So I can change the CNAME debian.netcologne.de pointing somewhere else (for example to mirror3.netcologne.de or ftp.de.debian.org) on maintenance or emergency. This said, mirror.netcologne.de shouldn't be used directly as a debian mirror. It would be great if you could undo the above change at least for bullseye. Greetings Roland (admin of mirror.netcologne.de/debian.netcologne.de) signature.asc Description: PGP signature
Bug#862139: [flash-kernel] Please, stop flashing multiple times
Le dimanche 7 février 2021, 05:03:56 CET Vagrant Cascadian a écrit : >[…] > > update-initramfs: Generating /boot/initrd.img-3.16.0-4-kirkwood > > flash-kernel: installing version 3.16.0-4-kirkwood > > Generating kernel u-boot image... done. > > Flashing kernel (2074936/2097152 bytes)... done. > > Flashing initramfs (5140458/9437184 bytes)... done. > > ... > > > Traitement des actions différées (« triggers ») pour flash-kernel > > (3.35+deb8u3) ... flash-kernel: installing version > > 3.16.0-4-kirkwood > > Generating kernel u-boot image... done. > > Flashing kernel (2074936/2097152 bytes)... done. > > Flashing initramfs (5140458/9437184 bytes)... done. > > This is almost certainly because flash-kernel has hooks in both the > kernel and initramfs: > > /etc/kernel/postinst.d/zz-flash-kernel > /etc/kernel/postrm.d/zz-flash-kernel > /etc/initramfs/post-update.d/flash-kernel > > I don't see a great way around this, as flash-kernel needs to be > updated when either gets updated, and they may often happen at the > same time. The triggers do at least prevent it from getting updated > every time a relevent package gets updated, even it if still happens > multiple times in any given run... > > > That said, someone with a better understanding of dpkg triggers might > be able to come up with something better... The problem is twofold: 1. Both changing the kernel and changing the initramfs trigger the flashing (which is okay) but the deferred trigger should be executed only once, which it’s not. (I’m not sure anymore that was the case, that was 4 years ago. I guess not as I’m talking about “flashing three times.”) 2. As (badly) shown on the excerpt the files are flashed both just when the package is installed (immediate) and when the whole update is finished (deferred). -- Sylvain L. Sauvage
