<div dir="ltr">Huh?  The problem occurs when apt updates initramfs, so it is a package manager issue, not a RAID manager issue.  Did you read the whole report?</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 10, 2017 at 1:48 PM, Julian Andres Klode <span dir="ltr"><<a href="mailto:jak@debian.org" target="_blank">jak@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Control: reassign -1<br>
On Fri, Feb 10, 2017 at 01:38:45PM -0800, Brad Doster wrote:<br>
> Package: apt<br>
> Version: 1.0.9.8.4<br>
<br>
Thanks for the laugh :) APT is your package manager, not your RAID<br>
manager. Reassigning there.<br>
<br>
<br>
><br>
> During initial installation of Debian 8, I used mdadm to create 2 RAID<br>
> arrays as follows:<br>
><br>
> /dev/md0 - RAID 1 - 4 drives - contains /boot only<br>
> /dev/md1 - RAID 5 - 3 drives + 1 spare - contains /<br>
><br>
> Both are needed to successfully boot the system.<br>
><br>
> During installation I name the machine HOSTA.  A few days later, I decided<br>
> to change the machine's host name to HOSTB.  After a few weeks of<br>
> successful operation of HOSTB, I ran apt-update followed by apt-upgrade.<br>
> Among the updates were linux-image updates, which caused initramfs to be<br>
> updated.  After the updates, rebooting the system landed me here:<br>
><br>
> =====<br>
> Gave up waiting for root device. Common problems:<br>
>   — Boot args (cat /proc/cmdline)<br>
>     — Check rootdelay= (did the system wait long enough?)<br>
>     — Check root= (did the system wait for the right device?)<br>
>   — Missing modules (cat /proc/modules; ls /dev)<br>
> ALERT! /dev/disk/by-uuid/054a6dcc-<wbr>d280-4aff-9977 does not exist.<br>
> Dropping to a shell!<br>
><br>
> BusyBox v.1.22.1 (Ubuntu 1:1.22.0-9deb8u1) built-in shell (ash)<br>
> Enter 'help' for list of built-in commands.<br>
><br>
> /bin/sh: can't access tty: job control turned off<br>
> (initramfs)<br>
> =====<br>
><br>
> In the initramfs shell, /etc/mdadm/mdamd.conf contained the new hostname,<br>
> HOSTB instead of HOSTA:<br>
><br>
> =====<br>
> # definitions of existing MD arrays<br>
> ARRAY /dev/md/0  metadata=1.2 UUID=413a2cf3:ef0784ac:<wbr>1e135c73:7a1723c6<br>
> name=HOSTB:0<br>
> ARRAY /dev/md/1  metadata=1.2 UUID=ae1ab583:e5e30fb9:<wbr>e2c807a2:b5e95f42<br>
> name=HOSTB:1<br>
>    spares=1<br>
> =====<br>
><br>
> Editing mdadm.conf to use HOSTA in place of HOSTB allowed me to assemble my<br>
> arrays and continue booting the system:<br>
><br>
> =====<br>
> (initramfs) mdadm --assemble --scan<br>
> mdadm: /dev/md/0 has been started with 4 drives.<br>
> mdadm: /dev/md/1 has been started with 3 drives and 1 spare.<br>
> (initramfs) exit<br>
> =====<br>
><br>
> After a successful boot, mdadm -D confirms that the original host name,<br>
> HOSTA is part of the array configuraion:<br>
><br>
> =====<br>
> mdadm -D /dev/md1<br>
> /dev/md1:<br>
>         Version : 1.2<br>
>   Creation Time : Thu Dec 29 09:02:43 2016<br>
>      Raid Level : raid5<br>
>      Array Size : 2130618368 (2031.92 GiB 2181.75 GB)<br>
>   Used Dev Size : 1065309184 (1015.96 GiB 1090.88 GB)<br>
>    Raid Devices : 3<br>
>   Total Devices : 4<br>
>     Persistence : Superblock is persistent<br>
><br>
>   Intent Bitmap : Internal<br>
><br>
>     Update Time : Thu Feb  9 17:25:16 2017<br>
>           State : clean<br>
>  Active Devices : 3<br>
> Working Devices : 4<br>
>  Failed Devices : 0<br>
>   Spare Devices : 1<br>
><br>
>          Layout : left-symmetric<br>
>      Chunk Size : 512K<br>
><br>
>            Name : HOSTA:1       # <--- here is the original hostname given<br>
> to the machine during installation<br>
>            UUID : ae1ab583:e5e30fb9:e2c807a2:<wbr>b5e95f42<br>
>          Events : 4831<br>
><br>
>     Number   Major   Minor   RaidDevice State<br>
>        0       8        3        0      active sync   /dev/sda3<br>
>        1       8       19        1      active sync   /dev/sdb3<br>
>        2       8       35        2      active sync   /dev/sdc3<br>
><br>
>        3       8       51        -      spare   /dev/sdd3<br>
> =====<br>
><br>
> In this case, the updates to initramfs should NOT have changed the hostname<br>
> in the mdadm.conf file.  Doing so prevented the arrays from being assembled<br>
> and the system from booting.<br>
><br>
> To get around the issue until the next apt-upgrade installs something<br>
> causing initramfs to be updated again, on the up and running system, edit<br>
> /etc/mdadm/mdadm.conf to use the original hostname and then run<br>
> update-initramfs to install the change.  Once done, the system reboots<br>
> normally again.<br>
><br>
> Once the issue is known, it is also possible to run apt-upgrade to<br>
> completion, then before rebooting, edit mdamd.conf and manually execute<br>
> update-initramfs.  This will prevent an untimely visit to the BusyBox<br>
> screen, and in the case of remote upgrades being done, will prevent the<br>
> need to physically visit the server in order to complete the boot process.<br>
><br>
> While this may be considered a problem with mdadm - why is it using a<br>
> potentially volatile parameter like hostname in its permanent<br>
> configuration? - until that is addressed, apt-upgrade should not modify the<br>
> hostname used in the mdadm.conf file.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Debian Developer - <a href="http://deb.li/jak" rel="noreferrer" target="_blank">deb.li/jak</a> | <a href="http://jak-linux.org" rel="noreferrer" target="_blank">jak-linux.org</a> - free software dev<br>
                  |  Ubuntu Core Developer |<br>
When replying, only quote what is necessary, and write each reply<br>
directly below the part(s) it pertains to ('inline').  Thank you.<br>
</font></span></blockquote></div><br></div>