Bug#1023448: SOLVED
The problem doesn't show up when I use another USB-Stick. So it looks like the problem is solved.
Bug#1023448: installation-reports: Hash sum mismatch when installing linux-image
Package: installation-reports Boot method: USB stick Image version: https://cdimage.debian.org/cdimage/bookworm_di_alpha1/amd64/iso-cd/debian-bookworm-DI-alpha1-amd64-netinst.iso Date: 03.11.2022 Machine: Standard PC Processor: Core i7-11700 @ 2.50 GHz Memory: 64 GB Partitions: /sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Disk model: Hitachi HDS72101 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: C338BFE6-3B2F-40EB-B8A9-62B73D82B37B Device Start End Sectors Size Type /dev/sda1 2048 4095 2048 1M Linux filesystem /dev/sda2 4096 97660927 97656832 46.6G Linux filesystem /dev/sda3 97660928 195317759 97656832 46.6G Linux filesystem /dev/sda4 195317760 205082623 9764864 4.7G Linux swap /dev/sda5 205082624 1083987967 878905344 419.1G Linux filesystem Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4c43] (rev 01) 00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:4c01] (rev 01) 00:14.0 USB controller [0c03]: Intel Corporation Device [8086:43ed] (rev 11) 00:14.2 RAM memory [0500]: Intel Corporation Device [8086:43ef] (rev 11) 00:16.0 Communication controller [0780]: Intel Corporation Device [8086:43e0] (rev 11) 00:17.0 SATA controller [0106]: Intel Corporation Device [8086:43d2] (rev 11) 00:1b.0 PCI bridge [0604]: Intel Corporation Device [8086:43c4] (rev 11) 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:43bc] (rev 11) 00:1d.0 PCI bridge [0604]: Intel Corporation Device [8086:43b0] (rev 11) 00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:4387] (rev 11) 00:1f.3 Audio device [0403]: Intel Corporation Device [8086:43c8] (rev 11) 00:1f.4 SMBus [0c05]: Intel Corporation Device [8086:43a3] (rev 11) 00:1f.5 Serial bus controller [0c80]: Intel Corporation Device [8086:43a4] (rev 11) 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU107 [10de:1f82] (rev a1) 01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:10fa] (rev a1) 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 16) 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 media: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system: [E] Clock/timezone setup: [ ] User/password setup: [ ] Install tasks: [ ] Install boot loader: [ ] Overall install: [ ] Comments/Problems: The image was copied to USB-Stick via: cp /dev/sdb The Debian installation was performed on partition /dev/sda2 Expecting that kernel 6.0 is installed. When trying to install the base system (linux-image) a hash sum mismath occurs - see syslog below: Nov 3 08:06:08 in-target: Selecting previously unselected package initramfs-tools.^M Nov 3 08:06:08 in-target: Preparing to unpack .../initramfs-tools_0.142_all.deb ...^M Nov 3 08:06:08 in-target: Unpacking initramfs-tools (0.142) ...^M Nov 3 08:06:09 in-target: Setting up linux-base (4.9) ...^M Nov 3 08:06:09 in-target: Setting up libklibc:amd64 (2.0.10-4) ...^M Nov 3 08:06:09 in-target: Setting up klibc-utils (2.0.10-4) ...^M Nov 3 08:06:09 in-target: No diversion 'diversion of /usr/share/initramfs-tools/hooks/klibc to /usr/share/initramfs-tools/hooks/klibc^i-t by klibc-utils', no ne removed.^M Nov 3 08:06:09 in-target: Setting up initramfs-tools-core (0.142) ...^M Nov 3 08:06:09 in-target: Setting up initramfs-tools (0.142) ...^M Nov 3 08:06:10 in-target: update-initramfs: deferring update (trigger activated)^M Nov 3 08:06:10 in-target: Processing triggers for initramfs-tools (0.142) ...^M Nov 3 08:06:11 base-installer: dpkg-divert: warning: diverting file '/sbin/start-stop-daemon' from an Essential package with rename is dangerous, use --no-re name Nov 3 08:06:11 /bin/in-target: warning: /target/etc/mtab won't be updated since it is a symlink. Nov 3 08:06:12 in-target: Reading package lists... Nov 3 08:06:12 in-target: Nov 3 08:06:12 in-target: Building dependency tree... Nov 3 08:06:12 in-target: Nov 3 08:06:12 in-target: Reading state information... Nov 3 08:06:12 in-target: The following additional packages will be installed: Nov 3 08:06:12 in-target: apparmor firmware-linux-free linux-image-5.19.0-1-amd64 Nov 3 08:06:12 in-target: Suggested packages: Nov 3 08:06:12 in-target: apparmor-profiles-extra apparmor-utils linux-doc-5.19 debian-kernel-handbook Nov 3 08:06:12 in-target: grub-pc | grub-efi-amd64 | extlinux Nov 3 08:06:12 in-target: The following NEW packages will be installed: Nov 3 08:06:12 in-target: apparmor firmware-linux-free linux-image-5.19.0-1-amd64
Bug#815786: d-i does not ask for hostname
From other installations I'm used to get ask for the new hostname - e.g. the installer prompts with the following message: "Please enter the hostname for this system. The hostname is a single word that identifies your system to the network. If you don't know what your hostname should be, consult your network administrator. If you are setting up your own home network, you can make something up here. Hostname: debian" (see attached picture) If the computer is connected via DHCP the suggested hostname from the DHCP-server is shown instead. I'm setting up the QNAP server in my office and will later move it to another building (with a different subnet ... aso). The reason is that my office is more quite and I want to have access to the serial console. For that reason it would be nice to have the possibility to set the hostname before the installation process starts. However, it looks like that the message (shown above) is missing for the QNAP (armel) installation. On 24.02.2016 21:12, Martin Michlmayr wrote: * Peter Nagel <peter.na...@kit.edu> [2016-02-24 13:47]: The debian installer (within expert mode) does not ask for the (new) hostname but just takes the hostname from the flash memory. We read the hostname from your existing configuration, but I don't see any code that actually sets this hostname in d-i (this might be a bug). We set the hostname to debian and the domain to example.org. Values obtained via DHCP take preference over these defaults. The reason we're setting the hostname is that you need to complete the network configuration, so you can SSH into the installer and afaik it's not possible to set the IP without setting other network parameters, such as hostname (i.e. doing the network configuration in two steps). So I'm not sure what to do about this bug report. I guess my question is: did the installer use the hostname from DHCP (or was it "debian") and if so what's wrong with taking the hostname from DHCP? The problem is that (in some situations) it can be quite difficult to change the hostname afterwards. E.g. if the installer creates a new RAID device this device would contain the given hostname from the installer. If this RAID device does later contain the /-directory it can be quite difficult to change the hostname-settings of the RAID device afterwards. A quick-fix would be to first (jump into a shell and to) change the hostname (within the installer) and than continue with the installation. However, it would be nice if the installer would ask for the hostname before the installation starts. smime.p7s Description: S/MIME Cryptographic Signature
Bug#815786: d-i does not ask for hostname
Package: debian-installer Boot method: network Image version: debian-installer_20150422+deb8u3_armel.deb Date: January 18, 2016 Machine: QNAP TS-420U Processor: Marvell 1.6 GHz Memory: 1GB DDR3 Severity: normal Partitions: Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/md0 ext4 19076820 832644 17252076 5% / udev devtmpfs 10240 0 10240 0% /dev tmpfs tmpfs 206700 4440202260 3% /run tmpfs tmpfs 516748 0516748 0% /dev/shm tmpfs tmpfs 5120 0 5120 0% /run/lock tmpfs tmpfs 516748 0516748 0% /sys/fs/cgroup Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Marvell Technology Group Ltd. Device [11ab:6282] (rev 01) Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab] 00:01.0 SCSI storage controller [0100]: Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port SATA-II [11ab:7042] (rev 02) Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab] Kernel driver in use: sata_mv 01:00.0 Host bridge [0600]: Marvell Technology Group Ltd. Device [11ab:6282] (rev 01) Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab] 01:01.0 USB controller [0c03]: Etron Technology, Inc. EJ168 USB 3.0 Host Controller [1b6f:7023] (rev 01) Subsystem: Etron Technology, Inc. EJ168 USB 3.0 Host Controller [1b6f:7023] Kernel driver in use: xhci_hcd 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: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[E] Comments/Problems: The debian installer (within expert mode) does not ask for the (new) hostname but just takes the hostname from the flash memory. The problem is that (in some situations) it can be quite difficult to change the hostname afterwards. E.g. if the installer creates a new RAID device this device would contain the given hostname from the installer. If this RAID device does later contain the /-directory it can be quite difficult to change the hostname-settings of the RAID device afterwards. A quick-fix would be to first (jump into a shell and to) change the hostname (within the installer) and than continue with the installation. However, it would be nice if the installer would ask for the hostname before the installation starts. smime.p7s Description: S/MIME Cryptographic Signature
Bug#791794: RAID device not active during boot
When all disks are available during boot the system is starting without problems: ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 10 Jul 13 18:15 2138f67e-7b9e-4960-80d3-2ac2ce31d882 - ../../sdc2 lrwxrwxrwx 1 root root 10 Jul 13 18:15 21a660eb-729d-48fe-b9e3-140ae0ee79f4 - ../../sdd2 lrwxrwxrwx 1 root root 9 Jul 13 18:15 *c4263f89-eb0c-4372-90ae-ce1a1545613e* - ../../*md0* lrwxrwxrwx 1 root root 10 Jul 13 18:15 cbeaebcb-2c55-48c0-b6bd-d5e8a5c4ac06 - ../../sdb2 lrwxrwxrwx 1 root root 10 Jul 13 18:15 ff2bae51-c5b8-41e3-855b-68ee57b61c0c - ../../sda2 When starting the system with only two (instead of four) disks I'm droped into emergency shell with the following error message: ALERT! /dev/disk/by-uuid/*c4263f89-eb0c-4372-90ae-ce1a1545613e* does not exist. Dropping to a shell! ... which seems to be consistent with the fact that the UUID for /dev/md0 is not available ... (initramfs) ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx1 00 10 Jul 13 15:20 cbeaebcb-2c55-48c0-b6bd-d5e8a5c4ac06 - ../../sdb2 lrwxrwxrwx1 00 10 Jul 13 15:20 ff2bae51-c5b8-41e3-855b-68ee57b61c0c - ../../sda2 ... which in turn is caused the RAID device itself being inactive at that time: (initramfs) cat /proc/mdstat Personalities : md0 : *inactive* sdb1[5](S) sda1[6](S) 39028736 blocks super 1.2 unused devices: none In order to re-activate /dev/md0 I use the following commands: (initramfs) mdadm --stop /dev/md0 [ 178.719551] md: md0 stopped. [ 178.722463] md: unbindsdb1 [ 178.725386] md: export_rdev(sdb1) [ 178.728804] md: unbindsda1 [ 178.731711] md: export_rdev(sda1) mdadm: stopped /dev/md0 (initramfs) mdadm --assemble /dev/md0 [ 214.171191] md: md0 stopped. [ 214.184471] md: bindsda1 [ 214.195838] md: bindsdb1 [ 214.218253] md: raid1 personality registered for level 1 [ 214.226156] md/raid1:md0: active with 1 out of 3 mirrors [ 214.231651] md0: detected capacity change from 0 to 19982581760 [ 214.247893] md0: unknown partition table mdadm: /dev/md0 has been started with 1 drive (out of 3) and 1 spare. (initramfs) cat /proc/mdstat Personalities : [raid1] md0 : *active* (auto-read-only) raid1 sdb1[5] sda1[6](S) 19514240 blocks super 1.2 [3/1] [U__] unused devices: none ... which will make the RAID device available in /dev/disk/by-uuid/ (initramfs) ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx1 009 Jul 13 15:24 *c4263f89-eb0c-4372-90ae-ce1a1545613e* - ../../md0 lrwxrwxrwx1 00 10 Jul 13 15:20 cbeaebcb-2c55-48c0-b6bd-d5e8a5c4ac06 - ../../sdb2 lrwxrwxrwx1 00 10 Jul 13 15:20 ff2bae51-c5b8-41e3-855b-68ee57b61c0c - ../../sda2 Now, if I exit the emergency shell the system is able to boot without problems. In *bug* report *#784070* it is mentioned that with the version of mdadm shipping with Debian Jessie, the --run parameter seems to be ignored when used in conjunction with --scan. According to the man page it is supposed to activate all arrays even if they are degraded. But instead, any arrays that are degraded are marked as 'inactive'. If the root filesystem is on one of those inactive arrays, the boot process is halted. As suggested in the bug report (see message#109) I have changed the file /usr/share/initramfs-tools/scripts/local-top/mdadm and used the comand update-initramfs -u in order to update /boot/initrd.img-3.16.* (... you might first want to make a copy of this file before update.) After reboot the system is able to start even if some disks (out of the RAID device) are missing (see bootlog from serial console below): ... Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Begin: Assembling all MD arrays ... [ 24.799665] random : nonblocking pool is initialized Failure: failed to assemble all arrays. done. Begin: Assembling all MD arrays ... *Warning: failed to assemble all arrays...attempting individual starts* Begin: attempting mdadm --run md0 ... [ 24.883069] md: raid1 personality registered for level 1 [ 24.889111] md/raid1:md0: active with 2 out of 3 mirrors [ 24.894598] md0: detected capacity change from 0 to 19982581760 mdadm: started array /dev/md/0 [ 24.908255] md0: unknown partition table *Success: started md0* done. done. Begin: Running /scripts/local-premount ... done. Begin: Checking root file system ... fsck from util-linux 2.25.2 /dev/md0: clean, 36905/1220608 files, 398026/4878560 blocks done. ... Problem solved ... ... and many thanks to Phil. PS: There is still one thing I do not understand: The file etc/mdadm/mdadm.conf (within initrd.img.*) contains an UUID (see below) ... ARRAY /dev/md/0
Bug#791794: RAID device not active during boot
Am 11.07.2015 18:40, schrieb Philip Hands: ... which is what suggests to me that it's been broken by other means -- the fact that one can apparently start it by hand tells you that it's basically working, so I'd think the described symptoms point strongly towards duff mdadm.conf in the initramfs. N.B. I've not very had much to do with systemd, so am in no sense an expert about that, but I've been using software raid and initrd's since almost as soon as they were available, and the idea that this would be down to systemd does not ring true. Thanks for pointing out this. Hopefully, someone is able to solve this problem. smime.p7s Description: S/MIME Cryptographic Signature
Bug#791794: INSTALL REPORT (Jessie on QNAP TS-420U)
Package: installation-reports Boot method: network Image version: http://ftp.debian.org/debian/dists/jessie/main/installer-armel/current/images/kirkwood/network-console/qnap/ts-41x/ Date: June 7, 2015 Machine: QNAP TS-420U Processor: Marvell 1.6 GHz Memory: 1GB DDR3 Partitions: Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/md0 ext4 19076820 986676 17098044 6% / udev devtmpfs 10240 0 10240 0% /dev tmpfs tmpfs 206704 4436202268 3% /run tmpfs tmpfs 516752 0516752 0% /dev/shm tmpfs tmpfs 5120 0 5120 0% /run/lock tmpfs tmpfs 516752 0516752 0% /sys/fs/cgroup Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Marvell Technology Group Ltd. Device [11ab:6282] (rev 01) Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab] 00:01.0 SCSI storage controller [0100]: Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port SATA-II [11ab:7042] (rev 02) Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab] Kernel driver in use: sata_mv 01:00.0 Host bridge [0600]: Marvell Technology Group Ltd. Device [11ab:6282] (rev 01) Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab] 01:01.0 USB controller [0c03]: Etron Technology, Inc. EJ168 USB 3.0 Host Controller [1b6f:7023] (rev 01) Subsystem: Etron Technology, Inc. EJ168 USB 3.0 Host Controller [1b6f:7023] Kernel driver in use: xhci_hcd 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: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[E] Overall install:[E] Comments/Problems: The problem seems to appear only when jessie is installed to RAID (e.g. RAID1)! Error message: flash-kernel-installer does not find UUID (see the two lines of syslog below): in-target: UUID eeb34bbe-375a-4dc1-939d-f56b801a4c75 doesn't exist in /dev/disk/by-uuid in-target: Warning: root device /dev/disk/by-uuid/eeb34bbe-375a-4dc1-939d-f56b801a4c75 does not exist Quickfix: When using the command 'udevadm trigger' before base-install the installer is able to install the boot loader and to finish the installation (compare http://forum.qnap.com/viewtopic.php?f=147t=111076). After reboot the new installed jessie is starting as expected. Output of mdstat (cat /proc/mdstat): Used RAID1 for Debian installation: Personalities : [raid1] md0 : active raid1 sdc2[2] sdd2[3](S) sdb2[1] sda2[0] 19514368 blocks super 1.2 [3/3] [UUU] PROBLEM: When I shutdown the system and remove any (active) harddisk (from RAID1) the system has problems to boot again. Error message (from bootlog at serial console) Gave up waiting for root device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/disk/by-uuid/61f390f9-c1db-4fbe-acd7-dd61bbcaeeca does not exist. Dropping to a shell! --- For comparision: I've done the same kind of installation with oldstable (= wheezy) which is able to boot without problems even though two (out of three) active disks are missing. (see https://www.mail-archive.com/debian-bugs-dist%40lists.debian.org/msg1336095.html) smime.p7s Description: S/MIME Cryptographic Signature
Bug#791710: INSTALL REPORT (Wheezy on QNAP TS-420U)
Package: installation-reports Boot method: network Image version: http://ftp.debian.org/debian/dists/Debian7.8/main/installer-armel/current/images/kirkwood/network-console/qnap/ts-41x/ Date: June 7, 2015 Machine: QNAP TS-420U Processor: Marvell 1.6 GHz Memory:1GB DDR3 Partitions: Filesystem Type 1K-blocks Used Available Use% Mounten rootfs rootfs19207764 686456 17545596 4% / udev devtmpfs 10240 0 10240 0% /dev tmpfs tmpfs88048192 87856 1% /run /dev/disk/by-uuid/23d2cd0b-e894-4699-94b8-0ae0b8e4e54d ext4 19207764 686456 17545596 4% / tmpfs tmpfs 5120 0 5120 0% /run/lk tmpfs tmpfs 566840 0566840 0% /run/sm Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Marvell Technology Group Ltd. Device [11ab:6282] (rev 01) Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab] 00:01.0 SCSI storage controller [0100]: Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port SATA-II [1) Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab] Kernel driver in use: sata_mv 01:00.0 Host bridge [0600]: Marvell Technology Group Ltd. Device [11ab:6282] (rev 01) Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab] 01:01.0 USB controller [0c03]: Etron Technology, Inc. EJ168 USB 3.0 Host Controller [1b6f:7023] (rev 0) Subsystem: Etron Technology, Inc. EJ168 USB 3.0 Host Controller [1b6f:7023] Kernel driver in use: xhci_hcd 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: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: I have selected 'oldstabel' (=wheezy) during installation (expert mode). Used RAID1 for Debian installation: #Personalities : [raid1] md0 : active raid1 sdc2[5](S) sdb2[4] sda2[0] sdd2[3] 19514240 blocks super 1.2 [3/3] [UUU] The system is able to boot from any (active) disk which has been tested by removing two active disks before boot several times (the spare disk is than used for recovery). The systems works fine ... NO PROBLEMS smime.p7s Description: S/MIME Cryptographic Signature
