[arch-general] Updating linux-lts initcpios... error: command failed to execute correctly

Wed Nov 7 14:03:07 UTC 2018

On 11/7/18 7:27 AM, Ralph Corderoy wrote:
> Hi,
> 
> This morning's `pacman -Su' had a problem building the fallback initcpio
> image for 4.14.79-1-lts.  Yesterday's /var/log/pacman.log shows
> 
>     [2018-11-06 10:45] [ALPM] upgraded linux-lts (4.14.78-1 -> 4.14.79-1)
>     [2018-11-06 10:45] [ALPM] running '60-linux-lts.hook'...
>     [2018-11-06 10:45] [ALPM] running '90-linux-lts.hook'...
> 
> that all went well.
> 
> Today, package `linux-lts' wasn't upgraded but 90-linux-lts.hook was
> triggered.  60-linux-lts.hook wasn't.

The 60- hook is:
Description = Updating linux-lts module dependencies...

and its purpose is to run depmod whenever you update modules.

The 90- hook is:
Description = Updating linux-lts initcpios...

and its purpose is to run mkinitcpio whenever you update either the
kernel, or else any file which is part of the mkinitcpio configuration.

$ pacman -Qo /usr/lib/initcpio/
/usr/lib/initcpio/ is owned by archiso 39-1
/usr/lib/initcpio/ is owned by btrfs-progs 4.19-1
/usr/lib/initcpio/ is owned by cryptsetup 2.0.5-1
/usr/lib/initcpio/ is owned by device-mapper 2.02.182-1
/usr/lib/initcpio/ is owned by dmraid 1.0.0.rc16.3-11
/usr/lib/initcpio/ is owned by lvm2 2.02.182-1
/usr/lib/initcpio/ is owned by mdadm 4.0-1
/usr/lib/initcpio/ is owned by mkinitcpio 25-1
/usr/lib/initcpio/ is owned by mkinitcpio-busybox 1.29.3-1
/usr/lib/initcpio/ is owned by systemd 239.300-1

As you can see, there's lots of things which can do so!

This explains why one ran and the other did not.

> pacman's TTY output complained
> `error: command failed to execute correctly' and the list of `Running'
> build hooks didn't complete.  The same steps for package `linux'
> immediately after didn't have the same problem.

This means mkinitcpio itself got borked, but rerunning it with a
different kernel preset works okay... why, remains to be seen.

>     ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-lts.img
>     ==> Image generation successful
>     ==> Building image from preset: /etc/mkinitcpio.d/linux-lts.preset: 'fallback'
>       -> -k /boot/vmlinuz-linux-lts -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-lts-fallback.img -S autodetect
>     ==> Starting build: 4.14.79-1-lts
>       -> Running build hook: [base]
>       -> Running build hook: [udev]
>       -> Running build hook: [modconf]
>       -> Running build hook: [block]
>     ==> WARNING: Possibly missing firmware for module: wd719x
>     ==> WARNING: Possibly missing firmware for module: aic94xx
>  →  error: command failed to execute correctly

So, the fallback image for linux-lts seems to have simply died halfway
through (but the main image generated okay).

> I was hoping pacman.log might have more detail, but it doesn't even
> record that there was an error.  I think that's a bug.
> 
>     [2018-11-07 11:18] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux-lts.preset: 'fallback'
>     [2018-11-07 11:18] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-linux-lts -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-lts-fallback.img -S autodetect
>     [2018-11-07 11:18] [ALPM-SCRIPTLET] ==> Starting build: 4.14.79-1-lts
>     [2018-11-07 11:18] [ALPM-SCRIPTLET]   -> Running build hook: [base]
>     [2018-11-07 11:18] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
>     [2018-11-07 11:18] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
>     [2018-11-07 11:18] [ALPM-SCRIPTLET]   -> Running build hook: [block]
>     [2018-11-07 11:18] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: wd719x
>     [2018-11-07 11:18] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: aic94xx
>     [2018-11-07 11:19] [ALPM] running '90-linux.hook'...
>     [2018-11-07 11:19] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'

Well, the log only contains a copy of the output from the hook which you
can look up after the fact, so it definitely won't have *more* input. As
for logging the failure of the hook to complete, I guess you could open
a ticket on the bugtracker for this (and/or post to the pacman-dev
mailing list if that floats your boat).

> Where should I look for clues why the command failed?
> And after that, is attempting another build of the image as simple as
> `/usr/bin/mkinitcpio -p linux-lts' as root?

This looks like it is another occurrence of
https://bugs.archlinux.org/task/60396

To test, you could try reinstalling a package that provides a mkinitcpio
configuration, and test resizing the terminal to see if you get the same
error.

Then, try installing pacman-git from the AUR or from my unofficial repo
hosted at
https://wiki.archlinux.org/index.php/Unofficial_user_repositories#eschwartz

The fix should be in pacman-git, and this should no longer crash.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20181107/8b1867e6/attachment.asc>