Greetings,
Because F17 and F18 installers have bugs when installing with encryption enabled for "/" on my notebook (and the F18 respin does not start installation at all) I decided to give F19-alpha a try.
However, the system runs very slow (compared to F17 on the same notebook) - XOrg performs poorly and larger applications (firefox) take a lot more time for startup than on F17.
I guess this is because of debugging options (run-time checks etc) enabled. Is there any way to avoid this additional debugging overhead somehow, like some kernel parameters or ....
Thx, Regina
On 04/24/13 21:58, Regina Anger wrote:
Greetings,
Because F17 and F18 installers have bugs when installing with encryption enabled for "/" on my notebook (and the F18 respin does not start installation at all) I decided to give F19-alpha a try.
However, the system runs very slow (compared to F17 on the same notebook) - XOrg performs poorly and larger applications (firefox) take a lot more time for startup than on F17.
I guess this is because of debugging options (run-time checks etc) enabled. Is there any way to avoid this additional debugging overhead somehow, like some kernel parameters or ....
Yes, it has been mentioned on the "test" list several times. It has been suggested to try adding 'slub_debug=-' to the kernel parameters.
On 04/24/2013 07:58 AM, Regina Anger wrote:
Greetings,
Because F17 and F18 installers have bugs when installing with encryption enabled for "/" on my notebook (and the F18 respin does not start installation at all) I decided to give F19-alpha a try.
However, the system runs very slow (compared to F17 on the same notebook) - XOrg performs poorly and larger applications (firefox) take a lot more time for startup than on F17.
I guess this is because of debugging options (run-time checks etc) enabled. Is there any way to avoid this additional debugging overhead somehow, like some kernel parameters or ....
Thx, Regina
I decided to run Fedora 19 Alpha and while I am not experiencing slowness but am experiencing problems with network manager. I have a dual band router and it won't connect to 5g network.
On Wed, 2013-04-24 at 15:58 +0200, Regina Anger wrote:
Greetings,
Because F17 and F18 installers have bugs when installing with encryption enabled for "/" on my notebook (and the F18 respin does not start installation at all) I decided to give F19-alpha a try.
However, the system runs very slow (compared to F17 on the same notebook) - XOrg performs poorly and larger applications (firefox) take a lot more time for startup than on F17.
I guess this is because of debugging options (run-time checks etc) enabled. Is there any way to avoid this additional debugging overhead somehow, like some kernel parameters or ....
Could people please remember to discuss F19 on the *Test* list, not on Users. Many of the people who can help you do not even read the Users list.
poc
On 24.04.2013 16:17, Regina Anger wrote:
Hello Ed,
Yes, it has been mentioned on the "test" list several times. It has been suggested to try adding 'slub_debug=-' to the kernel parameters.
Thx a lot, works now like a charme :)
https://fedoraproject.org/wiki/KernelDebugStrategy
poma
On 04/24/2013 05:55 PM, poma wrote:
On 24.04.2013 16:17, Regina Anger wrote:
Hello Ed,
Yes, it has been mentioned on the "test" list several times. It has been suggested to try adding 'slub_debug=-' to the kernel parameters.
Thx a lot, works now like a charme :)
Excuse my ignorance but how do you set the kernel parameters for 'slug_debug_' (.i.e in which file or whereabouts)?
Cheers,
Phil...
Am 24.04.2013 23:21, schrieb Phil Dobbin:
On 04/24/2013 05:55 PM, poma wrote:
On 24.04.2013 16:17, Regina Anger wrote:
Hello Ed,
Yes, it has been mentioned on the "test" list several times. It has been suggested to try adding 'slub_debug=-' to the kernel parameters.
Thx a lot, works now like a charme :)
Excuse my ignorance but how do you set the kernel parameters for 'slug_debug_' (.i.e in which file or whereabouts)?
as any other kernel-param in /boot/grub2/grub.cfg and /etc/default/grub while the latter is what will be used by grub2-mkconfig
On 04/24/2013 10:31 PM, Reindl Harald wrote:
Am 24.04.2013 23:21, schrieb Phil Dobbin:
On 04/24/2013 05:55 PM, poma wrote:
On 24.04.2013 16:17, Regina Anger wrote:
Hello Ed,
Yes, it has been mentioned on the "test" list several times. It has been suggested to try adding 'slub_debug=-' to the kernel parameters.
Thx a lot, works now like a charme :)
Excuse my ignorance but how do you set the kernel parameters for 'slug_debug_' (.i.e in which file or whereabouts)?
as any other kernel-param in /boot/grub2/grub.cfg and /etc/default/grub while the latter is what will be used by grub2-mkconfig
Thanks for that.
Cheers,
Phil...
On 04/24/2013 02:31 PM, Reindl Harald wrote:
as any other kernel-param in /boot/grub2/grub.cfg and /etc/default/grub while the latter is what will be used by grub2-mkconfig
Checking, my /etc/default/grub contains SYSFONT=True and I'm wondering why I see the error message about the font True not being found. If so, can I simply edit that out and rebuild /boot/grub2.grub.cfg?
Allegedly, on or about 24 April 2013, Joe Zeff sent:
Checking, my /etc/default/grub contains SYSFONT=True and I'm wondering why I see the error message about the font True not being found. If so, can I simply edit that out and rebuild /boot/grub2.grub.cfg?
I've never seen the associated errors people have discussed regarding SYSFONT=True (i.e. stalled boots). My /boot/grub2.grub.cfg file has always had:
SYSFONT=latarcyrheb-sun16
in the kernel parameters, as far as I'm aware, yet my /etc/default/grub file contains:
GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=True KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 quiet"
I don't recall if it's always been like that, or whether it had ever changed. The only change that I've made to it, was to remove rhgb from near the end of the list, though I've not yet installed a new kernel, for that change to propagate through. So, if the SYSFONT=True has been a recent change behind the scenes, I don't know what did it. It's owned by grub2-tools, and that's install date is well before the last kernel update.
My kernel updates get installed along with other software updates when I periodically do "yum update" on the command line, and they manage that all by themselves - I don't have to do anything else, by hand, to deal with kernel updates, like some people have mentioned.
On a related note, looking up SYSFONT=True came up with a bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=799401 which mentioned looking for a SYSFONT=True in /etc/sysconfig/i18n, but I don't see it there, either. Mine's simply:
LANG="en_AU.UTF-8" SYSFONT="latarcyrheb-sun16"
I was beginning to wonder whether the defaults/grub file was supposed to mention a specific font file, as a verbose list of what commands to put on the kernel line, or just set a flag regarding where to get font details from.
On 24.04.2013 23:21, Phil Dobbin wrote:
On 04/24/2013 05:55 PM, poma wrote:
On 24.04.2013 16:17, Regina Anger wrote:
Hello Ed,
Yes, it has been mentioned on the "test" list several times. It has been suggested to try adding 'slub_debug=-' to the kernel parameters.
Thx a lot, works now like a charme :)
Excuse my ignorance but how do you set the kernel parameters for 'slug_debug_' (.i.e in which file or whereabouts)?
Cheers,
Phil...
'slug_debug_'!? :)
https://www.kernel.org/doc/Documentation/vm/slub.txt … In order to switch debugging on one can add a option "slub_debug" to the kernel command line. That will enable full debugging for all slabs. …
The files in question depends on the boot loader used. ;) i.e. Syslinux - /boot/syslinux/syslinux.cfg GRUB(2) - /boot/grub/grub.cfg - grubby - /boot/grub/grub.cfg & /etc/default/grub - grub(2)-mkconfig
poma
On 04/24/2013 10:19 PM, Tim wrote:
I've never seen the associated errors people have discussed regarding SYSFONT=True (i.e. stalled boots).
I've not seen any problems either, on my desktop. My laptop, however, complains about it every time I boot. So far, it hasn't seemed to make a difference, but getting rid of the spurious error message would be nice.
Am 25.04.2013 01:25, schrieb Joe Zeff:
On 04/24/2013 02:31 PM, Reindl Harald wrote:
as any other kernel-param in /boot/grub2/grub.cfg and /etc/default/grub while the latter is what will be used by grub2-mkconfig
Checking, my /etc/default/grub contains SYSFONT=True and I'm wondering why I see the error message about the font True not being found. If so, can I simply edit that out and rebuild /boot/grub2.grub.cfg?
surely, you even can fix /boot/grub2.grub.cfg at it own as grubby does at kernel updates without calling grub2-mkconfig and taint the menu
On Apr 24, 2013 2:31 PM, "Reindl Harald" h.reindl@thelounge.net wrote:
Am 24.04.2013 23:21, schrieb Phil Dobbin:
On 04/24/2013 05:55 PM, poma wrote:
On 24.04.2013 16:17, Regina Anger wrote:
Hello Ed,
Yes, it has been mentioned on the "test" list several times. It has been suggested to try adding 'slub_debug=-' to the kernel
parameters.
Thx a lot, works now like a charme :)
Excuse my ignorance but how do you set the kernel parameters for 'slug_debug_' (.i.e in which file or whereabouts)?
as any other kernel-param in /boot/grub2/grub.cfg and /etc/default/grub while the latter is what will be used by grub2-mkconfig
--
I feel the needs to ask a question here: I did a fedup to f19 and didn't have an option to boot into it on grub; ought I have added the a link to the new kernel? I went to do this, but none of the files in grub2 look like the "splash-page" on boot, and I'm still on the "stable" - or non-alpha - kernel.
My choose of what happened is up here under "fedup"
On Thu, 2013-04-25 at 10:44 -0700, Richard Vickery wrote:
I feel the needs to ask a question here: I did a fedup to f19 and didn't have an option to boot into it on grub; ought I have added the a link to the new kernel? I went to do this, but none of the files in grub2 look like the "splash-page" on boot, and I'm still on the "stable" - or non-alpha - kernel.
Why do you keep asking about F19 on the wrong list?
poc
On Thu, Apr 25, 2013 at 11:18 AM, Patrick O'Callaghan <pocallaghan@gmail.com
wrote:
On Thu, 2013-04-25 at 10:44 -0700, Richard Vickery wrote:
I feel the needs to ask a question here: I did a fedup to f19 and didn't have an option to boot into it on grub; ought I have added the a link to the new kernel? I went to do this, but none of the files in grub2 look like the "splash-page" on boot, and I'm still on the "stable" - or non-alpha - kernel.
Why do you keep asking about F19 on the wrong list?
poc
--
Because I, like many other general, non-tech users out here on the
internet who don't understand the lists, am ignorant. This is why I continue asking on the wrong list. If you want to be more helpful, it might be possible to take this question and post it to the correct list.
Frankly, I don't exactly know where this exact list is, and not being on that list, it is impossible both to get a reply AND to get mail that I replied to, such as I did here. I know how governments, courts, legislation, and such things work, not mailing lists. Do I not have to be on this other list in order to ask something from other's on said list, let alone get a reply?
On Thu, Apr 25, 2013 at 13:12:43 -0700, Richard Vickery richard.vickeryrv@gmail.com wrote:
Frankly, I don't exactly know where this exact list is, and not being on that list, it is impossible both to get a reply AND to get mail that I replied to, such as I did here. I know how governments, courts, legislation, and such things work, not mailing lists. Do I not have to be on this other list in order to ask something from other's on said list, let alone get a reply?
It works a lot smoother if you are subscribed to the test list. If you are seriously running systems on rawhide or branched, it is recommended that you be subscribed to the test list.
Some of Fedora's lists are moderated and posts by non-members will eventually get released if appropriate. Some lists add reply-to headers and others don't. On the ones that don't add reply-to headers, you might get copied on replies, depending on who is replying.
Around 09:12pm on Thursday, April 25, 2013 (UK time), Richard Vickery scrawled:
Because I, like many other general, non-tech users out here on the internet who don't understand the lists, am ignorant. This is why I continue asking on the wrong list. If you want to be more helpful, it might be possible to take this question and post it to the correct list.
Frankly, I don't exactly know where this exact list is, and not being on that list, it is impossible both to get a reply AND to get mail that I replied to, such as I did here. I know how governments, courts, legislation, and such things work, not mailing lists. Do I not have to be on this other list in order to ask something from other's on said list, let alone get a reply?
On the page where you subscribed to the mailing list it clearly states "Discussion of test releases (alpha, beta, rawhide) should be directed to the test list"
You don't need to be a technical user (whatever that is) to understand this.
Mailing list page: https://lists.fedoraproject.org/mailman/listinfo/users
Steve
On 04/25/2013 01:12 PM, Richard Vickery issued this missive:
On Thu, Apr 25, 2013 at 11:18 AM, Patrick O'Callaghan <pocallaghan@gmail.com mailto:pocallaghan@gmail.com> wrote:
On Thu, 2013-04-25 at 10:44 -0700, Richard Vickery wrote: > I feel the needs to ask a question here: I did a fedup to f19 and > didn't > have an option to boot into it on grub; ought I have added the a link > to > the new kernel? I went to do this, but none of the files in grub2 look > like > the "splash-page" on boot, and I'm still on the "stable" - or > non-alpha - > kernel. Why do you keep asking about F19 on the wrong list? poc --Because I, like many other general, non-tech users out here on the internet who don't understand the lists, am ignorant. This is why I continue asking on the wrong list. If you want to be more helpful, it might be possible to take this question and post it to the correct list.
The correct list for pre-release variants of Fedora (e.g. F19) is "test@lists.fedoraproject.org" (a.k.a. "The Fedora Test List"). You have to join that list in the same manner as you joined this list.
All discussions about pre-released software (e.g. "F19", "rawhide", even updates of code for existing releases) occur on that list. Once F19 (or an updated RPM for an existing package) is released, then discussions regarding that released code shift over to THIS list.
In answer to your other question, grub2 is the default boot for F19 and grub2 looks a lot different than grub did. The fedup operation makes your system F19 and hence you aren't offered the old grub stuff. Also, being on F19 prevents us from answering a lot of your questions since most people on this list don't use F19 (yet).
I belong to both lists (test and users). I have an F19 machine for experimental purposes, but I'm not a seasoned F19 user. Some other members of this list are also members of test, but the reverse is certainly NOT true (most test members never even look at this list). ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - You can lead a horse to water, but if you can teach him to roll - - over and float on his back...you got something! - ----------------------------------------------------------------------
On Thu, Apr 25, 2013 at 1:46 PM, Rick Stevens ricks@alldigital.com wrote:
Because I, like many other general, non-tech users out here on the internet who don't understand the lists, am ignorant. This is why I continue asking on the wrong list. If you want to be more helpful, it might be possible to take this question and post it to the correct list.
The correct list for pre-release variants of Fedora (e.g. F19) is "test@lists.fedoraproject.org" (a.k.a. "The Fedora Test List"). You have to join that list in the same manner as you joined this list.
All discussions about pre-released software (e.g. "F19", "rawhide", even updates of code for existing releases) occur on that list. Once F19 (or an updated RPM for an existing package) is released, then discussions regarding that released code shift over to THIS list.
In answer to your other question, grub2 is the default boot for F19 and grub2 looks a lot different than grub did. The fedup operation makes your system F19 and hence you aren't offered the old grub stuff. Also, being on F19 prevents us from answering a lot of your questions since most people on this list don't use F19 (yet).
I belong to both lists (test and users). I have an F19 machine for experimental purposes, but I'm not a seasoned F19 user. Some other members of this list are also members of test, but the reverse is certainly NOT true (most test members never even look at this list). ------------------------------**------------------------------**----------
- Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
-- You can lead a horse to water, but if you can teach him to roll -
over and float on his back...you got something! -------------------------------**------------------------------**----------
Thank you! An answer I can reply happily with / to, rather than thinking that, unlike what the website says, this group is not so helpful.
If I am on the alpha program, why am I on 3.7x rather than 3.8x?
$ uname -rsvp Linux 3.7.2-204.fc18.x86_64 #1 SMP Wed Jan 16 16:22:52 UTC 2013 x86_64
Thanks,
On 04/25/2013 02:04 PM, Richard Vickery issued this missive:
On Thu, Apr 25, 2013 at 1:46 PM, Rick Stevens <ricks@alldigital.com mailto:ricks@alldigital.com> wrote:
Because I, like many other general, non-tech users out here on the internet who don't understand the lists, am ignorant. This is why I continue asking on the wrong list. If you want to be more helpful, it might be possible to take this question and post it to the correct list. The correct list for pre-release variants of Fedora (e.g. F19) is "test@lists.fedoraproject.org <mailto:test@lists.fedoraproject.org>" (a.k.a. "The Fedora Test List"). You have to join that list in the same manner as you joined this list. All discussions about pre-released software (e.g. "F19", "rawhide", even updates of code for existing releases) occur on that list. Once F19 (or an updated RPM for an existing package) is released, then discussions regarding that released code shift over to THIS list. In answer to your other question, grub2 is the default boot for F19 and grub2 looks a lot different than grub did. The fedup operation makes your system F19 and hence you aren't offered the old grub stuff. Also, being on F19 prevents us from answering a lot of your questions since most people on this list don't use F19 (yet). I belong to both lists (test and users). I have an F19 machine for experimental purposes, but I'm not a seasoned F19 user. Some other members of this list are also members of test, but the reverse is certainly NOT true (most test members never even look at this list). ------------------------------__------------------------------__---------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com <mailto:ricks@alldigital.com> - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - You can lead a horse to water, but if you can teach him to roll - - over and float on his back...you got something! - ------------------------------__------------------------------__----------Thank you! An answer I can reply happily with / to, rather than thinking that, unlike what the website says, this group is not so helpful.
If I am on the alpha program, why am I on 3.7x rather than 3.8x?
Ok, that's one we can probably handle. You can run newer systems on older kernels (many people do). It's not recommended but sometimes necessary if, for example, you have older hardware that newer kernels have orphaned for some reason.
The odds are that you have an option in your yum configuration that blocks upgrades in kernels (although I'd expect fedup to bypass that somehow). Look in your various /etc/yum* files and see if you have an "exclude=kernel*" thing in there. Quick check (as root):
# cd /etc # grep -R exclude yum*
Look for "exclude=" lines that aren't commented out. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - I doubt, therefore I might be. - ----------------------------------------------------------------------
On 04/25/2013 02:04 PM, Richard Vickery wrote:
Thank you! An answer I can reply happily with / to, rather than thinking that, unlike what the website says, this group is not so helpful.
As a matter of fact, this group has done everything it could to help you. It's repeatedly told you where you need to ask your questions, but up until now, you haven't accepted the fact that you're asking in the wrong place.
On Apr 25, 2013 2:22 PM, "Rick Stevens" ricks@alldigital.com wrote:
On 04/25/2013 02:04 PM, Richard Vickery issued this missive:
On Thu, Apr 25, 2013 at 1:46 PM, Rick Stevens <ricks@alldigital.com mailto:ricks@alldigital.com> wrote:
Because I, like many other general, non-tech users out here on
the
internet who don't understand the lists, am ignorant. This is
why I
continue asking on the wrong list. If you want to be more helpful, it might be possible to take this question and post it to the correct list. The correct list for pre-release variants of Fedora (e.g. F19) is "test@lists.fedoraproject.org <mailto:test@lists.fedoraproject.org>" (a.k.a. "The Fedora Test List"). You have to join that list in the same manner as you joined this list. All discussions about pre-released software (e.g. "F19", "rawhide", even updates of code for existing releases) occur on that list. Once F19 (or an updated RPM for an existing package) is released, then discussions regarding that released code shift over to THIS list. In answer to your other question, grub2 is the default boot for F19
and
grub2 looks a lot different than grub did. The fedup operation makes your system F19 and hence you aren't offered the old grub stuff.
Also,
being on F19 prevents us from answering a lot of your questions since most people on this list don't use F19 (yet). I belong to both lists (test and users). I have an F19 machine for experimental purposes, but I'm not a seasoned F19 user. Some other members of this list are also members of test, but the reverse is certainly NOT true (most test members never even look at this list).
------------------------------__------------------------------__----------
- Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com <mailto:ricks@alldigital.com> - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2
-
-
-
- You can lead a horse to water, but if you can teach him to roll
-
- over and float on his back...you got something!
-
------------------------------__------------------------------__----------
Thank you! An answer I can reply happily with / to, rather than thinking that, unlike what the website says, this group is not so helpful.
If I am on the alpha program, why am I on 3.7x rather than 3.8x?
Ok, that's one we can probably handle. You can run newer systems on older kernels (many people do). It's not recommended but sometimes necessary if, for example, you have older hardware that newer kernels have orphaned for some reason.
The odds are that you have an option in your yum configuration that blocks upgrades in kernels (although I'd expect fedup to bypass that somehow). Look in your various /etc/yum* files and see if you have an "exclude=kernel*" thing in there. Quick check (as root):
# cd /etc # grep -R exclude yum*Look for "exclude=" lines that aren't commented
I don't get anything.
On 04/25/2013 02:25 PM, Joe Zeff issued this missive:
On 04/25/2013 02:04 PM, Richard Vickery wrote:
Thank you! An answer I can reply happily with / to, rather than thinking that, unlike what the website says, this group is not so helpful.
As a matter of fact, this group has done everything it could to help you. It's repeatedly told you where you need to ask your questions, but up until now, you haven't accepted the fact that you're asking in the wrong place.
Joe,
I think that many of the responses Richard received read as "you're asking the wrong list, go away and ask on the correct list" without ever telling him what the correct list WAS. Nor was it ever explained to him where things would migrate between the "test" and "user" lists. I've been on various RHEL and Fedora lists for upwards of ten years and it can be confusing to me! But I'm an old fart and forget things.
To be honest, looking over the thread, some of the responses were also worded in a, shall we say, less than friendly manner? This list really exists to help people. No, we don't know all the answers, and yes, sometimes we get snarky, but that should be the exception rather than the rule. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - I never drink water because of the disgusting things that fish do - - in it. - - -- WC. Fields - ----------------------------------------------------------------------
On 04/25/2013 02:38 PM, Richard Vickery issued this missive:
On Apr 25, 2013 2:22 PM, "Rick Stevens" <ricks@alldigital.com mailto:ricks@alldigital.com> wrote:
On 04/25/2013 02:04 PM, Richard Vickery issued this missive:
On Thu, Apr 25, 2013 at 1:46 PM, Rick Stevens <ricks@alldigital.com
<mailto:ricks@alldigital.com mailto:ricks@alldigital.com>> wrote:
Because I, like many other general, non-tech users out hereon the
internet who don't understand the lists, am ignorant. Thisis why I
continue asking on the wrong list. If you want to be more helpful, it might be possible to take this question and post it to the correct list. The correct list for pre-release variants of Fedora (e.g. F19) is "test@lists.fedoraproject.orgmailto:test@lists.fedoraproject.org <mailto:test@lists.fedoraproject.org mailto:test@lists.fedoraproject.org>"
(a.k.a. "The Fedora Test List"). You have to join that list in the same manner as you joined this list. All discussions about pre-released software (e.g. "F19", "rawhide", even updates of code for existing releases) occur on that list. Once F19 (or an updated RPM for an existing package) is released, then discussions regarding that released code shift over to THIS list. In answer to your other question, grub2 is the default boot forF19 and
grub2 looks a lot different than grub did. The fedup operation makes your system F19 and hence you aren't offered the old grub stuff.Also,
being on F19 prevents us from answering a lot of your questionssince
most people on this list don't use F19 (yet). I belong to both lists (test and users). I have an F19 machine for experimental purposes, but I'm not a seasoned F19 user. Some other members of this list are also members of test, but the reverse is certainly NOT true (most test members never even look at this list).------------------------------__------------------------------__----------
- Rick Stevens, Systems Engineer, AllDigitalricks@alldigital.com mailto:ricks@alldigital.com
<mailto:ricks@alldigital.com <mailto:ricks@alldigital.com>> - - AIM/Skype: therps2 ICQ: 22643734 Yahoo:origrps2 -
--- You can lead a horse to water, but if you can teach him toroll -
- over and float on his back...you got something!-------------------------------__------------------------------__----------
Thank you! An answer I can reply happily with / to, rather than thinking that, unlike what the website says, this group is not so helpful.
If I am on the alpha program, why am I on 3.7x rather than 3.8x?
Ok, that's one we can probably handle. You can run newer systems on older kernels (many people do). It's not recommended but sometimes necessary if, for example, you have older hardware that newer kernels have orphaned for some reason.
The odds are that you have an option in your yum configuration that blocks upgrades in kernels (although I'd expect fedup to bypass that somehow). Look in your various /etc/yum* files and see if you have an "exclude=kernel*" thing in there. Quick check (as root):
# cd /etc # grep -R exclude yum*Look for "exclude=" lines that aren't commented
I don't get anything.
Hmmm, that's interesting. If you try to update your kernel specifically in a trial, what sort of messages do you get? You can try (as root):
# yum update kernel*
and see if you get any indications that something's being blocked. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - A squeegee, by any other name, wouldn't sound as funny. - ----------------------------------------------------------------------
On 04/25/2013 11:04 PM, Richard Vickery wrote:
Thank you! An answer I can reply happily with / to, rather than thinking that, unlike what the website says, this group is not so helpful.
If I am on the alpha program, why am I on 3.7x rather than 3.8x?
$ uname -rsvp Linux 3.7.2-204.fc18.x86_64 #1 SMP Wed Jan 16 16:22:52 UTC 2013 x86_64
Not sure what you mean by the "alpha program" but if you expect to be on F19 Alpha (note the *19*) then look again at the output of the command you gave. It says F18 (note the *18*). So that box is running F18 and not F19 alpha. And that is also the reason why it has kernel 3.7.x and not kernel 3.8.x. Or did I miss something?
Regards, Patrick
On 04/25/2013 03:10 PM, Patrick Lists issued this missive:
On 04/25/2013 11:04 PM, Richard Vickery wrote:
Thank you! An answer I can reply happily with / to, rather than thinking that, unlike what the website says, this group is not so helpful.
If I am on the alpha program, why am I on 3.7x rather than 3.8x?
$ uname -rsvp Linux 3.7.2-204.fc18.x86_64 #1 SMP Wed Jan 16 16:22:52 UTC 2013 x86_64
Not sure what you mean by the "alpha program" but if you expect to be on F19 Alpha (note the *19*) then look again at the output of the command you gave. It says F18 (note the *18*). So that box is running F18 and not F19 alpha. And that is also the reason why it has kernel 3.7.x and not kernel 3.8.x. Or did I miss something?
Patrick,
Richard claims to have "fedup"ped to F19. The kernel remains F18 and an old F18 kernel at that (I've got several F17 boxes with 3.8.4-102.fc17.x86_64 kernels). My suspicion was that a yum config is blocking a kernel update.
Richard, can you check the output of "cat /etc/issue" and verify that your machine really thinks it's F19? ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Hard work has a future payoff. Laziness pays off now. - ----------------------------------------------------------------------
On Thu, Apr 25, 2013 at 2:48 PM, Rick Stevens ricks@alldigital.com wrote:
On 04/25/2013 02:38 PM, Richard Vickery issued this missive:
On Apr 25, 2013 2:22 PM, "Rick Stevens" <ricks@alldigital.com mailto:ricks@alldigital.com> wrote:
On 04/25/2013 02:04 PM, Richard Vickery issued this missive:
On Thu, Apr 25, 2013 at 1:46 PM, Rick Stevens <ricks@alldigital.com
<mailto:ricks@alldigital.com mailto:ricks@alldigital.com>**> wrote:
Because I, like many other general, non-tech users out hereon the
internet who don't understand the lists, am ignorant. Thisis why I
continue asking on the wrong list. If you want to be more helpful, it might be possible to take this question and post it to the correct list. The correct list for pre-release variants of Fedora (e.g. F19) is "test@lists.fedoraproject.org<mailto:test@lists.**fedoraproject.org test@lists.fedoraproject.org> <mailto:test@lists.**fedoraproject.org test@lists.fedoraproject.org<mailto: test@lists.**fedoraproject.org test@lists.fedoraproject.org>>"
(a.k.a. "The Fedora Test List"). You have to join that list in the same manner as you joined this list. All discussions about pre-released software (e.g. "F19","rawhide",
even updates of code for existing releases) occur on that list.Once
F19 (or an updated RPM for an existing package) is released, then discussions regarding that released code shift over to THIS list. In answer to your other question, grub2 is the default boot forF19 and
grub2 looks a lot different than grub did. The fedup operationmakes
your system F19 and hence you aren't offered the old grub stuff.Also,
being on F19 prevents us from answering a lot of your questionssince
most people on this list don't use F19 (yet). I belong to both lists (test and users). I have an F19 machine for experimental purposes, but I'm not a seasoned F19 user. Some other members of this list are also members of test, but the reverse is certainly NOT true (most test members never even look at thislist).
------------------------------**__----------------------------** --__----------
- Rick Stevens, Systems Engineer, AllDigitalricks@alldigital.com mailto:ricks@alldigital.com
<mailto:ricks@alldigital.com <mailto:ricks@alldigital.com>> -- AIM/Skype: therps2 ICQ: 22643734 Yahoo:origrps2 -
--- You can lead a horse to water, but if you can teach him toroll -
- over and float on his back...you got something!-------------------------------**__----------------------------** --__----------
Thank you! An answer I can reply happily with / to, rather than
thinking
that, unlike what the website says, this group is not so helpful.
If I am on the alpha program, why am I on 3.7x rather than 3.8x?
Ok, that's one we can probably handle. You can run newer systems on older kernels (many people do). It's not recommended but sometimes necessary if, for example, you have older hardware that newer kernels have orphaned for some reason.
The odds are that you have an option in your yum configuration that blocks upgrades in kernels (although I'd expect fedup to bypass that somehow). Look in your various /etc/yum* files and see if you have an "exclude=kernel*" thing in there. Quick check (as root):
# cd /etc # grep -R exclude yum*Look for "exclude=" lines that aren't commented
I don't get anything.
Hmmm, that's interesting. If you try to update your kernel specifically in a trial, what sort of messages do you get? You can try (as root):
# yum update kernel*and see if you get any indications that something's being blocked. ------------------------------**------------------------------**----------
- Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com -
Thanks Rick.
On Thu, Apr 25, 2013 at 02:21:18PM -0700, Rick Stevens wrote:
On 04/25/2013 02:04 PM, Richard Vickery issued this missive:
If I am on the alpha program, why am I on 3.7x rather than 3.8x?
[...chomp...chomp...chomp...]
The odds are that you have an option in your yum configuration that blocks upgrades in kernels (although I'd expect fedup to bypass that somehow). Look in your various /etc/yum* files and see if you have an "exclude=kernel*" thing in there. Quick check (as root):
That kernel is not correct even for an up to date F18 system.
$ uname -r 3.8.8-202.fc18.x86_64
I have a feeling something else is wrong. It would be helpful to know all the installed kernel packages. What are the outputs of the following commands?
$ rpm -q kernel | sort $ grep UPDATEDEFAULT /etc/sysconfig/kernel
On Thu, Apr 25, 2013 at 3:10 PM, Patrick Lists < fedora-list@puzzled.xs4all.nl> wrote:
On 04/25/2013 11:04 PM, Richard Vickery wrote:
Thank you! An answer I can reply happily with / to, rather than thinking that, unlike what the website says, this group is not so helpful.
If I am on the alpha program, why am I on 3.7x rather than 3.8x?
$ uname -rsvp Linux 3.7.2-204.fc18.x86_64 #1 SMP Wed Jan 16 16:22:52 UTC 2013 x86_64
Not sure what you mean by the "alpha program" but if you expect to be on F19 Alpha (note the *19*) then look again at the output of the command you gave. It says F18 (note the *18*). So that box is running F18 and not F19 alpha. And that is also the reason why it has kernel 3.7.x and not kernel 3.8.x. Or did I miss something?
Regards, Patrick
The command called was: sudo fedup-cli --network 19 --debuglog fedupdebug.log
On Thu, 2013-04-25 at 14:42 -0700, Rick Stevens wrote:
I think that many of the responses Richard received read as "you're asking the wrong list, go away and ask on the correct list" without ever telling him what the correct list WAS.
Rick
If you check back in the archives you'll see that I for one did specifically say that the OP should post on the Test list. IIRC it was in relation to another question he had a few days ago.
poc
On 04/26/2013 12:23 AM, Richard Vickery wrote: [snip]
The command called was: sudo fedup-cli --network 19 --debuglog fedupdebug.log
Right, sorry I missed that you tried a fedup. I'm afraid I don't have a solution. I never used fedup nor did an upgrade. I always do a clean install to prevent things like this from happening.
Regards, Patrick
Am 25.04.2013 23:04, schrieb Richard Vickery:
Thank you! An answer I can reply happily with / to, rather than thinking that, unlike what the website says, this group is not so helpful.
If I am on the alpha program, why am I on 3.7x rather than 3.8x?
$ uname -rsvp Linux 3.7.2-204.fc18.x86_64 #1 SMP Wed Jan 16 16:22:52 UTC 2013 x86_64
nobody knows why you do not update your kernel 3.7.x is old, EOL and lacking a lot of security fixes 3.8.x is in the stable repos for any supported release
3.8.8-203.fc18.x86_64 3.8.8-102.fc17.x86_64 3.9.0-0.rc8.git0.2.fc19.x86_64
Am 26.04.2013 01:03, schrieb Reindl Harald:
Am 25.04.2013 23:04, schrieb Richard Vickery:
Thank you! An answer I can reply happily with / to, rather than thinking that, unlike what the website says, this group is not so helpful.
If I am on the alpha program, why am I on 3.7x rather than 3.8x?
$ uname -rsvp Linux 3.7.2-204.fc18.x86_64 #1 SMP Wed Jan 16 16:22:52 UTC 2013 x86_64
nobody knows why you do not update your kernel 3.7.x is old, EOL and lacking a lot of security fixes 3.8.x is in the stable repos for any supported release
3.8.8-203.fc18.x86_64 3.8.8-102.fc17.x86_64 3.9.0-0.rc8.git0.2.fc19.x86_64
and if you updated you kernel / OS it is most likely in /boot/grub2/grub.cfg and by whatever error not as default
there is a line like set default="0" which can be modified or simply after select the newest kernel at boot a "yum reinstall kernel" after make sure the newest one works will remove any other kernel and with the next update all should be fine again, or simply use grub2-mkconfig -o /boot/grub2/grub.cf to re-generate the grub-config, at the begin without the -o param to take a look what would happen
but you can for sure select the kernel at boot
thanks to people who still thinks it is a good idea to hide the alternate kernels in the grub menu as default and force users to take action by pressing keys at the grub-stage of boot
hence to not use linux alpha-releases if you are not firm with these things!
Hi Rick,
Your suspicions are correct:
$ cat /etc/issue Fedora release 18 (Spherical Cow) Kernel \r on an \m (\l)
On Thu, Apr 25, 2013 at 3:17 PM, Rick Stevens ricks@alldigital.com wrote:
On 04/25/2013 03:10 PM, Patrick Lists issued this missive:
On 04/25/2013 11:04 PM, Richard Vickery wrote:
Thank you! An answer I can reply happily with / to, rather than thinking that, unlike what the website says, this group is not so helpful.
If I am on the alpha program, why am I on 3.7x rather than 3.8x?
$ uname -rsvp Linux 3.7.2-204.fc18.x86_64 #1 SMP Wed Jan 16 16:22:52 UTC 2013 x86_64
Not sure what you mean by the "alpha program" but if you expect to be on F19 Alpha (note the *19*) then look again at the output of the command you gave. It says F18 (note the *18*). So that box is running F18 and not F19 alpha. And that is also the reason why it has kernel 3.7.x and not kernel 3.8.x. Or did I miss something?
Patrick,
Richard claims to have "fedup"ped to F19. The kernel remains F18 and an old F18 kernel at that (I've got several F17 boxes with 3.8.4-102.fc17.x86_64 kernels). My suspicion was that a yum config is blocking a kernel update.
Richard, can you check the output of "cat /etc/issue" and verify that your machine really thinks it's F19?
------------------------------**------------------------------**----------
- Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
-Hard work has a future payoff. Laziness pays off now. -------------------------------**------------------------------**----------
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.**org/mailman/listinfo/usershttps://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/**Mailing_list_guidelineshttp://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On Thu, Apr 25, 2013 at 4:24 PM, Reindl Harald h.reindl@thelounge.netwrote:
Am 26.04.2013 01:03, schrieb Reindl Harald:
Am 25.04.2013 23:04, schrieb Richard Vickery:
Thank you! An answer I can reply happily with / to, rather than
thinking that, unlike what the website says, this
group is not so helpful.
If I am on the alpha program, why am I on 3.7x rather than 3.8x?
$ uname -rsvp Linux 3.7.2-204.fc18.x86_64 #1 SMP Wed Jan 16 16:22:52 UTC 2013 x86_64
nobody knows why you do not update your kernel 3.7.x is old, EOL and lacking a lot of security fixes 3.8.x is in the stable repos for any supported release
3.8.8-203.fc18.x86_64 3.8.8-102.fc17.x86_64 3.9.0-0.rc8.git0.2.fc19.x86_64
and if you updated you kernel / OS it is most likely in /boot/grub2/grub.cfg and by whatever error not as default
there is a line like set default="0" which can be modified or simply after select the newest kernel at boot a "yum reinstall kernel" after make sure the newest one works will remove any other kernel and with the next update all should be fine again, or simply use grub2-mkconfig -o /boot/grub2/grub.cf to re-generate the grub-config, at the begin without the -o param to take a look what would happen
but you can for sure select the kernel at boot
thanks to people who still thinks it is a good idea to hide the alternate kernels in the grub menu as default and force users to take action by pressing keys at the grub-stage of boot
hence to not use linux alpha-releases if you are not firm with these things!
Reindl:
I am now on 3.8 after # yum update kernel* earlier today..
Am 26.04.2013 01:35, schrieb Richard Vickery:
Reindl:
I am now on 3.8 after # yum update kernel* earlier today..
which leaves the question open why are you on a 3.7.x from 2013-01 until today while others have their production servers for more than a month on 3.8.x
Mar 10 17:11:47 Installed: kernel-3.8.2-105.fc17.x86_64 Mar 17 18:49:44 Installed: kernel-3.8.3-101.fc17.x86_64 Mar 20 22:53:46 Erased: kernel-3.8.2-105.fc17.x86_64 Mar 23 17:07:02 Installed: kernel-3.8.4-101.fc17.x86_64 Mar 26 23:47:24 Erased: kernel-3.8.3-101.fc17.x86_64 Apr 06 18:45:32 Installed: kernel-3.8.6-101.fc17.x86_64 Apr 07 17:17:54 Erased: kernel-3.8.4-101.fc17.x86_64 Apr 18 13:45:39 Installed: kernel-3.8.8-100.fc17.x86_64 Apr 19 16:18:28 Erased: kernel-3.8.6-101.fc17.x86_64 Apr 24 19:30:44 Installed: kernel-3.8.8-102.fc17.x86_64
On 04/26/13 06:23, Richard Vickery wrote:
The command called was: sudo fedup-cli --network 19 --debuglog fedupdebug.log
This will be my only comment on your issue since, as others have noted, matters related to F19 need to be addressed on the test@lists.fedoraproject.org list....
I just tried doing a fedup on a fully updated F18 system and the process did not complete. The final output was...
zlib-1.2.7-10.fc19.x86_64.rpm | 88 kB 00:00:00 getting boot images... Traceback (most recent call last): File "/bin/fedup-cli", line 285, in <module> main(args) File "/bin/fedup-cli", line 236, in main raise NotImplementedError("use --instrepo or --skipkernel") NotImplementedError: use --instrepo or --skipkernel
So, it is unclear to me how/if you really did update.
I do wonder if....
rpm -qa | grep fc19
actually returns any results. If it does...you really should review the log and post all questions to the test list and file a bugzilla.
On Thu, Apr 25, 2013 at 5:18 PM, Ed Greshko Ed.Greshko@greshko.com wrote:
On 04/26/13 06:23, Richard Vickery wrote:
The command called was: sudo fedup-cli --network 19 --debuglog
fedupdebug.log
This will be my only comment on your issue since, as others have noted, matters related to F19 need to be addressed on the test@lists.fedoraproject.org list....
I just tried doing a fedup on a fully updated F18 system and the process did not complete. The final output was...
zlib-1.2.7-10.fc19.x86_64.rpm | 88 kB 00:00:00 getting boot images... Traceback (most recent call last): File "/bin/fedup-cli", line 285, in <module> main(args) File "/bin/fedup-cli", line 236, in main raise NotImplementedError("use --instrepo or --skipkernel") NotImplementedError: use --instrepo or --skipkernel
So, it is unclear to me how/if you really did update.
I do wonder if....
rpm -qa | grep fc19
actually returns any results. If it does...you really should review the log and post all questions to the test list and file a bugzilla.
-- The only thing worse than a poorly asked question is a cryptic answer. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Since I'm not up on F19, there is really no reason to write to the test list, is there? I believe I will give up with all this push-back.
rpm -qa | grep fc19 produced nothing. How am I supposed to write this to the test list when there is no context?
On 04/26/13 08:39, Richard Vickery wrote:
Since I'm not up on F19, there is really no reason to write to the test list, is there? I believe I will give up with all this push-back.
rpm -qa | grep fc19 produced nothing. How am I supposed to write this to the test list when there is no context?
Violating my declaration....
Well, earlier you stated....
"The command called was: sudo fedup-cli --network 19 --debuglog fedupdebug.log"
But, very apparently, you've not upgraded to F19. So, best to just drop it all and move on. Nothing on this thread applies to your situation.
On Thu, Apr 25, 2013 at 5:49 PM, Ed Greshko Ed.Greshko@greshko.com wrote:
On 04/26/13 08:39, Richard Vickery wrote:
Since I'm not up on F19, there is really no reason to write to the test
list, is there? I believe I will give up with all this push-back.
rpm -qa | grep fc19 produced nothing. How am I supposed to write this to
the test list when there is no context?
Violating my declaration....
Well, earlier you stated....
"The command called was: sudo fedup-cli --network 19 --debuglog fedupdebug.log"
But, very apparently, you've not upgraded to F19. So, best to just drop it all and move on. Nothing on this thread applies to your situation.
-- The only thing worse than a poorly asked question is a cryptic answer. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Fine by me if you don't want the help.
On 04/26/13 08:57, Richard Vickery wrote:
Fine by me if you don't want the help.
You totally misunderstand.....
It isn't a matter of not wanting to help. It is a matter of you're asking questions about F19 and you've not upgraded to F19!!!
So.... See you on the test list.... Where you have posted a "question".
On 04/25/2013 05:49 PM, Ed Greshko issued this missive:
On 04/26/13 08:39, Richard Vickery wrote:
Since I'm not up on F19, there is really no reason to write to the test list, is there? I believe I will give up with all this push-back.
rpm -qa | grep fc19 produced nothing. How am I supposed to write this to the test list when there is no context?
Violating my declaration....
Well, earlier you stated....
"The command called was: sudo fedup-cli --network 19 --debuglog fedupdebug.log"
But, very apparently, you've not upgraded to F19. So, best to just drop it all and move on. Nothing on this thread applies to your situation.
That is correct. A cat of his /etc/issue resulted in showing he's still on F18. The fedup probably failed in a similar manner (I don't think fedup is really fully baked yet).
Richard, if I read one of your last postings correctly, I believe your kernel issue has been resolved with a "yum update kernel*", in that you're now on a 3.8 kernel rather than 3.7. Is that correct? If not, check your /boot directory and verify you have 3.8 kernels in there. If so, then the problem is probably the grub configuration not booting the new kernel. Now that we've established that you actually on an F18 system, we can (probably) sort out the rest of your issues. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - If your broker is so damned smart...why is he still working? - ----------------------------------------------------------------------
On 04/26/13 09:06, Rick Stevens wrote:
(I don't think fedup is really fully baked yet).
It isn't..... For grins, I just tried it on a fully updated F18 system using....
fedup-cli --network 19 --debuglog /root/fed1.log --instrepo http://dl.fedoraproject.org/pub/fedora/linux/releases/test/19-Alpha/Fedora/x...
It downloads all the packages to upgrade. However, on reboot and selecting up Upgrade menu item it comes to a "hang".
On 04/25/2013 05:39 PM, Richard Vickery wrote:
Since I'm not up on F19, there is really no reason to write to the test list, is there? I believe I will give up with all this push-back.
I'd think that the people on that list would want to know that you're unable to install F19 with fedup and that they might even be able to help you.
Am 26.04.2013 02:57, schrieb Richard Vickery:
Well, earlier you stated.... "The command called was: sudo fedup-cli --network 19 --debuglog fedupdebug.log" But, very apparently, you've not upgraded to F19. So, best to just drop it all and move on. Nothing on this thread applies to your situation.Fine by me if you don't want the help
what help exactly you need?
sorry - until a short time ago you thougth even you are on F19 which was never the case, so do yourself a favour and start a new thread with whatever problem you have in the subject or let it be
On Thu, 25 Apr 2013 14:49:36 +0930, Tim wrote:
Allegedly, on or about 24 April 2013, Joe Zeff sent:
Checking, my /etc/default/grub contains SYSFONT=True and I'm wondering why I see the error message about the font True not being found. If so, can I simply edit that out and rebuild /boot/grub2.grub.cfg?
I've never seen the associated errors people have discussed regarding SYSFONT=True (i.e. stalled boots).
SYSFONT=True does not cause the boot to stop.
-
Bruno Wolff III -
Ed Greshko -
Joe Zeff -
Lawrence E Graves -
Michael Schwendt -
Patrick Lists -
Patrick O'Callaghan -
Phil Dobbin -
poma -
Regina Anger -
Reindl Harald -
Richard Vickery -
Rick Stevens -
Steve Searle -
Suvayu Ali -
Tim