Date: Mon, 30 Jul 2007 13:48:43 -0400
From: "Loeghmon T. Nejad" <loeghmon@gmail.com>
To: debian-user@lists.debian.org
Subject: Setfont
Message-ID: <666ccf3a0707301048w4c0bef1cn9825ba9336a3ecd2@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="----=_Part_37289_30857412.1185817723067"
------=_Part_37289_30857412.1185817723067
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi,
I have a minimal installation of Debian Etch (with xserver-xorg-core
installed) that gives me an error message when I run the script -at the
bottom of this email.
The message says,
"
setfont: command not found
mapscrn: command not found
"
Can you please tell me what I am doing wrong? This script is part of a
procedure that allows one to use Vim in Farsi -right to leftscript.
Thanksfor your help.
#!/bin/sh
#
# M. Ghassab Shiran
# Email: shiran@scn.de
#
# setup-io.farsi script for Linux.
#
# Execute this script during the startup or anytime as a superuser.
#
# Put any local setup commands in here.
#
INITTY=/dev/tty[1-7]
PATH=/sbin:/etc:/bin:/usr/sbin:/usr/bin
#
# kbd - Set the the console font and keyboard
# set numlock and set metabit mode on tty1 .. tty8
#
for tty in $INITTY
do
# setleds -D +num < $tty > /dev/null
setmetamode metabit < $tty > /dev/null
done
#
# Latin/Farsi keyboard/console
#
setfont far-a01.f16
mapscrn trivial
loadkeys us
# enable mapping
for tty in $INITTY
do
echo -n -e "\\033(K" >$tty
done
#---
--
Regards,
------=_Part_37289_30857412.1185817723067
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi,
I have a minimal installation of Debian Etch (with
xserver-xorg-core installed) that gives me an error message when I run the script -at the bottom of this
email.
The message says,
"
setfont: command not found
mapscrn: command not found
"
Can you please tell me what I am doing wrong? This script is part of a procedure that allows one to use Vim in Farsi -right to left- script.Thanks for your help.
#!/bin/sh
#
# M. Ghassab Shiran
# Email: shiran@scn.de
#
# setup-io.farsi script for Linux.
#
# Execute this script during the startup or anytime as a superuser.
#
# Put any local setup commands in here.
#
INITTY=/dev/tty[1-7]
PATH=/sbin:/etc:/bin:/usr/sbin:/usr/bin
#
# kbd - Set the the console font and keyboard
# set numlock and set metabit mode on tty1 .. tty8
#
for tty in $INITTY
do
# setleds -D +num < $tty > /dev/null
setmetamode metabit < $tty > /dev/null
done
#
# Latin/Farsi keyboard/console
#
setfont far-a01.f16
mapscrn trivial
loadkeys us
# enable mapping
for tty in $INITTY
do
echo -n -e "\\033(K" >$tty
done
#---
--
Regards,
------=_Part_37289_30857412.1185817723067--
Date: Mon, 30 Jul 2007 20:10:43 +0200
From: Florian Kulzer <florian.kulzer+debian@icfo.es>
To: debian-user@lists.debian.org
Subject: Re: utf8 Problems
Message-ID: <20070730181043.GA31248@localhost>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Jul 28, 2007 at 18:31:19 +0200, Bernhard Kuemel wrote:
> Hi debian-user!
>=20
> I converted to utf8 in the hope that my non ASCII character problems
> would disappear. They are now ... different.
Having your system on utf8 means that you should be able to display and
use all sorts of special characters, limited only by the fonts you have
installed. However, you still have to convert texts which are in
different encodings, especially since some applications do not declare
the used encoding properly. Often it is not even possible to declare the
encoding in a standardized way, for example in plain text files.
=20
> I used utf8migrationtool and locale now says:
>=20
> bernhard@b:~$ locale
> LANG=3Den_US.UTF-8
[ snip: The rest is en_US.UTF-8, too. ]
> I am in Austria, where we speak German, but I chose en because the
> German translations are often so ridiculous (in mc's config:
> 'verbose operation' gets 'redselige Vorgaenge', bash says 'getoetet'
> instead of 'killed', when a process get's killed).
>=20
> I chose US because I tought that was most used and thus most stable.
I do the same because I also do not like the translations; they just
seem stilted and unnatural to me. You can still use other locales for
some things, for example to have day-month-year dates, sensible paper
sizes, and POSIX numbers/sorting:
$ locale | grep -v en_US
LC_NUMERIC=3DPOSIX
LC_TIME=3Den_GB.UTF-8
LC_COLLATE=3DPOSIX
LC_PAPER=3Dde_DE.UTF-8
LC_ALL=3D
You can mix and match as you want, provided that you generated the
necessary locales. (dpkg-reconfigure locales)
> Now the problems:
>=20
> I wanted to print a German text containing umlauts from a web page.
> I marked it in iceweasel and pasted it into a 'konsole' running bash
> running 'cat >x'. 'lpr x' printed only a page with the character 'K'.
>=20
> 'hexdump -C x' says:
>=20
> 00000010 20 20 20 20 20 20 4b fc 6e 64 69 67 75 6e 67 73 |
> K.ndigungs|
> 00000020 62 65 73 63 68 72 e4 6e 6b 75 6e 67 65 6e 0a 0a
> |beschr.nkungen..|
>=20
> so ü is 0xfc, ä is 0xf4, and the characters are printed as
0xe4 (typo)
> periods '.'.
Those are the iso8859-1 codes for "=C3=BC" and "=C3=A4":
$ echo -n "=C3=BC=C3=A4" | iconv -f utf8 -t iso8859-1 | hd
00000000 fc e4 |..|
00000002
Here I used "iconv" to convert the uft8 output of echo to the iso8859-1
encoding. You can use it the other way round to convert the text from
the website to utf8:
iconv -f iso8859-1 -t utf8 | icat >x
It is probably possible to omit the "-t utf8" declaration since iconv
should just consult the locale setting if "to" or "from" are not
explicitly specified.
Other common encodings to try in such cases are iso8859-15 (if the text
has Euro symbols) and cp1250 (a Microsoft codepage). "iconv -l" will
give you a full listing of all supported encodings.
> mc's viewer says:
>=20
> 00000010 20 20 20 20 20 20 4B FC 6E 64 69 67 75 6E 67 73
> K=C3=83=C2=BCndigungs
> 00000020 62 65 73 63 68 72 E4 6E 6B 75 6E 67 65 6E 0A 0A
> beschr=C3=83=C2=A4nkungen..
>=20
> Here ü is still only the single byte 0xFC, but it gets printed
> as 'A' with a tilde and a '1/4' character. ä is again 0xE4 but
> printed as 'A' with a tilde and a circle with 4 short lines
> extending from the circle diagonally.
That is very strange: Two-character sequences like "=C3=83=C2=BC" are norma=
lly the
symptom of interpreting an utf8-encoded special character as if the text
was in an iso* encoding instead. (utf8 uses multi-byte sequences for
special characters.)
$ echo "=C3=BC=C3=A4" | iconv -f iso8859-1 -t utf8
=C3=83=C2=BC=C3=83=C2=A4
(To demonstrate this, I deliberate told iconv to misinterpret the uft8
output of echo as being in iso8859-1.)
It looks like mc recognizes that there are iso8859-1 encoded characters,
converts them internally to utf8 and then fails in the last step by
interpreting the converted characters as iso8859-1 again. This is either
a bug of mc or a configuration problem.
> Opening x in openoffice writer shows rhombuses with question marks
> for each umlaut.
That is the proper reaction: Your text has bytes in it which make no
sense in utf8 and therefore a "this makes no sense" placeholder is
displayed. Your terminal should react in the same way:
$ echo "=C3=BC=C3=A4" | iconv -f utf8 -t iso8859-1
=EF=BF=BD=EF=BF=BD
> Opening x.html in openoffice writer I was unable to remove all the
> table etc. stuff and so was unable to reformat the text so it would
> fit on one page. Hmm, it might work, if I copied the text from there
> into a new document. But here I want to solve the locale problems,
> or what should I call the problem?
It is an encoding problem. The webpage does not declare it properly, the
browser screws it up or the copy/paste mechanism gets confused. The
safest approach is to save the page as html or txt (depending on whether
you want to preserve some formatting) and convert it to utf8 with iconv;
some trial-and-error might be necessary to figure which encoding was
used. (If you absolutely want to rule out screw-ups of your browser then
you have to use wget to download the page.)
=20
> mc (midnight commander, a norton commander clone) of course goes
> crazy again, but I was not surprised and accepted that it prints 'a'
> with '^' instead of line art, etc. More serious was that when I
> 'ssh'ed to a different computer (not sure which) it got confused
> about which line it was on and I messed up editing /etc/fstab.
Regarding mc: see above. The ssh problem might indicate that you do not
set all environmental variables properly on the remote machine.
=20
> man gets quote characters wrong, printing 'a' with '^' instead and
> so does gcc.
Can you give an example or do you see this with all manpages?
=20
> I also have problems with kvirc. IIRC I can get it to display
> iso8859-1 correctly, but not utf8, and the smart utf8/iso8859-1 mode
> does not work. I chat with users who use iso8859-1 and utf8.
Maybe your KDE does not get the proper locale setting. (It does not read
all the shell initialization files.) Does it help if you start kvirc
=66rom the konsole?
=20
> Is there a package which is responsible for all these problems so I
> can file a bug report against it? Or are these bugs in konsole, gcc,
> man, bash, mc, iceweasel, openoffice and kvirc? Or ... is the bug
> sitting in front of the computer again :)?
You may have a screw-up with environmental variables somewhere. What is
in your /etc/default/locale configuration file? Do you still have an old
/etc/environment hanging round?
> I wonder if it's easier to set up debian from scratch.
Normally that should not be necessary. When I migrated my laptop to utf8
I simply generated the new *.UTF-8 locales and set LANG and the LC_*
environmental variables accordingly. (I never use special characters in
filenames and that saved me a lot of work, of course.)
[...]
--=20
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |
Date: Mon, 30 Jul 2007 12:19:57 -0700
From: Bob McGowan <bob_mcgowan@symantec.com>
To: debian-user@lists.debian.org
Subject: Re: curses-interface ftp client with resume?
Message-ID: <46AE39DD.6070900@symantec.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080506040207000607020809"
This is a cryptographically signed message in MIME format.
--------------ms080506040207000607020809
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Douglas Allan Tutty wrote:
> On Sun, Jul 29, 2007 at 10:51:14PM +0300, Andrei Popescu wrote:
>> On Sat, Jul 28, 2007 at 09:44:28PM -0400, Douglas Allan Tutty wrote:
>>> I'm on dialup and often access the internet via a slow computer by
>>> sshing into my fast computer (which has the modem).
>>>
>>> Right now, if I want to download something like an iso file via ftp
>>> (there being no rsync mirror available), I put the url in a file, e.g.
>> No torrents either?
>
> No. For my current download, I found a mirror that also offers rsync
> (although it doesn't advertise it). However, lots of things are
> available via FTP that aren't available any other way.
>
>>> 3. It would be nice to have a curses interface like mc that lets me
>>> browse to the correct file, then tag the file for downloading which puts
>>> it into the above queue.
>> AFAIK mc can do ftp. I didn't use it much, but it might do most of what
>> you need.
>
> mc can't resume; it only wants to overwrite, append, or cancel.
>
> Doug.
>
>
There is, in addition to the 'ncftp' package, an 'ncftp2', described as
an older version, but with an ncurses interface. If it supports the
same r similar feature set as ncftp, then it should be able to resume, etc.
I use ncftp, so am not familiar with ncftp2, I just know it exists.
--
Bob McGowan
--------------ms080506040207000607020809
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJHzCC
AuowggJToAMCAQICEGJ01+eLADj0JJQQ6mYYD7YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDkwNzIzMjIwM1oX
DTA3MDkwNzIzMjIwM1owSjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEnMCUG
CSqGSIb3DQEJARYYYm9iX21jZ293YW5Ac3ltYW50ZWMuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAreE3QGsl+S8sSMa+47mwvSsRUXRo7nAxCuPyO82co6aKIj3HfHpt
ad6Ct6JWTjWb6RHzkf5H5UvrlBxi1QhlLe5hALcdFNekO5vbtWSNAsQAUfEiPe4b1e7iOCNY
zefbNaEgM4yQX6zSZEhPAdSq4bU4cXbyxmw3lVA48AdhA/M18fCQ4Q/DfRNit72Iy2f3isSE
d8k2YI/Iq1vks9be2+3/5hR2adqfGUKwBP8/JIFsaB0dngifOTlwOOLQyVV4zCiCVlhIK/NI
ZIa6ldIU7Bs9QxauOoF9gIuOP/RaEPMrfrUMPMpJkSyqijAj0zsKBBEeftmIgkE9x1T7UrMN
0QIDAQABozUwMzAjBgNVHREEHDAagRhib2JfbWNnb3dhbkBzeW1hbnRlYy5jb20wDAYDVR0T
AQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBkb7U/3ygdvn5n2H+1RFgerZkdQf4s5UwGwT4c
bFCynmuyekDmTcwPneekzPuYtVcrJXQRz2FGNyW7bZlZS7IG2Q5sxlc4lRX5O/H5XgzUOW3a
dAInokaS9OUioMv/HJ48cBt0ldLYQmrYPL+gVah6yWbJWxCZhOMgU8b9tU385zCCAuowggJT
oAMCAQICEGJ01+eLADj0JJQQ6mYYD7YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDkwNzIzMjIwM1oXDTA3MDkw
NzIzMjIwM1owSjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEnMCUGCSqGSIb3
DQEJARYYYm9iX21jZ293YW5Ac3ltYW50ZWMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAreE3QGsl+S8sSMa+47mwvSsRUXRo7nAxCuPyO82co6aKIj3HfHptad6Ct6JW
TjWb6RHzkf5H5UvrlBxi1QhlLe5hALcdFNekO5vbtWSNAsQAUfEiPe4b1e7iOCNYzefbNaEg
M4yQX6zSZEhPAdSq4bU4cXbyxmw3lVA48AdhA/M18fCQ4Q/DfRNit72Iy2f3isSEd8k2YI/I
q1vks9be2+3/5hR2adqfGUKwBP8/JIFsaB0dngifOTlwOOLQyVV4zCiCVlhIK/NIZIa6ldIU
7Bs9QxauOoF9gIuOP/RaEPMrfrUMPMpJkSyqijAj0zsKBBEeftmIgkE9x1T7UrMN0QIDAQAB
ozUwMzAjBgNVHREEHDAagRhib2JfbWNnb3dhbkBzeW1hbnRlYy5jb20wDAYDVR0TAQH/BAIw
ADANBgkqhkiG9w0BAQUFAAOBgQBkb7U/3ygdvn5n2H+1RFgerZkdQf4s5UwGwT4cbFCynmuy
ekDmTcwPneekzPuYtVcrJXQRz2FGNyW7bZlZS7IG2Q5sxlc4lRX5O/H5XgzUOW3adAInokaS
9OUioMv/HJ48cBt0ldLYQmrYPL+gVah6yWbJWxCZhOMgU8b9tU385zCCAz8wggKooAMCAQIC
AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh
cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm
BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h
aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV
BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD
EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B
1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A
gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E
CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa
MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M
DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa
C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1
3iSx0x1G/11fZU8xggNkMIIDYAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQQIQYnTX54sAOPQklBDqZhgPtjAJBgUrDgMCGgUAoIIBwzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA3MzAxOTE5NTdaMCMG
CSqGSIb3DQEJBDEWBBQ9X1dOyfnyhMcXIcSVVH6lcS1tqjBSBgkqhkiG9w0BCQ8xRTBDMAoG
CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq
hkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc
VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs
IEZyZWVtYWlsIElzc3VpbmcgQ0ECEGJ01+eLADj0JJQQ6mYYD7YwgYcGCyqGSIb3DQEJEAIL
MXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGJ0
1+eLADj0JJQQ6mYYD7YwDQYJKoZIhvcNAQEBBQAEggEAN1CEjokXDu5Pc/cQOLgmx5yfRNHc
KnrPLwQgfRx0qHCIseEMkhPFtFbqQ1o/LZYrjqrIrcltEblwBl92PvTn9M0cBp7rw/03qIbf
uikRdDeRwlE8w1V50Km5Bc4fk0JVZqq/SDGo6LrNrzk3Y85NGB1D/tTePPYtd5nXIxwGQQSq
rqqJ5Vx48v6Pkz9Vez21Pmq09/Lv/krSy/oCTBLrlbPtKEuwWkiP9DtqNcBTUXnFX4EOp7Q9
DH6/2Ggh65F8IU9zPUcZZ1OAtLqzebLwfU9EUqnpFLUG6v/bWIEPwZ3R0MI70Ba2BFoRUKUi
DW065gU2mDRWkz6+dITyQYWdWQAAAAAAAA==
--------------ms080506040207000607020809--
Date: Mon, 30 Jul 2007 19:50:05 +0100
From: Wackojacko <wackojacko32@ntlworld.com>
To: debian-user@lists.debian.org
Cc: debian user <debian-user@lists.debian.org>
Subject: Re: problems installing with 'writemaster' CDROM
Message-ID: <46AE32DD.6080409@ntlworld.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
michael wrote:
> On Sat, 2007-07-28 at 18:03 +0100, Wackojacko wrote:
>> michael wrote:
>>
>> <snip lspci output showing ICH8 controller>
>>> iTCO_wdt 20625 0
>>> iTCO_vendor_support 12741 1 iTCO_wdt
>>> snd_page_alloc 19025 2 snd_hda_intel,snd_pcm
>>> i2c_core 35777 1 i2c_i801
>>> rtc_cmos 17017 0
>>> sr_mod 26853 0
>>> cdrom 44009 1 sr_mod
>>> sg 45673 0
>>> dm_snapshot 25609 0
>>> dm_zero 10817 0
>>> dm_mirror 30785 0
>>> dm_mod 68785 9
>>> dm_multipath,dm_snapshot,dm_zero,dm_mirror
>>> pata_marvell 16449 0
>>> ata_piix 25413 3
>>> ata_generic 17221 0
>>> libata 137201 3 pata_marvell,ata_piix,ata_generic
>>> sd_mod 37441 5
>>> scsi_mod 168697 4 sr_mod,sg,libata,sd_mod
>>> ext3 141905 2
>>> jbd 73009 1 ext3
>>> mbcache 18249 1 ext3
>>> ehci_hcd 42957 0
>>> ohci_hcd 30405 0
>>> uhci_hcd 34401 0
>> It would appear from this, and other info in subsequent e-mails, that
>> you need to load the 'ata_piix' module. When the install stalls do
>> Ctrl+Alt+F2 to get to another terminal and 'modprobe ata_piix'.
>> Apologies if you have already tried this.
>
> I hadn't tried that particular module, but doesn't help :(
>
>
>> There is a possibility that the etch kernel is not new enough for this
>> MB, what kernel does fedora run on? If this is the case you may need a
>> custom installer, google is your friend here.
>
> 2.6.22.1-33.fc7
>
>
That's probably the reason then if the box is very new. Look for a
custom installer or, if the box is not mission critical, try the testing
installer which should have a newer kernel.
HTH
Wackojacko.
Date: Mon, 30 Jul 2007 19:55:57 +0100
From: Wackojacko <wackojacko32@ntlworld.com>
To: debian user <debian-user@lists.debian.org>
Subject: Re: Debian4 network install woes [WAS: problems installing with 'writemaster'
CDROM]
Message-ID: <46AE343D.2020909@ntlworld.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
michael wrote:
> On Sat, 2007-07-28 at 18:01 +0100, michael wrote:
>> On Sat, 2007-07-28 at 14:47 +0100, Wackojacko wrote:
>>> michael wrote:
>>>> Folks, I've a new machine
>>> Its likely that the machine has more bearing on this problem than the
>>> CDROM itself. We need more information regarding the Motherboard and in
>>> particular the IDE or SATA chip the drive is connected to.
>>>
>>>> with a "writemaster" CDROM drive. When trying
>>>> to install Debian 4.0 from iso image burnt to CD, it initially
>>>> recognises the CD and starts the installation but fails at the screen
>>>> where the CD drive is to be recognised (for continuing the
>>>> installation). I've tried various module/device combos but all to no
>>>> avail. I've looked about on Google but not come up with a working
>>>> solution.
>>>>
>>>> Has anybody else successfully uses this CDROM drive to install Debian,
>>>> or have suggestions on how I can determine a working module/device
>>>> combo. Please let me know if you need any further information.
>> here's some more info (snippets from 'dmesg'):
>> sd 1:0:0:0: [sdb] Attached SCSI disk
>> ata_piix 0000:00:1f.5: MAP [ P0 P2 P1 P3 ]
>> ACPI: PCI Interrupt 0000:00:1f.5[A] -> GSI 19 (level, low) -> IRQ 19
>> PCI: Setting latency timer of device 0000:00:1f.5 to 64
>> scsi2 : ata_piix
>> scsi3 : ata_piix
>> ata3: SATA max UDMA/133 cmd 0x0000000000012128 ctl 0x000000000001214e
>> bmdma 0x00000000000120f0 irq 19
>> ata4: SATA max UDMA/133 cmd 0x0000000000012120 ctl 0x000000000001214a
>> bmdma 0x00000000000120f8 irq 19
>> ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 17 (level, low) -> IRQ 17
>> PCI: Setting latency timer of device 0000:02:00.0 to 64
>> scsi4 : pata_marvell
>> scsi5 : pata_marvell
>> ata5: PATA max UDMA/100 cmd 0x0000000000011018 ctl 0x0000000000011026
>> bmdma 0x0000000000011000 irq 17
>> ata6: DUMMY
>> BAR5:00:00 01:7F 02:22 03:CA 04:00 05:00 06:00 07:00 08:00 09:00 0A:00
>> 0B:00 0C:01 0D:00 0E:00 0F:00
>> ata5.00: ATAPI: TSSTcorpCD/DVDW SH-S182M, SB03, max UDMA/33
>> ata5.00: configured for UDMA/33
>> scsi 4:0:0:0: CD-ROM TSSTcorp CD/DVDW SH-S182M SB03 PQ: 0
>> ANSI: 5
>> device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised:
>> dm-devel@redhat.com
>> kjournald starting. Commit interval 5 seconds
>> EXT3-fs: mounted filesystem with ordered data mode.
>>
>> sd 0:0:0:0: Attached scsi generic sg0 type 0
>> sd 1:0:0:0: Attached scsi generic sg1 type 0
>> scsi 4:0:0:0: Attached scsi generic sg2 type 5
>> sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
>> Uniform CD-ROM driver Revision: 3.20
>> sr 4:0:0:0: Attached scsi CD-ROM sr0
>> rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
>> rtc0: alarms up to one month
>> iTCO_vendor_support: vendor-support=0
>> ACPI: PCI Interrupt 0000:06:03.0[A] -> GSI 19 (level, low) -> IRQ 19
>> iTCO_wdt: Intel TCO WatchDog Timer Driver v1.01 (21-Jan-2007)
>> iTCO_wdt: Found a ICH8DO TCO device (Version=2, TCOBASE=0x0460)
>> iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
>> Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
>> Copyright (c) 1999-2006 Intel Corporation.
>> ACPI: PCI Interrupt 0000:00:19.0[A] -> GSI 20 (level, low) -> IRQ 20
>> PCI: Setting latency timer of device 0000:00:19.0 to 64
>> Floppy drive(s): fd0 is 1.44M
>> parport_pc 00:09: reported by Plug and Play ACPI
>> parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE]
>> FDC 0 is a National Semiconductor PC87306
>>
>> cdrom: sr0: mrw address space DMA selected
>> ISO 9660 Extensions: Microsoft Joliet Level 3
>> ISO 9660 Extensions: RRIP_1991A
>> SELinux: initialized (dev sr0, type iso9660), uses genfs_contexts
>>
>
> As W-J, suggested, I've tried a Ubuntu installation CD which does indeed
> detect and use the CDROM okay. Here's a snippet of the syslog:
> Jul 30 14:05:42 kernel: [ 3.554527] scsi 4:0:0:0: CD-ROM
> TSSTcorp CD/DVDW SH-S182M SB03 PQ: 0 ANSI: 5
> Jul 30 14:05:42 kernel: [ 3.562154] SCSI device sda: 976773168 512-byte hdwr sectors (500108 MB)
> Jul 30 14:05:42 kernel: [ 3.562163] sda: Write Protect is off
> Jul 30 14:05:42 kernel: [ 3.562165] sda: Mode Sense: 00 3a 00 00
> Jul 30 14:05:42 kernel: [ 3.562174] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> Jul 30 14:05:42 kernel: ce sda: 976773168 512-byte hdwr sectors (500108 MB)
> Jul 30 14:05:42 kernel: [ 3.562208] sda: Write Protect is off
> Jul 30 14:05:42 kernel: [ 3.562209] sda: Mode Sense: 00 3a 00 00
> Jul 30 14:05:42 kernel: [ 3.562217] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> Jul 30 14:05:42 kernel: [ 3.562220] sda: sda1 sda2
> Jul 30 14:05:42 kernel: [ 3.581569] sd 0:0:0:0: Attached scsi disk sda
> Jul 30 14:05:42 kernel: [ 3.581647] SCSI device sdb: 1465149168 512-byte hdwr sectors (750156 MB)
> Jul 30 14:05:42 kernel: [ 3.581653] sdb: Write Protect is off
> Jul 30 14:05:42 kernel: [ 3.581654] sdb: Mode Sense: 00 3a 00 00
> Jul 30 14:05:42 kernel: [ 3.581663] SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> Jul 30 14:05:42 kernel: [ 3.581685] SCSI device sdb: 1465149168 512-byte hdwr sectors (750156 MB)
> Jul 30 14:05:42 kernel: [ 3.581690] sdb: Write Protect is off
> Jul 30 14:05:42 kernel: [ 3.581692] sdb: Mode Sense: 00 3a 00 00
> Jul 30 14:05:42 kernel: [ 3.581700] SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> Jul 30 14:05:42 kernel: [ 3.581702] sdb: sdb1
> Jul 30 14:05:42 kernel: [ 3.598588] sd 1:0:0:0: Attached scsi disk sdb
> Jul 30 14:05:42 kernel: [ 3.600403] sd 0:0:0:0: Attached scsi generic sg0 type 0
> Jul 30 14:05:42 kernel: [ 3.600470] sd 1:0:0:0: Attached scsi generic sg1 type 0
> Jul 30 14:05:42 kernel: [ 3.600539] sr 4:0:0:0: Attached scsi generic sg2 type 5
> Jul 30 14:05:42 kernel: [ 3.604923] sr0: scsi3-mmc drive: 32x/40x writer dvd-ram cd/rw xa/form2 cdda tray
> Jul 30 14:05:42 kernel: [ 3.604925] Uniform CD-ROM driver Revision: 3.20
> Jul 30 14:05:42 kernel: [ 3.605010] sr 4:0:0:0: Attached scsi CD-ROM sr0
>
>
> (not 100% sure that's all the relevant info...)
>
> any ideas? I've tried all I can think of and Googled endlessly...
>
> Thanks
> Michael
>
>
What kernel?
OK another option is to debootstrap (google for more info). You can
boot Ubuntu (maybe even from FC I'm not sure) and install debian etch
then update the kernel (if this is what's causing the problem) with one
from backports (www.backports.org?) or compiling from sources. You can
use debian sources from sid and kernel-package (make-kpkg command).
HTH
Wackojacko
Date: Mon, 30 Jul 2007 13:43:39 -0400
From: Douglas Allan Tutty <dtutty@porchlight.ca>
To: debian-user@lists.debian.org
Subject: Re: GTK+ File dialog hangs
Message-ID: <20070730174339.GA14125@titan>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Mon, Jul 30, 2007 at 12:35:08PM -0500, Ron Johnson wrote:
> The closest to that which I have seen is that the larger a directory
> gets, the longer it takes to open a GTK File dialog. And it just
> burns up the CPU. If there's more than 12000 files, the File dialog
> will "never" open.
>
Wow. I've never had a single directory with 12000 files. What file
dialog have you tried that does work? How do KDE file dialogs handle
it?
Doug.
End of debian-user-digest Digest V2007 Issue #2065
**************************************************
Received on Mon Jul 30 15:30:52 2007