My old Thinkpad T30 (on which I ran fedup from F18 to F19) is beginning to seem like more effort than it's worth, ever if eventual success of the effort were a sure thing. Is there a FedDown lurking out there somewhere?
Will an install DVD for F18 (preferably one with both gnome and xfce4) let me treat the installation as if it were an upgrade, and preserve my data and tweaks?
Failing both of the above, does anyone have any experience running CentOS on a T30 or comparable?
My old Thinkpad T30 (on which I ran fedup from F18 to F19) is beginning to seem like more effort than it's worth, ever if eventual success of the effort were a sure thing. Is there a FedDown lurking out there somewhere?
Will an install DVD for F18 (preferably one with both gnome and xfce4) let me treat the installation as if it were an upgrade, and preserve my data and tweaks?
Have not worked with a T30, but on T51, T51e, and T60 I have done limited testing, and found that changing to lightdm makes it work for me.
Got info from user poma
# yum install lightdm # systemctl enable lightdm --force # systemctl start lightdm
OK, I did that, by cutting and pasting; thanks!
Unfortunately , however, it's ove r my head.
The issue I've had with older machine that I've tried upgrading to 19 is that if I open a terminal windows from the X windows, the gnome shell starts using 20% to 40% of the cpu. Don't see anything with xfce and opening a terminal window.
Remember I'm only on it with ssh -- and even if I had a command line on the laptop itself, I wouldn't know how to open a terminal , much less launch the whole GUI.
I rebooted, hoping for a login screen. No such luck. I tried typing xfce and enter, and xfce4 and enter, and finally startx, for lack of any other ide a ; they all failed.
Incidentally, I follow this list via gmane, where all the webgibberish makes your text completely illegible; please desist. (I'm replying via your direct carbon, using a mailer I have little experience with and no liking for.) In fact, I'm pretty sure the list has a rule against any form of html , anyway.
On Wed, 16 Oct 2013 10:39:05 -0700, Joe Zeff wrote:
On 10/16/2013 08:22 AM, beartooth@comcast.net wrote:
I rebooted, hoping for a login screen. No such luck. I tried typing xfce and enter, and xfce4 and enter, and finally startx, for lack of any other idea; they all failed.
From a CLI:
startxfce4
Aha! I tried that, first as root over ssh, and got screensful of error messages; hit ^C, and tried it as userid (still over ssh); got more errors. So I rebooted.
The monitor on the T30 showed (and still shows) normal-looking boot messages as far as one saying "Started Install ABRT coredump hook," marked OK, but no further. I.e., it offers no login screen.
So I tried startxfce4 again as userid over ssh -Y, and got more errors. :-(
On 10/16/2013 01:13 PM, Beartooth wrote:
On Wed, 16 Oct 2013 10:39:05 -0700, Joe Zeff wrote:
On 10/16/2013 08:22 AM, beartooth@comcast.net wrote:
I rebooted, hoping for a login screen. No such luck. I tried typing xfce and enter, and xfce4 and enter, and finally startx, for lack of any other idea; they all failed.
From a CLI:
startxfce4
Aha! I tried that, first as root over ssh, and got screensful of error messages; hit ^C, and tried it as userid (still over ssh); got more errors. So I rebooted.
The monitor on the T30 showed (and still shows) normal-looking boot messages as far as one saying "Started Install ABRT coredump hook," marked OK, but no further. I.e., it offers no login screen.
So I tried startxfce4 again as userid over ssh -Y, and got more errors. :-(
You might try asking at the Xfce forum: http://forum.xfce.org/index.php because this might be DE specific. However, before you do, have you made sure that ssh is set up to deal properly with X? (I don't think that it is by default.)
On Wed, 16 Oct 2013 13:30:19 -0700, Joe Zeff wrote:
[....]
You might try asking at the Xfce forum: http://forum.xfce.org/index.php because this might be DE specific. However, before you do, have you made sure that ssh is set up to deal properly with X? (I don't think that it is by default.)
From "man:ssh" on Konqueror :
-X Enables X11 forwarding. This can also be specified on a per-host basis in a configuration file.
X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user's X authorization database) can access the local X11 display through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring.
For this reason, X11 forwarding is subjected to X11 SECURITY extension restrictions by default. Please refer to the ssh -Y option and the ForwardX11Trusted directive in ssh_config(5) for more information. -x Disables X11 forwarding. -Y Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls. -y Send log information using the syslog(3) system module. By default this information is sent to stderr
My experience has been that -Y often works here, but that -X mostly doesn't. So I use -Y, as sparingly as I can.
On 10/17/2013 09:44 AM, Beartooth wrote:
-X Enables X11 forwarding. This can also be specified on a per-host basis in a configuration file.
Yes, I know it can be done; that's why I didn't tell you that you were trying something that doesn't work. I was just pointing out that it's not the default, and making sure you'd activated it.
On Tue, Oct 15, 2013 at 05:04:26PM +0000, Beartooth wrote:
My old Thinkpad T30 (on which I ran fedup from F18 to F19) is beginning to seem like more effort than it's worth, ever if eventual success of the effort were a sure thing. Is there a FedDown lurking out there somewhere?
You can always try `yum --releasever=18 distro-sync'. But it goes without saying, there are no guarantees whatsover.
That said, could you elaborate your actual problem? Maybe then someone can help.
On Wed, 16 Oct 2013 18:00:11 +0200, Suvayu Ali wrote:
On Tue, Oct 15, 2013 at 05:04:26PM +0000, Beartooth wrote:
My old Thinkpad T30 (on which I ran fedup from F18 to F19) is beginning to seem like more effort than it's worth, ever if eventual success of the effort were a sure thing. Is there a FedDown lurking out there somewhere?
You can always try `yum --releasever=18 distro-sync'. But it goes without saying, there are no guarantees whatsover.
That said, could you elaborate your actual problem? Maybe then someone can help.
I'll try, and also refer you to a thread I began Sunday, called "F19 : getting to GUI (or anywhere)," in case I omit anything.
I had F18 running fine, till I did a fedup (by the website) to F19. It seemed to finish, and claimed success. I rebooted. The display that came up was way, way oversize. I did Ctrl-Alt-F1 (or maybe F2; I disremember); it helped, and the display has been more like normal size since.
The text displays in a very dim pink-orange-brown color, reminiscent of a flashlight whose batteries are almost dead, with the green OK of the boot messages barely discernible. (I have it plugged into a UPS.)
It rarely finishes booting, or else abandons the display. At first it stopped when it hit sendmail; now it stops after saying it has installed an ABRT core dump hook (whatever that is).
In any case, it fails to show a login screen. It responds to ssh over my LAN; so I can log in that way. Here's another attempt to work over ssh -Y (which didn't affect the display on the T30's own monitor).
[root@T30 ~]# xinit
X.Org X Server 1.14.3 Release Date: 2013-09-12 X Protocol Version 11, Revision 0 Build Operating System: 3.10.9-200.fc19.x86_64 Current Operating System: Linux T30.localdomain 3.11.1-200.fc19.i686.PAE #1 SMP Sat Sep 14 15:20:42 UTC 2013 i686 Kernel command line: BOOT_IMAGE=/vmlinuz-0- rescue-1d7352e603b24d77a5b516b0204a434a root=/dev/mapper/vg_t30-lv_root ro rd.md=0 rd.dm=0 KEYTABLE=us SYSFONT=True rd.lvm.lv=vg_t30/lv_swap rd.luks=0 LANG=en_US.UTF-8 rd.lvm.lv=vg_t30/lv_root rhgb quiet Build Date: 16 September 2013 12:43:28AM Build ID: xorg-x11-server 1.14.3-1.fc19 Current version of pixman: 0.30.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed Oct 16 16:35:33 2013 (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension XFree86-VidModeExtension Initializing built-in extension XFree86-DGA Initializing built-in extension XFree86-DRI Initializing built-in extension DRI2 Loading extension GLX (II) [KMS] Kernel modesetting enabled. The XKEYBOARD keymap compiler (xkbcomp) reports:
Internal error: Could not resolve keysym XF86AudioMicMute
Errors from xkbcomp are not fatal to the X server The XKEYBOARD keymap compiler (xkbcomp) reports:
Internal error: Could not resolve keysym XF86AudioMicMute
Errors from xkbcomp are not fatal to the X server xinit: Unable to run program "xterm": No such file or directory Specify a program on the command line or make sure that /usr/bin is in your path.
xinit: connection to X server lost
waiting for X server to shut down (EE) Server terminated successfully (0). Closing log file
[root@T30 ~]#
On Wed, 16 Oct 2013 18:00:11 +0200, Suvayu Ali wrote:
On Tue, Oct 15, 2013 at 05:04:26PM +0000, Beartooth wrote:
Is there a FedDown lurking out there somewhere?
You can always try `yum --releasever=18 distro-sync'. But it goes without saying, there are no guarantees whatsover.
Well, I ran it once, and it gave me a lot of errors, then suggested the usual rpm command and the --skipbroken command. I ran the rpm command, then "yum clean all" for good measure; then I arrowed up to the command above, and added --skipbroken to it.
Next time I looked, it was racing through its items faster than I've ever seen it do, on and on, and on. I fact, it's still doing it. If anyone had told me all this fifty years ago, I wouldn't've believed a word of it.
I think, assuming this succeeds, that it's time to go through the lists in yumex or packagekit, looking for things I know I never use, and uninstalling them on general principles.
MUCH LATER (in fact, next day): I left it still running when I went to bed. This morning it had stopped, saying that it had been killed, but not when nor why. I restarted it, and it's still running.
On 10/20/2013 12:04 PM, Beartooth wrote:
On Wed, 16 Oct 2013 18:00:11 +0200, Suvayu Ali wrote:
On Tue, Oct 15, 2013 at 05:04:26PM +0000, Beartooth wrote:
Is there a FedDown lurking out there somewhere?
You can always try `yum --releasever=18 distro-sync'. But it goes without saying, there are no guarantees whatsover.
Well, I ran it once, and it gave me a lot of errors, then suggested the usual rpm command and the --skipbroken command. I ran the rpm command, then "yum clean all" for good measure; then I arrowed up to the command above, and added --skipbroken to it.
Next time I looked, it was racing through its items faster than I've ever seen it do, on and on, and on. I fact, it's still doing it. If anyone had told me all this fifty years ago, I wouldn't've believed a word of it.
I think, assuming this succeeds, that it's time to go through the lists in yumex or packagekit, looking for things I know I never use, and uninstalling them on general principles.
MUCH LATER (in fact, next day): I left it still running when I went to bed. This morning it had stopped, saying that it had been killed, but not when nor why. I restarted it, and it's still running.
Hmmmm? I wonder if there's a yum command that will change a i686 system to a x86_64 system of the same release.
On 10/20/2013 02:28 PM, Chris Kloiber wrote:
# yum abracadabra *poof!*
:-P
On 10/20/2013 1:16 PM, Mark LaPierre wrote:
Hmmmm? I wonder if there's a yum command that will change a i686 system to a x86_64 system of the same release.
LOL!!!
On Wed, 16 Oct 2013 18:00:11 +0200, Suvayu Ali wrote:
On Tue, Oct 15, 2013 at 05:04:26PM +0000, Beartooth wrote:
My old Thinkpad T30 (on which I ran fedup from F18 to F19) is beginning to seem like more effort than it's worth, ever if eventual success of the effort were a sure thing. Is there a FedDown lurking out there somewhere?
You can always try `yum --releasever=18 distro-sync'. But it goes without saying, there are no guarantees whatsover.
It did it again. At some time in the night, after many hours of lists too fast to read, it got to
[....] --> Processing Dependency: libGL.so.1 for package: 1:qt- x11-4.8.5-8.fc18.i686 --> Processing Dependency: libGL.so.1 for package: fltk-1.3.0-8.fc18.i686 ---> Package net-tools.i686 0:2.0-0.6.20130109git.fc19 will be erased ---> Package nut-client.i686 0:2.6.5-12.fc19 will be erased Killed [root@T30 ~]#
I'm guessing I might as well go try CentOS ....
-
Beartooth -
Chris Kloiber -
Joe Zeff -
Mark LaPierre -
Michael D. Setzer II -
Suvayu Ali