Results 1 to 2 of 2

Thread: dracut systemd pre-mount hook failure with mdadm array named (e.g.) any:1403

  1. #1
    Join Date
    Oct 2016
    Posts
    35

    Default dracut systemd pre-mount hook failure with mdadm array named (e.g.) any:1403

    Has anybody succeeded in booting consistently from an mdadm array whose superblock HOMEHOST is not equal to /etc/hostname and whose superblock NAME (in HOMEHOST:NAME) is outside the usual 0-127 range (e. g., md1403 instead of md3)?
    If yes, I would like to learn his trick.

    In theory (which I should know well enough), it sounds easy, but in practice it looks like a mess. Search on the internet, and you will find lots of fairly advanced users having problems with it.

    I use UUIDs everywhere, but dracut seems to care little about mdadm.conf, apparently because users make too many mistakes in it. (I thought this was Windows mentality and the reason why we prefer Linux.)

  2. #2
    Join Date
    Oct 2016
    Posts
    35

    Default Re: dracut systemd pre-mount hook failure with mdadm array named (e.g.) any:1403

    I suspect it is a bug in the dracut pre-mount hook, because the failure (booting timeout) of that hook only depended on the specific naming of the mdadm array in its superblock and (for its device name) in mdadm.conf, even though all array naming complied with mdadm configuration rules.

    I used names with which mdadm assembles the array perfectly well, without further ado, while dracut seemed to be unreasonably restrictive. (To restrict the naming possibilities to a narrow pattern is counterproductive, because it prevents an easier identification of the array, which was anyway always known to dracut and mdadm by the UUID I used.) I could even assemble the array from the emergency console I got after the booting timeout of the dracut pre-mount hook, using the simplest mdadm assemble command (e.g., "mdadm --assemble /dev/md1403", no further parameter needed), which shows that the array was configured completely well and identifiable through mdadm.conf beyond any doubt even for dracut in the booting process (a copy of mdadm.conf was included in the initrd).

    Unfortunately, I have no time at the moment to research the matter further. Hopefully somebody else can continue.

    A useful console command to analyse the content of the initrd produced by dracut is "lsinitrd"; it outputs a list of all files in the initrd (which is, after all, only a file archive). The content of any single file inside the initrd can be output by "lsinitrd -f <name of that single file>". The shell scripts used by dracut to produce the initrd are in /usr/lib/dracut. Also, there are quite a number of man entries starting with "dracut."; a nice flow chart is "man dracut.bootup", which "illustrates the ordering of the services, if systemd is used in the dracut initramf" (as in my case; a copy of /usr/lib/systemd/systemd was contained in the initrd).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •