Re: grub2 always defaults to old kernel despite correct configuration
> What is the output of "grub2-editenv list"? As mentioned: # grub2-editenv list saved_entry=2dc3a3c6f8494c8fb93c27f99dc3a246-5.3.8-300.fc31.x86_64 boot_success=1 boot_indeterminate=0 kernelopts=root=UUID=ac6336b1-7fd2-43d7-af44-51b592f3ab8f ro rhgb quiet The saved_entry field matches what grubby shows - From everything I can see it appears correctly configured. As I mentioned in my original post I've even moved all the config files aside and reinstalled grub so that it would return to defaults. I've now been reading https://systemd.io/BOOT_LOADER_SPECIFICATION but cannot find anything related to this problem. Everything looks OK. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
Re: VPN options
> I am planning on running a Virtual Private Network from my Fedora > firewall out to a UML virtual colo (running RH9) at another site. > That site will be the place I present services to the world; > httpd, ssh, sftp, smtp. This is to comply with the "no servers" > and dynamic ip restrictions on my Comcast connection to the net; > if my firewall always drives an outbound connection to the > colocation site, I am not worried about changes of ip address, > and I am not opening any inbound ports. > > There are a number of options for the VPN - the most attractive > are cipe ( http://sites.inka.de/sites/bigred/devel/cipe.html ) > and FreeSwan ( http://www.freeswan.org/ ), though I am told that > one can do all this through an ssh tunnel. I would rather have > simple and secure than super-duper; I have plenty of bandwidth, > and will send outbound http and smtp from the firewall, so the > main bandwidth user will be incoming spam/b/b/b/b mail. > > Anyone have some experiences to share about setting up VPN? Is > there anything about either cipe or FreeSwan that is likely to > break with FC1 or FC2? > > Keith I think you can found all info about Fedora in this post about VPNs https://www.techtimes.com/articles/245819/20191027/the-best-vpn-services-what-they-offer-and-base-on.htm. I hope it's will help you protect your problem. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
Re: grub2 always defaults to old kernel despite correct configuration
On Fri, 08 Nov 2019 06:20:30 - Not Random wrote: > I need to understand how Fedora/grub determines the newest kernel as that > logic is somehow broken. I have no idea how it determines the newest, but the saved kernel is saved in the grubenv file which you can edit with the grub2-editenv command (but only after getting hundreds of errors because the command line syntax for editenv is very obscure and easy to scre up :-). ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
Re: Fedora 30 workstation keeps crashing...
Hi people. I'm happy to report that my computer no longer crashes. I made 2 changes: - I uninstalled the broadcom-wl package and started using a wired network connection. - I upgraded to Fedora 31. I also noticed that the crashes seem to have happened when I was running openOffice-Libre. It appears to have gotten a big upgrade in Fedora 31. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
Re: GRUB and nonstandard EFI partitions
On 07/11/2019 23:59, stan via users wrote: press the key that opens the machine firmware (used to be called BIOS, but it isn't really any more), usually F2 or Del. Then look at the boot menu provided, and select the UEFI version of the install media to boot. That will boot it in EFI mode, and it will install in EFI mode. Does that mean that the install media should appear in my uefi boot menu as (at least) two entries? Or are we talking about the grub menu that appears *after* booting from the flash drive? After booting I can confirm whether the install media is in uefi mode by checking if /sys/firmware/efi exists, right? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
F31 upgrade non-starter
Everyone: I just tried to upgrade to F31. And I couldn't get past a few seconds in the upgrade environment before it "failed out" and rebooted to F30, after touching nothing. For the record: I started by running: sudo dnf upgrade --refresh When one of my packages (a third-party package named mkvtoolnix) didn't upgrade I reran the upgrade command with two additional flags, per the explicit suggestion: sudo dnf upgrade --best --allowerasing That did it, and I have a working version of mkvtoolnix, even with its GUI apparently baked in (so that the separate mkvtoolnix-gui package is obsolete and now removed). Then I ran this command: sudo dnf system-upgrade download --refresh --releasever=31 --best --allowerasing It took many hours, but I got 2.8 gigabytes of downloads. I also imported three GPG keys. It did successful transaction check and test. Before anyone asks: I have never been able to do a successful CLI upgrade using the system-upgrade package without passing the --allowerasing switch to the download command. I passed the --best switch because it seemed to work on the upgrade command and I thought I was adding an extra measure of security. Then I ran sudo dnf system-upgrade reboot And what happened? Well, first it rebooted into the upgrade environment. And I saw the progress screen. And then, rather abruptly, the upgrade progress screen vanished. I saw a very brief message from a program called "watchdog" that went by too quickly to read. Then it rebooted into my present F30 environment. Result: I have a working system, but it's still in F30 and I don't know why it failed to start the upgrade process, or how to get it started. At the moment I have a bunch of downloads of F31 packages, all dressed up and nowhere to go. If anyone wants to see logs, I ask just one thing: tell me what are their names, and in what folder I will find them. Then I'll be happy to copy and paste them. As far as I know, nothing like this issue has shown up in Bugzilla, unless I'm missing something. Temlakos ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
Re: F31 upgrade non-starter
On 11/8/19 7:40 PM, Temlakos wrote: Everyone: I just tried to upgrade to F31. And I couldn't get past a few seconds in the upgrade environment before it "failed out" and rebooted to F30, after touching nothing. For the record: I started by running: sudo dnf upgrade --refresh When one of my packages (a third-party package named mkvtoolnix) didn't upgrade I reran the upgrade command with two additional flags, per the explicit suggestion: sudo dnf upgrade --best --allowerasing That did it, and I have a working version of mkvtoolnix, even with its GUI apparently baked in (so that the separate mkvtoolnix-gui package is obsolete and now removed). Then I ran this command: sudo dnf system-upgrade download --refresh --releasever=31 --best --allowerasing It took many hours, but I got 2.8 gigabytes of downloads. I also imported three GPG keys. It did successful transaction check and test. Before anyone asks: I have never been able to do a successful CLI upgrade using the system-upgrade package without passing the --allowerasing switch to the download command. I passed the --best switch because it seemed to work on the upgrade command and I thought I was adding an extra measure of security. Then I ran sudo dnf system-upgrade reboot And what happened? Well, first it rebooted into the upgrade environment. And I saw the progress screen. And then, rather abruptly, the upgrade progress screen vanished. I saw a very brief message from a program called "watchdog" that went by too quickly to read. Then it rebooted into my present F30 environment. Result: I have a working system, but it's still in F30 and I don't know why it failed to start the upgrade process, or how to get it started. At the moment I have a bunch of downloads of F31 packages, all dressed up and nowhere to go. If anyone wants to see logs, I ask just one thing: tell me what are their names, and in what folder I will find them. Then I'll be happy to copy and paste them. As far as I know, nothing like this issue has shown up in Bugzilla, unless I'm missing something. Temlakos Postscript: The log at /var/log/dnf.log has a "CRITICAL ERROR" message--something about having conflicting commands and not being able to install the "best" version. They suggest passing the --skip-broken switch. Questions: 1. How do I remove the present downloads so I can start over? 2. Should I pass the --best flag, when running dnf system-upgrade download, or skip that? 3. Should I pass --allowerasing? 4. Should I pass --skip-broken? And especially should I pass --allowerasing and --skip-broken both at once? Temlakos ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
Re: F31 upgrade non-starter
On 11/9/19 9:04 AM, Temlakos wrote: The log at /var/log/dnf.log has a "CRITICAL ERROR" message--something about having conflicting commands and not being able to install the "best" version. They suggest passing the --skip-broken switch. First, post the exact "errors". Questions: 1. How do I remove the present downloads so I can start over? dnf system-upgrade clean 2. Should I pass the --best flag, when running dnf system-upgrade download, or skip that? 3. Should I pass --allowerasing? 4. Should I pass --skip-broken? And especially should I pass --allowerasing and --skip-broken both at once? The last 3 questions are irrelevant until the error is understood. -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
Re: F31 upgrade non-starter *RESENT*
On 11/9/19 8:40 AM, Temlakos wrote: If anyone wants to see logs, I ask just one thing: tell me what are their names, and in what folder I will find them. Then I'll be happy to copy and paste them. First question. Do you have python3-dnf-plugin-system-upgrade-4.0.7-2.fc30 installed? It is the latest version which addresses some cases with symptoms you've described. The logs you want to investigate are dnf.librepo.log dnf.log dnf.log.1 dnf.rpm.log located in /var/log -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
Re: F31 upgrade non-starter
Hi, Run this command: journalctl -r Then search 'Failed to start System Upgrade using DNF' or 'system-upgrade'. Can you find any matching line? If so, you may also see some errors related to this issue. Fix that error should let you upgrade to F31. On Sat, Nov 9, 2019 at 8:41 AM Temlakos wrote: > Everyone: > > I just tried to upgrade to F31. And I couldn't get past a few seconds in > the upgrade environment before it "failed out" and rebooted to F30, > after touching nothing. > > For the record: I started by running: > > sudo dnf upgrade --refresh > > When one of my packages (a third-party package named mkvtoolnix) didn't > upgrade I reran the upgrade command with two additional flags, per the > explicit suggestion: > > sudo dnf upgrade --best --allowerasing > > That did it, and I have a working version of mkvtoolnix, even with its > GUI apparently baked in (so that the separate mkvtoolnix-gui package is > obsolete and now removed). > > Then I ran this command: > > sudo dnf system-upgrade download --refresh --releasever=31 --best > --allowerasing > > It took many hours, but I got 2.8 gigabytes of downloads. I also > imported three GPG keys. It did successful transaction check and test. > Before anyone asks: I have never been able to do a successful CLI > upgrade using the system-upgrade package without passing the > --allowerasing switch to the download command. I passed the --best > switch because it seemed to work on the upgrade command and I thought I > was adding an extra measure of security. > > Then I ran > > sudo dnf system-upgrade reboot > > And what happened? Well, first it rebooted into the upgrade environment. > And I saw the progress screen. > > And then, rather abruptly, the upgrade progress screen vanished. I saw a > very brief message from a program called "watchdog" that went by too > quickly to read. > > Then it rebooted into my present F30 environment. > > Result: I have a working system, but it's still in F30 and I don't know > why it failed to start the upgrade process, or how to get it started. > > At the moment I have a bunch of downloads of F31 packages, all dressed > up and nowhere to go. > > If anyone wants to see logs, I ask just one thing: tell me what are > their names, and in what folder I will find them. Then I'll be happy to > copy and paste them. > > As far as I know, nothing like this issue has shown up in Bugzilla, > unless I'm missing something. > > Temlakos > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@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 > ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
Re: GRUB and nonstandard EFI partitions
On 11/8/19 2:36 PM, Kad Zayar via users wrote: On 07/11/2019 23:59, stan via users wrote: press the key that opens the machine firmware (used to be called BIOS, but it isn't really any more), usually F2 or Del. Then look at the boot menu provided, and select the UEFI version of the install media to boot. That will boot it in EFI mode, and it will install in EFI mode. Does that mean that the install media should appear in my uefi boot menu as (at least) two entries? Or are we talking about the grub menu that appears *after* booting from the flash drive? If you have legacy (CSM) mode enabled, then likely you will see an entry for both, one UEFI and one legacy. This is the system boot menu, not grub. Once you get the grub menu, the mode has already been determined. After booting I can confirm whether the install media is in uefi mode by checking if /sys/firmware/efi exists, right? Yes. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
FC31 upgrade notes
Hi All,
Here are my upgrade notes on Fedora 30 to 31.
not that they are specific to me. Let me know
if you want me to expound on any of them.
Hope it helps someone else:
-T
FC 30 -->> FC 31:
https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
# rpm --rebuilddb
# rpm -Va --nofiles --nodigest
if anything is too new, do a
# dnf downgrade offender(s)
# dnf --enablerepo=* update --refresh
# dnf install python3-dnf-plugin-system-upgrade
# dnf system-upgrade download --refresh --releasever=31 --allowerasing
--best
If there are any failures or "system-upgrade reboot" starts and reboots
back into the old operating system, remove or clean up the offenders
until the above completes correctly.
IMPORTANT, then you must clean out the upgrade cache and start over
without the "--allowerasing" and "--best"
# dnf system-upgrade clean
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-primary
# dnf clean packages <-- optional
# dnf system-upgrade -v reboot --debugsolver
If a problem still exists, look through the new logs for and "CRIT" or
"CRITICAL" notations /var/log/dnf.log and dnf.rpm.log for messages which
may offer clues.
Post upgrade:
Note: the upgrade buggers up bind-chroot and perl 6
Firewall (iptables):
# systemctl enable custom-firewall.service
# systemctl stop custom-firewall.service
# systemctl start custom-firewall.service
eth.ext.rules:
modify:
lease_file=$(ls -t ${lease_dir}/internal*lease | sed -n 1,1p)
mask=$(cat $lease_file | grep NETMASK | awk -F "=" '{print $2}')
eth1_addr=$(cat $lease_file | grep -v _ADDRESS | grep
ADDRESS | awk -F "=" '{print $2}')
eth1_net=$(echo $eth1_addr | sed -e "s/\./ /g" | awk '{print
$1"." $2"." $3".0/"}')$ETH1_MASK
DHCPD=$(cat $lease_file | grep SERVER_ADDRESS | awk -F "="
'{print $2}')
gateway_addr=$(cat $lease_file | grep SERVER_ADDRESS | awk
-F "=" '{print $2}')
# Set up (local) DNS (bind, named) outgoing querry rules
$tbls -A dsl-out -o $eth1 -p tcp --dport domain
-m state --state NEW,ESTABLISHED -j ACCEPT
$tbls -A dsl-out -o $eth1 -p udp --dport domain
-m state --state NEW,ESTABLISHED -j ACCEPT
$tbls -A dsl-in-i $eth1 -p udp --sport domain -d
$eth1_addr -m state --state RELATED,ESTABLISHED -j ACCEPT
$tbls -A dsl-in-i $eth1 -p tcp ! --syn --sport domain
-d $eth1_addr-m state --state RELATED,ESTABLISHED -j ACCEPT
/etc/resolv.conf
Comment out "search" and "nameserver" entries
Temporarily add "nameserver 8.8.8.8"
disable the firewall (eth.ext.reset)
Reinstall bind and bind-chroot
# dnf reinstall bind bind-chroot
# systemctl enable named-chroot.service
# systemctl start named-chroot.service
Reenable bind's (dns) SELinux rules:
# setsebool -P nis_enabled 1
# ausearch -c 'named' --raw | audit2allow -M my-named
# semodule -X 300 -i my-named.pp
Test with
$ host google.com 127.0.0.1
/etc/resolv.conf
restore commented out "search" and "nameserver" entries
comment out "nameserver 8.8.8.8"
Test with
$ host google.com
Perl 6:
remove and reinstall Perl 6 (Rakudo)
# dnf remove rakudo-zef rakudo
# dnf install rakudo-zef rakudo
Download and install the latest or desired release from:
https://github.com/nxadm/rakudo-pkg/releases
for example:
# dnf install
/home/CDs/Linux/Perl/6/rakudo-pkg-Fedora31-2019.07.1-03.x86_64.rpm
Make sure all you module begin with "unit module ;".
Fedora 31
will not tolerate modules without it any more.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@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
Re: F31 upgrade non-starter
On 11/8/19 8:08 PM, Ed Greshko wrote: On 11/9/19 9:04 AM, Temlakos wrote: The log at /var/log/dnf.log has a "CRITICAL ERROR" message--something about having conflicting commands and not being able to install the "best" version. They suggest passing the --skip-broken switch. First, post the exact "errors". Questions: 1. How do I remove the present downloads so I can start over? dnf system-upgrade clean 2. Should I pass the --best flag, when running dnf system-upgrade download, or skip that? 3. Should I pass --allowerasing? 4. Should I pass --skip-broken? And especially should I pass --allowerasing and --skip-broken both at once? The last 3 questions are irrelevant until the error is understood. I believe the relevant passage in dnf.log is as follows: Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 122, in cli_run ret = resolving(cli, base) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 158, in resolving base.resolve(cli.demands.allow_erasing) File "/usr/lib/python3.7/site-packages/dnf/base.py", line 766, in resolve raise exc dnf.exceptions.DepsolveError: Problem: cannot install the best candidate for the job - conflicting requests 2019-11-08T23:36:58Z CRITICAL Error: Problem: cannot install the best candidate for the job - conflicting requests 2019-11-08T23:36:58Z INFO (try to add '--skip-broken' to skip uninstallable packages) 2019-11-08T23:36:58Z DDEBUG Cleaning up. Before that, I see the following somewhat unusual entries: 2019-11-08T23:36:41Z DDEBUG Base command: system-upgrade 2019-11-08T23:36:41Z DDEBUG Extra commands: ['system-upgrade', 'upgrade'] 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/bunkus-org.repo; Configuration: OptionBinding with id "failovermethod" does not exist 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/bunkus-org.repo; Configuration: OptionBinding with id "failovermethod" does not exist 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/fedora-updates-modular.repo; Configuration: OptionBinding with id "failovermethod" does not exist 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/fedora-updates-modular.repo; Configuration: OptionBinding with id "failovermethod" does not exist 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/fedora-updates-modular.repo; Configuration: OptionBinding with id "failovermethod" does not exist The repostory "bunkus-org.repo" has one package in it, called mkvtoolnix, that I updated just before running dnf system-upgrade download. I have not seen fedora-updates-modular.repo before. Every other repository seems to have good information. Temlakos ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
Re: F31 upgrade non-starter *RESENT*
On 11/8/19 8:10 PM, Ed Greshko wrote: On 11/9/19 8:40 AM, Temlakos wrote: If anyone wants to see logs, I ask just one thing: tell me what are their names, and in what folder I will find them. Then I'll be happy to copy and paste them. First question. Do you have python3-dnf-plugin-system-upgrade-4.0.7-2.fc30 installed? It is the latest version which addresses some cases with symptoms you've described. The logs you want to investigate are dnf.librepo.log dnf.log dnf.log.1 dnf.rpm.log located in /var/log Yes, I have the python package you named, in the version you named. I have just sent in some clippings from dnf.log. Temlakos ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
Re: F31 upgrade non-starter
On 11/9/19 9:34 AM, Temlakos wrote: On 11/8/19 8:08 PM, Ed Greshko wrote: On 11/9/19 9:04 AM, Temlakos wrote: The log at /var/log/dnf.log has a "CRITICAL ERROR" message--something about having conflicting commands and not being able to install the "best" version. They suggest passing the --skip-broken switch. First, post the exact "errors". Questions: 1. How do I remove the present downloads so I can start over? dnf system-upgrade clean 2. Should I pass the --best flag, when running dnf system-upgrade download, or skip that? 3. Should I pass --allowerasing? 4. Should I pass --skip-broken? And especially should I pass --allowerasing and --skip-broken both at once? The last 3 questions are irrelevant until the error is understood. I believe the relevant passage in dnf.log is as follows: Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 122, in cli_run ret = resolving(cli, base) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 158, in resolving base.resolve(cli.demands.allow_erasing) File "/usr/lib/python3.7/site-packages/dnf/base.py", line 766, in resolve raise exc dnf.exceptions.DepsolveError: Problem: cannot install the best candidate for the job - conflicting requests 2019-11-08T23:36:58Z CRITICAL Error: Problem: cannot install the best candidate for the job - conflicting requests 2019-11-08T23:36:58Z INFO (try to add '--skip-broken' to skip uninstallable packages) 2019-11-08T23:36:58Z DDEBUG Cleaning up. Before that, I see the following somewhat unusual entries: 2019-11-08T23:36:41Z DDEBUG Base command: system-upgrade 2019-11-08T23:36:41Z DDEBUG Extra commands: ['system-upgrade', 'upgrade'] 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/bunkus-org.repo; Configuration: OptionBinding with id "failovermethod" does not exist 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/bunkus-org.repo; Configuration: OptionBinding with id "failovermethod" does not exist 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/fedora-updates-modular.repo; Configuration: OptionBinding with id "failovermethod" does not exist 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/fedora-updates-modular.repo; Configuration: OptionBinding with id "failovermethod" does not exist 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/fedora-updates-modular.repo; Configuration: OptionBinding with id "failovermethod" does not exist Those messages are benign. The repostory "bunkus-org.repo" has one package in it, called mkvtoolnix, that I updated just before running dnf system-upgrade download. I have not seen fedora-updates-modular.repo before. Every other repository seems to have good information. I still don't see, from what you've supplied, what packages are causing the issue. I would run... dnf system-upgrade clean and then dnf system-upgrade download --releasever=31 followed by dnf system-upgrade reboot And check the logs again. At this point I would certainly *not* add --allowerasing, --skip-broken, or --best. I find these options are "options of last resort" which should only be used *after* probelms have been fully identified and understood. I find adding them without question can confuse more than clarify. -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
Re: F31 upgrade non-starter [SOLVED] [SUCCESS]
On 11/8/19 9:05 PM, Ed Greshko wrote: On 11/9/19 9:34 AM, Temlakos wrote: On 11/8/19 8:08 PM, Ed Greshko wrote: On 11/9/19 9:04 AM, Temlakos wrote: The log at /var/log/dnf.log has a "CRITICAL ERROR" message--something about having conflicting commands and not being able to install the "best" version. They suggest passing the --skip-broken switch. First, post the exact "errors". Questions: 1. How do I remove the present downloads so I can start over? dnf system-upgrade clean 2. Should I pass the --best flag, when running dnf system-upgrade download, or skip that? 3. Should I pass --allowerasing? 4. Should I pass --skip-broken? And especially should I pass --allowerasing and --skip-broken both at once? The last 3 questions are irrelevant until the error is understood. I believe the relevant passage in dnf.log is as follows: Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 122, in cli_run ret = resolving(cli, base) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 158, in resolving base.resolve(cli.demands.allow_erasing) File "/usr/lib/python3.7/site-packages/dnf/base.py", line 766, in resolve raise exc dnf.exceptions.DepsolveError: Problem: cannot install the best candidate for the job - conflicting requests 2019-11-08T23:36:58Z CRITICAL Error: Problem: cannot install the best candidate for the job - conflicting requests 2019-11-08T23:36:58Z INFO (try to add '--skip-broken' to skip uninstallable packages) 2019-11-08T23:36:58Z DDEBUG Cleaning up. Before that, I see the following somewhat unusual entries: 2019-11-08T23:36:41Z DDEBUG Base command: system-upgrade 2019-11-08T23:36:41Z DDEBUG Extra commands: ['system-upgrade', 'upgrade'] 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/bunkus-org.repo; Configuration: OptionBinding with id "failovermethod" does not exist 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/bunkus-org.repo; Configuration: OptionBinding with id "failovermethod" does not exist 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/fedora-updates-modular.repo; Configuration: OptionBinding with id "failovermethod" does not exist 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/fedora-updates-modular.repo; Configuration: OptionBinding with id "failovermethod" does not exist 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/fedora-updates-modular.repo; Configuration: OptionBinding with id "failovermethod" does not exist Those messages are benign. The repostory "bunkus-org.repo" has one package in it, called mkvtoolnix, that I updated just before running dnf system-upgrade download. I have not seen fedora-updates-modular.repo before. Every other repository seems to have good information. I still don't see, from what you've supplied, what packages are causing the issue. I would run... dnf system-upgrade clean and then dnf system-upgrade download --releasever=31 followed by dnf system-upgrade reboot And check the logs again. At this point I would certainly *not* add --allowerasing, --skip-broken, or --best. I find these options are "options of last resort" which should only be used *after* probelms have been fully identified and understood. I find adding them without question can confuse more than clarify. Success! First I re-ran dnf upgrade --refresh, to make sure I had a fully up-to-date system. Then I followed your instructions almost to the letter, in that I passed --refresh to dnf system-upgrade download, per the "Quick system-upgrade doc" accessible through a link at getfedora.com. I did not pass --best, --allowerasing, or --skip-broken. Two remarkable things: 1. A download process that before had taken about seven hours, took forty minutes this time. 2. The system did not instruct me to run the command again; it said to run dnf system-upgrade reboot forthwith. This I did. It went through three cycles of the progress bar moving from zero to 100 percent complete. The first took about a minute; the second maybe twenty minutes; the third about five minutes. After that it booted into F31, which is what I am now running. I know this because it installed an F31 version of the current kernel. You've given me good advice before; you did so again this time. Thank you. Temlakos ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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/li
Re: FC31 upgrade notes
On 11/9/19 9:24 AM, ToddAndMargo via users wrote: Hi All, Here are my upgrade notes on Fedora 30 to 31. not that they are specific to me. Let me know if you want me to expound on any of them. Hope it helps someone else: -T FC 30 -->> FC 31: https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/ # rpm --rebuilddb # rpm -Va --nofiles --nodigest if anything is too new, do a # dnf downgrade offender(s) # dnf --enablerepo=* update --refresh The above is, IMO, bad advice. --enablerepo=* will enable "testing" repos. This may easily result in updates to packages to versions not yet in the upgrade version. The result can be needless downgrading of packages during the upgrade process. # dnf install python3-dnf-plugin-system-upgrade # dnf system-upgrade download --refresh --releasever=31 --allowerasing --best The above is also, IMO, bad advice. It should not be necessary to use --allowerasing or --best. These should be used only when problems have been found to exist and determined to be necessary. As shown by the thread "F31 upgrade non-starter" these and other options applied without the need can lead to false failures. In other words, using options in the attempt to fix problems which don't exist may lead to phantom problems. -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
Re: grub2 always defaults to old kernel despite correct configuration
> I have no idea how it determines the newest, but the saved > kernel is saved in the grubenv file which you can edit > with the grub2-editenv command (but only after getting > hundreds of errors because the command line syntax > for editenv is very obscure and easy to scre up :-). Thank you. The confusing thing is that the output of 'grub2-editenv list' and grubby both show that currently the correct (newest) kernel is the saved kernel. This kernel isn't what is actually selected at boot though! This thread has been helpful to confirm that I'm not crazy! ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
Re: FC31 upgrade notes
On 11/8/19 8:42 PM, Ed Greshko wrote: On 11/9/19 9:24 AM, ToddAndMargo via users wrote: Hi All, Here are my upgrade notes on Fedora 30 to 31. not that they are specific to me. Let me know if you want me to expound on any of them. Hope it helps someone else: -T FC 30 -->> FC 31: https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/ # rpm --rebuilddb # rpm -Va --nofiles --nodigest if anything is too new, do a # dnf downgrade offender(s) # dnf --enablerepo=* update --refresh The above is, IMO, bad advice. --enablerepo=* will enable "testing" repos. This may easily result in updates to packages to versions not yet in the upgrade version. The result can be needless downgrading of packages during the upgrade process. Only you never updated all your repos before. I do all the time. Everything has to be updated. And yes, I have seen that debated too. # dnf install python3-dnf-plugin-system-upgrade # dnf system-upgrade download --refresh --releasever=31 --allowerasing --best The above is also, IMO, bad advice. It should not be necessary to use --allowerasing or --best. These should be used only when problems have been found to exist and determined to be necessary. I found that --allowerasing will error out on dumb things I have done, which allows me to fix them. Did you notice later on, I stated to not use the --allowerasing? As shown by the thread "F31 upgrade non-starter" these and other options applied without the need can lead to false failures. In other words, using options in the attempt to fix problems which don't exist may lead to phantom problems. I have not found that to be the case ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
Re: grub2 always defaults to old kernel despite correct configuration
On Fri, 2019-11-08 at 06:20 +, Not Random wrote: > /etc/default/grub contains: > GRUB_DEFAULT=saved > which as you say is the default for Fedora. > > There's no benefit in changing /etc/default/grub as it is already set > correctly. I think the problem is that just tells Fedora to use the previously saved entry as its default, and there's other things (perhaps more than one) that determine what will actually be the default. In the old grub (which was easier to follow the instructions) if you wanted a particular boot entry to be remembered as the default, you had to add a save default instruction to that boot stanza. As that stanza was executed, it set itself as default and booted that kernel. Any other entry that didn't have that instruction, wasn't remembered. I'm not sure if grub2 behaves that way, too. There's a boot once option, which means that you make a decision to boot from some other kernel, without changing the saved default. You might boot from a rescue option to fix something, and not want that to be the default, you'll like your next normal boot to do the usual kernel. There's a boot next option, which allows you to set which entry to boot next time, after doing that the subsequent boot will be the default. That can be used for things like making the PC reboot into the UEFI config mode. Once you exit the config, it'll reboot and boot up to your usual kernel. Doing a bit of googling, /boot/grub2/grubenv file cannot be manually edited. Use the following command instead: [root@host ~]# grub2-set-default 0 [root@host ~]# grub2-editenv list saved_entry=0 That 0 should mean the most recently installed kernel. -- uname -rsvp Linux 3.10.0-1062.4.1.el7.x86_64 #1 SMP Fri Oct 18 17:15:30 UTC 2019 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
Re: FC31 upgrade notes
On 11/9/19 1:22 PM, ToddAndMargo via users wrote: On 11/8/19 8:42 PM, Ed Greshko wrote: On 11/9/19 9:24 AM, ToddAndMargo via users wrote: Hi All, Here are my upgrade notes on Fedora 30 to 31. not that they are specific to me. Let me know if you want me to expound on any of them. Hope it helps someone else: -T FC 30 -->> FC 31: https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/ # rpm --rebuilddb # rpm -Va --nofiles --nodigest if anything is too new, do a # dnf downgrade offender(s) # dnf --enablerepo=* update --refresh The above is, IMO, bad advice. --enablerepo=* will enable "testing" repos. This may easily result in updates to packages to versions not yet in the upgrade version. The result can be needless downgrading of packages during the upgrade process. Only you never updated all your repos before. I do all the time. Everything has to be updated. And yes, I have seen that debated too. The Official Upgrade Instructions are to be found at https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/ They make no mention of updating from "testing" prior to upgrading. You happen to do things which are pretty much not what most others would do. My suggestion is that people use the official upgrade instructions. # dnf install python3-dnf-plugin-system-upgrade # dnf system-upgrade download --refresh --releasever=31 --allowerasing --best The above is also, IMO, bad advice. It should not be necessary to use --allowerasing or --best. These should be used only when problems have been found to exist and determined to be necessary. I found that --allowerasing will error out on dumb things I have done, which allows me to fix them. Did you notice later on, I stated to not use the --allowerasing? Your text appears to be saying, use --allowerasing --best and then if you have issues do a clean and then proceed without using them. Counteractive, IMO. Don't use them first. And, only use them if found to be necessary after, should problems exist, one has diagnosed them to be helpful. As shown by the thread "F31 upgrade non-starter" these and other options applied without the need can lead to false failures. In other words, using options in the attempt to fix problems which don't exist may lead to phantom problems. I have not found that to be the case You may have not. But others have. Note the cited thread. -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
