Bug#791794: RAID device not active during boot
The problem might be related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789152. However, in my case everything seems to be fine as long as all harddisks (within the RAID) are working. The Problem appears only if during boot one (or more) disk(s) out of the RAID device have a problem. The problem might be related to the fact that jessie comes with a new init system which has a stricter handling of failing auto mounts during boot. If it fails to mount an auto mount, systemd will drop to an emergency shell rather than continuing the boot - see release-notes (section 5.6.1): https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#systemd-upgrade-default-init-system For example: If you have installed your system to a RAID1 device and the system is faced with a power failure which (might at the same time) causes a damage to one of your harddisks (out of this RAID1 device) your system will (during boot) drop to an emergency shell rather than boot from the remaining harddisk(s). I found that during boot (for some reason) the RAID device is not active anymore and therefore not available within /dev/disk/by-uuid (what causes the drop to the emergency shell). A quickfix (to boot the system) would be, to re-activate the RAID device (e.g. /dev/md0) from the emergency shell ... mdadm --stop /dev/md0 mdadm --assemble /dev/md0 ... and to exit the shell. Nevertheless, it would be nice if the system would boot automatically (as it is known to happend under wheezy) in order to be able to use e.g. a spare disk for data synchronization. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55a0d0cf.8060...@kit.edu
Bug#791794: RAID device not active during boot
On Sat, Jul 11, 2015 at 10:16:15AM +0200, Nagel, Peter (IFP) wrote: The problem might be related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789152. However, in my case everything seems to be fine as long as all harddisks (within the RAID) are working. The Problem appears only if during boot one (or more) disk(s) out of the RAID device have a problem. The problem might be related to the fact that jessie comes with a new init system which has a stricter handling of failing auto mounts during boot. If it fails to mount an auto mount, systemd will drop to an emergency shell rather than continuing the boot - see release-notes (section 5.6.1): https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#systemd-upgrade-default-init-system Would a temporary work-around be to use another init system? For example: If you have installed your system to a RAID1 device and the system is faced with a power failure which (might at the same time) causes a damage to one of your harddisks (out of this RAID1 device) your system will (during boot) drop to an emergency shell rather than boot from the remaining harddisk(s). I found that during boot (for some reason) the RAID device is not active anymore and therefore not available within /dev/disk/by-uuid (what causes the drop to the emergency shell). A quickfix (to boot the system) would be, to re-activate the RAID device (e.g. /dev/md0) from the emergency shell ... mdadm --stop /dev/md0 mdadm --assemble /dev/md0 ... and to exit the shell. Nevertheless, it would be nice if the system would boot automatically (as it is known to happend under wheezy) in order to be able to use e.g. a spare disk for data synchronization. After all, isn't it the whole point of a RAID1 that it can keep going when one of its hard drives fails? I currently have this situation on a wheezy system, and it will continue until I have the replacement physical drive prepared for installation. The RAID1 is running fine with just one physical drive. It would be seriously inconvenient to be unable to boot in a straightforward manner. It's not as if it's being quiet about the matter -- I keep getting emails elling me that one of the drives is missing. -- hendrik -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150711161247.ga5...@topoi.pooq.com
Bug#783641: marked as done (d-i.debian.org: edos4udebs needs an update for jessie)
Your message dated Sat, 11 Jul 2015 15:51:26 +0200 with message-id 20150711135126.gr30...@mraw.org and subject line Re: Bug#783641: d-i.debian.org: edos4udebs needs an update for jessie has caused the Debian Bug report #783641, regarding d-i.debian.org: edos4udebs needs an update for jessie 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.) -- 783641: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783641 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: d-i.debian.org Severity: normal edos-debcheck was obsoleted by dose-debcheck but the latter wants different options (-foo → --foo mainly), and its output also changed, so edos4udebs wants to be updated accordingly. (Also: https://lists.debian.org/debian-boot/2015/04/msg00622.html) Mraw, KiBi. ---End Message--- ---BeginMessage--- Cyril Brulebois k...@debian.org (2015-04-28): edos-debcheck was obsoleted by dose-debcheck but the latter wants different options (-foo → --foo mainly), and its output also changed, so edos4udebs wants to be updated accordingly. I've just done that with r70001 to r70005, new URL (edos → dose): http://d-i.debian.org/dose/ I've also added a redirect at the old location. Current situation in testing/unstable isn't too bad, with a single problem, already reported: #788703. Mraw, KiBi. signature.asc Description: Digital signature ---End Message---
Bug#791794: RAID device not active during boot
Hendrik Boom hend...@topoi.pooq.com writes: On Sat, Jul 11, 2015 at 10:16:15AM +0200, Nagel, Peter (IFP) wrote: The problem might be related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789152. However, in my case everything seems to be fine as long as all harddisks (within the RAID) are working. The Problem appears only if during boot one (or more) disk(s) out of the RAID device have a problem. The problem might be related to the fact that jessie comes with a new init system which has a stricter handling of failing auto mounts during boot. If it fails to mount an auto mount, systemd will drop to an emergency shell rather than continuing the boot - see release-notes (section 5.6.1): https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#systemd-upgrade-default-init-system Would a temporary work-around be to use another init system? It seems very unlikely to me that the init system has anything to do with this. If switching away from systemd fixes it, then that would suggest that the file system in question is not actually needed for boot, so should be marked as such in fstab (with nofail or noauto) If getting past that point (by using sysvinit, which ignores the failure) results in an operational RAID (presumably running in degraded mode), then that would suggest that it's only being started by the /etc/init.d/mdadm script, which would seem to suggest that the scripts in the initramfs are not doing it, which would normally be a consequence of having something wrong with /etc/mdamdm/mdadm.conf when the initramfs was built. The underlying problem is the failure to bring up the raid in the initramfs, which is before systemd gets involved. For example: If you have installed your system to a RAID1 device and the system is faced with a power failure which (might at the same time) causes a damage to one of your harddisks (out of this RAID1 device) your system will (during boot) drop to an emergency shell rather than boot from the remaining harddisk(s). I found that during boot (for some reason) the RAID device is not active anymore and therefore not available within /dev/disk/by-uuid (what causes the drop to the emergency shell). A quickfix (to boot the system) would be, to re-activate the RAID device (e.g. /dev/md0) from the emergency shell ... mdadm --stop /dev/md0 mdadm --assemble /dev/md0 ... and to exit the shell. Nevertheless, it would be nice if the system would boot automatically (as it is known to happend under wheezy) in order to be able to use e.g. a spare disk for data synchronization. After all, isn't it the whole point of a RAID1 that it can keep going when one of its hard drives fails? Exactly, 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. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#792152: PredictableNetworkInterfaceNames not used in installed /etc/network/interfaces
Package: installation-reports Boot method: CD (virtual) Image version: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso Date: July 11, 2015 Machine: VirtualBox VM Processor: Intel Core i7-2600K Memory: 512 MB Partitions: df -Tl will do; the raw partition table is preferred Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/sda1 ext4 1931600 825488989940 46% / udev devtmpfs 10240 0 10240 0% /dev tmpfs tmpfs 101264 4472 96792 5% /run tmpfs tmpfs 253156 0253156 0% /dev/shm tmpfs tmpfs 5120 0 5120 0% /run/lock tmpfs tmpfs 253156 0253156 0% /sys/fs/cgroup Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] [8086:1237] (rev 02) 00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] [8086:7000] 00:01.1 IDE interface [0101]: Intel Corporation 82371AB/EB/MB PIIX4 IDE [8086:7111] (rev 01) Kernel driver in use: ata_piix 00:02.0 VGA compatible controller [0300]: InnoTek Systemberatung GmbH VirtualBox Graphics Adapter [80ee:beef] 00:03.0 Ethernet controller [0200]: Intel Corporation 82540EM Gigabit Ethernet Controller [8086:100e] (rev 02) Subsystem: Intel Corporation PRO/1000 MT Desktop Adapter [8086:001e] Kernel driver in use: e1000 00:04.0 System peripheral [0880]: InnoTek Systemberatung GmbH VirtualBox Guest Service [80ee:cafe] 00:05.0 Multimedia audio controller [0401]: Intel Corporation 82801AA AC'97 Audio Controller [8086:2415] (rev 01) Subsystem: Intel Corporation Device [8086:] Kernel driver in use: snd_intel8x0 00:06.0 USB controller [0c03]: Apple Inc. KeyLargo/Intrepid USB [106b:003f] Kernel driver in use: ohci-pci 00:07.0 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 08) 00:0d.0 SATA controller [0106]: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] [8086:2829] (rev 02) Kernel driver in use: ahci 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: [O] 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: Network non-functional after first boot, but works during install. Problem appears to be that network interface is called eth0 in /etc/network/interfaces, but name after first boot is enp0s3. This is shell-only install. Reinstalled several times, it's reproduced 100% of the time. Problem seems to be related to this: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ I switched to terminal during install, and 80-net-setup-link.rules is not under /lib/udev/rules.d. So during install network interface is still called eth0, could that be the problem? If I switch to terminal during install and do: ln -s /dev/null /target/etc/udev/rules.d/80-net-setup-link.rules then old network names are used after first boot and network starts ok. But that's a step backwards... proper thing would be if the network name written to /target/etc/network/interfaces is correct on first boot. Alternatively if I change eth0 to enp0s3 in /etc/network/interfaces after install, then ifup, that also fixes it. My /etc/network/interfaces at first boot looks like: # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet dhcp
Processed: still happens in d-i 20150606
Processing control commands: found -1 20150606 Bug #781290 [debian-installer] LUKS encrypted partitions set to wrong type There is no source info for the package 'debian-installer' at version '20150606' with architecture '' Unable to make a source version for version '20150606' Marked as found in versions 20150606. -- 781290: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781290 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b781290.143665852625302.transcr...@bugs.debian.org
Bug#781290: still happens in d-i 20150606
Control: found -1 20150606 This week I reinstalled my laptop with Debian GNU/Linux 8.1.0 Jessie - Official amd64 CD Binary-1 20150606-14:19 and I was surprised that the encrypted LVM volume I created manually from partman has a Linux (83) type instead of Linux LVM (8e). Cheers, Alex signature.asc Description: Digital signature
Processed: merge with bug 767682
Processing control commands: severity -1 important Bug #788842 [debian-installer] D-I: Installer stuck at 33% when formatting ext4. Severity set to 'important' from 'normal' merge -1 767682 Bug #788842 [debian-installer] D-I: Installer stuck at 33% when formatting ext4. Bug #788842 [debian-installer] D-I: Installer stuck at 33% when formatting ext4. Marked as found in versions debian-installer/20150107. Added tag(s) d-i. Bug #767682 [debian-installer] D-I: installer hangs on re-formatting ext4 partition (having grub in the partition boot record). Merged 767682 788842 -- 767682: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767682 788842: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788842 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b788842.143665711018841.transcr...@bugs.debian.org
Processed: merge with bug 767682
Processing control commands: severity -1 important Bug #789427 [debian-installer] debian-installer: debian installer mkfs.ext3 hangs while formatting a new partition Severity set to 'important' from 'normal' merge -1 767682 Bug #789427 [debian-installer] debian-installer: debian installer mkfs.ext3 hangs while formatting a new partition Bug #789427 [debian-installer] debian-installer: debian installer mkfs.ext3 hangs while formatting a new partition Marked as found in versions debian-installer/20150107. Added tag(s) d-i. Bug #767682 [debian-installer] D-I: installer hangs on re-formatting ext4 partition (having grub in the partition boot record). Bug #788842 [debian-installer] D-I: Installer stuck at 33% when formatting ext4. Merged 767682 788842 789427 -- 767682: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767682 788842: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788842 789427: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789427 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b789427.143665711018852.transcr...@bugs.debian.org
Bug#788842: merge with bug 767682
Control: severity -1 important Control: merge -1 767682 It seems to me that both #788842 and #789427 are the same bug than #767682 that I stumbled upon on Mon Jul 6th, so let's merge them altogether. Cheers, Alex signature.asc Description: Digital signature
Processed: still happens in d-i 20150606
Processing control commands: found -1 20150606 Bug #767682 [debian-installer] D-I: installer hangs on re-formatting ext4 partition (having grub in the partition boot record). Bug #788842 [debian-installer] D-I: Installer stuck at 33% when formatting ext4. Bug #789427 [debian-installer] debian-installer: debian installer mkfs.ext3 hangs while formatting a new partition There is no source info for the package 'debian-installer' at version '20150606' with architecture '' Unable to make a source version for version '20150606' Marked as found in versions 20150606. Marked as found in versions 20150606. Marked as found in versions 20150606. -- 767682: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767682 788842: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788842 789427: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789427 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b767682.143665810423654.transcr...@bugs.debian.org
Bug#767682: still happens in d-i 20150606
Control: found -1 20150606 Stumbled upon this bug last Monday while installing Jessie from Debian GNU/Linux 8.1.0 Jessie - Official amd64 CD Binary-1 20150606-14:19 on top of a previous Ubuntu installation that had an existing /boot partition on sda3 formatted with ext4. I formatted the partition from the TUI and then I found that a confirmation was required before proceeding by mkfs.ext4. After that the installation was performed successfully. Cheers, Alex signature.asc Description: Digital signature
