Closed allaeddineomc closed 1 year ago
What is "kernel vanilla"?
Which .repo
file are you using?
Replacing the kernel typically requires the use of rpm-ostree override replace
; see this FAQ entry for Red Hat CoreOS which explains how to replace the kernel:
https://copr.fedorainfracloud.org/coprs/g/kernel-vanilla/fedora/ i'm using this repo which is supposedly an official fedora repo
Anything in a COPR and not in the Fedora repositories is not an official package.
See:
Instructions to try them in https://coreos.github.io/rpm-ostree/ex-replace/
i guess it's still a silverblue issue that rpm-ostree is unable to update system packages from copr also this package is very important in cases like my case where i have to use it to know if my kernel issues are upstream or related to fedora patches , because without that all kernel bug reports from silverblue users will not have that much value especially when they are hardware specific and maintainers can't reproduce on their machines
Have you tried the instructions in https://coreos.github.io/rpm-ostree/ex-replace/ ?
yes and it didn't work
x sudo rpm-ostree override replace --experimental --freeze --from repo=kernel-vanilla-fedora kernel kernel-core kernel-modules
error: Failed to invoke RegisterClient: Timeout was reached
Please provide the journal logs for rpm-ostreed. We can not help you with "it did not work".
I tried reproducing this issue in a VM and was not able to. (Though I had to disable SecureBoot for the VM)
[core@fedora ~]$ rpm-ostree status
State: idle
Deployments:
● fedora:fedora/37/x86_64/silverblue
Version: 37.20230209.0 (2023-02-09T00:46:24Z)
BaseCommit: 319016f4e0ab3078cec37752128ff431bd77e3e71a122a5586df46b79097f050
GPGSignature: Valid signature by ACB5EE4E831C74BB7C168D27F55AD3FB5323552A
LayeredPackages: langpacks-en
fedora:fedora/37/x86_64/silverblue
Version: 37.1.7 (2022-11-05T06:01:00Z)
Commit: bfe9de223c9a4ba4a793d3e01f6b09024c919685ee73c896af767958725cac79
GPGSignature: Valid signature by ACB5EE4E831C74BB7C168D27F55AD3FB5323552A
[core@fedora ~]$ cat /etc/yum.repos.d/kernel-vanilla.repo
[kernel-vanilla]
name=Copr repo for fedora owned by @kernel-vanilla
baseurl=https://download.copr.fedorainfracloud.org/results/@kernel-vanilla/fedora/fedora-$releasever-$basearch/
type=rpm-md
skip_if_unavailable=True
gpgcheck=1
gpgkey=https://download.copr.fedorainfracloud.org/results/@kernel-vanilla/fedora/pubkey.gpg
repo_gpgcheck=0
enabled=1
enabled_metadata=1
[core@fedora ~] $ sudo rpm-ostree override replace --experimental --freeze --from repo=kernel-vanilla kernel kernel-core kernel-modules kernel-modules-extra
Checking out tree 319016f... done
Enabled rpm-md repositories: fedora-cisco-openh264 fedora-modular updates-modular updates fedora kernel-vanilla updates-archive
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2022-10-06T11:01:40Z solvables: 4
rpm-md repo 'fedora-modular' (cached); generated: 2022-11-05T07:58:03Z solvables: 1454
rpm-md repo 'updates-modular' (cached); generated: 2023-01-03T01:27:52Z solvables: 1464
rpm-md repo 'updates' (cached); generated: 2023-02-09T08:58:55Z solvables: 18329
rpm-md repo 'fedora' (cached); generated: 2022-11-05T08:04:38Z solvables: 66822
rpm-md repo 'kernel-vanilla' (cached); generated: 2023-02-09T12:51:18Z solvables: 30
rpm-md repo 'updates-archive' (cached); generated: 2023-02-09T09:27:37Z solvables: 23277
Resolving dependencies... done
Applying 4 overrides and 3 overlays
Processing packages... done
Running pre scripts... done
Running post scripts... done
Running posttrans scripts... done
Writing rpmdb... done
Generating initramfs... done
Writing OSTree commit... done
Staging deployment... done
Upgraded:
kernel 6.1.9-200.fc37 -> 6.1.11-250.vanilla.fc37
kernel-core 6.1.9-200.fc37 -> 6.1.11-250.vanilla.fc37
kernel-modules 6.1.9-200.fc37 -> 6.1.11-250.vanilla.fc37
kernel-modules-extra 6.1.9-200.fc37 -> 6.1.11-250.vanilla.fc37
Use "rpm-ostree override reset" to undo overrides
Run "systemctl reboot" to start a reboot
[core@fedora ~]$ rpm-ostree status
State: idle
Deployments:
fedora:fedora/37/x86_64/silverblue
Version: 37.20230209.0 (2023-02-09T00:46:24Z)
BaseCommit: 319016f4e0ab3078cec37752128ff431bd77e3e71a122a5586df46b79097f050
GPGSignature: Valid signature by ACB5EE4E831C74BB7C168D27F55AD3FB5323552A
Diff: 4 upgraded
LocalOverrides: kernel-modules kernel kernel-modules-extra kernel-core 6.1.9-200.fc37 -> 6.1.11-250.vanilla.fc37
LayeredPackages: langpacks-en
● fedora:fedora/37/x86_64/silverblue
Version: 37.20230209.0 (2023-02-09T00:46:24Z)
BaseCommit: 319016f4e0ab3078cec37752128ff431bd77e3e71a122a5586df46b79097f050
GPGSignature: Valid signature by ACB5EE4E831C74BB7C168D27F55AD3FB5323552A
LayeredPackages: langpacks-en
fedora:fedora/37/x86_64/silverblue
Version: 37.1.7 (2022-11-05T06:01:00Z)
Commit: bfe9de223c9a4ba4a793d3e01f6b09024c919685ee73c896af767958725cac79
GPGSignature: Valid signature by ACB5EE4E831C74BB7C168D27F55AD3FB5323552A
[core@fedora ~]$ rpm -q kernel
kernel-6.1.9-200.fc37.x86_64
[core@fedora ~]$ uname -r
6.1.9-200.fc37.x86_64
[core@fedora ~]$ sudo systemctl reboot
...
[core@fedora ~]$ rpm-ostree status
State: idle
Deployments:
● fedora:fedora/37/x86_64/silverblue
Version: 37.20230209.0 (2023-02-09T00:46:24Z)
BaseCommit: 319016f4e0ab3078cec37752128ff431bd77e3e71a122a5586df46b79097f050
GPGSignature: Valid signature by ACB5EE4E831C74BB7C168D27F55AD3FB5323552A
LocalOverrides: kernel-modules kernel kernel-modules-extra kernel-core 6.1.9-200.fc37 -> 6.1.11-250.vanilla.fc37
LayeredPackages: langpacks-en
fedora:fedora/37/x86_64/silverblue
Version: 37.20230209.0 (2023-02-09T00:46:24Z)
BaseCommit: 319016f4e0ab3078cec37752128ff431bd77e3e71a122a5586df46b79097f050
GPGSignature: Valid signature by ACB5EE4E831C74BB7C168D27F55AD3FB5323552A
LayeredPackages: langpacks-en
[core@fedora ~]$ rpm -q kernel
kernel-6.1.11-250.vanilla.fc37.x86_64
[core@fedora ~]$ uname -r
6.1.11-250.vanilla.fc37.x86_64
i will try updating to the latest commit and trying again , maybe it has something to do with my outdated system
it hangs in this state for a while than fails
while here's what journalctl shows
and it shows this error after failure
while journalctl shows this
retrying after failure causes it to download the rpms again , that might be something to look into
Is it possible that you have either a really slow network connection or a slow disk?
From the logs you showed, it looks like it takes over 10 minutes to download the RPMs from the repo. I don't recall my test taking that much time.
Given that it is taking so much time for downloading the RPMs, I wonder if there is some kind of DBus timeout happening with the rpm-ostree
client...this is starting to get out of realm of expertise, so I don't know if that is a reasonable guess.
It might be useful to have a more complete view of the journal leading up to and during this transaction.
yeah the internet speed in algeria is that bad , how can i get more logs ?
i think this is related to the problem i had when trying to use rpm-ostree deploy "commit"
in issue #402 since that was worked around by running ostree pull "commit"
before running rpm-ostree deploy "commit"
so it didn't reach that timeout
For more logs, just the content of journalctl -b
in a pasetbin (i.e. https://paste.centos.org/) would be a start.
One workaround may be to download the RPMs locally first, then create an yum repo that rpm-ostree
could reference.
Something like:
$ mkdir -p /var/tmp/kernel-vanilla-repo
$ pushd /var/tmp/kernel-vanilla-repo
/var/tmp/kernel-vanilla-repo ~
$ curl -LO https://download.copr.fedorainfracloud.org/results/%40kernel-vanilla/fedora/fedora-37-x86_64/05506704-stable-fedora-releases/kernel-6.1.11-250.vanilla.fc37.x86_64.rpm
$ curl -LO https://download.copr.fedorainfracloud.org/results/%40kernel-vanilla/fedora/fedora-37-x86_64/05506704-stable-fedora-releases/kernel-core-6.1.11-250.vanilla.fc37.x86_64.rpm
$ curl -LO https://download.copr.fedorainfracloud.org/results/%40kernel-vanilla/fedora/fedora-37-x86_64/05506704-
$ curl -LO https://download.copr.fedorainfracloud.org/results/%40kernel-vanilla/fedora/fedora-37-x86_64/05506704-stable-fedora-releases/kernel-modules-extra-6.1.11-250.vanilla.fc37.x86_64.rpm
$ createrepo_c .
# cat << EOF > /etc/yum.repos.d/kernel-vanilla-local.repo
[kernel-vanilla-local]
baseurl=file:///var/tmp/kernel-vanilla-repo
gpgcheck=0
enabled=1
EOF
$ sudo rpm-ostree override replace --experimental --freeze --from repo=kernel-vanilla-local kernel kernel-core kernel-modules kernel-modules-extra
Note: createrepo_c
is not installed as part of the Silverblue base content set, so I ran that command from a Fedora container.
$ podman run --rm -it -v /var/tmp/kernel-vanilla-repo:/host:z registry.fedoraproject.org/fedora:37
(in container) # dnf -y install createrepo_c
(in container) # pushd /host
(in container) # createrepo_c .
Directory walk started
Directory walk done - 4 packages
Temporary output repo path: ./.repodata/
Preparing sqlite DBs
Pool started (with 5 workers)
Pool finished
this worked but since it's local it won't be different from downloading rpm files and using a normal override which won't keep the kernel updated here are the logs from the boot where the override failed , they are quite messy because i did a lot of stuff there https://paste.centos.org/view/800eaf23
this worked but since it's local it won't be different from downloading rpm files and using a normal override which won't keep the kernel updated
Sort of. If your local yum repo is never updated, then yes I believe your kernel will always stay the same. However, if you keep that local yum repo up-to-date with the latest versions from the COPR repo, I believe the override will also get updated each time you do rpm-ostree upgrade
Alternatively, there may be a knob somewhere for adjusting the DBus timeout which might help in situations where the network connectivity is not fast enough. I don't know of one off-hand (or if that will even help). @travier do you know of any?
here are the logs from the boot where the override failed , they are quite messy because i did a lot of stuff there https://paste.centos.org/view/800eaf23
I skimmed the logs around the time you were using rpm-ostree override replace
and didn't see anything else that would explain the problems you were seeing; I think the slow network connectivity is probably the likely culprit.
FWIW, I created a quick one-off container image that streamlines some of the downloading of the vanilla kernel and might be of use for you - https://github.com/miabbott/kernel-vanilla-downloader
I'd file a bug for rpm-ostree.
sudo rpm-ostree override replace --experimental --freeze --from repo=kernel-vanilla-fedora kernel kernel-core kernel-modules error: Failed to invoke RegisterClient: Timeout was reached
Repo address in this command is not valid therefore rpm-ostree can't fetch packages
Here's a full command-list which works for me.
Download repo file
sudo wget https://copr.fedorainfracloud.org/coprs/g/kernel-vanilla/fedora/repo/fedora-$(rpm -E %fedora)/kernel-vanilla-fedora-fedora-$(rpm -E %fedora).repo -O /etc/yum.repos.d/g-kernel-vanilla-fedora-fedora-$(rpm -E %fedora).repo
Find a repo address
head -1 /etc/yum.repos.d/g-kernel-vanilla-fedora-fedora-$(rpm -E %fedora).repo
Should be something like:
[copr:copr.fedorainfracloud.org:group_kernel-vanilla:fedora]
(Optionally) restore previously overridden kernel (otherwise you might get "conflicting requests")
sudo rpm-ostree override reset kernel kernel-core kernel-modules kernel-modules-core kernel-modules-extra
Install kernel from the repo
sudo rpm-ostree override replace --experimental --freeze --from repo=copr:copr.fedorainfracloud.org:group_kernel-vanilla:fedora kernel kernel-core kernel-modules kernel-modules-core kernel-modules-extra
Describe the bug kernel vanilla uses the same package name of the fedora kernel (kernel-core) so usinf rpm-ostree override isn't possible , and running an upgrade after adding the copr repo pulls the default fedora kernel
To Reproduce
Expected behavior updates to the vanilla kernel
Screenshots![Screenshot from 2023-02-03 14-21-18](https://user-images.githubusercontent.com/57415185/216613594-e9ef6920-53fc-487a-b955-4bc795985c8b.png)
OS version:
Additional context Add any other context about the problem here.