Updated from F20 to F21 on two systems, one a VM, the other bare metal. Used nonproduct to accommodate customizations.
Had zero problems.
Tony Camuso wrote:
Updated from F20 to F21 on two systems, one a VM, the other bare metal. Used nonproduct to accommodate customizations.
I had a moderate experience with Fedup on two Thinkpad laptops.
One (T510) worked perfectly, except that I could not turn off the touchpad, until told that Fn+F8 did this (permanently, to my surprise).
The second (T61) lost WiFi after Fedup, which I have not been able to recover.
I'd be happier if there were some evidence that the Fedup developers were keeping a note of problems. Reference to user experience is not one of Fedora's strong points.
On 12/22/14 19:53, Timothy Murphy wrote:
I'd be happier if there were some evidence that the Fedup developers were keeping a note of problems.
Of course that would only come about if the folks having problems would be so kind as to file bugzillas.
On 23/12/14 02:35, Ed Greshko wrote:
On 12/22/14 19:53, Timothy Murphy wrote:
I'd be happier if there were some evidence that the Fedup developers were keeping a note of problems.
Of course that would only come about if the folks having problems would be so kind as to file bugzillas.
I tried to file a bugzilla once, in respect of a problem that I'd found --- or at least thought I'd found. Can't remember what the problem was; it was quite a while ago.
Anyhow I found it impossible. The interface was opaque, myriad questions were asked that I had no idea how to answer, and the whole thing was riddled with incomprehensible geek-speak. I gave up and have not been back since.
cheers,
Rolf Turner
Ed Greshko wrote:
On 12/22/14 19:53, Timothy Murphy wrote:
I'd be happier if there were some evidence that the Fedup developers were keeping a note of problems.
Of course that would only come about if the folks having problems would be so kind as to file bugzillas.
I agree that would be good. (I did actually file a bugzilla for one of my two Fedup problems.)
But I think a simple survey - "How did your Fedup go?" - would be good too. I guess 80% would just say "Fine", but it might be worth knowing what problems the other 20% encountered.
On 12/23/2014 08:06 AM, Timothy Murphy wrote:
Ed Greshko wrote:
On 12/22/14 19:53, Timothy Murphy wrote:
I'd be happier if there were some evidence that the Fedup developers were keeping a note of problems.
Of course that would only come about if the folks having problems would be so kind as to file bugzillas.
I agree that would be good. (I did actually file a bugzilla for one of my two Fedup problems.)
But I think a simple survey - "How did your Fedup go?" - would be good too. I guess 80% would just say "Fine", but it might be worth knowing what problems the other 20% encountered.
I have used Fedup to upgrade Fedora every release from F18 to F21, and it has worked flawlessly except for F21. I use the nvidia proprietary driver, both the kmod binary version and the akmod source version, and I had all sorts of problems with them after Fedup in F21 for the first time. The binary driver was not upgraded to a version supporting the initial F21 kernel even though an upgrade was available and at boot time the akmod version was not compiled into the kernel. I had to run a dnf upgrade command after the Fedup process to get the right version of the kmod driver for the kernel version. The other issue I have since running Fedup, relative to the nvidia module, the F21 upgrade has installed both debug and non-debug versions of the kernel such that the nvidia drivers both the binary version and the compiled source code version cannot be installed into the debug kernel but can be installed into the non-debug kernel, and Fedora, in my opinion have stupidly, made the debug kernel version the default kernel (and I haven't found any info from net searches on how to change this so that with any future upgrades of the kernel the default kernel will always be the non-debug version. If I want to use the debug version then I will select that from the Advanced Options submenu). I have also queried in another thread around plymouth not working properly, but this is no different to F20.
regards, Steve
On Wed, 2014-12-24 at 07:07 +1100, Stephen Morris wrote:
Fedora, in my opinion have stupidly, made the debug kernel version the default kernel (and I haven't found any info from net searches on how to change this so that with any future upgrades of the kernel the default kernel will always be the non-debug version.
Is Fedora 21 still using /etc/default/grub for regenerating each grub menu? If so, change the GRUB_DEFAULT= clause to your preference, then regenerate the config file.
[tim@fluffy ~]$ cat /etc/default/grub GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="vconsole.font=latarcyrheb-sun16 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) quiet" GRUB_DISABLE_RECOVERY="true"
On Mon, Dec 22, 2014 at 1:20 PM, Tony Camuso tcamuso@redhat.com wrote:
Updated from F20 to F21 on two systems, one a VM, the other bare metal. Used nonproduct to accommodate customizations.
Had zero problems.
In the past couple of weeks I've upgraded ~20 physical machines (ranging from low-end laptops to high-end 4S servers) and more than 20 VMs (32bit and 64bit) to Fedora 21 with near zero issues (some had missing kernel modules 3.17.4-30*, but a simple update + adding kernel-modules-extra solved it. I still have issue getting bumblebee to work on two laptops, but its not urgent [IGP works just fine], so I'm ignoring it for now...).
All in all, a *very* solid release. Congrats to the Fedora team and to all involved.
- Gilboa
On Mon, Dec 22, 2014 at 1:53 PM, Timothy Murphy gayleard@eircom.net wrote:
Tony Camuso wrote:
Updated from F20 to F21 on two systems, one a VM, the other bare metal. Used nonproduct to accommodate customizations.
I had a moderate experience with Fedup on two Thinkpad laptops.
One (T510) worked perfectly, except that I could not turn off the touchpad, until told that Fn+F8 did this (permanently, to my surprise).
The second (T61) lost WiFi after Fedup, which I have not been able to recover.
Kernel version?
I'd be happier if there were some evidence that the Fedup developers were keeping a note of problems.
It looks like a kernel driver issue and not a Fedup issue. If the machine boots after the upgrade and your RPM DB is sane, Fedup did its job.
Reference to user experience is not one of Fedora's strong points.
I doubt that this attitude is productive...
- Gilboa
Le 25/12/2014 19:04, Gilboa Davara a écrit :
On Mon, Dec 22, 2014 at 1:20 PM, Tony Camuso tcamuso@redhat.com wrote:
Updated from F20 to F21 on two systems, one a VM, the other bare metal. Used nonproduct to accommodate customizations.
Had zero problems.
In the past couple of weeks I've upgraded ~20 physical machines (ranging from low-end laptops to high-end 4S servers) and more than 20 VMs (32bit and 64bit) to Fedora 21 with near zero issues (some had missing kernel modules 3.17.4-30*, but a simple update + adding kernel-modules-extra solved it. I still have issue getting bumblebee to work on two laptops, but its not urgent [IGP works just fine], so I'm ignoring it for now...).
All in all, a *very* solid release. Congrats to the Fedora team and to all involved.
- Gilboa
I didn't get any problem during and after the upgrade. Very good release, i agree !
Thanks from France ;)
On 12/25/2014 06:08 PM, Tim wrote:
On Wed, 2014-12-24 at 07:07 +1100, Stephen Morris wrote:
Fedora, in my opinion have stupidly, made the debug kernel version the default kernel (and I haven't found any info from net searches on how to change this so that with any future upgrades of the kernel the default kernel will always be the non-debug version.
Is Fedora 21 still using /etc/default/grub for regenerating each grub menu? If so, change the GRUB_DEFAULT= clause to your preference, then regenerate the config file.
[tim@fluffy ~]$ cat /etc/default/grub GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="vconsole.font=latarcyrheb-sun16 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) quiet" GRUB_DISABLE_RECOVERY="true"
Thanks for the reply Tim. F21 is still using /etc/default/grub and I have GRUB_DEFAULT=saved in that file already, but it makes no difference. All that parameter seems to do is write the kernel file name out to an external file and does not change the top level kernel entry in grub.cfg nor in the mbr. I don't understand enough about the script files used by grub to determine how the script settles on the debug kernel as the default, other than when you issue ls /boot the debug kernel is the last one listed.
regards, Steve
On Fri, 2014-12-26 at 09:04 +1100, Stephen Morris wrote:
Thanks for the reply Tim. F21 is still using /etc/default/grub and I have GRUB_DEFAULT=saved in that file already, but it makes no difference.
It should mean "boot the same as last time," so whenever you pick an entry from the list, the same one gets used, each boot, until you pick differently.
There may need to be another keyword, elsewhere, to make each selection get saved (GRUB_DEFAULT=saved just says to use it), but I'm not familiar enough with the new GRUB.
Alternatively, changed =saved to point to a specific kernel.
You need to study the manual, come back to the list with any questions about things you can't understand.
On Thu, Dec 25, 2014 at 9:15 PM, Tim ignored_mailbox@yahoo.com.au wrote:
On Fri, 2014-12-26 at 09:04 +1100, Stephen Morris wrote:
Thanks for the reply Tim. F21 is still using /etc/default/grub and I have GRUB_DEFAULT=saved in that file already, but it makes no difference.
It should mean "boot the same as last time," so whenever you pick an entry from the list, the same one gets used, each boot, until you pick differently.
That behavior also requires GRUB_SAVEDEFAULT='true'. By itself, GRUB_DEFAULT=saved merely causes grubenv to be consulted for what to boot rather than it being statically defined in the grub.cfg.
There may need to be another keyword, elsewhere, to make each selection get saved (GRUB_DEFAULT=saved just says to use it), but I'm not familiar enough with the new GRUB.
Alternatively, changed =saved to point to a specific kernel.
Look at the grub.cfg and find the menuentry you want:
menuentry 'Fedora, with Linux 3.17.4-301.fc21.x86_64' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.17.4-301.fc21.x86_64-advanced-f3332d09-65f9-48c5-8539-c2b9ec8c75b4' {
And copy-paste the last section, using it in this command:
grub2-set-default 'gnulinux-3.17.4-301.fc21.x86_64-advanced-f3332d09-65f9-48c5-8539-c2b9ec8c75b4'
Or set it as GRUB_DEFAULT= in /etc/default/grub and the make a new grub.cfg with grub2-mkconfig -o /boot/grub2/grub.cfg
You need to study the manual, come back to the list with any questions about things you can't understand.
It might be helpful but I see it mainly targeted at developers who are boot and OS install oriented. It's not really an end user manual, and grub isn't really meant for interaction by users.
On 12/26/2014 05:13 PM, Chris Murphy wrote:
On Thu, Dec 25, 2014 at 9:15 PM, Tim ignored_mailbox@yahoo.com.au wrote:
On Fri, 2014-12-26 at 09:04 +1100, Stephen Morris wrote:
Thanks for the reply Tim. F21 is still using /etc/default/grub and I have GRUB_DEFAULT=saved in that file already, but it makes no difference.
It should mean "boot the same as last time," so whenever you pick an entry from the list, the same one gets used, each boot, until you pick differently.
That behavior also requires GRUB_SAVEDEFAULT='true'. By itself, GRUB_DEFAULT=saved merely causes grubenv to be consulted for what to boot rather than it being statically defined in the grub.cfg.
There may need to be another keyword, elsewhere, to make each selection get saved (GRUB_DEFAULT=saved just says to use it), but I'm not familiar enough with the new GRUB.
Alternatively, changed =saved to point to a specific kernel.
Look at the grub.cfg and find the menuentry you want:
menuentry 'Fedora, with Linux 3.17.4-301.fc21.x86_64' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.17.4-301.fc21.x86_64-advanced-f3332d09-65f9-48c5-8539-c2b9ec8c75b4' {
And copy-paste the last section, using it in this command:
grub2-set-default 'gnulinux-3.17.4-301.fc21.x86_64-advanced-f3332d09-65f9-48c5-8539-c2b9ec8c75b4'
Or set it as GRUB_DEFAULT= in /etc/default/grub and the make a new grub.cfg with grub2-mkconfig -o /boot/grub2/grub.cfg
You need to study the manual, come back to the list with any questions about things you can't understand.
It might be helpful but I see it mainly targeted at developers who are boot and OS install oriented. It's not really an end user manual, and grub isn't really meant for interaction by users.
Thanks for your response Chris, the only problem with that is that command is needed to be issued every time the kernel is upgraded. What I am looking for is a method whereby, if with the next kernel upgrade, there is an upgrade to the debug kernel and an upgrade to the non-debug kernel, grub will select the non-debug kernel automatically rather than the debug kernel as seems to be happening with the F21 upgrade.
regards, Steve
On 12/29/2014 07:19 AM, Stephen Morris wrote:
On 12/26/2014 05:13 PM, Chris Murphy wrote:
On Thu, Dec 25, 2014 at 9:15 PM, Tim ignored_mailbox@yahoo.com.au wrote:
On Fri, 2014-12-26 at 09:04 +1100, Stephen Morris wrote:
Thanks for the reply Tim. F21 is still using /etc/default/grub and I have GRUB_DEFAULT=saved in that file already, but it makes no difference.
It should mean "boot the same as last time," so whenever you pick an entry from the list, the same one gets used, each boot, until you pick differently.
That behavior also requires GRUB_SAVEDEFAULT='true'. By itself, GRUB_DEFAULT=saved merely causes grubenv to be consulted for what to boot rather than it being statically defined in the grub.cfg.
There may need to be another keyword, elsewhere, to make each selection get saved (GRUB_DEFAULT=saved just says to use it), but I'm not familiar enough with the new GRUB.
Alternatively, changed =saved to point to a specific kernel.
Look at the grub.cfg and find the menuentry you want:
menuentry 'Fedora, with Linux 3.17.4-301.fc21.x86_64' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.17.4-301.fc21.x86_64-advanced-f3332d09-65f9-48c5-8539-c2b9ec8c75b4'
{
And copy-paste the last section, using it in this command:
grub2-set-default 'gnulinux-3.17.4-301.fc21.x86_64-advanced-f3332d09-65f9-48c5-8539-c2b9ec8c75b4'
Or set it as GRUB_DEFAULT= in /etc/default/grub and the make a new grub.cfg with grub2-mkconfig -o /boot/grub2/grub.cfg
You need to study the manual, come back to the list with any questions about things you can't understand.
It might be helpful but I see it mainly targeted at developers who are boot and OS install oriented. It's not really an end user manual, and grub isn't really meant for interaction by users.
Thanks for your response Chris, the only problem with that is that command is needed to be issued every time the kernel is upgraded. What I am looking for is a method whereby, if with the next kernel upgrade, there is an upgrade to the debug kernel and an upgrade to the non-debug kernel, grub will select the non-debug kernel automatically rather than the debug kernel as seems to be happening with the F21 upgrade.
I specified GRUB_SAVEDEFAULT='true' and that seemed to work great. Now all that remains is to determine, why F21 has settled on the debug kernel as the default if F21 isn't still Beta, why grub doesn't honour resolution settings as F20 grub did, why plymouth no longer works properly in F21 or like it did in F20, why the nvidia source code modules don't compile at boot time when needed and why if there is no ethernet available and wireless is switched off the KDE desktop does not start properly.
regards, Steve
regards, Steve