Re: Squeeze System Bricked after Software Upgrades 09/04

2010-09-04 Thread Alex Kuklin
On 04.09.2010 17:50, Gilbert Sullivan wrote:
 I have a Panasonic subnotebook (CF-R3) that has been functioning
 superbly for months under Squeeze with Xfce/gdm. It has an integrated
 Intel video system and a Japanese / English keyboard with which I have
 used the standard kernel mapping (chosen during Expert install). This
 is Squeeze with no proprietary firmware and the stock repositories (no
 third party repositories, no non-free, all software installations
 throughout the history of the system on this OS being made through
 aptitude).

 This morning (09/04) after applying latest updates through aptitude, I
 rebooted the system. It hard locked after it started loading gdm. The
 REISUB key combination had no effect whatsoever on the system. I was
 unable to connect to it via Ethernet. I had to force it down with the
 power switch.

 I can boot into recovery mode. I used touch /forcefsck to get a file
 system check during a reboot. No errors reported.

1) show
a)`uname -a` output
b) `lspci` output

there are chances that the problem resides in new xorg drivers/code.
Next steps depend on you particular video card model.

-- 
Alex

 


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c826057@kuklin.ru



Re: Squeeze System Bricked after Software Upgrades 09/04

2010-09-04 Thread Gilbert Sullivan

On 09/04/2010 11:05 AM, Alex Kuklin wrote:


1) show
a)`uname -a` output
b) `lspci` output

there are chances that the problem resides in new xorg drivers/code.
Next steps depend on you particular video card model.



Thanks, Alex.

~# uname -a
Linux argh 2.6.32-5-686 #1 SMP Wed Aug 25 14:28:12 UTC 2010 i686 GNU/Linux

~# lspci
00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV 
Processor to I/O Controller (rev 02)
00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV 
Processor to I/O Controller (rev 02)
00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV 
Processor to I/O Controller (rev 02)
00:01.0 PCI bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV 
Processor to AGP Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM 
Integrated Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated 
Graphics Device (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM 
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 
EHCI Controller (rev 03)

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface 
Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE 
Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) 
SMBus Controller (rev 03)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM 
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
02:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)

02:05.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 88)
02:05.1 System peripheral: Ricoh Co Ltd R5C575 SD Bus Host Adapter

Sorry for the extra verbiage. I figured you only wanted video subsystem 
information, but I just redirected the output to a file on a flash drive 
and sneaker-netted it to the Dell. I figured I'd include it all instead 
of risking removing something that might have an outside chance of being 
useful.


Thank you for your time,
Gilbert


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4c82648e.6060...@comcast.net



Re: Squeeze System Bricked after Software Upgrades 09/04

2010-09-04 Thread Gilbert Sullivan

On 09/04/2010 11:07 AM, Damon L. Chesser wrote:

Not an exact solution, but perhaps you should not run testing as a
desktop:  http://www.debian.org/doc/FAQ/ch-choosing.en.html

Not meant to be snarky, just trying to say testing is for testing.


I understand what you're saying, but I made the switch to testing for a 
lot of reasons having to do with application functionality and (of 
course) curiosity. Besides, Debian testing has been a lot more solid for 
me on these systems than Ubuntu LTS was for me! It's all relative.


;-)

I take good care of my data, so even the worst a total system meltdown 
can do is to cost me a couple of hours configuration time. I love 
Squeeze partially because it's giving me a chance to see and work 
through an occasional issue. I've been able to troubleshoot my way 
through almost all of the problems I've run into using the man files and 
other references.




Now, on to something more helpful:  can you boot the machine into a live
distro of some sort, to verify that the machine it's self does not have
a failure?




I'll have to do a bit of rearranging to do that. It will probably be a 
couple of hours before I can try. I have to say that a hardware issue 
doesn't seem likely. It would be a heck of a coincidence. But I'll give 
it a shot.


Thanks,
Gilbert


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4c826697.2050...@comcast.net



Re: Squeeze System Bricked after Software Upgrades 09/04

2010-09-04 Thread Sven Joachim
On 2010-09-04 17:23 +0200, Gilbert Sullivan wrote:

 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM
 Integrated Graphics Device (rev 02)
 00:02.1 Display controller: Intel Corporation 82852/855GM Integrated
 Graphics Device (rev 02)

My crystal ball tells me that you've been hit by this change in the
kernel:

,
| linux-2.6 (2.6.32-21) unstable; urgency=high
| 
|   [ Ben Hutchings ]
|   [...]
|   * [x86] i915: Blacklist i830, i845, i855 for KMS
| (Closes: #568207, #582105, #593432, #593507)
`

So downgrading the kernel would be my first attempt.

Sven


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hbi5ttar@turtle.gmx.de



Re: Squeeze System Bricked after Software Upgrades 09/04

2010-09-04 Thread Damon L. Chesser
On Sat, 2010-09-04 at 10:50 -0400, Gilbert Sullivan wrote:
 I have a Panasonic subnotebook (CF-R3) that has been functioning 
 superbly for months under Squeeze with Xfce/gdm. It has an integrated 
 Intel video system and a Japanese / English keyboard with which I have 
 used the standard kernel mapping (chosen during Expert install). This is 
 Squeeze with no proprietary firmware and the stock repositories (no 
 third party repositories, no non-free, all software installations 
 throughout the history of the system on this OS being made through 
 aptitude).
 
 This morning (09/04) after applying latest updates through aptitude, I 
 rebooted the system. It hard locked after it started loading gdm. The 
 REISUB key combination had no effect whatsoever on the system. I was 
 unable to connect to it via Ethernet. I had to force it down with the 
 power switch.
 
 I can boot into recovery mode. I used touch /forcefsck to get a file 
 system check during a reboot. No errors reported.
 
 Below is the list of software upgrades applied this morning.
 
 --8-
 [INSTALL, DEPENDENCIES] libxapian22
 [UPGRADE] apt 0.7.25.3 - 0.8.0
 [UPGRADE] apt-utils 0.7.25.3 - 0.8.0
 [UPGRADE] aptitude 0.6.3-3 - 0.6.3-3.1
 [UPGRADE] aptitude-doc-en 0.6.3-3 - 0.6.3-3.1
 [UPGRADE] firmware-linux-free 2.6.32-20 - 2.6.32-21
 [UPGRADE] libept1 1.0.3 - 1.0.3+b1
 [UPGRADE] libldap-2.4-2 2.4.17-2.1 - 2.4.23-4
 [UPGRADE] libparted0debian1 2.3-1 - 2.3-2
 [UPGRADE] libsdl-gfx1.2-4 2.0.20-1 - 2.0.20-1.1
 [UPGRADE] linux-base 2.6.32-20 - 2.6.32-21
 [UPGRADE] linux-image-2.6.32-5-686 2.6.32-20 - 2.6.32-21
 [UPGRADE] python-apt 0.7.96.1 - 0.7.97.1
 [UPGRADE] python-gobject 2.21.1-2 - 2.21.4+is.2.21.3-1
 [UPGRADE] python-xapian 1.0.20-1 - 1.2.3-3
 [UPGRADE] xserver-common 2:1.7.7-3 - 2:1.7.7-4
 [UPGRADE] xserver-xephyr 2:1.7.7-3 - 2:1.7.7-4
 [UPGRADE] xserver-xorg-core 2:1.7.7-3 - 2:1.7.7-4
 --8-
 
 I have a very different notebook (Dell Precision M70) that has exactly 
 the same installation history. (I run them side-by-side, relying upon 
 the Panasonic system as an emergency backup if the Dell should fail.) No 
 problems ever running Squeeze on these systems other than some minor 
 issues in the Nouveau driver transition on the Dell system a couple of 
 months ago.
 
 I've tried examining dmesg output, /var/log/syslog, /var/log/Xorg.0.log 
 -- but, if there is evidence in there of why this is happening I'm not 
 seeing it. (I'm happy to admit that I've in well over my head on this, 
 though.)
 
  From the list of upgraded software I suppose that my problem is either 
 with the linux-image upgrade or with the xserver upgrades. 
 Unfortunately, I have no previous kernels from which to boot the system. 
 It does not have an optical drive, but I can attach one to a USB port 
 and boot another environment if need be. I have a feeling that this 
 isn't a hardware issue, though.
 
 Would someone be willing to lead me through troubleshooting? I'd really 
 appreciate it!
 
 

Not an exact solution, but perhaps you should not run testing as a
desktop:  http://www.debian.org/doc/FAQ/ch-choosing.en.html  

Not meant to be snarky, just trying to say testing is for testing.

Now, on to something more helpful:  can you boot the machine into a live
distro of some sort, to verify that the machine it's self does not have
a failure?


-- 
Damon
da...@damtek.com


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1283612859.2458.10.ca...@dam-mobile



Re: Squeeze System Bricked after Software Upgrades 09/04

2010-09-04 Thread Gilbert Sullivan

On 09/04/2010 11:36 AM, Sven Joachim wrote:

On 2010-09-04 17:23 +0200, Gilbert Sullivan wrote:


00:02.0 VGA compatible controller: Intel Corporation 82852/855GM
Integrated Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated
Graphics Device (rev 02)


My crystal ball tells me that you've been hit by this change in the
kernel:

,
| linux-2.6 (2.6.32-21) unstable; urgency=high
|
|   [ Ben Hutchings ]
|   [...]
|   * [x86] i915: Blacklist i830, i845, i855 for KMS
| (Closes: #568207, #582105, #593432, #593507)
`


Hi, Sven.

Ouch! That's so mean of them!

:P



So downgrading the kernel would be my first attempt.



I'm going to ask a couple of questions because I'm not quite sure how to 
even research them.


The situation right now is that the system isn't connected to a network. 
I gather that, in order to downgrade the kernel, I've got to manage to 
connect from a command line interface. Haven't done that before in 
Linux. I use wicd. I'm supposing it's time to do man ifup and man 
ifdown. I think I can get through that.


However, I've never downgraded a package. From what I can see it looks 
as though 'dpkg -i package.deb' is used, providing I can find out how to 
get the appropriate package. I just looked in /var/cache/apt/archives 
and didn't see the previous image in there. That would be my fault. I 
used 'aptitude purge ~c'. Doh! I've been blithely doing 'aptitude 
autoclean' and 'aptitude purge ~c' after each set of upgrades all along. 
I read that that was a good practice on the Debian users forum. Eh. 
Maybe not so much. I've been blindly trusting that I would be able to 
work my way around any new issues that came up with package upgrades.


But having my display subsystem blacklisted doesn't seem to be something 
I can work around.


Do you have any specific suggestions as to how I could go about this? Is 
it time to retire this subnotebook (at least from use with Debian)? I 
really don't much like the idea of staying locked at an earlier 
linux-image version due to the possibility of related security issues. 
(I guess they're rare, but I'd still prefer to be as up-to-date as 
possible.)


Many thanks to you,
Gilbert


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4c826e1c.5040...@comcast.net



Re: Squeeze System Bricked after Software Upgrades 09/04

2010-09-04 Thread Sven Joachim
On 2010-09-04 18:04 +0200, Gilbert Sullivan wrote:

 I'm going to ask a couple of questions because I'm not quite sure how
 to even research them.

 The situation right now is that the system isn't connected to a
 network. I gather that, in order to downgrade the kernel, I've got to
 manage to connect from a command line interface. Haven't done that
 before in Linux. I use wicd. I'm supposing it's time to do man ifup
 and man ifdown. I think I can get through that.

You could also try wicd-curses if that's installed, or use X with the
vesa driver.  Here's an /etc/X11/xorg.conf for that:

--8---cut here---start-8---
Section Device
Identifier  n
Driver  vesa
EndSection
--8---cut here---end---8---

 However, I've never downgraded a package. From what I can see it looks
 as though 'dpkg -i package.deb' is used, providing I can find out how
 to get the appropriate package.

It gets a bit more complicated if the package to be downgraded has tight
versioned dependencies forcing you to downgrade other packages, but that
is the basic recipe, and it should work in this case.

 I just looked in
 /var/cache/apt/archives and didn't see the previous image in
 there. That would be my fault. I used 'aptitude purge ~c'. Doh! I've
 been blithely doing 'aptitude autoclean' and 'aptitude purge ~c' after
 each set of upgrades all along. I read that that was a good practice
 on the Debian users forum. Eh. Maybe not so much. I've been blindly
 trusting that I would be able to work my way around any new issues
 that came up with package upgrades.

I run aptitude autoclean every once in a while, but only when I'm
reasonably sure there are no major problems with the currently installed
packages.

 But having my display subsystem blacklisted doesn't seem to be
 something I can work around.

 Do you have any specific suggestions as to how I could go about this?
 Is it time to retire this subnotebook (at least from use with Debian)?

It is a bit early to say this, but users of Intel 8xx graphics have been
hosed for a while due to frequent GPU lockups, and no satisfactory
solution has been found so far.

 I really don't much like the idea of staying locked at an earlier
 linux-image version due to the possibility of related security
 issues. (I guess they're rare, but I'd still prefer to be as
 up-to-date as possible.)

The downgraded kernel has a big security hole already (CVE-2010-2240),
but as long as you don't have malicious local users there is not too
much to worry about.

Sven


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878w3htqbh@turtle.gmx.de



Re: Squeeze System Bricked after Software Upgrades 09/04

2010-09-04 Thread Gilbert Sullivan

On 09/04/2010 12:40 PM, Sven Joachim wrote:

You could also try wicd-curses if that's installed, or use X with the
vesa driver.  Here's an /etc/X11/xorg.conf for that:

--8---cut here---start-8---
Section Device
Identifier  n
Driver  vesa
EndSection
--8---cut here---end---8---



Thanks, Sven! I got the Panasonic system connected using ifup, grabbed 
the 2.6.32-20 linux-image from the snapshot server, and transferred it 
from the Dell notebook to the Panasonic notebook over the network.


However, just as I was about to roll up my sleeves and really start 
messing the system up I got your response. I hadn't even thought about 
reverting to vesa using /etc/X11/xorg.conf.


I decided to experiment. The system seems to make an abortive attempt at 
loading gdm with a different login background from the one I have 
designated, and then it succeeds! I'm able to boot using the new kernel! 
Is there any reason why I shouldn't just continue this way (using vesa)?


I can see that the system is slightly slower than it was, but it 
honestly isn't enough to bother me. I use these systems strictly for 
office applications, e-mail, remote access to other systems, and Web 
browsing. Obviously with no proprietary stuff installed I don't use them 
for watching movies or playing games online or anything like that.



It gets a bit more complicated if the package to be downgraded has tight
versioned dependencies forcing you to downgrade other packages, but that
is the basic recipe, and it should work in this case.


I'll remember that if I decide to proceed with the kernel downgrade.


I run aptitude autoclean every once in a while, but only when I'm
reasonably sure there are no major problems with the currently installed
packages.


Maybe I'll be a little more circumspect about going all the way with 
upgrades from now on.


;-)


But having my display subsystem blacklisted doesn't seem to be
something I can work around.

Do you have any specific suggestions as to how I could go about this?
Is it time to retire this subnotebook (at least from use with Debian)?


It is a bit early to say this, but users of Intel 8xx graphics have been
hosed for a while due to frequent GPU lockups, and no satisfactory
solution has been found so far.


Yes. This is where I've really been pretty boneheaded. You see, I've 
seen Intel 8xx graphics users complaining bitterly for quite a while 
now, but I've never had the least bit of trouble with this system, and 
it gets used for many hours every day. I imagine I just don't use 
applications that tend to give rise to GPU lockups, but I'm running Xfce 
with all of the desktop compositing bells and whistles enabled.


Anyway, I've just been shrugging my shoulders and figuring that maybe 
there was something special about this Panasonic's particular 
implementation of the graphics hardware that wasn't subject to the 
problems people were seeing. It didn't occur to me that my display 
subsystem might get blacklisted at some point.



The downgraded kernel has a big security hole already (CVE-2010-2240),
but as long as you don't have malicious local users there is not too
much to worry about.


This is a single-user system, and I'm usually not malicious -- well, not 
intentionally anyway. As we've seen, sometimes stupidity can accomplish 
what one might ordinarily be tempted to attribute to malice.


:-D

I'm thinking I should just forge ahead using the vesa driver and keeping 
up with the updates. Do you think that's a tenable approach?


I really appreciate your help, Sven.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4c828277.5030...@comcast.net



Re: Squeeze System Bricked after Software Upgrades 09/04

2010-09-04 Thread Gilbert Sullivan

On 09/04/2010 11:07 AM, Damon L. Chesser wrote:

Now, on to something more helpful:  can you boot the machine into a live
distro of some sort, to verify that the machine it's self does not have
a failure?


Hi, Damon.

Just wanted to get back to you. The hardware is okay. Sven reminded me 
that I could use the vesa driver. (I had got used to not having an 
/etc/X11/xorg.conf file any more.) The system is working great now.


I appreciate your help.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4c828443.9010...@comcast.net



Re: Squeeze System Bricked after Software Upgrades 09/04

2010-09-04 Thread Damon L. Chesser
On Sat, 2010-09-04 at 13:31 -0400, Gilbert Sullivan wrote:
 On 09/04/2010 12:40 PM, Sven Joachim wrote:
  You could also try wicd-curses if that's installed, or use X with the
  vesa driver.  Here's an /etc/X11/xorg.conf for that:
 
  --8---cut here---start-8---
  Section Device
  Identifier  n
  Driver  vesa
  EndSection
  --8---cut here---end---8---
 
 
 Thanks, Sven! I got the Panasonic system connected using ifup, grabbed 
 the 2.6.32-20 linux-image from the snapshot server, and transferred it 
 from the Dell notebook to the Panasonic notebook over the network.
 
 However, just as I was about to roll up my sleeves and really start 
 messing the system up I got your response. I hadn't even thought about 
 reverting to vesa using /etc/X11/xorg.conf.
 
 I decided to experiment. The system seems to make an abortive attempt at 
 loading gdm with a different login background from the one I have 
 designated, and then it succeeds! I'm able to boot using the new kernel! 
 Is there any reason why I shouldn't just continue this way (using vesa)?
 
 I can see that the system is slightly slower than it was, but it 
 honestly isn't enough to bother me. I use these systems strictly for 
 office applications, e-mail, remote access to other systems, and Web 
 browsing. Obviously with no proprietary stuff installed I don't use them 
 for watching movies or playing games online or anything like that.
 
  It gets a bit more complicated if the package to be downgraded has tight
  versioned dependencies forcing you to downgrade other packages, but that
  is the basic recipe, and it should work in this case.
 
 I'll remember that if I decide to proceed with the kernel downgrade.
 
  I run aptitude autoclean every once in a while, but only when I'm
  reasonably sure there are no major problems with the currently installed
  packages.
 
 Maybe I'll be a little more circumspect about going all the way with 
 upgrades from now on.

Install apt-listbugs.  That way before the packages installs, you will
get a list of reported bugs against that package and you can decide if
you want to continue or not.

 
 ;-)
 
  But having my display subsystem blacklisted doesn't seem to be
  something I can work around.
 
  Do you have any specific suggestions as to how I could go about this?
  Is it time to retire this subnotebook (at least from use with Debian)?
 
  It is a bit early to say this, but users of Intel 8xx graphics have been
  hosed for a while due to frequent GPU lockups, and no satisfactory
  solution has been found so far.
 
 Yes. This is where I've really been pretty boneheaded. You see, I've 
 seen Intel 8xx graphics users complaining bitterly for quite a while 
 now, but I've never had the least bit of trouble with this system, and 
 it gets used for many hours every day. I imagine I just don't use 
 applications that tend to give rise to GPU lockups, but I'm running Xfce 
 with all of the desktop compositing bells and whistles enabled.
 
 Anyway, I've just been shrugging my shoulders and figuring that maybe 
 there was something special about this Panasonic's particular 
 implementation of the graphics hardware that wasn't subject to the 
 problems people were seeing. It didn't occur to me that my display 
 subsystem might get blacklisted at some point.
 
  The downgraded kernel has a big security hole already (CVE-2010-2240),
  but as long as you don't have malicious local users there is not too
  much to worry about.
 
 This is a single-user system, and I'm usually not malicious -- well, not 
 intentionally anyway. As we've seen, sometimes stupidity can accomplish 
 what one might ordinarily be tempted to attribute to malice.
 
 :-D
 
 I'm thinking I should just forge ahead using the vesa driver and keeping 
 up with the updates. Do you think that's a tenable approach?
 
 I really appreciate your help, Sven.
 
 


-- 
Damon
da...@damtek.com


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1283622259.16031.12.ca...@dam-main.hsd1.ga.comcast.net.



Re: Squeeze System Bricked after Software Upgrades 09/04

2010-09-04 Thread Gilbert Sullivan

On 09/04/2010 11:05 AM, Alex Kuklin wrote:

1) show
a)`uname -a` output
b) `lspci` output

there are chances that the problem resides in new xorg drivers/code.
Next steps depend on you particular video card model.


Hi, Alex.

The information you had me get via the 'uname -a' and 'lspci' commands 
provided the key. Sven saw it and pointed out the fact that the new 
kernel blacklists my video subsystem with kernel mode setting. Sven then 
reminded me that I could use the vesa video driver by using a simple 
/etc/X11/xorg.conf file. I've got the little computer up and running 
now, albeit a little more slowly that it used to run.


Many thanks for starting me down the right path.

Regards,
Gilbert


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4c828541.80...@comcast.net



Re: Squeeze System Bricked after Software Upgrades 09/04

2010-09-04 Thread Sven Joachim
On 2010-09-04 19:31 +0200, Gilbert Sullivan wrote:

 However, just as I was about to roll up my sleeves and really start
 messing the system up I got your response. I hadn't even thought about
 reverting to vesa using /etc/X11/xorg.conf.

 I decided to experiment. The system seems to make an abortive attempt
 at loading gdm with a different login background from the one I have
 designated, and then it succeeds! I'm able to boot using the new
 kernel! Is there any reason why I shouldn't just continue this way
 (using vesa)?

Well, if the disadvantages of vesa do not bother you.  It's slow and may
not support your display's native resolution, but it works for basic 2D.

 I can see that the system is slightly slower than it was, but it
 honestly isn't enough to bother me. I use these systems strictly for
 office applications, e-mail, remote access to other systems, and Web
 browsing. Obviously with no proprietary stuff installed I don't use
 them for watching movies or playing games online or anything like
 that.

That's good, when I last had to use the vesa driver and watched a DVD
movie, I got warnings about dropped frames.  Well, that was six years
ago.

 I'm thinking I should just forge ahead using the vesa driver and
 keeping up with the updates. Do you think that's a tenable approach?

Just watch out for future kernels that may re-enable KMS, the vesa
driver is not compatible with that.  You will have to switch back to
intel (or fbdev) then.

Sven


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871v99tmly@turtle.gmx.de



Re: Squeeze System Bricked after Software Upgrades 09/04

2010-09-04 Thread Gilbert Sullivan

On 09/04/2010 01:44 PM, Damon L. Chesser wrote:

Install apt-listbugs.  That way before the packages installs, you will
get a list of reported bugs against that package and you can decide if
you want to continue or not.


Thank you for the heads-up on that. I actually have apt-listchanges 
installed and thought that it would have warned me of something like 
this. Apparently not. Either that, or I don't know how to use it.


Regards,
Gilbert


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4c82962d.1000...@comcast.net



Re: Squeeze System Bricked after Software Upgrades 09/04

2010-09-04 Thread Gilbert Sullivan

On 09/04/2010 02:00 PM, Sven Joachim wrote:

Well, if the disadvantages of vesa do not bother you.  It's slow and may
not support your display's native resolution, but it works for basic 2D.


I'm thinking I'll stick with vesa for now. And it does support this 
display's native resolution of 1024x768. The only slight drawback I have 
with it right now is that it seems to get a false start on loading the 
login screen, but then it comes up fine. Everything seems to work!



That's good, when I last had to use the vesa driver and watched a DVD
movie, I got warnings about dropped frames.  Well, that was six years
ago.


Everything should improve over six years. Well, everything except me, 
perhaps.



Just watch out for future kernels that may re-enable KMS, the vesa
driver is not compatible with that.  You will have to switch back to
intel (or fbdev) then.


I understand, I think. And switching back to intel or the framebuffer 
driver should simply be a matter of eliminating the little 
/etc/X11/xorg.conf file (or altering what's in it), I suppose.


Again, many thanks for your patience and expertise. Your posts are 
always a source of valuable information.


Regards,
Gilbert


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4c829817.9040...@comcast.net