I just upgraded to the new 5.7 kernel and it has a lot of bugs.
It can't even initialize my swap file:
Jul 26 21:01:12 localhost.HPNotebook systemd[1]: fedora.swap.swap: Failed with result 'exit-code'. 6 Jul 26 21:01:12 localhost.HPNotebook systemd[1]: Failed to activate swap /fedora.swap. 7 Jul 26 21:01:12 localhost.HPNotebook systemd[1]: Dependency failed for Swap. 8 Jul 26 21:01:12 localhost.HPNotebook systemd[1]: swap.target: Job swap.target/start failed with result 'dependency'. 9 Jul 26 21:01:12 localhost.HPNotebook swapon[994]: swapon: /fedora.swap: swapon failed: Invalid argument 10 Jul 26 21:01:26 localhost.HPNotebook swapon[1084]: swapon: /fedora.swap: swapon failed: Invalid argument 11 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: fedora.swap.swap: Failed with result 'exit-code'. 12 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: Failed to activate swap /fedora.swap. 13 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: Dependency failed for Swap. 14 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: swap.target: Job swap.target/start failed with result 'dependency'. 15 Jul 26 21:01:26 localhost.HPNotebook swapon[1093]: swapon: /fedora.swap: swapon failed: Invalid argument 16 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: fedora.swap.swap: Failed with result 'exit-code'. 17 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: Failed to activate swap /fedora.swap. 18 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: Dependency failed for Swap.
This doesn't happen in 5.6
There are a slew of other problems.
A log file can be found here:
I really am too tired to file a bug since nothing really gets fixed.
What I want to do is uninstall the 5.7 kernel.
If I uninstall the kernel will running an older kernel cause problems during system upgrade ?
Okay guys how do I uninstall a kernel ?
sudo dnf remove kernel-5.7.10-201.fc32.x86_64
does absolutely nothing.
I can even boot from the removed kernel after the removal.
How do I remove a kernel for good ?
I want it gone from the GRUB boot menu too.
On 7/26/20 9:17 PM, Sreyan Chakravarty wrote:
I just upgraded to the new 5.7 kernel and it has a lot of bugs.
It can't even initialize my swap file:
Jul 26 21:01:12 localhost.HPNotebook systemd[1]: fedora.swap.swap: Failed with result 'exit-code'. 6 Jul 26 21:01:12 localhost.HPNotebook systemd[1]: Failed to activate swap /fedora.swap. 7 Jul 26 21:01:12 localhost.HPNotebook systemd[1]: Dependency failed for Swap. 8 Jul 26 21:01:12 localhost.HPNotebook systemd[1]: swap.target: Job swap.target/start failed with result 'dependency'. 9 Jul 26 21:01:12 localhost.HPNotebook swapon[994]: swapon: /fedora.swap: swapon failed: Invalid argument 10 Jul 26 21:01:26 localhost.HPNotebook swapon[1084]: swapon: /fedora.swap: swapon failed: Invalid argument 11 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: fedora.swap.swap: Failed with result 'exit-code'. 12 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: Failed to activate swap /fedora.swap. 13 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: Dependency failed for Swap. 14 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: swap.target: Job swap.target/start failed with result 'dependency'. 15 Jul 26 21:01:26 localhost.HPNotebook swapon[1093]: swapon: /fedora.swap: swapon failed: Invalid argument 16 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: fedora.swap.swap: Failed with result 'exit-code'. 17 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: Failed to activate swap /fedora.swap. 18 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: Dependency failed for Swap.
This doesn't happen in 5.6
There are a slew of other problems.
A log file can be found here:
I really am too tired to file a bug since nothing really gets fixed.
What I want to do is uninstall the 5.7 kernel.
If I uninstall the kernel will running an older kernel cause problems during system upgrade ?
On Sun, 26 Jul 2020 22:15:51 +0530 Sreyan Chakravarty wrote:
Okay guys how do I uninstall a kernel ?
First you have to boot into an older kernel. Then you might want to look for all rpms with 5.7.10-201 in the name and remove them all since they broke kernels up into multiple packages for some reason.
That should also get it out of the boot menu, but the next time you do an update it will come back unless you put an exclude line in dnf.conf to make it never install any kernel packages.
On Sun, Jul 26, 2020 at 10:46 PM Tom Horsley horsley1953@gmail.com wrote:
On Sun, 26 Jul 2020 22:15:51 +0530 Sreyan Chakravarty wrote:
Okay guys how do I uninstall a kernel ?
First you have to boot into an older kernel. Then you might want to look for all rpms with 5.7.10-201 in the name and remove them all since they broke kernels up into multiple packages for some reason.
That should also get it out of the boot menu, but the next time you do an update it will come back unless you put an exclude line in dnf.conf to make it never install any kernel packages.
Thanks.
Can't I just blacklist this particular kernel version ?
On 7/26/20 10:45 PM, Tom Horsley wrote:
First you have to boot into an older kernel. Then you might want to look for all rpms with 5.7.10-201 in the name and remove them all since they broke kernels up into multiple packages for some reason.
That should also get it out of the boot menu, but the next time you do an update it will come back unless you put an exclude line in dnf.conf to make it never install any kernel packages.
Ok.
How do I remove a specific version of a package using DNF ?
These are the installed packages for 5.7:
$ dnf list installed kernel-* | grep -i 5.7
kernel-core.x86_64 5.7.10-201.fc32 kernel-devel.x86_64 5.7.10-201.fc32 kernel-headers.x86_64 5.7.10-200.fc32 kernel-modules.x86_64 5.7.10-201.fc32 kernel-modules-extra.x86_64 5.7.10-201.fc32
How exactly do I remove these ?
What will be the DNF command ?
Sreyan Chakravarty wrote:
How do I remove a specific version of a package using DNF ?
Refer to the "SPECIFYING PACKAGES" section in the dnf man page. It explains the syntax options you can use to specify a <package-spec>, which is used by many dnf commands, like dnf remove.
While there, the remove-n, remove-na, and remove-nevra commands are also worth reading about. They come in handy occasional.
These are the installed packages for 5.7:
$ dnf list installed kernel-* | grep -i 5.7
Perhaps this is a minor point, but it's good to get in the habit of escaping shell wildcard characters, like '*' in the above command. You can do that either with quoting ('kernel-*') or prefixing the wildcard character with a backslash (kernel-*).
Not escaping the '*' _appears_ to work as expected -- until you run it in a directory where a pathname matches kernel-*. Then, you find out the shell expands the glob first, before dnf has a chance to see the argument you intended.
kernel-core.x86_64 5.7.10-201.fc32 kernel-devel.x86_64 5.7.10-201.fc32 kernel-headers.x86_64 5.7.10-200.fc32 kernel-modules.x86_64 5.7.10-201.fc32 kernel-modules-extra.x86_64 5.7.10-201.fc32
How exactly do I remove these ?
As you'll find in the man page, dnf accepts glob patterns, which are much like shell glob patterns. You can use them to remove all 5.7 kernels, something like:
$ sudo dnf remove 'kernel*-5.7.*'
Similarly, you can use the patterns to avoid the need for the pipe to grep above (which also didn't need the -i option, as your argument is numeric):
$ sudo dnf list installed 'kernel*-5.7.*'
HTH,
On 7/27/20 12:23 AM, Todd Zullinger wrote:
Refer to the "SPECIFYING PACKAGES" section in the dnf man page. It explains the syntax options you can use to specify a <package-spec>, which is used by many dnf commands, like dnf remove.
The doc is all good but without some real examples I find it difficult to translate the doc to actual commands.
But that's probably because I am a noob and not use to reading docs seriously yet.
Perhaps this is a minor point, but it's good to get in the habit of escaping shell wildcard characters, like '*' in the above command.
I didn't know that. I will do that from now on, thanks.
As you'll find in the man page, dnf accepts glob patterns, which are much like shell glob patterns. You can use them to remove all 5.7 kernels, something like:
$ sudo dnf remove 'kernel*-5.7.*'
Would this have had the same effect as:
sudo dnf remove $(rpm -qa | grep ^kernel | grep 5.7)
??
Similarly, you can use the patterns to avoid the need for the pipe to grep above (which also didn't need the -i option, as your argument is numeric):
$ sudo dnf list installed 'kernel*-5.7.*'
Yeah I tried this but this does not give the name of the packages in a way I can use in 'dnf remove' command, thus it was not very helpful.
Sreyan Chakravarty wrote:
On 7/27/20 12:23 AM, Todd Zullinger wrote:
Refer to the "SPECIFYING PACKAGES" section in the dnf man page. It explains the syntax options you can use to specify a <package-spec>, which is used by many dnf commands, like dnf remove.
The doc is all good but without some real examples I find it difficult to translate the doc to actual commands.
But that's probably because I am a noob and not use to reading docs seriously yet.
Yeah, I can still remember that. And it still happens to me with some documentation. :)
In the example below, I used kernel*-5.7.* as the package spec. To turn that into an example which helps illustrate the man page, let's break it up...
The subsection "NEVRA Matching" lists the forms dnf accepts. For kernel*-5.7.*, we're matching the name-[epoch:]version form (the '[epoch:]' portion means it's optional to provide the Epoch portion (that's the E in NEVRA¹).
So kernel* is the Name part and 5.7.* is the Version part in the specification. As both have globs in them, we look at the Globs section which says:
* Matches any number of characters.
That's what allows the package-spec to match all the kernel subpackages. (In theory, you could list them all out using the '{}' notation -- but I think that's either buggy or incorrect documentation. It likely relies on the shell's brace expansion rather than dnf's.)
We do the same '*' glob to match kernel patch releases like 5.7.9 or 5.7.10. We could use 5.7* there, but then it would match 5.70 (and any other 5.7x version). While that isn't a real problem in this case, with one extra '.' the pattern can be explicit about what we want.
¹ The others are Name, Version, Release, and Architecture, just to be be clear.
As you'll find in the man page, dnf accepts glob patterns, which are much like shell glob patterns. You can use them to remove all 5.7 kernels, something like:
$ sudo dnf remove 'kernel*-5.7.*'Would this have had the same effect as:
sudo dnf remove $(rpm -qa | grep ^kernel | grep 5.7)
??
Indeed. And without the cost of forking several subprocesses. (Those extra subprocesses don't cost enough to matter here, but in some cases they can be much more expensive. I try to avoid them when I can easily do so and where doing so doesn't come at the expense of readability of the resulting command line.)
Similar to dnf, rpm's query option (-q or --query) accepts globs. So if I were doing rpm -qa, I'd drop the first grep pattern and use:
rpm -qa 'kernel*' | grep -- '-5.7'
I think it's worth noting that the grep pattern should be quoted too, or otherwise escaped so the '' makes it to grep. As written (grep 5.7), the pattern which grep gets after the shell parses it is 5.7. Since '.' is a regular expression metacharacter which means "any character", 'grep 5.7' would match 5N7, 507, and all sorts of things. Again, that doesn't happen to cause false positives in this case, but that's relying a bit too much on luck and it _will_ burn you some day.
Similarly, you can use the patterns to avoid the need for the pipe to grep above (which also didn't need the -i option, as your argument is numeric):
$ sudo dnf list installed 'kernel*-5.7.*'Yeah I tried this but this does not give the name of the packages in a way I can use in 'dnf remove' command, thus it was not very helpful.
That's the thing, you can use the same pattern to dnf remove, so you don't have to futz around copying and pasting the output at all. That's both error-prone and waste of time. :)
If you _do_ need such output from dnf, you can control the format a lot more using the repoquery subcommand. It accepts the --qf (or --queryformat) option. With that, you can format the output almost any way you'd like. The default output from repoquery is much more suitable already:
$ sudo dnf repoquery --installed 'kernel*-5.7*'
The --qf option could be used as:
--qf "%{name}-%{version}-%{release}"
But that's common enough that there's a shortcut to it, the --nvr option:
$ sudo dnf repoquery --installed --nvr 'kernel*-5.7*'
The --qf / --queryformat option in dnf behaves almost exactly like the corresponding option in rpm. In dnf, there are a few additional query tags, like the repo a package comes from, which rpm does not have. But they're pretty close to identical in most respects.
Hope that's helpful. It should give you some concrete examples to think of while reading the man page. And then you can experiment with dnf list or dnf repoquery to see how the patterns apply.
P.S.: Unlike some other mail lists, we tend not to include each other in the To or Cc fields for replies. The list requires a subscription to post, so anyone who has sent a message is a member and can read replies via the list. :)
On Mon, Jul 27, 2020 at 8:09 PM Todd Zullinger tmz@pobox.com wrote:
The subsection "NEVRA Matching" lists the forms dnf accepts. For kernel*-5.7.*, we're matching the name-[epoch:]version form (the '[epoch:]' portion means it's optional to provide the Epoch portion (that's the E in NEVRA¹).
So kernel* is the Name part and 5.7.* is the Version part in the specification. As both have globs in them, we look at the Globs section which says:
* Matches any number of characters.That's what allows the package-spec to match all the kernel subpackages. (In theory, you could list them all out using the '{}' notation -- but I think that's either buggy or incorrect documentation. It likely relies on the shell's brace expansion rather than dnf's.)
Ok I have a couple of questions:
1 )
I tried: $ dnf repoquery --installed kernel*-5.6.* kernel-0:5.6.10-300.fc32.x86_64 kernel-0:5.6.8-200.fc31.x86_64 kernel-core-0:5.6.10-300.fc32.x86_64 kernel-core-0:5.6.8-200.fc31.x86_64 kernel-devel-0:5.6.10-300.fc32.x86_64 kernel-devel-0:5.6.8-200.fc31.x86_64 kernel-headers-0:5.6.10-300.fc32.x86_64 kernel-modules-0:5.6.10-300.fc32.x86_64 kernel-modules-0:5.6.8-200.fc31.x86_64 kernel-modules-extra-0:5.6.10-300.fc32.x86_64 kernel-modules-extra-0:5.6.8-200.fc31.x86_64
Where is the extra 0 in " kernel-0 " coming from ? If you see the rpm -qa output the zero is not present there:
$ rpm -qa | grep ^kernel | grep '5.6'
kernel-devel-5.6.10-300.fc32.x86_64 kernel-5.6.10-300.fc32.x86_64 kernel-headers-5.6.10-300.fc32.x86_64 kernel-core-5.6.10-300.fc32.x86_64 kernel-core-5.6.8-200.fc31.x86_64 kernel-modules-5.6.8-200.fc31.x86_64 kernel-5.6.8-200.fc31.x86_64
2)
How do I know which is the epoch and the version and the release in NEVRA ? And are there any standard separators between them ?
kernel-5.6.10-300.fc32.x86_64
Which is what here ? I know the name is 'kernel' that one was easy. :-)
Thanks for your help. I want to use DNF wherever I can since it is the more standard way to do package queries.
On 7/29/20 2:57 PM, Sreyan Chakravarty wrote:
I tried: $ dnf repoquery --installed kernel*-5.6.* kernel-0:5.6.10-300.fc32.x86_64
Where is the extra 0 in " kernel-0 " coming from ? If you see the rpm -qa output the zero is not present there:
That seems like an odd command, but that "0:" is the epoch (0 is also no epoch). That command includes the epoch in the listing.
$ rpm -qa | grep ^kernel | grep '5.6'
kernel-5.6.8-200.fc31.x86_64
rpm by default does not include the epoch info. It's rarely relevant.
How do I know which is the epoch and the version and the release in NEVRA ? And are there any standard separators between them ?
kernel-5.6.10-300.fc32.x86_64
Which is what here ? I know the name is 'kernel' that one was easy. :-)
There's no epoch shown there. Here's a fun command for you to try (all on one line): rpm -q --qf "Name: %{NAME}\nEpoch: %{EPOCH}\nRelease: %{RELEASE}\nVersion: %{VERSION}\n" kernel
"rpm --querytags" will give you a list of all the tags you can use there.
Thanks for your help. I want to use DNF wherever I can since it is the more standard way to do package queries.
rpm is probably faster, but can only give you information about what is currently installed on your computer. dnf can look through all the repository files to get you info on anything that's available.
Hi,
I'm mostly replying to Sreyan's questions, hopefully adding to what you've said (much) more succinctly than I, Samuel. I may have taken a few tangents along the way.
Samuel Sieb wrote:
On 7/29/20 2:57 PM, Sreyan Chakravarty wrote:
I tried: $ dnf repoquery --installed kernel*-5.6.* kernel-0:5.6.10-300.fc32.x86_64
Where is the extra 0 in " kernel-0 " coming from ? If you see the rpm -qa output the zero is not present there:
That seems like an odd command, but that "0:" is the epoch (0 is also no epoch). That command includes the epoch in the listing.
It is why I mentioned the --nvr option to repoquery too, knowing that the default format of the output from `dnf repoquery` differs from `rpm -q`. :)
And yes, many long-time users (myself included) generally prefer to use the rpm command directly for querying the local rpm database, at least in the case of simple package listings. Things like `rpm -qa --last` are very handy, and easier to use than the `dnf history` commands (for me, anyway).
There are are good uses for `dnf repoquery` too -- even for local package queries. Particularly when you want to list the repository from which a package was installed.
$ rpm -qa | grep ^kernel | grep '5.6'
kernel-5.6.8-200.fc31.x86_64
rpm by default does not include the epoch info. It's rarely relevant.
Until it is, of course. ;)
That's when you end up wondering why something isn't updating because you can see that 1.0 is less than 2.0, yet dnf installs the 1.0 version.
The way NEVRA is listed is still generally jarring to view though. And I do agree that it's not relevant in the vast majority of cases.
(It'll probably be even less so over time, since Fedora started doing a distro-sync for system upgrades a few releases or so ago. That means epoch's don't have to live in a package forever just because they were set ages ago.)
How do I know which is the epoch and the version and the release in NEVRA ? And are there any standard separators between them ?
kernel-5.6.10-300.fc32.x86_64
Which is what here ? I know the name is 'kernel' that one was easy. :-)
The fields are separated by a '-' character (except for the oddball of '%{ARCH}' at the end, which uses a '.' as the separator).
If you want to parse the fields from a package name on your own, you split it from right to left, since the package name may contain a '-' character. (If you're writing scripts to do that, it's probably better to use a library for it. In the past, the yum code included an rpmUtils python module, which included a splitFilename() method¹. I'm not sure offhand what the recommended replacement for that is. It's not a task I need to perform from a script with any frequency.)
¹ https://github.com/rpm-software-management/yum/blob/f8616a2d6/rpmUtils/miscu...
Thanks for your help. I want to use DNF wherever I can since it is the more standard way to do package queries.
rpm is probably faster, but can only give you information about what is currently installed on your computer. dnf can look through all the repository files to get you info on anything that's available.
Indeed. I think it's preferable to use whichever tool is best suited to the task. It's sometimes convenient to use dnf for local queries, but it's very unlikely to ever be as quick as rpm for those tasks. (I chuckled at the very generously-worded "rpm is probably faster" part of that sentence Samuel. :)
And often, trying to use dnf requires more effort than it would to do the same thing in rpm, like the example of querying the locally installed kernel rpm's from this thread. (Of course, if the goal is only to remove the packages, then there's no need to query them, get a list, then feed it to dnf at all.)
While I'd say it's probably best to use dnf for installing and removing packages rather than using rpm for that task, even that's just a general guideline.
There's nothing wrong with using rpm to install or update a package. However, doing so does stop dnf from:
* recording the origin repository of the package * allowing dnf history to undo an install * preventing you from removing critical packages
(among various other niceties).
Whether or not any of those reasons are important or not is a matter of personal preference for the most part. It's always good to know when a guideline is worth ignoring. :)
On Sun, 26 Jul 2020 at 12:47, Sreyan Chakravarty sreyan32@gmail.com wrote:
I just upgraded to the new 5.7 kernel and it has a lot of bugs.
If you are using ext4, look for the "swapfile has holes https://bugzilla.kernel.org/show_bug.cgi?id=207585" message. There is a kernel bug, but two proposed fixes, one looks like a quick hack, the other points to a more basic flaw in the implementation.
One misconfiguration can cause multiple failures.
Other distros are reporting problems and have workarounds: https://bbs.archlinux.org/viewtopic.php?id=256503
It can't even initialize my swap file:
Jul 26 21:01:12 localhost.HPNotebook systemd[1]: fedora.swap.swap: Failed with result 'exit-code'. 6 Jul 26 21:01:12 localhost.HPNotebook systemd[1]: Failed to activate swap /fedora.swap. 7 Jul 26 21:01:12 localhost.HPNotebook systemd[1]: Dependency failed for Swap. 8 Jul 26 21:01:12 localhost.HPNotebook systemd[1]: swap.target: Job swap.target/start failed with result 'dependency'. 9 Jul 26 21:01:12 localhost.HPNotebook swapon[994]: swapon: /fedora.swap: swapon failed: Invalid argument 10 Jul 26 21:01:26 localhost.HPNotebook swapon[1084]: swapon: /fedora.swap: swapon failed: Invalid argument 11 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: fedora.swap.swap: Failed with result 'exit-code'. 12 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: Failed to activate swap /fedora.swap. 13 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: Dependency failed for Swap. 14 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: swap.target: Job swap.target/start failed with result 'dependency'. 15 Jul 26 21:01:26 localhost.HPNotebook swapon[1093]: swapon: /fedora.swap: swapon failed: Invalid argument 16 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: fedora.swap.swap: Failed with result 'exit-code'. 17 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: Failed to activate swap /fedora.swap. 18 Jul 26 21:01:26 localhost.HPNotebook systemd[1]: Dependency failed for Swap.
This doesn't happen in 5.6
There are a slew of other problems.
A log file can be found here:
I really am too tired to file a bug since nothing really gets fixed.
Maybe you shouldn't be using Fedora. One reason Fedora exists is to catch problems like this. Given that there is a simple workaround and more than one way to "fix" it, it may take some time for a fix to make it into the kernel. The bug was reported in May, so "some time" might translate to "real soon now".
What I want to do is uninstall the 5.7 kernel. apply
Why not apply the workaround.
If I uninstall the kernel will running an older kernel cause problems during system upgrade ?
-- Regards, Sreyan _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On Sun, Jul 26, 2020 at 10:18 PM George N. White III gnwiii@gmail.com wrote:
Maybe you shouldn't be using Fedora.
Thanks I will take that under advisement.
The bug was reported in May, so "some time" might translate to "real soon now".
Was it reported in Fedora or the kernel-mailing lists ?
Why not apply the workaround.
Simple, I don't want to be a tester for a new kernel. The last version of 5.6 was really stable.
Now back to the real question :
Is there a way to remove the kernel ?
On Sun, 26 Jul 2020 22:50:07 +0530 Sreyan Chakravarty sreyan32@gmail.com wrote:
Is there a way to remove the kernel ?
Run rpm -qa | grep -i kernel* | less In the resulting list, you will see all installed packages associated with kernel-5.7*, the kernel that you want to remove.
dnf will not let you remove a running kernel, so you will have to reboot, hit space or F2 or ... while booting to bring up the grub menu. Then, select the 5.6 kernel you want to run, and boot it.
Now, run dnf remove [list of kernel packages found above]
And, voilá, the kernel it is gone.
On 7/26/20 11:19 PM, stan via users wrote:
dnf will not let you remove a running kernel, so you will have to reboot, hit space or F2 or ... while booting to bring up the grub menu. Then, select the 5.6 kernel you want to run, and boot it.
Now, run dnf remove [list of kernel packages found above]
And, voilá, the kernel it is gone.
Yeah, I have removed the a kernel component via:
sudo dnf remove kernel-*5.7.10-201.fc32.x86_64
And it did remove something but it did not remove the kernel as it is still present on the GRUB menu and is bootable.
Running the following command I get the output:
$ dnf list installed kernel-* | grep -i 5.7
kernel-core.x86_64 5.7.10-201.fc32 kernel-devel.x86_64 5.7.10-201.fc32 kernel-headers.x86_64 5.7.10-200.fc32 kernel-modules.x86_64 5.7.10-201.fc32 kernel-modules-extra.x86_64 5.7.10-201.fc32
How on earth do I now remove these ?
Could you just give me a sample DNF remove command for these ?
Thanks so much.
On Sun, 26 Jul 2020 23:26:05 +0530 Sreyan Chakravarty sreyan32@gmail.com wrote:
Running the following command I get the output:
$ dnf list installed kernel-* | grep -i 5.7
kernel-core.x86_64 5.7.10-201.fc32 kernel-devel.x86_64 5.7.10-201.fc32 kernel-headers.x86_64 5.7.10-200.fc32 kernel-modules.x86_64 5.7.10-201.fc32 kernel-modules-extra.x86_64 5.7.10-201.fc32
How on earth do I now remove these ?
Could you just give me a sample DNF remove command for these ?
Thanks so much.
That is the problem with the dnf technique, it doesn't give the actual package name, you have to put it together manually.
On my system I ran the following convoluted command in order to isolate a single kernel. rpm -qa | grep ^kernel | grep 5.8 | grep rc5 | less
The results: kernel-modules-5.8.0-0.rc5.20200717git07a56bb875af.1.20200719.fc31.x86_64 kernel-tools-libs-5.8.0-0.rc5.20200717git07a56bb875af.1.20200719.fc31.x86_64 kernel-modules-extra-5.8.0-0.rc5.20200717git07a56bb875af.1.20200719.fc31.x86_64 kernel-modules-internal-5.8.0-0.rc5.20200717git07a56bb875af.1.20200719.fc31.x86_64 kernel-devel-5.8.0-0.rc5.20200717git07a56bb875af.1.20200719.fc31.x86_64 kernel-tools-libs-devel-5.8.0-0.rc5.20200717git07a56bb875af.1.20200719.fc31.x86_64 kernel-headers-5.8.0-0.rc5.20200717git07a56bb875af.1.20200719.fc31.x86_64 kernel-core-5.8.0-0.rc5.20200717git07a56bb875af.1.20200719.fc31.x86_64 kernel-5.8.0-0.rc5.20200717git07a56bb875af.1.20200719.fc31.x86_64 kernel-tools-5.8.0-0.rc5.20200717git07a56bb875af.1.20200719.fc31.x86_64
Notice that rpm returns the actual package name. So, I would just create a command like dnf remove \ kernel-core-5.8.0-0.rc5.20200717git07a56bb875af.1.20200719.fc31.x86_64 \ kernel-5.8.0-0.rc5.20200717git07a56bb875af.1.20200719.fc31.x86_64 \ etc. until all of them are listed.
In an actual shell instead of an email message, the backslash escape is not needed, just a space between them. Double click to select, paste using middle mouse button, space, double click to select, paste using middle mouse button, space, etc.
On 7/26/20 11:56 PM, stan via users wrote:
That is the problem with the dnf technique, it doesn't give the actual package name, you have to put it together manually.
On my system I ran the following convoluted command in order to isolate a single kernel. rpm -qa | grep ^kernel | grep 5.8 | grep rc5 | less
Thank you once again. Your technique worked like a charm.
Here is the command I used:
sudo dnf remove $(rpm -qa | grep ^kernel | grep 5.7)
Did the trick perfectly. Only have 2 stable 5.6 kernels now.
I did have a couple lingering questions though:
What is the difference between dnf and rpm ? When do I use dnf over rpm and vice versa ? Shouldn't DNF be able to do everything that rpm does ?
What is reason for the existence of both ?
On Mon, 27 Jul 2020 17:46:30 +0530 Sreyan Chakravarty sreyan32@gmail.com wrote:
Did the trick perfectly. Only have 2 stable 5.6 kernels now.
Great!
What is the difference between dnf and rpm ? When do I use dnf over rpm and vice versa ? Shouldn't DNF be able to do everything that rpm does ?
What is reason for the existence of both ?
rpm is the main database of packages on the system. dnf sits on top of rpm and provides more functionality and ease of use, as well as more protection from making errors.
dnf can do (almost) everything rpm does, and more. In this case it would have been possible to run a repoquery with formatting to create the actual package name as output, but it would have been a lot more work.
rpm keeps track of low level details and is the authority for packages on the system, dnf provides abstraction to make package handling easier for the user (packagekit takes that abstraction even further). I would not use rpm, except in an emergency, to install or remove a package, I would use dnf. It is safer. But rpm is great for quick queries, though I sometimes use dnf search depending on what I am looking for.
On 7/27/20 7:17 AM, stan via users wrote:
On Mon, 27 Jul 2020 17:46:30 +0530 Sreyan Chakravarty sreyan32@gmail.com wrote:
Did the trick perfectly. Only have 2 stable 5.6 kernels now.
Great!
What is the difference between dnf and rpm ? When do I use dnf over rpm and vice versa ? Shouldn't DNF be able to do everything that rpm does ?
What is reason for the existence of both ?
rpm is the main database of packages on the system. dnf sits on top of rpm and provides more functionality and ease of use, as well as more protection from making errors.
More specifically, dnf uses rpm for the actual package management operations. dnf provides the dependency resolving and package downloading.
On Mon, Jul 27, 2020 at 7:47 PM stan via users < users@lists.fedoraproject.org> wrote:
rpm keeps track of low level details and is the authority for packages on the system, dnf provides abstraction to make package handling easier for the user (packagekit takes that abstraction even further). I would not use rpm, except in an emergency, to install or remove a package, I would use dnf. It is safer. But rpm is great for quick queries, though I sometimes use dnf search depending on what I am looking for.
Any way to permanently stop a particular kernel version from being
installed ?
Like this version 5.7 was causing problems, so any way I can stop this version from getting installed in future updates ?
Future versions of 5.7 will probably work fine and don't want to stop them from getting installed.
Any way this is possible ?
Sreyan Chakravarty wrote:
On Mon, Jul 27, 2020 at 7:47 PM stan via users < users@lists.fedoraproject.org> wrote:
rpm keeps track of low level details and is the authority for packages on the system, dnf provides abstraction to make package handling easier for the user (packagekit takes that abstraction even further). I would not use rpm, except in an emergency, to install or remove a package, I would use dnf. It is safer. But rpm is great for quick queries, though I sometimes use dnf search depending on what I am looking for.
Any way to permanently stop a particular kernel version from being
installed ?
Like this version 5.7 was causing problems, so any way I can stop this version from getting installed in future updates ?
Future versions of 5.7 will probably work fine and don't want to stop them from getting installed.
Any way this is possible ?
The dnf excludepkgs config option should work. I haven't used it often with a version in the pattern, so you might want to be careful that it doesn't match more than you intend. Something like this, in either the main dnf.conf or in specific repo files:
excludepkgs=kernel*-5.7.*
On 7/26/20 10:56 AM, Sreyan Chakravarty wrote:
Yeah, I have removed the a kernel component via:
sudo dnf remove kernel-*5.7.10-201.fc32.x86_64
And it did remove something but it did not remove the kernel as it is still present on the GRUB menu and is bootable.
You didn't give the output from dnf, but I assume that it only let you remove the kernel metapackage because you can't remove the running kernel.
Running the following command I get the output:
$ dnf list installed kernel-* | grep -i 5.7
kernel-core.x86_64 5.7.10-201.fc32 kernel-devel.x86_64 5.7.10-201.fc32 kernel-headers.x86_64 5.7.10-200.fc32 kernel-modules.x86_64 5.7.10-201.fc32 kernel-modules-extra.x86_64 5.7.10-201.fc32
A better command, at least for removal purposes would be "rpm -qa | grep kernel".
How on earth do I now remove these ?
Could you just give me a sample DNF remove command for these ?
You need to boot into a different kernel and then run: dnf remove kernel-core-5.7.10-201.fc32 Removing that will remove the other ones as well.
On 7/27/20 12:51 AM, Samuel Sieb wrote:
You didn't give the output from dnf, but I assume that it only let you remove the kernel metapackage because you can't remove the running kernel.
I don't know what I removed at first, but it did remove something according to DNF.
A better command, at least for removal purposes would be "rpm -qa | grep kernel".
I wonder why this isn't in the doc somewhere.
On 7/26/20 9:48 AM, George N. White III wrote:
On Sun, 26 Jul 2020 at 12:47, Sreyan Chakravarty <sreyan32@gmail.com mailto:sreyan32@gmail.com> wrote:
I just upgraded to the new 5.7 kernel and it has a lot of bugs.If you are using ext4, look for the "swapfile has holes https://bugzilla.kernel.org/show_bug.cgi?id=207585" message. There is a kernel bug, but two proposed fixes, one looks like a quick hack, the other points to a more basic flaw in the implementation.
Interesting, I've only ever used "dd" to create swap files. Anyway, if you do run into this problem, there's a very simple fix.
On 7/27/20 1:49 AM, Samuel Sieb wrote:
Interesting, I've only ever used "dd" to create swap files. Anyway, if you do run into this problem, there's a very simple fix.
If this was the only problem I may have reconsidered, but even /boot/efi was not mounted on my system and God knows what other kernel modules were not loaded.
On 7/26/20 2:23 PM, Samuel Sieb wrote:
On 7/26/20 8:47 AM, Sreyan Chakravarty wrote:
I just upgraded to the new 5.7 kernel and it has a lot of bugs.
A "lot" of bugs?
It can't even initialize my swap file:
I too experienced the "swap file has holes" issue after I upgraded F32 to the 5.7 kernel. All I had to do to recover swap space was remove and recreate my swap file:
# rm /storage/var/swap/swap0 # dd if=/dev/zero of=/storage/var/swap/swap0 bs=1G count=32 status=progress # chmod 600 /storage/var/swap/swap0 # mkswap /storage/var/swap/swap0 # swapon /storage/var/swap/swap0
In my opinion, this is a pretty easy workaround. I'll stick with the 5.7 kernel unless I run into other issues.
Dave
On 7/27/20 1:15 AM, Dave Ulrick wrote:
In my opinion, this is a pretty easy workaround. I'll stick with the 5.7 kernel unless I run into other issues.
5.7 could not mount /boot/efi in my case.
Also there was a message :
Failed Loading Kernel Modules
In my case I need it to be more stable before I use it daily.
On 7/27/20 5:29 AM, Sreyan Chakravarty wrote:
On 7/27/20 1:15 AM, Dave Ulrick wrote:
In my opinion, this is a pretty easy workaround. I'll stick with the 5.7 kernel unless I run into other issues.
5.7 could not mount /boot/efi in my case.
Also there was a message :
Failed Loading Kernel Modules
I've had that message for a very long time on many computers. It hasn't had any effect and I haven't bothered investigating what it's trying to load.
On Mon, Jul 27, 2020 at 11:05 PM Samuel Sieb samuel@sieb.net wrote:
I've had that message for a very long time on many computers. It hasn't had any effect and I haven't bothered investigating what it's trying to load.
Well have tried accessing the /boot/efi directory on computers that you did receive this error on. Could you cd into the directories ?
On 7/27/20 12:00 PM, Sreyan Chakravarty wrote:
On Mon, Jul 27, 2020 at 11:05 PM Samuel Sieb <samuel@sieb.net mailto:samuel@sieb.net> wrote:
I've had that message for a very long time on many computers. It hasn't had any effect and I haven't bothered investigating what it's trying to load.Well have tried accessing the /boot/efi directory on computers that you did receive this error on. Could you cd into the directories ?
I've never had a problem with /boot/efi getting mounted and that won't have anything to do with the module loading error. You need to check your logs to see what's going on. I didn't see anything relevant in what you posted so far.
On Sun, 26 Jul 2020 at 16:24, Samuel Sieb samuel@sieb.net wrote:
On 7/26/20 8:47 AM, Sreyan Chakravarty wrote:
I just upgraded to the new 5.7 kernel and it has a lot of bugs.
A "lot" of bugs?
It can't even initialize my swap file:
How did you create that swap file?
If it is the bug reported in May, a normal swapfile on ext4 that has been used with a 5.6 kernel can be rejected One fix is to modify the test that fails, but a comment to that proposed patch indicated that there is some provision for special handling of swapfiles that should be used. I assume that, absent a kernel patch, the problem could come back, e.g., after booting an older kernel to repair something.
On 7/27/20 12:53 AM, Samuel Sieb wrote:
A "lot" of bugs?
Yeah, I have linked a full pastebin of errors in the first message of this thread.
Don't get be wrong, 5.6 also had errors at startup according to journalctl -b, but nothing as basic as not being able to initialize swap or mounting the /boot/efi directory.
There are also other kernel modules that failed loading at startup.
Hope 5.7 becomes more stable soon.
How did you create that swap file?
Via fallocate and then running mkswap on it.
-
Dave Ulrick -
George N. White III -
Samuel Sieb -
Sreyan Chakravarty -
stan -
Todd Zullinger -
Tom Horsley