Hi Eli,

$ pacman -Qo /usr/lib/initcpio/ /usr/lib/initcpio/ is owned by archiso 39-1 ...

Thanks, it hadn't occurred to me to use -Qo on a directory before.

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.

Understood. I was thinking along the lines of how a ./configure writes to an agreed file descriptor other than stdout/stderr for more verbose detail, that kind of thing, but there weren't extra messages to record anyway given below suggests it's a SIGPIPE. Would the exit status of the hook have reflected that signal by being 128+13?

As for logging the failure of the hook to complete, I guess you could open a ticket on the bugtracker for this

Okay. https://bugs.archlinux.org/task/60735

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

It's very likely. I know I did maximise the X terminal part-way through pacman's run to unwrap lines.

To test...

I'll skip that, sorry. Way behind with life as it is at the moment. I've looked at the bug report and the patch and it seems sound.

...

And after that, is attempting another build of the image as simple as `/usr/bin/mkinitcpio -p linux-lts' as root?

I did this and it seems to have gone well. Thanks for the prompt answers. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy

On 11/7/18 5:46 PM, Ralph Corderoy wrote:

Hi leoutation,

...

...

This morning's `pacman -Su' had a problem building the fallback initcpio

Right command is pacman -Syu

Not in my case as I've previously done a `pacman -Syuw' during `free bandwidth' hours, thanks to cron. Later on, when I'm at the keyboard and it's a convenient time for breakage, I upgrade to what's already been downloaded manually and definitely don't want `-y'. :-)

That's dangerous because you could forget and run pacman -S pkgname. Not saying you would, and in fact I've done -Sywu all the time myself... But, just because I do it doesn't mean I should. ;) Instead, I eventually did some fiddling with the checkupdates script, which can be seen here: https://git.archlinux.org/users/eschwartz/pacman-contrib.git/commit/?id=80be... This will eventually make its way to pacman-contrib upstream, but it's pending some pacman changes which are still in git and only very recently landed. In the meantime you can also use https://github.com/eli-schwartz/dotfiles/blob/master/bin/cacheupdates Just run cacheupdates the way you'd run checkupdates, but if you specify the argument "-d" (or "--download") then it will also try to download any pending updates into the cache, still using the temporary copy of the syncdbs. -- Eli Schwartz Bug Wrangler and Trusted User

On 11/8/18 12:25 PM, Ralph Corderoy wrote:

Hi Eli,

...

...

Not in my case as I've previously done a `pacman -Syuw' during `free bandwidth' hours, thanks to cron. Later on, when I'm at the keyboard and it's a convenient time for breakage, I upgrade to what's already been downloaded manually and definitely don't want `-y'. :-)

That's dangerous because you could forget and run pacman -S pkgname.

AIUI, if I did then the version of pkgname it would try to download to install would be that snap-shotted when cron ran `pacman -Syuw'. And that's a problem because that version might not be available for download any more if a later one has been made available? Similarly, with packages pkgname depends on. Is there another problem I don't know?

-_- No, the problem is that you'll accidentally do a partial update. The package itself might very well be cached already, but if not, you'll get a 404 "cannot find package, I will now error without doing anything". That's not "dangerous". Dangerous is when you break your system by installing incompatible packages via a "successful" partial update.

I actually tend to: sudo -i at 1:23 <<<'pacman -Syw pkgname' as it's normally not urgent.

Can an attempt to fetch an old, now missing, package still occur even with `pacman -Sy pkgname' because the remote database has been altered, and old versions removed, between the -y's refresh and fetching a long list of packages?

It won't be old and now missing, because you used -Sy and it will refresh *again*. But if you don't use -y, then trying to install a package first looks in the cache, where it may not need to be fetched... -- Eli Schwartz Bug Wrangler and Trusted User

On 11/8/18 1:05 PM, Ralph Corderoy wrote:

...

It won't be old and now missing, because you used -Sy and it will refresh *again*.

But isn't it multiple stages with a race condition?

1 Update /var/lib/pacman/sync/core.db 2 Update /var/lib/pacman/sync/extra.db 3 Update /var/lib/pacman/sync/community.db 4 Update /var/lib/pacman/sync/multilib.db 5 Create /var/cache/pacman/pkg/foo-1.0.pkg.tar.xz 6 Create /var/cache/pacman/pkg/bar-2.0.pkg.tar.xz 7 Create /var/cache/pacman/pkg/xyzzy-3.0.pkg.tar.xz

Can the remote core.db be updated between 1 and 6 because bar 2.1 is available? Do bar-2.0.pkg.tar.xz and bar-2.1.pkg.tar.xz ever exist at the same time? Perhaps the fetch of bar-2.0.pkg.tar.xz might fail because it's been removed by the time it's attempted.

This is nothing to do with my original question. :-) I guess I'm asking how is a consistent multi-file database of indexes and `records' presented? It might be that the rare times this happens, the user just runs `pacman -Sy pkgname' again.

Well, most users will have multiple mirrors in their pacman mirrorlist. So if the package is no longer available on the first mirror, pacman will keep trying until it finds it somewhere. Also, the job we use to delete old packages only runs at 3-hour intervals, which means there's a window of opportunity when multiple versions are still available, and most mirrors sync roughly hourly but not on the same minute of that hour. So it would be an odd coincidence if you managed to mistime your update such that 1) your mirror updates in the seconds between syncing the db and downloading the package 2) that mirror update is during its one-hour sync cycle that is also the one-third of the time when the cleanup job runs 3) every one of your fallback mirrors is newer than your first configured mirror If you do manage to win this game of roulette, you can just pacman -Syu again. :) pacman will simply abort the upgrade if it cannot find one of the package files, so consistency is maintained -- it's just a much more exotic case of "I haven't done pacman -Syu in a week and cannot install new packages that have been updated on the mirrors". ... Source: ansible repo containing our dbscripts role, and in particular, the job cleanup.{service,time} : https://git.archlinux.org/infrastructure.git/tree/roles/dbscripts/files The dbscripts cleanup script itself: https://git.archlinux.org/dbscripts.git/tree/cron-jobs/ftpdir-cleanup -- Eli Schwartz Bug Wrangler and Trusted User