Andreas Jaeger wrote:

What problems do you have?

This pertains to a ftp install. I didn't even get as far as running anything, or trying to compile anything. The MD5sums for the ispell American and British dictionaries seem to be wrong. kdebase3 also failed the MD5sum check, but that was picked up later during an online update. I suppose the ftp transfer of the kdebase rpm might have failed at first, but the two ispell dictionaries have failed the checksum consistently every time, and on several different mirrors. I pre-formatted my second drive in SuSE 9.0, XFS on all partitions. I did so because I wanted to try XFS, with varying journal sizes (see a comment below for the reasoning behind this), and the install doesn't allow that as far as I could tell. As I customarily do when installing a new version, I switch the two drives so /dev/hda is always the boot drive. This turned out to be a disaster. After the install was complete, I tried copying my data over from the 9.0 to the 9.3 installation, using recursive cp. The system locked up cold after a short while. This was actually my second warning bell, because a previous wget, under 9.0, targetted to that same partition also locked the system cold, after an equally short time. BTW, this brings up another point. Previously I had tried an ftp install of 9.2, several in fact, and every time I could not even get past downloading more than a couple of rpm's, so I guess by this time I have had 3 bells go off. Next an ordinary user starting up the graphical desktop (default runlevel is 3, desktop is KDE) could not do so: either xinit crashed, or something in KDE, most likely kwin, crashed, almost immediately. The result was a system that had the user still logged in, with all of his processes in uninterruptible sleep (status D in top). That user could no longer log in (the new console immediately went into uninterruptible sleep), but the administrator still could log in and everything seemed recoverable -- until I tried to reboot, that is. That locked the system up cold, presumably when the ordinary user's processes were being sent a KILL signal. The end result was a forced system reset (the nice friendly button on the front of the computer case, that is), and a totally corrupted /home partition. It could not be mounted, and xfs_repair just locked up. The /usr partition also wound up with a lot of errors on it, but at least it would mount. The /opt partition I didn't even bother to check. At that point, I umounted /home, and fired up badblocks because this partition had previously shown hard errors in the drive media, destructive mode (no point in trying to salvage what cannot even be read) -- the partition is fine, and continues to check OK with both destructive and non-destructive tests. Conclusion: either XFS in 9.0 is f***ed, or it is in 9.3 -- or there are incompatibilities between the two versions used in each of these SuSE releases. If that isn't it, then I have to say that XFS itself is rather susceptible to nonrecoverable errors in the event of a forced reboot -- but that goes against all that I have read on the Internet. Here are some typical formatting combinations I used, which may have some bearing on the matter (but I rather doubt it) root partition (520 MB) - blocksize 512b, journal size 2500 blocks (this runs roughly in agreement with some information I found on tweaking an XFS system to get better speed out of it). This partition suffered the least corruption of all, yet it includes both /var and /tmp. /home partition (4.9GB) - I think I just let mkfs.xfs use the defaults here, so 4KB blocksize and a journal size of 2560 blocks. /usr (4.9GB) - also default values. /data partition (target of the copy and wget that locked up, 61,6GB) - 4K blocks and a 32MB journal (8K blocks) I'm about to try another install of 9.3 in the next few days -- maybe I'll wait until mid-week when I can get some more CDRs, and fetch the 5 install iso files -- but I doubt I will be using XFS, unless it can be demonstrated conclusively to me that this won't all just happen again. Oh, and yes, my 9.0 kernel is the most recent available with YOU.

Carlos E. R. wrote:

The Friday 2005-07-01 at 16:55 -0600, Darryl Gregorash wrote:

I'm about to try another install of 9.3 in the next few days -- maybe I'll wait until mid-week when I can get some more CDRs, and fetch the 5 install iso files -- but I doubt I will be using XFS, unless it can be demonstrated conclusively to me that this won't all just happen again.

Nobody can demonstrate that.

Actually, not as difficult as you think. Just give me a reasonable amount of something more than mere anecdotal "evidence". I'll accept two standard deviations on any meaningful amount of real testing, as should anyone.

But I'm using 9.3 and several partitions types: ext3, reiserfs, xfs... no problems. I have done forced reboots several times (I'm trying suspend to disk and it crashes), and I haven't detected corruptions so far.

I certainly didn't say I have a problem in *not* writing to the drive.

Your system might have hardware problems of some kind; for example, bad memory can corrupt journalled filesystems.

Amazingly, any possible such hardware problem has never affected any Reiser partion I have, consistently destroys one particular XFS partition, and consistenly locks up the system when doing large-volume writes to another particular XFS partition. The partition that is destroyed is subsequently unrecognizable, and the other is so corrupted that, although it can be mounted and read, none of the files actually exist. xfs_repair is of no use with either one. No other XFS partition has ever had more than recoverable errors on it as a result of these crashes. No hardware error can ever produce such consistent failure to manifest itself with one file system, yet show such consistent presence and behaviour with a different file system. Even if the XFS driver is always loaded into one particular region in memory, and that region happens to have intermittent errors, on balance of probability, such consistency is impossible. As confirmed by significant testing, the drive is OK -- so what else is left?

On Friday 01 July 2005 20:04, Cristian Rodriguez wrote:

for DVDs in Linux screw the MPAA and ; do dig $DVDs.z.zoy.org ; done | \ perl -ne 's/\.//g; print pack("H224",$1) if(/^x([^z]*)/)' | gunzip

Very subversive. I love it.

Peter, On Saturday 02 July 2005 08:40, Peter B Van Campen wrote:

On Saturday 02 July 2005 00:04, Randall R Schulz wrote:

...

On Friday 01 July 2005 20:04, Cristian Rodriguez wrote: for DVDs in Linux screw the MPAA and; do dig $DVDs.z.zoy.org; done \ |perl -ne 's/\.//g; print pack("H224",$1) if(/^x([^z]*)/)' |gunzip

Very subversive. I love it.

Hi,

Comeon, share with the rest of us! :0)

Run the command pipeline from Cristian's signature and you'll see. Also, break it down to see the source of the data it outputs ("man dig", if necessary).

PeterB

Randall Schulz

Anders Johansson wrote:

On Saturday 02 July 2005 17:40, Peter B Van Campen wrote:

...

On Saturday 02 July 2005 00:04, Randall R Schulz wrote:

...

On Friday 01 July 2005 20:04, Cristian Rodriguez wrote:

...

for DVDs in Linux screw the MPAA and ; do dig $DVDs.z.zoy.org ; done

| \ perl -ne 's/\.//g; print pack("H224",$1) if(/^x([^z]*)/)' |

gunzip

Very subversive. I love it.

Hi,

Comeon, share with the rest of us! :0)

If you run that command it will print out the CSS decryption algorithm. Someone is using DNS to distribute libdvdcss :)

I guess something in the mailing messed it up for me. I get a file, but it's not in gzip format: for DVDs in Linux screw the MPAA and ; do dig $DVDs.z.zoy.org ; done| perl -ne 's/\.//g; print pack("H224",$1) if(/^x([^z]*)/)' |gunzip What did I lose? -- A lot of us are working harder than we want, at things we don't like to do. Why? ...In order to afford the sort of existence we don't care to live. -- Bradford Angier

On Saturday 02 July 2005 12:07, ken wrote:

...

for DVDs in Linux screw the MPAA and ; do dig $DVDs.z.zoy.org ; done| perl -ne 's/\.//g; print pack("H224",$1) if(/^x([^z]*)/)' |gunzip

What did I lose?

It never hurts to look at the code and understand what it's going to do, especially since you are, in effect, giving some other coder access to your shell. Put this in a file an execute it: -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- #!/bin/bash --norc for DVDs in Linux screw the MPAA and; do dig $DVDs.z.zoy.org; done \ |perl -ne 's/\.//g; print pack("H224",$1) if(/^x([^z]*)/)' \ |gunzip -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- Randall Schulz

Ken, On Saturday 02 July 2005 14:00, ken wrote:

Randall R Schulz wrote:

...

...

It never hurts to look at the code and understand what it's going to do, especially since you are, in effect, giving some other coder access to your shell.

Put this in a file an execute it:

...

Randall Schulz

Good points. Also, it's not a good idea to run any strange scripts as root. Personally, I created a user (called "test") which is used to run/test such scripts.

Not bad ideas. But this is a simple script. It's not hard to see whether it's going to have any untoward effects. Plus, it would be a pretty brazen way for Cristian to try to invade or damage unwary users' systems.

Back to the script itself.... I added a "set -x" above the code and got this output:

+ dig Linux.z.zoy.org + perl -ne 's/\.//g; print pack("H224",$1) if(/^x([^z]*)/)' + gunzip + dig screw.z.zoy.org + dig the.z.zoy.org + dig MPAA.z.zoy.org + dig and.z.zoy.org

Given the simplicity of the code, this is eminently predictable (up to the precise order of execution of processes joined by pipes).

gunzip: stdin: not in gzip format

This, however, is not. (Predictable, that is.) I hate to ask this, but you are running this on a Linux system, right? I know of ways to configure Cygwin, which will happily run this script, that might cause the symptom you're seeing. Anyway, try replacing the pipe into gunzip with a redirection into a file. Then use the "file" command to ascertain what sort of data is coming out of the perl stage of that script. You might also simply "less" that file. While it's surely fully of binary, less will protect you from that and if there's anything obvious, say diagnostics from perl, you'll see it.

So I'm still having the same problem, i.e., not in gzip format.

Of course, I could just send you the text produced on my system, but where's the fun in that? Randall Schulz

Ken: El Sáb 02 Jul 2005 16:00, ken escribió:

So I'm still having the same problem, i.e., not in gzip format.

I experienced similar problems which I found out were related to failed DNS server queries. If, for example, I run 'dig Linux.z.zoy.org', I get the following error: ; <<>> DiG 9.2.2 <<>> Linux.z.zoy.org ;; global options: printcmd ;; connection timed out; no servers could be reached This is true for every host name but 'and'; this last one returns the authoritative name servers for zoy.org, which helps to adjust the script: ==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- #!/bin/bash --norc for DVDs in Linux screw the MPAA and; do dig @ns1.zoy.org $DVDs.z.zoy.org; done \ | perl -ne 's/\.//g; print pack("H224",$1) if(/^x([^z]*)/)' \ | gunzip ==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- Instead of '@ns1.zoy.org' you can try with '@ns2.zoy.org ' and '@ns3.zoy.org'. Once the name server to be queried is being specified, the script runs fine on my PC. Regards, -- Andreas Philipp Noema Ltda. Bogotá, D.C. - Colombia http://www.noemasol.com

Ken, On Sunday 03 July 2005 03:25, ken wrote:

...

...

This is true for every host name but 'and'; this last one returns the authoritative name servers for zoy.org, which helps to adjust the script:

==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- #!/bin/bash --norc for DVDs in Linux screw the MPAA and; do dig @ns1.zoy.org $DVDs.z.zoy.org; done \

| perl -ne 's/\.//g; print pack("H224",$1) if(/^x([^z]*)/)' \ | gunzip

==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-

...

;; Query time: 262 msec ;; SERVER: 64.81.159.2#53(64.81.159.2) ;; WHEN: Sat Jul 2 17:09:51 2005 ;; MSG SIZE rcvd: 47

What's the perl part of the command/script supposed to do with this?

Once again, the code supplies the answer (obviously). The Perl code explicitly ignores lines that do not begin with an 'x' followed by characters other than 'z'. Before that, it removes all periods from the input. Now the lines it keeps (those starting with 'x') are simply hex-encoded data which the pack built-in turns into corresponding binary for gunzip. Randall Schulz

Ken, On Sunday 03 July 2005 07:28, ken wrote:

Randall R Schulz wrote:

...

Ken,

On Sunday 03 July 2005 03:25, ken wrote:

...

...

...

This is true for every host name but 'and'; this last one returns the authoritative name servers for zoy.org, which helps to adjust the script:

==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- #!/bin/bash --norc for DVDs in Linux screw the MPAA and; do dig @ns1.zoy.org $DVDs.z.zoy.org; done \

| perl -ne 's/\.//g; print pack("H224",$1) if(/^x([^z]*)/)' \ | gunzip

==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-

...

What I meant was that, after the parsing by perl, there's nothing left of the output (i.e., no output) from "dig and.z.zoy.org".

That's because you're not getting successful resolution of the DNS request. Did you run the script as modified by Andreas Philipp and shown above? Randall Schulz

Donn L Washburn wrote:

On Fri, 01 Jul 2005 16:54:07 +0100 Info wrote:

...

Was ruuning 8.2 and quite liked this distro. Decided to upgrade to 9.3. Wouldn't updgrade so had to install from scratch - big mistake!

Finding 9.3 very slow. Took install suggestions as far as disk configure is concerned but do not really understand what happened. Told it may be something to do with the way the disk(LVM) is configured? Open Office keeps falling over. Desktop hangs quite often - what does this remind you of? At least killing the X-server allows me to sign on again. Would like to be able to switch on/off NIS also network devices?

Seriously considering reverting to Fedora

I also agree. SuSE9.3 has been nothing but a headache. About 50% of the programs that compiled very clean under 9.2 fail to compile in 9.3. Try jpilot that worked under 9.2. The only way I got it to work was via a RPM. My guess is SuSE is now using old RPMs and not one compiled under 9.3.

It could also be the sources at fault. If I build anything, I get the latest as they are more likely to build and work. Earlier you mentioned wine-20050524, that fails to build, but wine-20050628 builds fine.

To also to get a USB drive to work it takes about 4 or 5 reboot efforts to be seen by the system. However, "lsusb" see it just fine

...

I wonder what dmesg said about it. I've not had any of the horrors on upgrades that I had with 9.2. the 9.2 fresh installs worked great, the upgrades took a lot of jiggery pokery to get working. 9.3 both upgrades and fresh installs have been 100%, x86 on Athlon and P-II/333 64M + 2M video card laptop and x86_64 laptop. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Keen licensed Private Pilot Retired IBM Mainframes and Sun Servers Tech Support Specialist Microsoft Windows Free Zone - Linux used for all Computing Tasks

Donn L Washburn wrote:

On Fri, 01 Jul 2005 16:54:07 +0100 Info wrote:

...

Was ruuning 8.2 and quite liked this distro. Decided to upgrade to 9.3. Wouldn't updgrade so had to install from scratch - big mistake!

Finding 9.3 very slow. Took install suggestions as far as disk configure is concerned but do not really understand what happened. Told it may be something to do with the way the disk(LVM) is configured? Open Office keeps falling over. Desktop hangs quite often - what does this remind you of? At least killing the X-server allows me to sign on again. Would like to be able to switch on/off NIS also network devices?

Seriously considering reverting to Fedora

I also agree. SuSE9.3 has been nothing but a headache. About 50% of the programs that compiled very clean under 9.2 fail to compile in 9.3. Try jpilot that worked under 9.2. The only way I got it to work was via a RPM. My guess is SuSE is now using old RPMs and not one compiled under 9.3.

To also to get a USB drive to work it takes about 4 or 5 reboot efforts to be seen by the system. However, "lsusb" see it just fine

I have had no problems with 9.3. I installed it on an IBM Thinkpad, and can plug in my USB Zip Drive or USB CD-Recorder and both work perfectly, no rebooting required. OpenOffice also works very well. 9.3 is about as fast on my 1.13 Ghz laptop, as 9.2 on a 2.8 Intel system. My guess is your hardware. Possibly memory or hard-drive, either configured incorrectly, detected incorrectly, or possibly faulty. I think most people do not have these problems, so I would definitely check out the hardware. James Wright

Jon Nelson writes:

I have to second that. 9.3 is considerably faster for me on my laptop as well, one think to try is to disable acpi at boot time, the powersaving stuff turned on by default can really slow the machine down, because it's turning my 1.8GHz machine into a 200MHz one.

Just edit /etc/sysconfig/powersave or do not start the powersave daemon at all. But the powersave daemon should turn up the speed if it's needed - so it should be 200 Mhz while the cpu is bored and 1.8 Ghz if you give it a big job to do, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Jon Nelson wrote:

On Fri, 1 Jul 2005, Andreas Jaeger wrote:

...

Jon Nelson writes:

...

I have to second that. 9.3 is considerably faster for me on my laptop as well, one think to try is to disable acpi at boot time, the powersaving stuff turned on by default can really slow the machine down, because it's turning my 1.8GHz machine into a 200MHz one.

Just edit /etc/sysconfig/powersave or do not start the powersave daemon at all. But the powersave daemon should turn up the speed if it's needed - so it should be 200 Mhz while the cpu is bored and 1.8 Ghz if you give it a big job to do,

And it does that, *generally*, just fine. However, it turns it down too quickly, so that I find interactive use quite choppy.

I can't *complain* about it, it's doing it's job, but either I haven't sat down and figured out how to get it to behave more like what I want. Before SuSE, I ran cpydyn and it seemed to do a better job, perhaps I just need to fiddle with it.

Also, for some reason, it loses its mind from time to time and always reverts to "Dynamic" even when I almost always set it to "Performance".

I wish the ACPI in my *DELL* Laptop didn't suck so badly, that's the last Dell I'll likely ever buy.

Except for detecting the fans, powersave on my Dell Inspiron 600m works fine. The cpu is throttled properly. The temperature and battery status is displayed in gkrellm just fine. The alarms for low battery level work fine too (though I'd like to be able to set these by minutes rather than percent of batter). A little icon even pops up (both in gkrellm and in the top panel) when the laptop is plugged into the mains. IOW, all that stuff is good. However, I have had a LOT of other problems: intermittent hanging of shutdown invoked from "Desktop | Logout | Shutdown", wireless not being configured correctly via Yast or invoked correctly from netapplet (though this worked initially-- for a couple weeks-- before inexplicably pooping out), Yast doesn't correctly identify the ATI 9000 M9 video card (so I had to configure that by hand), and MANY source rpms not installing, and autologin has never worked right. I'm sure there's a few other problems I'm forgetting right now. I understand that laptops, with all the hardware and networking and other dynamics that the OS has to deal with, makes for a lot of complexity. But getting things to run right has taken **way** longer with Suse 9.3 than I ever imagined it would. -- A lot of us are working harder than we want, at things we don't like to do. Why? ...In order to afford the sort of existence we don't care to live. -- Bradford Angier

Cristian Rodriguez wrote:

2005/7/1, Info :

...

Was ruuning 8.2 and quite liked this distro. Decided to upgrade to 9.3. Wouldn't updgrade so had to install from scratch - big mistake!

Finding 9.3 very slow.

works faster than 9.2 for me.

...

Open Office keeps falling over.

have similiar problem.

OpenOffice with 9.3 didn't work for me, but the ones from www.openoffice.org are OK. The only other problem I have is with a PhoneSkype USB phone keypad that shows up in /sys, but udev doesn't seem to register a device for it. Latest NVidia driver 7667 is AOK also. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Keen licensed Private Pilot Retired IBM Mainframes and Sun Servers Tech Support Specialist Microsoft Windows Free Zone - Linux used for all Computing Tasks