Package install in chroot

Several users has been reporting on problems installing using Architect.

Now I don't think Architect is the source of the error.

The error manifest with a different packages - the package is not consistent and the number of packages neither.

The commonality is libalpm hooks like this

error: hook /mnt/usr/share/libalpm/hooks/update-mime-database.hook line 2: invalid value path
error: failed to commit transaction (failed to run transaction hooks)

The following topics contains examples

I have been able to reproduce the these messages using simple basestrap on an installation target.

The message is always the same line 2: invalid value path.

Looking at one the hooks - have something changed with the hooks definition?

[Trigger]
Type = Path
Operation = Install
Operation = Upgrade
Operation = Remove
Target = usr/share/mime/packages/*.xml

[Action]
Description = Updating the MIME type database...
When = PostTransaction
Exec = /usr/bin/update-mime-database /usr/share/mime
1 Like

@philm

When I compare libalpm hook files in /usr/share/libalpm/hooks between upstream Arch and Manjaro I find they are different and the error message is line 2 where Manjaro has Path and Arch has File.

One example file is 30-systemd-tmpfiles.hook
Manjaro

[Trigger]
Type = Path

Arch

[Trigger]
Type = File

This creates failed installs using Architect and most likely updates as well.

1 Like

The following hooks contains an invalid Trigger - causing transactions to fail

❯ grep -iRl 'Type = Path' /usr/share/libalpm/hooks
/usr/share/libalpm/hooks/90-mkinitcpio-install.hook
/usr/share/libalpm/hooks/30-systemd-binfmt.hook
/usr/share/libalpm/hooks/99-grub.hook
/usr/share/libalpm/hooks/30-systemd-update.hook
/usr/share/libalpm/hooks/update-mime-database.hook
/usr/share/libalpm/hooks/dbus-reload.hook
/usr/share/libalpm/hooks/30-systemd-tmpfiles.hook
/usr/share/libalpm/hooks/30-systemd-daemon-reload.hook
/usr/share/libalpm/hooks/30-systemd-sysctl.hook
/usr/share/libalpm/hooks/30-systemd-hwdb.hook
/usr/share/libalpm/hooks/xorg-mkfontscale.hook
/usr/share/libalpm/hooks/30-systemd-udev-reload.hook
/usr/share/libalpm/hooks/60-mkinitcpio-remove.hook
/usr/share/libalpm/hooks/30-systemd-catalog.hook
/usr/share/libalpm/hooks/20-systemd-sysusers.hook

@philm @oberon @Ste74

6 Likes

Uhmm this is a change made by Arch with the definitions of Path and File inside the hook function.. Now Arch use Path and not File to trigger the hook.. maybe for some reason we have not sync the changed into libalpm :thinking: let check us..

I have checked the mkinitcpio upstream source

https://sources.archlinux.org/other/mkinitcpio/mkinitcpio-27.tar.gz

In file src/libalpm/hooks/

  • 90-mkinitcpio-install.hook
  • 60-mkinitcpio-remove.hook

Arch has Trigger -> Type = File

Manjaro has Trigger -> Type = Path

The errors are not generated in a consistent manner - more like random.

https://www.archlinux.org/todo/alpm-hooks-should-use-type-path-not-file/

only deprecated, Path is for next version
with "file" we have only warning "File targets are deprecated, use Path instead" as view in commit (and is a old commit :thinking:)


here we have path and not Path ! (in error message) so hook file is bad
error not change case, so this error is OK with this commit

1 Like

So it is not the hook file which is wrong - that is nice to know :slight_smile:

Thank you for finding that reference to the Arch to-do list

I understand that now - So in reality the Manjaro files uses the correct Type but not all binaries has been updated - so it is the binaries/scripts which are at fault - not the hooks.

That is one hell of coordination - and I also understand why something fails - others do not - and the inconsistency in the appearance - phew.

Todo List: alpm-hooks should use Type = Path, not File

2020-01-19 - Eli Schwartz

pacman 5.2 deprecated hooks which use the "File" type; see https://git.archlinux.org/pacman.git/commit/?id=39c20ad4f1d5f6e915b5be8976b6a94885ca3b0c for details.

We should use the renamed type, which is "Path". This change is a simple find/replace and has no side effects.

File is only deprecated, we can use File or Path one more year

File or Path change nothing (only one warning) : code(to bash) in libalpm

if [[ $key == "Type" ]]; then
    if [[ $value == "Package" ]]; then
        $type=ALPM_HOOK_TYPE_PACKAGE;
    elif [[ $value == "File" ]]; then
        echo "File targets are deprecated, use Path instead\n");
        $type=ALPM_HOOK_TYPE_PATH;
    elif [[ $value == "Path" ]]; then
        $type=ALPM_HOOK_TYPE_PATH;
    else
        printf "hook %s line %d: invalid value %s\n" $file $line $value
    fi
fi

in your error we have "invalid value path", so is normal : good value is Path not path (but in usr/share/libalpm/hooks/update-mime-database.hook I have the good value ???)

1 Like

I have realized that the new value is Path and my files - mostly - has Path.

I guess we just have to sit it through - but a couple of users has reported that they get errors while installing using Manjaro Architect - and my initial fear was that it affected updating as well.

I have done a couple of Arch installs - for the practice - and I compared those CLI installs with my Manjaro installs - and the Arch installs was all using File but my Manjaro installs used Path - now I know that the File is the deprecated and Path the substitution.

Still I am puzzled by the fact that pacman (libalpm) sometimes throws errors when the trigger uses Path but not when it uses File.

But thanks to the responses in this thread - I have a little more knowledge on the matter :slight_smile:

At least now the error message has change :slight_smile:

This is a screenshot caught documenting the messages and how to reproduce using minimal efforts

  1. Create a virtual machine.
  2. Boot using a Manjaro ISO - I used Architect 18.1.0.
  3. Create a partition and format the partition
  4. Mount the partition to /mnt
  5. Run basestrap to populate the root
    • basestrap base linux55 networkmanager mkinitcpio nano
Screenshot

Complete vbox screenshot taken by using Hoste

We are also used to a package owning files installed on the system - this leaves another question open - e.g. where does the file /usr/share/libalpm/hooks/90-mkinitcpio-install.hook come from?

❯ uname -a
Linux thinkstation 5.5.0-1-MANJARO #1 SMP PREEMPT Mon Jan 27 09:39:12 UTC 2020 x86_64 GNU/Linux
❯ ls -la /usr/share/libalpm/hooks
...
-rw-r--r-- 1 root root  266 23 jan 10:01 90-mkinitcpio-install.hook
...
❯ pacman -Qo 90-mkinitcpio-install.hook
error: No package owns 90-mkinitcpio-install.hook

ok
boot with architect iso , default pacman 5.1
run setup (setup run auto update)
exit setup (install nothing)
pacman -Qi pacman -> return 5.1 :scream: : Path is only for 5.2

fix: only create new iso with pacman 5.2

3 Likes

On my system I see this:

$ pacman -Qo /usr/share/libalpm/hooks/90-mkinitcpio-install.hook 
/usr/share/libalpm/hooks/90-mkinitcpio-install.hook is owned by mkinitcpio 27-2.1

(full path is needed)

1 Like

Yes I noted that - some parts of the puzzles - begin to look right.

I didn't even think of checking the version of pacman on the live ISO. :+1: great idea.

So even Architect script is self updating - when base strapping - the older version is used.

This also explains why the issue is not existing when the used version of pacman is 5.2 which it is on newer ISOs.

This whole investigation and the reason for using 18.1.0 Architect ISO was to reproduce issues a user reported in my CLI install guide - thank you @papajoke and @freggel.doe for providing your insight. Your comments are providing valuable clues.

So - to recap

  • ISOs which uses pacman 5.1 will produce the errors simply because pacman should also be updated when updating trust database.

The pacman.conf has a setting to hold back - yes you are right - pacman

HoldPkg      = pacman glibc manjaro-system
# If upgrades are available for these packages they will be asked for first
SyncFirst    = manjaro-system archlinux-keyring manjaro-keyring

So if you we learn that users are getting weird errors during install using Architect we know pacman itself can be the culprit and pacman itself should be updated.

sudo pacman -S pacman

You would have thought - when querying pacman database you need to use the full path - I didn't know

❯ pacman -Qo /usr/share/libalpm/hooks/90-mkinitcpio-install.hook
/usr/share/libalpm/hooks/90-mkinitcpio-install.hook is owned by mkinitcpio 27-2.1

It is very important knowledge we have gained here - thank you for taking time to investigate this with me.

1 Like

err... it should be

sudo pacman -S pamac-common

otherwise it will say

:: installing pacman (5.2.1-4) breaks dependency 'pacman<5.2' required by pamac-common 

:wink:

Anyway, thank you for the tip i was getting mad by trying to debug my installation.

The problem is that hooks files provided with several packages are not valid for pacman 5.1 which breaks the transaction.

The correct approach will be to remove pamac packages - update pacman - then reinstall pamac.

I managed to boot my system at last, but i still have an issue. I cannot see GRUB boot manager at all, my system goes from blank screen to login. I checked grub conf and TIMEOUT is set right so there is something more subtle at work.
I checked the installation log even but i could not find any hint

   :: manjaro-architect 0.9.30-1 ::

02/09/20 22:59:20 system: UEFI, init: systemd nw-client: nmtui 
02/09/20 22:59:23 set LANG=it_IT.UTF-8
02/09/20 22:59:23 set font ter-116n 
02/09/20 22:59:23 loadkeys it 
02/09/20 22:59:26 refresh database 
02/09/20 22:59:38 unmount /mnt 
02/09/20 22:59:38 --------- [lsblk] ------------
02/09/20 22:59:38 /dev/sda1 1,8T
02/09/20 22:59:38 /dev/sdb1 499M
02/09/20 22:59:38 /dev/sdb2 100M
02/09/20 22:59:38 /dev/sdb3 16M
02/09/20 22:59:38 /dev/sdb4 464,7G
02/09/20 22:59:38 /dev/sdb5 535M
02/09/20 22:59:38 /dev/sdc1 1K
02/09/20 22:59:38 /dev/sdc5 465,8G
02/09/20 22:59:38 /dev/sdd1 512M
02/09/20 22:59:38 /dev/sdd2 931G
02/09/20 22:59:38 /dev/sdf1 1,9G
02/09/20 22:59:38 /dev/sdf2 4M
02/09/20 22:59:38 already mounted: sdf1
02/09/20 22:59:39 ignore crypted: 
02/09/20 22:59:39 in partitions delete item /dev/sdf1 no: 20 / 21
02/09/20 22:59:39 partitions: /dev/sda1 1,8T /dev/sdb1 499M /dev/sdb2 100M /dev/sdb3 16M /dev/sdb4 464,7G /dev/sdb5 535M /dev/sdc1 1K /dev/sdc5 465,8G /dev/sdd1 512M /dev/sdd2 931G /dev/sdf2 4M
02/09/20 22:59:48 mount /dev/sdd2 as mkfs.btrfs -f. 
02/09/20 22:59:48 create mountpoint /mnt 
02/09/20 22:59:51 mount /dev/sdd2 autodefrag,noatime,nossd
02/09/20 23:00:00 already mounted: sdd2
sdf1
02/09/20 23:00:09 mkfs.vfat -F32 /dev/sdd1 
02/09/20 23:00:10 create /mnt/boot/efi 
02/09/20 23:00:10 mount /dev/sdd1 /mnt/boot/efi 
02/09/20 23:00:27 edit pacman-mirrors.conf
02/09/20 23:02:38 refresh pacman-keys
02/09/20 23:04:07 pull profiles repo 
02/09/20 23:04:19 selected: "yay + base-devel" linux414 linux419 linux54
02/09/20 23:04:19 modules: KERNEL-headers
KERNEL-broadcom-wl
KERNEL-headers
KERNEL-broadcom-wl
02/09/20 23:04:22 selected: [Manjaro-budgie]
02/09/20 23:05:07 filter_packages 
02/09/20 23:05:09 selected 'full' profile
02/09/20 23:05:09 packages to install:

...

02/09/20 23:44:22 install basepkgs 
02/09/20 23:44:22 configure vconsole
02/09/20 23:44:22 root on btrfs volume. Amend mkinitcpio.
02/09/20 23:45:03 re-run mkinitcpio 
02/09/20 23:45:03 base installed succesfully.
02/09/20 23:45:03 copy overlay 
02/09/20 23:45:03 copy root config 
02/09/20 23:45:03 enable bluetooth cronie ModemManager NetworkManager org.cups.cupsd tlp tlp-sleep avahi-daemon haveged  Created symlink /etc/systemd/system/dbus-org.bluez.service -> /usr/lib/systemd/system/bluetooth.service.
02/09/20 23:45:03 disable pacman-init 
02/09/20 23:45:04 enable lightdm Created symlink /etc/systemd/system/display-manager.service -> /usr/lib/systemd/system/lightdm.service.
02/09/20 23:49:58 Auto-installazione Drivers proprietari 
02/09/20 23:50:54 grub-install --target=x86_64-efi warning: efibootmgr-16-2 is up to date -- skipping
02/09/20 23:50:57 Install GRUB 
02/09/20 23:51:05 generate_fstab 
02/09/20 23:51:13 set_hostname 
02/09/20 23:51:18 set_locale 
02/09/20 23:51:27 set_xkbmap it 
02/09/20 23:51:38 set_timezone Europe/Rome 
02/09/20 23:51:40 set_hw_clock 
02/09/20 23:51:56 set_root_password New password: Retype new password: passwd: password updated successfully
02/09/20 23:52:08 default shell: [/bin/bash]
02/09/20 23:52:26 add user to groups 
02/09/20 23:52:26 create user pwd New password: Retype new password: passwd: password updated successfully
02/09/20 23:53:31 exit installer.

UPDATE: even Timeshift does not work. Creating btrfs snapshot says: "system partition has an unsupported secondary volume layout. Exiting"
It seems it cannot see @, @home, and @cache subvolumes.

So it seems the regression is affecting only the 18.1.0 isos: Budgie, Mate and Architect. Am i correct?

yes, only (old) iso with pacman 5.1 and not 5.2

it's possible to view pacman version in "iso-version-pkgs.txt" text file before download, for example

all iso entry

Already checked but thanks anyway :relaxed:

Forum kindly sponsored by