Last night, after I successfully upgraded my F13 test desktop from F13->F14 w/preupgrade, I started the same operation on my F12 laptop.
The results were not so good.
X86_64, Asus S96J laptop, w/ATI Mobility Radeon X1600 video card, IPW3945, 2GB RAM, 350GB disk.
1) I had recently installed WICD (from ATRpms, so shoot me) because it worked better for me than NetworkManager under F12. Under F14, it fails to start properly (yes, its the fc14 version now). So, I disabled it and re-enabled NetworkManager. I have networking back for now.
2) X11 no longer starts up. I'm using the radeon driver for my ATI Technologies Inc M56P [Radeon Mobility X1600]. It was working just fine (as fine can be with the radeon driver), but now it dies with a seg fault with only 3 frames on the stack. I have re-configured to run the VESA driver, but, I miss my 1200x800 native resolution. VESA can only do 1024x768. I can attach my (used to be working) xorg.conf for anyone interested, but it fails in exactly the same way if I delete it as well. I can try again and send along an Xorg.0.log if it will help.
2a) VESA has lots of problems returning to a proper video mode. If I run dosbox in full-screen mode, when it returns to X11, the resolution is less than stellar. Its the same size, but it seems like every other pixel is missing. Heck, All I have to do is switch to a diferent virtual console, and X11 is hosed when I return to it. Even the color pallette seems to be changed. I have to logout and restart the X server to get it back.
3) VMWare-Server won't compile. Seems it can't find the kernel headers. Its looking in /usr/src/linux/include, but that directory seems to be missing. (I built it successfully a number of times under F12.) I have kernel, kernel-devel, and kernel-headers installed. That used to be enough for VMWare-server.
4) There are a number of python errors during bootup. They are not in DMESG.
5) the console screen during bootup contains lines starting with [ [ mmm.nnnn ] messages that were not visible on F12. It makes looking at the [OK] and [Failed] service messges difficult.
I'm sure I've missed something else (I haven't tested suspend/hibernate yet), but for now, this is what I've noticed.
Imagine my surprise at No Network and No Graphics after completion of preupgrade. Not a lot of fun.
I still have an F11 server that I need to upgrade, but not until I get my laptop's problems sorted out.
And, for those of you who are still reading, yes, I have read both the F13 and F14 release notes, but nothing stands out (to me) that I may have missed.
Suggestions welcome.
On Wed, Nov 03, 2010 at 14:52:05 -0400, "Kevin J. Cummings" cummings@kjchome.homeip.net wrote:
- X11 no longer starts up. I'm using the radeon driver for my ATI
Technologies Inc M56P [Radeon Mobility X1600]. It was working just fine (as fine can be with the radeon driver), but now it dies with a seg fault with only 3 frames on the stack. I have re-configured to run the VESA driver, but, I miss my 1200x800 native resolution. VESA can only do 1024x768. I can attach my (used to be working) xorg.conf for anyone interested, but it fails in exactly the same way if I delete it as well. I can try again and send along an Xorg.0.log if it will help.
Using nomodeset might get you by.
On 11/03/2010 11:52 AM, Kevin J. Cummings wrote:
Last night, after I successfully upgraded my F13 test desktop from F13->F14 w/preupgrade, I started the same operation on my F12 laptop.
The results were not so good.
X86_64, Asus S96J laptop, w/ATI Mobility Radeon X1600 video card, IPW3945, 2GB RAM, 350GB disk.
- I had recently installed WICD (from ATRpms, so shoot me) because it
worked better for me than NetworkManager under F12. Under F14, it fails to start properly (yes, its the fc14 version now). So, I disabled it and re-enabled NetworkManager. I have networking back for now.
- X11 no longer starts up. I'm using the radeon driver for my ATI
Technologies Inc M56P [Radeon Mobility X1600]. It was working just fine (as fine can be with the radeon driver), but now it dies with a seg fault with only 3 frames on the stack. I have re-configured to run the VESA driver, but, I miss my 1200x800 native resolution. VESA can only do 1024x768. I can attach my (used to be working) xorg.conf for anyone interested, but it fails in exactly the same way if I delete it as well. I can try again and send along an Xorg.0.log if it will help.
2a) VESA has lots of problems returning to a proper video mode. If I run dosbox in full-screen mode, when it returns to X11, the resolution is less than stellar. Its the same size, but it seems like every other pixel is missing. Heck, All I have to do is switch to a diferent virtual console, and X11 is hosed when I return to it. Even the color pallette seems to be changed. I have to logout and restart the X server to get it back.
- VMWare-Server won't compile. Seems it can't find the kernel
headers. Its looking in /usr/src/linux/include, but that directory seems to be missing. (I built it successfully a number of times under F12.) I have kernel, kernel-devel, and kernel-headers installed. That used to be enough for VMWare-server.
- There are a number of python errors during bootup. They are not in
DMESG.
- the console screen during bootup contains lines starting with [ [ mmm.nnnn ] messages that were not visible on F12. It makes looking
at the [OK] and [Failed] service messges difficult.
I'm sure I've missed something else (I haven't tested suspend/hibernate yet), but for now, this is what I've noticed.
Imagine my surprise at No Network and No Graphics after completion of preupgrade. Not a lot of fun.
I still have an F11 server that I need to upgrade, but not until I get my laptop's problems sorted out.
And, for those of you who are still reading, yes, I have read both the F13 and F14 release notes, but nothing stands out (to me) that I may have missed.
Suggestions welcome.
I think the main problem is that you skipped F13 and jumped to F14 directly. Usually the most well-tested upgrades are to $release+
Don't forget to go through all the .rpmnew and .rpmsave files and replace/merge them as necessary
On 11/03/2010 02:51 PM, Bruno Wolff III wrote:
On Wed, Nov 03, 2010 at 14:52:05 -0400, "Kevin J. Cummings" cummings@kjchome.homeip.net wrote:
- X11 no longer starts up. I'm using the radeon driver for my ATI
Technologies Inc M56P [Radeon Mobility X1600]. It was working just fine (as fine can be with the radeon driver), but now it dies with a seg fault with only 3 frames on the stack. I have re-configured to run the VESA driver, but, I miss my 1200x800 native resolution. VESA can only do 1024x768. I can attach my (used to be working) xorg.conf for anyone interested, but it fails in exactly the same way if I delete it as well. I can try again and send along an Xorg.0.log if it will help.
Using nomodeset might get you by.
Already using it....
On 11/03/2010 03:11 PM, Konstantin Svist wrote:
I think the main problem is that you skipped F13 and jumped to F14 directly. Usually the most well-tested upgrades are to $release+
I surely hope that if F12->F14 is *not* a supported upgrade path, then preupgrade should *NOT* allow it to be done. There was a problem with a previous release (ISTR it was either F9 -> F11 or F10 -> F12) not being able to be skipped, and part of the process disallowed it. Unfortunately, it was after the packages had been downloaded, but it was right after the first re-boot to install them, and the particular error message was buried in one of the alternate windows, but, it clearly stated that the upgrade I was trying was not supported (I did indeed need to go through the intermediate step). [The problem was the visible error message only stated that the update process could not find the previous installation root.] That requirement was also documented in the release notes. I saw nothing in either the F13 or F14 release notes requiring a serial update from F12.
Don't forget to go through all the .rpmnew and .rpmsave files and replace/merge them as necessary
Good point, I forgot about those. I will have to go looking for them....
On Wed, 03 Nov 2010 12:11:45 -0700 Konstantin Svist wrote:
[ ... ]
I think the main problem is that you skipped F13 and jumped to F14 directly. Usually the most well-tested upgrades are to $release+
BTW, citing http://fedoraproject.org/wiki/PreUpgrade
| Upgrade to current release directly | Preupgrade provides an upgrade directly to the latest version of Fedora. | It is not necessary to upgrade to intermediate versions. For example, | it is possible to go from Fedora 12 to Fedora 14 directly.
--Frank Elsner
On 11/03/2010 03:38 PM, Kevin J. Cummings wrote:
On 11/03/2010 03:11 PM, Konstantin Svist wrote:
I think the main problem is that you skipped F13 and jumped to F14 directly. Usually the most well-tested upgrades are to $release+
*from: http://fedoraproject.org/wiki/PreUpgrade "Upgrade to current release directly* Preupgrade provides an upgrade directly to the latest version of Fedora. It is not necessary to upgrade to intermediate versions. For example, it is possible to go from Fedora 12 to Fedora 14 directly." fyi, roger wells
I surely hope that if F12->F14 is *not* a supported upgrade path, then preupgrade should *NOT* allow it to be done. There was a problem with a previous release (ISTR it was either F9 -> F11 or F10 -> F12) not being able to be skipped, and part of the process disallowed it. Unfortunately, it was after the packages had been downloaded, but it was right after the first re-boot to install them, and the particular error message was buried in one of the alternate windows, but, it clearly stated that the upgrade I was trying was not supported (I did indeed need to go through the intermediate step). [The problem was the visible error message only stated that the update process could not find the previous installation root.] That requirement was also documented in the release notes. I saw nothing in either the F13 or F14 release notes requiring a serial update from F12.
Don't forget to go through all the .rpmnew and .rpmsave files and replace/merge them as necessary
Good point, I forgot about those. I will have to go looking for them....
On 11/03/2010 01:26 PM, Roger K. Wells wrote:
On 11/03/2010 03:38 PM, Kevin J. Cummings wrote:
On 11/03/2010 03:11 PM, Konstantin Svist wrote:
I think the main problem is that you skipped F13 and jumped to F14 directly. Usually the most well-tested upgrades are to $release+
*from: http://fedoraproject.org/wiki/PreUpgrade "Upgrade to current release directly* Preupgrade provides an upgrade directly to the latest version of Fedora. It is not necessary to upgrade to intermediate versions. For example, it is possible to go from Fedora 12 to Fedora 14 directly." fyi, roger wells
I didn't mean that it's unsupported, just that it's most likely not as well tested as 13->14 We programmers often like to say that "it just works" even though later it turns out it doesn't :|
On Wed, 03 Nov 2010 14:52:05 -0400 "Kevin J. Cummings" cummings@kjchome.homeip.net wrote:
Last night, after I successfully upgraded my F13 test desktop from F13->F14 w/preupgrade, I started the same operation on my F12 laptop.
The results were not so good.
X86_64, Asus S96J laptop, w/ATI Mobility Radeon X1600 video card, IPW3945, 2GB RAM, 350GB disk.
...snip...
- X11 no longer starts up. I'm using the radeon driver for my ATI
Technologies Inc M56P [Radeon Mobility X1600]. It was working just fine (as fine can be with the radeon driver), but now it dies with a seg fault with only 3 frames on the stack. I have re-configured to run the VESA driver, but, I miss my 1200x800 native resolution. VESA can only do 1024x768. I can attach my (used to be working) xorg.conf for anyone interested, but it fails in exactly the same way if I delete it as well. I can try again and send along an Xorg.0.log if it will help.
Sure, can you Send the Xorg.0.log attached to your reply to this? also, you might try with No /etc/X11/xorg.conf at all, and let the driver autodetect things.
...snip...
- VMWare-Server won't compile. Seems it can't find the kernel
headers. Its looking in /usr/src/linux/include, but that directory seems to be missing. (I built it successfully a number of times under F12.) I have kernel, kernel-devel, and kernel-headers installed. That used to be enough for VMWare-server.
kernel-devel should be it, but you must be running the exact same version of the kernel as your kernel-devel is for it to work. So:
yum update reboot yum install kernel-devel
You may also be using the PAE kernel, which means you want kernel-PAE-devel instead of kernel-devel.
- There are a number of python errors during bootup. They are not
in DMESG.
Try /var/log/boot.log or /var/log/messages.
- the console screen during bootup contains lines starting with
[ [ mmm.nnnn ] messages that were not visible on F12. It makes looking at the [OK] and [Failed] service messges difficult.
Those are timestamps since boot. They can be very usefull to see when a message was logged so you know it's old, etc.
kevin
On Wed, Nov 03, 2010 at 04:39:43PM -0600, Kevin Fenzi wrote:
On Wed, 03 Nov 2010 14:52:05 -0400 "Kevin J. Cummings" cummings@kjchome.homeip.net wrote:
Last night, after I successfully upgraded my F13 test desktop from F13->F14 w/preupgrade, I started the same operation on my F12 laptop.
The results were not so good.
X86_64, Asus S96J laptop, w/ATI Mobility Radeon X1600 video card, IPW3945, 2GB RAM, 350GB disk.
...snip...
- X11 no longer starts up. I'm using the radeon driver for my ATI
Technologies Inc M56P [Radeon Mobility X1600]. It was working just fine (as fine can be with the radeon driver), but now it dies with a seg fault with only 3 frames on the stack. I have re-configured to run the VESA driver, but, I miss my 1200x800 native resolution. VESA can only do 1024x768. I can attach my (used to be working) xorg.conf for anyone interested, but it fails in exactly the same way if I delete it as well. I can try again and send along an Xorg.0.log if it will help.
Sure, can you Send the Xorg.0.log attached to your reply to this? also, you might try with No /etc/X11/xorg.conf at all, and let the driver autodetect things.
...snip...
- VMWare-Server won't compile. Seems it can't find the kernel
headers. Its looking in /usr/src/linux/include, but that directory seems to be missing. (I built it successfully a number of times under F12.) I have kernel, kernel-devel, and kernel-headers installed. That used to be enough for VMWare-server.
kernel-devel should be it, but you must be running the exact same version of the kernel as your kernel-devel is for it to work. So:
yum update reboot yum install kernel-devel
You may also be using the PAE kernel, which means you want kernel-PAE-devel instead of kernel-devel.
- There are a number of python errors during bootup. They are not
in DMESG.
Try /var/log/boot.log or /var/log/messages.
- the console screen during bootup contains lines starting with
[ [ mmm.nnnn ] messages that were not visible on F12. It makes looking at the [OK] and [Failed] service messges difficult.
Those are timestamps since boot. They can be very usefull to see when a message was logged so you know it's old, etc.
Those messages on the console (with the timestamp) are from dmesg. These are visible on the console in F14 because rc.sysinit no longer sets the dmesg logging level, thus all messages from dmesg end up being written to the console. See dmesg(1) for more information. If you have an older Fedora machine handy you can look at rc.sysinit where you will find the following:
# Fix console loglevel if [ -n "$LOGLEVEL" ]; then /bin/dmesg -n $LOGLEVEL fi
This is missing from F14.
I'm of the opinion that this should be fixed. Printing dmesg messages to the console by default is too much.
I was able to get things back to normal by adding 'dmesg -n 3' to rc.sysinit. If there is a better way, please let me know. Also, if there is a compelling reason that this was removed from F14, I'd be interested to know what that reason is.
Ryan
On Sun, 14 Nov 2010 21:25:08 -0600 "Ryan O'Hara" rohara@redhat.com wrote:
Those messages on the console (with the timestamp) are from dmesg. These are visible on the console in F14 because rc.sysinit no longer sets the dmesg logging level, thus all messages from dmesg end up being written to the console. See dmesg(1) for more information. If you have an older Fedora machine handy you can look at rc.sysinit where you will find the following:
Fix console loglevel if [ -# n "$LOGLEVEL" ]; then /bin/dmesg -n $LOGLEVEL fi
This is missing from F14.
I'm of the opinion that this should be fixed. Printing dmesg messages to the console by default is too much.
I was able to get things back to normal by adding 'dmesg -n 3' to rc.sysinit. If there is a better way, please let me know. Also, if there is a compelling reason that this was removed from F14, I'd be interested to know what that reason is.
Thank you for posting this.
I used the above with an else in case $LOGLEVEL wasn't defined. I assume that is the reason it was dropped, but if it still exists, I'll use it.
#Fix console loglevel if [ -# n "$LOGLEVEL" ]; then /bin/dmesg -n $LOGLEVEL else /bin/dmesg -n 3 fi
On 11/15/2010 09:42 AM, stan wrote:
On Sun, 14 Nov 2010 21:25:08 -0600 "Ryan O'Hara"rohara@redhat.com wrote:
Those messages on the console (with the timestamp) are from dmesg. These are visible on the console in F14 because rc.sysinit no longer sets the dmesg logging level, thus all messages from dmesg end up being written to the console. See dmesg(1) for more information. If you have an older Fedora machine handy you can look at rc.sysinit where you will find the following:
Fix console loglevel if [ -# n "$LOGLEVEL" ]; then /bin/dmesg -n $LOGLEVEL fi
This is missing from F14.
I'm of the opinion that this should be fixed. Printing dmesg messages to the console by default is too much.
I was able to get things back to normal by adding 'dmesg -n 3' to rc.sysinit. If there is a better way, please let me know. Also, if there is a compelling reason that this was removed from F14, I'd be interested to know what that reason is.
Thank you for posting this.
I used the above with an else in case $LOGLEVEL wasn't defined. I assume that is the reason it was dropped, but if it still exists, I'll use it.
#Fix console loglevel if [ -# n "$LOGLEVEL" ]; then /bin/dmesg -n $LOGLEVEL else /bin/dmesg -n 3 fi
Uh, the F13 version actually reads:
# Fix console loglevel if [ -n "$LOGLEVEL" ]; then /bin/dmesg -n $LOGLEVEL fi
"if [ -# n "$LOGLEVEL" ]; then" is incorrect and will probably make the shell mark the line as an error. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, C2 Hosting ricks@nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - "The Schizophrenic: An Unauthorized Autobiography" - ----------------------------------------------------------------------
On Mon, Nov 15, 2010 at 10:42:17AM -0700, stan wrote:
On Sun, 14 Nov 2010 21:25:08 -0600 "Ryan O'Hara" rohara@redhat.com wrote:
Those messages on the console (with the timestamp) are from dmesg. These are visible on the console in F14 because rc.sysinit no longer sets the dmesg logging level, thus all messages from dmesg end up being written to the console. See dmesg(1) for more information. If you have an older Fedora machine handy you can look at rc.sysinit where you will find the following:
Fix console loglevel if [ -# n "$LOGLEVEL" ]; then /bin/dmesg -n $LOGLEVEL fi
This is missing from F14.
I'm of the opinion that this should be fixed. Printing dmesg messages to the console by default is too much.
I was able to get things back to normal by adding 'dmesg -n 3' to rc.sysinit. If there is a better way, please let me know. Also, if there is a compelling reason that this was removed from F14, I'd be interested to know what that reason is.
Thank you for posting this.
Happy to help.
I used the above with an else in case $LOGLEVEL wasn't defined. I assume that is the reason it was dropped, but if it still exists, I'll use it.
I believe $LOGLEVEL was defined in /etc/sysconfig/init, but I am not completely sure. That file still exists on F14, but LOGLEVEL is no longer defined, as you found out.
#Fix console loglevel if [ -# n "$LOGLEVEL" ]; then /bin/dmesg -n $LOGLEVEL else /bin/dmesg -n 3 fi
That will work.
I still don't understand why it was removed. Hoping someone can enlighten me.
Ryan
On Mon, Nov 15, 2010 at 10:29:27AM -0800, Rick Stevens wrote:
On 11/15/2010 09:42 AM, stan wrote:
On Sun, 14 Nov 2010 21:25:08 -0600 "Ryan O'Hara"rohara@redhat.com wrote:
Those messages on the console (with the timestamp) are from dmesg. These are visible on the console in F14 because rc.sysinit no longer sets the dmesg logging level, thus all messages from dmesg end up being written to the console. See dmesg(1) for more information. If you have an older Fedora machine handy you can look at rc.sysinit where you will find the following:
Fix console loglevel if [ -# n "$LOGLEVEL" ]; then /bin/dmesg -n $LOGLEVEL fi
This is missing from F14.
I'm of the opinion that this should be fixed. Printing dmesg messages to the console by default is too much.
I was able to get things back to normal by adding 'dmesg -n 3' to rc.sysinit. If there is a better way, please let me know. Also, if there is a compelling reason that this was removed from F14, I'd be interested to know what that reason is.
Thank you for posting this.
I used the above with an else in case $LOGLEVEL wasn't defined. I assume that is the reason it was dropped, but if it still exists, I'll use it.
#Fix console loglevel if [ -# n "$LOGLEVEL" ]; then /bin/dmesg -n $LOGLEVEL else /bin/dmesg -n 3 fi
Uh, the F13 version actually reads:
# Fix console loglevel if [ -n "$LOGLEVEL" ]; then /bin/dmesg -n $LOGLEVEL fi
"if [ -# n "$LOGLEVEL" ]; then" is incorrect and will probably make the shell mark the line as an error.
Sorry. That error originated in my post. Assuming cut-and-paste error on my part. Thanks for catching this.
Ryan
I just wanted to send out an update after (almost) 2 weeks.
On 11/03/2010 02:52 PM, Kevin J. Cummings wrote:
Last night, after I successfully upgraded my F13 test desktop from F13->F14 w/preupgrade, I started the same operation on my F12 laptop.
The results were not so good.
X86_64, Asus S96J laptop, w/ATI Mobility Radeon X1600 video card, IPW3945, 2GB RAM, 350GB disk.
[snip]
- X11 no longer starts up. I'm using the radeon driver for my ATI
Technologies Inc M56P [Radeon Mobility X1600]. It was working just fine (as fine can be with the radeon driver), but now it dies with a seg fault with only 3 frames on the stack. I have re-configured to run the VESA driver, but, I miss my 1200x800 native resolution. VESA can only do 1024x768. I can attach my (used to be working) xorg.conf for anyone interested, but it fails in exactly the same way if I delete it as well. I can try again and send along an Xorg.0.log if it will help.
I tried starting the radeon server both with and without an xorg.conf file in /etc/X11. I get the same results.
I tried removing "nomodeset" from my kernel boot line. With the radeon driver configured, things get worse. It still doesn't start, and I lose my keyboard and have to lean on the power button to get control back.
I removed the bootchart stuff, no difference.
The Xorg.0.log files I saved are too big to send to the list (in fact, the list moderator bounced them back to me with no personal explanation of why). So, I'm putting them on my home server. They can be found here:
http://kjchome.homeip.net:81/Xorg.0.log.none http://kjchome.homeip.net:81/Xorg.0.log.radeon
I suppose I should open a bug against the radeon driver in bugzilla and attach them there.
2a) VESA has lots of problems returning to a proper video mode. If I run dosbox in full-screen mode, when it returns to X11, the resolution is less than stellar. Its the same size, but it seems like every other pixel is missing. Heck, All I have to do is switch to a diferent virtual console, and X11 is hosed when I return to it. Even the color pallette seems to be changed. I have to logout and restart the X server to get it back.
I tried the VESA driver without "nomodeset". Things get worse.
I will open a bug against the VESA driver as well.
[snip]
6) I found that alsa-plugins-pulseaudio was an i686 RPM on my system. I installed the x86_64 version, and some sound problems went away. I was actually amazed at how mush was actually working without it being the correct architecture.
7) Eclipse bombs out on me. Whenever I bring up an old project and either try and edit it, or run make (build) on it, java dies and eclipse aborts. I've tried submitting a bug report with ABRT, but it tries to download 173 debuginfo packages and ends up aborting itself (it can't either find something or rebuild something).
8) I found/fixed a problem with KDUMP, but that wasn't working for me on F12 either.
9) Suspend works (probably because I'm using the VESA video driver), but aborts when resuming. I haven't looked into why yet.
10) Hibernate seems to work OK, but I've not done enough testing with it to be sure.
Suggestions welcome.
stan wrote:
On Sun, 14 Nov 2010 21:25:08 -0600 "Ryan O'Hara"rohara@redhat.com wrote:
Those messages on the console (with the timestamp) are from dmesg. These are visible on the console in F14 because rc.sysinit no longer sets the dmesg logging level, thus all messages from dmesg end up being written to the console. See dmesg(1) for more information. If you have an older Fedora machine handy you can look at rc.sysinit where you will find the following:
Fix console loglevel if [ -# n "$LOGLEVEL" ]; then /bin/dmesg -n $LOGLEVEL fi
This is missing from F14.
I'm of the opinion that this should be fixed. Printing dmesg messages to the console by default is too much.
I was able to get things back to normal by adding 'dmesg -n 3' to rc.sysinit. If there is a better way, please let me know. Also, if there is a compelling reason that this was removed from F14, I'd be interested to know what that reason is.
Thank you for posting this.
I used the above with an else in case $LOGLEVEL wasn't defined. I assume that is the reason it was dropped, but if it still exists, I'll use it.
#Fix console loglevel if [ -# n "$LOGLEVEL" ]; then /bin/dmesg -n $LOGLEVEL else /bin/dmesg -n 3 fi
/bin/dmesg -n ${LOGLEVEL:-3}
On Wed, 17 Nov 2010 14:56:04 -0500 Bill Davidsen davidsen@tmr.com wrote:
stan wrote:
#Fix console loglevel if [ -n "$LOGLEVEL" ]; then /bin/dmesg -n $LOGLEVEL else /bin/dmesg -n 3 fi
/bin/dmesg -n ${LOGLEVEL:-3}
That's slick. I presume you meant /bin/dmesg -n ${LOGLEVEL:3} changing the -3 to a 3? I didn't look up the documentation, just extrapolating.
On 11/17/2010 04:22 PM, stan wrote:
On Wed, 17 Nov 2010 14:56:04 -0500 Bill Davidsen davidsen@tmr.com wrote:
stan wrote:
#Fix console loglevel if [ -n "$LOGLEVEL" ]; then /bin/dmesg -n $LOGLEVEL else /bin/dmesg -n 3 fi
/bin/dmesg -n ${LOGLEVEL:-3}
That's slick. I presume you meant /bin/dmesg -n ${LOGLEVEL:3} changing the -3 to a 3? I didn't look up the documentation, just extrapolating.
Nope. Read the bash man page. Particularly the section on parameter substitution....
stan wrote:
On Wed, 17 Nov 2010 14:56:04 -0500 Bill Davidsendavidsen@tmr.com wrote:
stan wrote:
#Fix console loglevel if [ -n "$LOGLEVEL" ]; then /bin/dmesg -n $LOGLEVEL else /bin/dmesg -n 3 fi
/bin/dmesg -n ${LOGLEVEL:-3}
That's slick. I presume you meant /bin/dmesg -n ${LOGLEVEL:3} changing the -3 to a 3? I didn't look up the documentation, just extrapolating.
What I wrote means to use the $LOGLEVEL value if defined, else to use the default value "3". See the bash manual for operators, there are a bunch, of which ":-" is the one I use most often.
Another 2 weeks (or more) have gone by, and I have another update. B^)
I am now booting using the radeon driver. I have 1200x800 on my laptop again. What I had to do was remove both "nomodeset" and "VGA=791" from my kernel boot line in /etc/grub.conf. I also deleted my /etc/X11/xorg.conf file. It would seem that the "VGA=791" is what was hosing X11 over when it tried to startup. To boot, while the screen starts up in 80x25 text mode, it changes to a higher resolution text mode during the boot up for me (the whole reason I was using "VGA=791" in the first place).
I can not only run in full resolution again, but switching back and forth between text consoles and the GUI is now instantaneous and perfect (no screen corruption). I have also noticed that I can now suspend and resume properly. This hasn't been the case since F9 (when "nomodeset" was required in order for suspend to complete properly).
The only "problem" I am running into is the desktop background. Way back in FC6, I set it to the "Earth from Space" background. It is a 1600x1200 JPG with the Earth seen in the lower left corner. Because my screen is 1200x800 native, this background is now appearing "scaled" on my desktop, which means it is 1067x800 and is centered in my display with 2 white bars on the left and right sides. If I right click on the desktop, I can bring up the "Change Desktop Background" window (which is labeled "Appearance Properties" and I can select "stretch" for the Style, and the 2 white bars disappear as the picture streches to fill my display. This is the way it was on both FC6 and F9. I have changed nothing here. Since F12 and now on F14 I can "temporarily" change the size of my desktop, *BUT* when I switch to another virtual desktop (I am running with 9 virtual desktops in a 3x3 arrangement) the changes disappear and the "Earth from Space" desktop re-appears in its original scaled version (with the white bars again). I've even changed the picture to a different one, but, no luck. It stays while I stay in that virtual desktop, but reverts back to "Earth from Space" "scaled" the minute I change virtual desktops. It remains reverted, even if I return to the virtual desktop that I changed it in! This one is frustrating me. Anyone have any ideas on what might be wrong, or how I can change my desktop appearance in a more *permanent* manner?
On Sat, Dec 04, 2010 at 12:46:32 -0500, "Kevin J. Cummings" cummings@kjchome.homeip.net wrote:
me. Anyone have any ideas on what might be wrong, or how I can change my desktop appearance in a more *permanent* manner?
This doesn't solve the desktop oddity, but you could make a new image at the correct resolution using some image manipulation tool and then use that for the background image.
On 12/04/2010 12:55 PM, Bruno Wolff III wrote:
On Sat, Dec 04, 2010 at 12:46:32 -0500, "Kevin J. Cummings" cummings@kjchome.homeip.net wrote:
me. Anyone have any ideas on what might be wrong, or how I can change my desktop appearance in a more *permanent* manner?
This doesn't solve the desktop oddity, but you could make a new image at the correct resolution using some image manipulation tool and then use that for the background image.
No Joy. B^(
1) It doesn't seem to matter what image I choose to use as my desktop background. It doesn't stick.
2) It doesn't seem to matter how that background is viewed (styled?) After it reverts I'm back to Earth from Space, Scaled.
3) The only thing that *does* seem to stick, is the Colors: selection. I've managed to change the background color from white to black. Now at least, the white bars on the sides are now black bars and blend with the background image.
4) OK, I was also able to add an image to the background selections, and it seems to have stuck in the selection window, but, no matter which background I choose, it eventually reverts back to Earth from Space, Scaled.
On 12/04/2010 11:56 AM, Kevin J. Cummings wrote:
- It doesn't seem to matter what image I choose to use as my desktop
background. It doesn't stick.
Try installing and using Wallpapoz. I originally tried it so I could have a different background on each desktop, but found it much more interesting just to have a set of random wallpapers. (Mind you, I could mix both effects by having a different list for each desktop, but that's much more bother than it's worth to me.) Even if you want one and only one wallpaper, it should be able to override whatever Gnome's trying to do.
On 12/04/2010 03:16 PM, Joe Zeff wrote:
On 12/04/2010 11:56 AM, Kevin J. Cummings wrote:
- It doesn't seem to matter what image I choose to use as my desktop
background. It doesn't stick.
Try installing and using Wallpapoz. I originally tried it so I could have a different background on each desktop, but found it much more interesting just to have a set of random wallpapers. (Mind you, I could mix both effects by having a different list for each desktop, but that's much more bother than it's worth to me.) Even if you want one and only one wallpaper, it should be able to override whatever Gnome's trying to do.
Thank-you! And we have a winner! I discovered that I *already* had wallpapoz installed and it was running. After I removed it, and killed the running processes, my Gnome desktop control returned to normal! Wallpapoz was what was screwing it up!
B^)
-
Bill Davidsen -
Bruno Wolff III -
Frank Elsner -
Joe Zeff -
Kevin Cummings -
Kevin Fenzi -
Konstantin Svist -
Rick Stevens -
Roger K. Wells -
Ryan O'Hara -
stan