We put the auto-update in there because when Arch Linux removes or renames packages, the installer breaks while looking for packages . The auto-update allows our updated package lists to arrive on ISOs that may have been downloaded weeks or months ago.
That would explain why when selecting 30 or more additional packages doesn’t break the install like it does with Arco.
OK booted into the live environment and ran the one command, launched Thunar, did a search and the only downloads folder is mine that I have on my one drive. So looks like no file was actually downloaded or at least it was kept by the system.
rebornos@rebornosiso ~ % curl --silent --output ~/Downloads/calamares-configuration.pkg.tar.zst --location "$(curl 'https://api.github.com/repos/rebornos-team/calamares-configuration/releases/latest' | jq '.assets[] | select(.name | endswith(".zst")).browser_download_url' | cat | cut -d '"' -f 2)"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 16153 0 16153 0 0 71433 0 --:--:-- --:--:-- --:--:-- 71473
23 rebornos@rebornosiso ~ %
This is baffling. The transfer was 100% but the file did not download? Let us try to download on the temporary filesystem:
curl --silent --output /tmp/calamares-configuration.pkg.tar.zst --location "$(curl 'https://api.github.com/repos/rebornos-team/calamares-configuration/releases/latest' | jq '.assets[] | select(.name | endswith(".zst")).browser_download_url' | cat | cut -d '"' -f 2)"
ls -l /tmp/calamares-configuration.pkg.tar.zst
Before I do that I though it was odd that there was no Download folder for the live environment. Is that normal?
I ran 2 tests with the previous installer and that hangs at the calamares update, ( photo ) additionally with
the current installer (2024 08 03) which works well even with calamares update and custom packages, BUT there is no “New Githunb Package” existing for the ['calamares-config…" … so that does not solve the problem really right ? - just tells that the problem occurs when there is a github update …
@ycom1 Can you try the below on a terminal on the live environment?
curl --silent --output /tmp/calamares-core.pkg.tar.zst --location "$(curl 'https://api.github.com/repos/rebornos-team/calamares-core/releases/latest' | jq '.assets[] | select(.name | endswith(".zst")).browser_download_url' | cat | cut -d '"' -f 2)"
ls -l /tmp/calamares-core.pkg.tar.zst
OK my ISO is 7-27 so maybe it has issues with the calamares version non it.
130 rebornos@rebornosiso ~ % curl --silent --output /tmp/calamares-core.pkg.tar.zst --location “$(curl ‘https://api.github.com/repos/rebornos-team/calamares-core/releases/latest’ | jq '.assets | select(.name | endswith(”.zst")).browser_download_url’ | cat | cut -d ‘"’ -f 2)"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 9397 100 9397 0 0 50910 0 --:–:-- --:–:-- --:–:-- 51070
3 rebornos@rebornosiso ~ % ls -l /tmp/calamares-core.pkg.tar.zst
ls: cannot access ‘/tmp/calamares-core.pkg.tar.zst’: No such file or directory
2 rebornos@rebornosiso ~ %
update:
2024 08 03 has no issues because related to that there is no github update,
that does not mean that the problem not occurs when in the future there are updates,
2024 07 27 freezes on install, then if I restart the online installer then it installs
just takes a really long time …
The curl command failed to download the Github package.
I see now why it is happening. Somewhere in the recent past, a “debug” package starts to appear on building the package, that interferes with the URL extraction. So two URLs are generated instead of one:
~
❯ echo "$(curl 'https://api.github.com/repos/rebornos-team/calamares-core/releases/latest' | jq '.assets[] | select(.name | endswith(".zst")).browser_download_url' | cat | cut -d '"' -f 2)"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 9397 100 9397 0 0 20554 0 --:--:-- --:--:-- --:--:-- 20517
https://github.com/RebornOS-Team/calamares-core/releases/download/v3.3.8_002/calamares-core-3.3.8_002-1-x86_64.pkg.tar.zst
https://github.com/RebornOS-Team/calamares-core/releases/download/v3.3.8_002/calamares-core-debug-3.3.8_002-1-x86_64.pkg.tar.zst
It is possible to filter out one URL by adding an extra grep -v command in the pipe chain.
~
❯ echo "$(curl 'https://api.github.com/repos/rebornos-team/calamares-core/releases/latest' | jq '.assets[] | select(.name | endswith(".zst")).browser_download_url' | grep -v debug | cat | cut -d '"' -f 2)"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 9397 100 9397 0 0 25355 0 --:--:-- --:--:-- --:--:-- 25397
https://github.com/RebornOS-Team/calamares-core/releases/download/v3.3.8_002/calamares-core-3.3.8_002-1-x86_64.pkg.tar.zst
So the below commands should run successfully:
curl --silent --output /tmp/calamares-core.pkg.tar.zst --location "$(curl 'https://api.github.com/repos/rebornos-team/calamares-core/releases/latest' | jq '.assets[] | select(.name | endswith(".zst")).browser_download_url' | cat | grep -v debug | cut -d '"' -f 2)"
ls -l /tmp/calamares-core.pkg.tar.zst
I will fix the URL extraction in the welcome app’s code to account for this.
1 Like
ah I see, …cool 
…
and also is really good that @CCG insisted on this problem
1 Like
Yea on Garuda we ran into this with a couple of programs and it eventually got addressed y the maintainers. Had a feeling that issue wasn’t completely fixed.
1 Like