[SOLVED] Local repository for offline install (since 2025)?

0rd0N@t · 2025-02-12 18:12:33

tl;dr BEGIN

In the past I could follow the instructions from both #Prepare_local_repository and #Installing_packages_from_a_CD/DVD_or_USB_stick for a working configuration. It's not the case anymore.

Q: I'm no longer able to create a local repository for an offline install to another system since the introduction of pacman 7.0.0 due to several errors. Which are the right steps to follow as of now?

But my question might also be rewritten as:

Q: Now I'm able to create a local repository for an offline install to another system ONLY by DISABLING DownloadUser = alpm (introduced in pacman 7) in /etc/pacman.conf, and so acting as root directly. Since I believe both DownloadUser = ... and #DisableSandbox have been introduced for security reasons, and so it's probably better not to bypass them, which are the proper commands in order to create a local repository nowadays WITHOUT disabling those two new options?

tl;dr END • Below you can find more details about the errors I've encountered.

I've read some other threads (e.g. permission issues and notes about the new pacman) before posting, but I haven't been able to find any useful hint, other than the suggestion not to create the repo inside a user's ${HOME}.

To prepare the local repository I'm using another Arch system, working and updated; the four use cases I've already performed follow (all the commands have been executed inside a Zsh shell).

Test 1: as alpm (indirectly, nologin), repo INSIDE my user's ${HOME} # It doesn't work.

DownloadUser = alpm
#DisableSandbox

mkdir -pv /tmp/blankdb1
sudo chown -cR :alpm /tmp/blankdb1
chmod -cR g+w /tmp/blankdb1

mkdir -pv ~/pkg1
sudo chown -cR :alpm ~/pkg1
chmod -cR g+w ~/pkg1

cd ~/pkg1
pacman -Syw --cachedir . --dbpath /tmp/blankdb1 base linux
error: you cannot perform this operation unless you are root.          # Correct.
sudo pacman -Syw --cachedir . --dbpath /tmp/blankdb1 base linux

error: restricting filesystem access failed because the landlock rule for the temporary download directory could not be added!
error: could not open file ./download-jYyrgT/linux-6.13.2.arch1-1-x86_64.pkg.tar.zst.part: No such file or directory
error: failed to setup a download payload for linux-6.13.2.arch1-1-x86_64.pkg.tar.zst
warning: failed to retrieve some files
error: failed to commit transaction (failed to retrieve some files)
Errors occurred, no packages were upgraded.

Test 2: as alpm (indirectly, nologin), repo OUTSIDE my user's ${HOME} # It doesn't work.

DownloadUser = alpm
#DisableSandbox

mkdir -pv /tmp/blankdb2
sudo chown -cR :alpm /tmp/blankdb2
chmod -cR g+w /tmp/blankdb2

sudo mkdir -pv /pkg2
sudo chown -cR :alpm /pkg2
sudo chmod -cR g+w /pkg2

cd /pkg2
sudo pacman -Syw --cachedir . --dbpath /tmp/blankdb2 base linux

error: restricting filesystem access failed because the landlock rule for the temporary download directory could not be added!
error: could not open file ./download-FuXgXi/linux-6.13.2.arch1-1-x86_64.pkg.tar.zst.part: No such file or directory
error: failed to setup a download payload for linux-6.13.2.arch1-1-x86_64.pkg.tar.zst
warning: failed to retrieve some files
error: failed to commit transaction (failed to retrieve some files)
Errors occurred, no packages were upgraded.

Test 3: as my usual user account (already in wheel), repo INSIDE my user's ${HOME} # It doesn't work.

DownloadUser = myuser          # My everyday-use login account.
#DisableSandbox

mkdir -pv /tmp/blankdb3

mkdir -pv ~/pkg3

cd ~/pkg3
sudo pacman -Syw --cachedir . --dbpath /tmp/blankdb3 base linux

error: restricting filesystem access failed because the landlock rule for the temporary download directory could not be added!
error: could not open file ./download-UoltD6/linux-6.13.2.arch1-1-x86_64.pkg.tar.zst.part: No such file or directory
error: failed to setup a download payload for linux-6.13.2.arch1-1-x86_64.pkg.tar.zst
warning: failed to retrieve some files
error: failed to commit transaction (failed to retrieve some files)
Errors occurred, no packages were upgraded.

Test 4: as root, repo OUTSIDE my user's ${HOME} # It works.

#DownloadUser = alpm
#DisableSandbox

mkdir -pv /tmp/blankdb4

mkdir -pv /pkg4

cd /pkg4
pacman -Syw --cachedir . --dbpath /tmp/blankdb4 base linux

Repo creation all ok, at the first try.

General variant

In all the tests, if I also uncomment DisableSandbox, the line

error: restricting filesystem access failed because the landlock rule for the temporary download directory could not be added!

goes away, but the other errors remain and the repo creation doesn't complete, unless I act as root, as in test #4.

Test 2: as alpm (indirectly, nologin) variant

If I also add

sudo setfacl -R -m g:alpm:rwx /pkg2
sudo setfacl -R -m g:alpm:rwx /tmp/blankdb2

(as suggested here) before downloading the packages, unluckily nothing changes.

It looks to me like this is a deadlock (unless operating as root, but then... what's the difference from pacman 6? Is DownloadUser pointless?).

Many thanks in advance for any help.

Last edited by 0rd0N@t (2025-02-20 12:06:17)

cryptearth · 2025-02-12 23:37:26

although I can'T help with the actual issue - can you please strip your post from all this raindbow puke - aka the formatting - it really disturbs the readflow instread of helping it

0rd0N@t wrote:

tl;dr BEGIN
In the past I could follow the instructions from https://wiki.archlinux.org/title/Offlin … repository and https://wiki.archlinux.org/title/Pacman … _USB_stick for a working configuration. It's not the case anymore.
Q: I'm no longer able to create a local repository for an offline install to another system since the introduction of pacman 7.0.0 due to several errors. Which are the right steps to follow as of now?
But my question might also be rewritten as:
Q: [It looks like] now I'm able to create a local repository for an offline install to another system ONLY by DISABLING DownloadUser = alpm ( https://archlinux.org/news/manual-inter … -required/ in pacman 7.0.0) in /etc/pacman.conf (e.g. by acting as root directly). Since I believe DownloadUser (and #DisableSandbox too) were introduced for good reasons (e.g. security), which are the proper commands in order to create a local repository nowadays WITHOUT disabling those two new options in /etc/pacman.conf?
tl;dr END
Below you can find more details about the errors I've encountered.

looks way better and reads way more easily

Last edited by cryptearth (2025-02-12 23:43:31)

seth · 2025-02-13 08:12:29

Don't flail around, post

pacman-conf

for the desired configuration, notably the local repo, and "findmnt -T /path/to/repo/packages" as well as "getfacl" on every path element (getfacl path; getfacl path/to; …)

Since you linked the usb/dvd wiki: there're some non-posix filesystems (fat/iso9660) involved?
You'd have to handle their permissions w/ the mount options, since there're no file permissions on those FS

Allan · 2025-02-13 08:34:38

Why are you setting the group ownership of the download directory to alpm? That is the download USER.

0rd0N@t · 2025-02-13 10:50:38

Allan wrote:

Why are you setting the group ownership of the download directory to alpm? That is the download USER.

Before opening this thread I've (unsuccessfully) tried to build a custom offline repo on my own in several ways (only the «classic», pre-pacman 7 root approach worked).

Believing at least some of the errors...

error: could not open file ./download-jYyrgT/linux-6.13.2.arch1-1-x86_64.pkg.tar.zst.part: No such file or directory
error: failed to setup a download payload for linux-6.13.2.arch1-1-x86_64.pkg.tar.zst
warning: failed to retrieve some files
error: failed to commit transaction (failed to retrieve some files)

... were related to permission issues (since as root I had no problems), I also tried to fix them with chown, as suggested here.

But I only did it for my attempts #1 and #2 as (indirectly) alpm, not as myself (#3) and as root (#4).

Those were just attempts, trials and errors. Still hoping for hints for one of the possible «right ways». We'll see.

Last edited by 0rd0N@t (2025-02-19 23:14:42)

0rd0N@t · 2025-02-13 11:31:52

seth wrote:

post

pacman-conf

I keep my Arch machine at workplace, where I'll be tomorrow. Please allow me one day to retrieve my pacman configuration file from it, so I'll be able to post it here.

seth wrote:

Since you linked the usb/dvd wiki: there're some non-posix filesystems (fat/iso9660) involved?

No. The temporary package download directory is located inside the only EXT4 partition of my already working Arch system (/ and /home are the same partition, no LVM and no encryption).

Afterwards, the downloaded packages will be moved to a different external drive, inside another EXT4 partition, which will be mounted as the main repo from the other machine, the new-system-to-be-installed.

I linked #Installing_packages_from_a_CD/DVD_or_USB_stick for the sake of completeness only, because it contents was more accurate than #Prepare_local_repository (I always keep both those links at hand).

For instance, it corrected a mistake I made years ago while trying to create my first offline repo: the temporary blank DB to properly resolve the dependencies must be a directory, not a file.

Last edited by 0rd0N@t (2025-02-19 23:26:33)

0rd0N@t · 2025-02-15 13:13:11

seth wrote:

post
pacman-conf
for the desired configuration

Here it is the output of the command (from my working system, the one from which I'm trying to download the packages in order to build the custom offline repo):

[options]
RootDir = /
DBPath = /var/lib/pacman/
CacheDir = /var/cache/pacman/pkg/
HookDir = /etc/pacman.d/hooks/
GPGDir = /etc/pacman.d/gnupg/
LogFile = /var/log/pacman.log
DownloadUser = alpm
HoldPkg = pacman
HoldPkg = glibc
Architecture = x86_64
Color
VerbosePkgLists
ILoveCandy
ParallelDownloads = 20
CleanMethod = KeepInstalled
SigLevel = PackageRequired
SigLevel = PackageTrustedOnly
SigLevel = DatabaseOptional
SigLevel = DatabaseTrustedOnly
LocalFileSigLevel = PackageOptional
LocalFileSigLevel = PackageTrustedOnly
[core]
Usage = All
Server = https://geo.mirror.pkgbuild.com/core/os/x86_64
...
Server = https://mirrors.nguyenhoang.cloud/archlinux/core/os/x86_64
[extra]
Usage = All
Server = https://geo.mirror.pkgbuild.com/extra/os/x86_64
...
Server = https://mirrors.nguyenhoang.cloud/archlinux/extra/os/x86_64

I cut more than 1800 lines from this output (they're just mirrors for the core and [extra] sections automatically inserted; if you feel like it's the case, I can provide them later).

seth wrote:

notably the local repo

The reference to the local repo is not present yet, since, as of now, I'm stuck with the download phase.

It will be present on another pacman configuration file (the one I'll be using in the new-system-to-be-installed, after the boot on it from an updated official live ISO), which might be different from the original one as in the following lines:

diff pacman.conf.download pacman.conf.install

44c44
< SigLevel    = Required DatabaseOptional
---
> SigLevel    = TrustAll
78,79c78,79
< [core]
< Include = /etc/pacman.d/mirrorlist
---
> #[core]
> #Include = /etc/pacman.d/mirrorlist
84,85c84,85
< [extra]
< Include = /etc/pacman.d/mirrorlist
---
> #[extra]
> #Include = /etc/pacman.d/mirrorlist
98,100c98,100
< #[custom]
< #SigLevel = Optional TrustAll
< #Server = file:///home/custompkgs
---
> [repo]
> SigLevel = TrustAll
> Server = file:///repo

There, /repo will be the mountpoint for an EXT4 partition which will be storing the local repository on a separate drive, mounted specifically for the occasion.

seth wrote:

and "findmnt -T /path/to/repo/packages"

Below you can find the package cache of my actual working system...

findmnt -T /var/cache/pacman/pkg

TARGET SOURCE    FSTYPE OPTIONS
/      /dev/sda2 ext4   rw,relatime

... and the temporary package download directory for the future somewhere-else-install:

findmnt -T /repo/pkg

TARGET SOURCE    FSTYPE OPTIONS
/      /dev/sda2 ext4   rw,relatime

seth wrote:

as well as "getfacl" on every path element (getfacl path; getfacl path/to; ...)

getfacl /repo

# file: repo
# owner: root
# group: alpm
user::rwx
group::r-x
group:alpm:rwx
mask::rwx
other::r-x

getfacl /repo/{db,pkg}

# file: repo/db
# owner: root
# group: alpm
user::rwx
group::rwx
group:alpm:rwx
mask::rwx
other::r-x

# file: repo/pkg
# owner: root
# group: alpm
user::rwx
group::rwx
group:alpm:rwx
mask::rwx
other::r-x

But again, unfortunately, the following commands...

cd /repo/pkg
sudo pacman -Syw --cachedir . --dbpath /repo/db base linux

... still produce the same errors:

:: Proceed with download? [Y/n]
:: Retrieving packages...
...
error: restricting filesystem access failed because the landlock rule for the temporary download directory could not be added!
error: could not open file ./download-sgsR3V/linux-6.13.2.arch1-1-x86_64.pkg.tar.zst.part: No such file or directory
error: failed to setup a download payload for linux-6.13.2.arch1-1-x86_64.pkg.tar.zst
warning: failed to retrieve some files
error: failed to commit transaction (failed to retrieve some files)
Errors occurred, no packages were upgraded.

Some additional points I'd like to highlight, other than the already mentioned underlying Z Shell:

I'm behind a corporate proxy, configured in an already executable /etc/profile.d/proxy.sh as suggested here, and preserved from user to admin through Defaults env_keep += "*_proxy *_PROXY", as in here;
my current proxy configuration doesn't block any actual system update (i.e. sudo pacman -Syu works correctly).

I still think the obstacle is just the download phase, not the (future) install phase.

I say so because I've recently already performed several successfull offline install attempts on another machines through a custom offline repo built not with sudo pacman -Syw, but instead by syncing /var/cache/pacman/pkg from my working system (followed of course by a proper repo-add call), and the installation completed as expected.

And also, because the final installation must be performed as root anyway.

Last edited by 0rd0N@t (2025-02-20 10:35:12)

seth · 2025-02-15 15:08:34

cryptearth wrote:

can you please strip your post from all this raindbow puke

cd /repo
sudo -u alpm touch db/foo
sudo -u alpm touch pkg/bar
pacman -V
systemctl --version
uname -a
cat /proc/cmdline

And finally the entire output of

sudo pacman --debug -Syw --cachedir . --dbpath /repo/db base linux

And just as a cross-check, have you tried owning /repo/{db,pkg} to alpm?

NuSkool · 2025-02-15 22:13:53

I can duplicate op's error when using sudo rather than su to root. See 'EDIT:' below

Works fine ran as root via 'su'.

I did have to make some command adjustments related to my setup.
1) provide a default 'pacman.conf'. I used 'paccat pacman -- pacman.conf > .pacman.conf
2) per the wiki (optionally?), I created/provided a '--dbpath .blankdb'

Here's the command I used for both tests:

As root ran as expected after a few adjustments to the command.

# pacman -Syw --cachedir /home/jeff/Testing/L-Test-offload-install/Packages/ --dbpath .blankdb --config .pacman.conf base base-devel

As user using sudo, the following errors.

$ sudo pacman -Syw --cachedir . --config .pacman.conf --dbpath .blankdb base base-devel

error: restricting filesystem access failed because the landlock rule for the temporary download directory could not be added!
error: could not open file ./download-CVo16X/gcc-14.2.1+r753+g1cd744a6828f-1-x86_64.pkg.tar.zst.part: No such file or directory
error: failed to setup a download payload for gcc-14.2.1+r753+g1cd744a6828f-1-x86_64.pkg.tar.zst
warning: failed to retrieve some files
error: failed to commit transaction (failed to retrieve some files)
Errors occurred, no packages were upgraded.

Does this example possibly shed any light on unexpected behavior or issues with sudo?

EDIT:

OK, the devil was in the details and disregard the above failure with sudo.
After verifying the results using similar commands this time I came up with different result and cause in my case.

$ sudo pacman -Syw --cachedir . --config .pacman.conf --dbpath .blankdb base base-devel
[sudo] password for jeff: 

----

:: Retrieving packages...
 Total (  0/147)                                            231.6 MiB  18.8 GiB/s 00:00 [##################################################] 100%

error: restricting filesystem access failed because the landlock rule for the temporary download directory could not be added!
error: could not open file ./download-K8oIhg/gcc-14.2.1+r753+g1cd744a6828f-1-x86_64.pkg.tar.zst.part: No such file or directory
error: failed to setup a download payload for gcc-14.2.1+r753+g1cd744a6828f-1-x86_64.pkg.tar.zst
warning: failed to retrieve some files
error: failed to commit transaction (failed to retrieve some files)
Errors occurred, no packages were upgraded.

$ sudo pacman -Syw --cachedir /home/jeff/Testing/J-Test-offload-install-user/Packages/ --config .pacman.conf --dbpath .blankdb base base-devel

----

Total (147/147)                                      231.6 MiB  83.8 MiB/s 00:03 [###############################################] 100%
(147/147) checking keys in keyring                                                [###############################################] 100%
(147/147) checking package integrity                                              [###############################################] 100%

This seems to point to the '--cachedir' difference being my issue which the op is also using. ie: '--cachedir .' rather than a full path

$ sudo pacman -Syw --cachedir /home/jeff/Testing/J-Test-offload-install-user/Packages/ --config .pacman.conf --dbpath .blankdb base base-devel
$ sudo pacman -Syw --cachedir .                                                      --config .pacman.conf --dbpath .blankdb base base-devel

@Allan, Is this possibly an issue with pacman handling the '.' path differently than in past versions?
The wiki link does use '.' in the examples. https://wiki.archlinux.org/title/Pacman … _USB_stick

Last edited by NuSkool (2025-02-15 23:55:05)

Allan · 2025-02-16 06:31:50

Interesting. Please file a bug report and I will fix it.

https://gitlab.archlinux.org/pacman/pacman

NuSkool · 2025-02-17 18:12:07

Allan wrote:

Interesting. Please file a bug report and I will fix it.
https://gitlab.archlinux.org/pacman/pacman

Status report: I've formally applied for the position of 'Arch bug reporter'!

IIRC, my application has to go before the next "Council of Elders" meeting held during the 3rd full moon of the new year for a majority vote on approval.

If I'm approved I'll proceed with the bug reporting process.

In the case that my application is denied approval, I included a paragraph in my application, pleading for a higher up to follow through with the report process on this potential bug with reference to this post.

I believe I could initiate a formal appeal process should my application be denied, but unfortunately my legal staff has recommended that it would not be a financially wise to move to proceed on appeal.

This is all my attempt at some light hearted humor poking a finger at the current bug reporting process. I've sent an email for access.

EDIT UPDATE:
An account was created and a link was provided in an email to finish the registration process.
Unfortunately it seems to require a cell phone (+ 2FA ?), which I choose to not use.
Not the first time this decision has eliminated the possibility to use/do something.
Sorry but I'm out with trying to fill out this bug report.

And I am truly disappointed being locked out of contributing via bug reports for a distro I've been on 15+ years.
It's cool though and I'd not trade my decision/choice on privacy for what I'm missing out on.

Last edited by NuSkool (2025-02-20 02:30:04)

0rd0N@t · 2025-02-20 12:04:51

To me the problem is solved. Thanks everybody for the analysis, the comments and the solution.

NuSkool wrote:

This seems to point to the '--cachedir' difference being my issue which the op is also using. ie: '--cachedir .' rather than a full path

Yes, I did so because I followed the examples as suggested on the ArchWiki (again, from both the aforementioned links #Prepare_local_repository and #Installing_packages_from_a_CD/DVD_or_USB_stick).

For the sake of completeness, here are the full MWEs for the four cases I considered:

Test 4: as root, repo OUTSIDE my user's ${HOME} # It works.

#DownloadUser = alpm
#DisableSandbox

It already worked from the beginning. See the commands from the first post. No changes needed.

Test 2: as alpm (indirectly, nologin), repo OUTSIDE my user's ${HOME} # Now it works.

DownloadUser = alpm
#DisableSandbox

sudo mkdir -pv /repo/{db,pkg}
sudo pacman -Syw --cachedir /repo/pkg --config /etc/pacman.conf --dbpath /repo/db base base-devel

Test 3: as my usual user account (already in wheel), repo INSIDE my user's ${HOME} # Now it works.

DownloadUser = myuser          # My everyday-use login account.
#DisableSandbox

mkdir -pv ${HOME}/repo/{db,pkg}
sudo pacman -Syw --cachedir ${HOME}/repo/pkg --config /etc/pacman.conf --dbpath ${HOME}/repo/db base base-devel

Test 1: as alpm (indirectly, nologin), repo INSIDE my user's ${HOME} # It still doesn't work.

DownloadUser = alpm
#DisableSandbox

mkdir -pv ${HOME}/repo/{db,pkg}
sudo pacman -Syw --cachedir ${HOME}/repo/pkg --config /etc/pacman.conf --dbpath ${HOME}/repo/db base base-devel

:: Synchronizing package databases...
error: could not open file /home/myuser/repo/db/sync/download-sll7yn/core.db.part: Permission denied
error: failed to setup a download payload for core.db
error: failed to synchronize all databases (failed to retrieve some files)

sudo chown -cR :alpm ${HOME}/repo          # root owned too much inside the directory.
chmod -cR g+w ${HOME}/repo
sudo setfacl -R -m g:alpm:rwx ${HOME}/repo
sudo pacman -Syw --cachedir ${HOME}/repo/pkg --config /etc/pacman.conf --dbpath ${HOME}/repo/db base base-devel

:: Synchronizing package databases...
error: could not open file /home/myuser/repo/db/sync/download-sll7yn/core.db.part: Permission denied
error: failed to setup a download payload for core.db
error: failed to synchronize all databases (failed to retrieve some files)

sudo chown -cR myuser:alpm ${HOME}/repo    # Again, try to reown what's root's.
sudo setfacl -R -m g:alpm:rwx ${HOME}/repo
sudo pacman -Syw --cachedir ${HOME}/repo/pkg --config /etc/pacman.conf --dbpath ${HOME}/repo/db base base-devel

:: Synchronizing package databases...
error: could not open file /home/myuser/repo/db/sync/download-sll7yn/core.db.part: Permission denied
error: failed to setup a download payload for core.db
error: failed to synchronize all databases (failed to retrieve some files)

This still doesn't work, but, as per my needs, there's no need to analyze further this case: like NuSkool wrote in here, the info on the recent pacman upgrade regarding «users with local repos» is incomplete for repos under users' home directories. But in my opinion it's better to skip this last case instead of risking other issues.

I'd rather suggest both the Wiki pages #Prepare_local_repository and #Installing_packages_from_a_CD/DVD_or_USB_stick to be edited by removing the cd call and by providing a full path to the --cachedir option, since the provided command, written as it looks now, doesn't work anymore.

cryptearth wrote:

can you please strip your post from all this raindbow puke - aka the formatting

I edited all my previous posts, doing my best in trying to keep them at the bare minimum, in a way that still allows me to distinguish the most relevant parts at eyesight.

Some doubts about formatting have arisen, but maybe I'll open a dedicated thread later, instead of overcharging and sending OT the current one.

Really thanks again. I mark this thread as solved.

Arch Linux

#1 2025-02-12 18:12:33

[SOLVED] Local repository for offline install (since 2025)?

#2 2025-02-12 23:37:26

Re: [SOLVED] Local repository for offline install (since 2025)?

#3 2025-02-13 08:12:29

Re: [SOLVED] Local repository for offline install (since 2025)?

#4 2025-02-13 08:34:38

Re: [SOLVED] Local repository for offline install (since 2025)?

#5 2025-02-13 10:50:38

Re: [SOLVED] Local repository for offline install (since 2025)?

#6 2025-02-13 11:31:52

Re: [SOLVED] Local repository for offline install (since 2025)?

#7 2025-02-15 13:13:11

Re: [SOLVED] Local repository for offline install (since 2025)?

#8 2025-02-15 15:08:34

Re: [SOLVED] Local repository for offline install (since 2025)?

#9 2025-02-15 22:13:53

Re: [SOLVED] Local repository for offline install (since 2025)?

#10 2025-02-16 06:31:50

Re: [SOLVED] Local repository for offline install (since 2025)?

#11 2025-02-17 18:12:07

Re: [SOLVED] Local repository for offline install (since 2025)?

#12 2025-02-20 12:04:51

Re: [SOLVED] Local repository for offline install (since 2025)?

Board footer