Can issues with partial upgrades be fixed via chroot?

Skeleton2323 · 2025-08-09 23:52:28

Note: This is just a question for the sake of curiosity, I don't have an issue with my installation

I was wondering if in the case of this thread: https://bbs.archlinux.org/viewtopic.php?id=307424 (pacman broken, resorting to using pacman-static, mismatched package versions), what would be the outcome of booting into a live cd, chrooting into the installed environmment and just running "pacman-syu"? Would it fix stuff such as broken keyrings and whatever else needs to be fixed for pacman to work again? Or would it complain, just like in the installed system?

Allan · 2025-08-10 00:54:50

Chrooting just gets you essentially back to where you started. Using pacman with the --root parameter would be fine for a rescue from the live cd.

Skeleton2323 · 2025-08-10 16:35:39

overall though, this will restore pacman's functionality no?

WorMzy · 2025-08-10 17:23:23

No, if you chroot in to the broken system, then you'll only have access to the broken pacman installation, same as if you booted into that system in the first place. Like Allan says, using the liveCD pacman installation with the --root flag allows you to interact with the broken system with an unbroken pacman, and you can use that to fix the broken pacman installation (by running -Syu or whatever).

NuSkool · 2025-08-11 06:31:06

I'm a bit confused and have never used either or these, although I have used '-b, --dbpath' and alternative '--config' with different settings.

It was recommended to use the '--root' option to fix a broken system. Wouldn't the guest system need mounted to the live CD? (see second: NOTE)
Does the '--root' option set the other options and vars to use those from the newly defined root location?

What difference would/should a user expect to see between using these two options to restore a broken system or pacman?
Generally speaking, what would the best use case scenario for each of these be?
They almost seem interchangeable, but thinking there's a good reason for both.

man pacman wrote:

-r, --root <path>
Specify an alternative installation root (default is /). This should not be used as a way to install software into /usr/local instead
of /usr. NOTE: If database path or log file are not specified on either the command line or in pacman.conf(5), their default location
will be inside this root path. NOTE: This option is not suitable for performing operations on a mounted guest system. See --sysroot
instead.

--sysroot <dir>
Specify an alternative system root. This path will be prepended to all other configuration directories and any repository servers
beginning with file://. Any paths or URLs passed as targets will not be modified. This allows mounted guest systems to be properly
operated on.

Last edited by NuSkool (2025-08-11 06:35:34)

seth · 2025-08-11 07:05:55

--sysroot chroots, if the target system is sufficiently fucked up, this won't work.
You probably want to use --cachedir next to --root and you might have to chroot into the system or use --sysroot for a finally sanitizing pass.

close2zero · 2025-08-11 07:09:27

This is just a guess. But I think what WorMzy ment was NOT to chroot into the environment, but boot up archiso and mount your broken system to the usual mount point. Then use pacman with the --root flag to point to the mount point (the root directory of your broken system). The point is: You are now using the archiso pacman outside the broken system, pointing it to work inside the broken system.

[Edit]
@seth Sorry, you posted while I was writing mine.
@Skeleton2323 You should follow the guidelines you'll get from seth.

Last edited by close2zero (2025-08-11 07:14:56)

NuSkool · 2025-08-11 18:05:55

After a fresh look this morning along with testing revealed that the 'pacman-conf' command covers all the details I was unsure of.

--sysroot Uses config from inside --sysroot path. (Any paths or URLs passed as targets will not be modified.)

$ pacman-conf -S /var/lib/archbuild/extra-x86_64/jeff/

RootDir  = /var/lib/archbuild/extra-x86_64/jeff/
DBPath   = /var/lib/archbuild/extra-x86_64/jeff/var/lib/pacman/
CacheDir = /var/lib/archbuild/extra-x86_64/jeff/var/cache/pacman/pkg/
HookDir  = /var/lib/archbuild/extra-x86_64/jeff/etc/pacman.d/hooks/
GPGDir   = /var/lib/archbuild/extra-x86_64/jeff/etc/pacman.d/gnupg/
LogFile  = /var/lib/archbuild/extra-x86_64/jeff/var/log/pacman.log

--root Uses config from system it's ran on, with the exceptions below. (RootDir, DBPath, LogFile)

$ pacman-conf -R /var/lib/archbuild/extra-x86_64/jeff/

RootDir  = /var/lib/archbuild/extra-x86_64/jeff/
DBPath   = /var/lib/archbuild/extra-x86_64/jeff/var/lib/pacman/
CacheDir = /var/cache/pacman/pkg/
CacheDir = /usr/local/aurch/repo
HookDir  = /etc/pacman.d/hooks/
GPGDir   = /etc/pacman.d/gnupg/
LogFile  = /var/lib/archbuild/extra-x86_64/jeff/var/log/pacman.log

Last edited by NuSkool (2025-08-11 18:14:28)

Arch Linux

#1 2025-08-09 23:52:28

Can issues with partial upgrades be fixed via chroot?

#2 2025-08-10 00:54:50

Re: Can issues with partial upgrades be fixed via chroot?

#3 2025-08-10 16:35:39

Re: Can issues with partial upgrades be fixed via chroot?

#4 2025-08-10 17:23:23

Re: Can issues with partial upgrades be fixed via chroot?

#5 2025-08-11 06:31:06

Re: Can issues with partial upgrades be fixed via chroot?

#6 2025-08-11 07:05:55

Re: Can issues with partial upgrades be fixed via chroot?

#7 2025-08-11 07:09:27

Re: Can issues with partial upgrades be fixed via chroot?

#8 2025-08-11 18:05:55

Re: Can issues with partial upgrades be fixed via chroot?

Board footer