i'm trying to cd-install crux2.3-i586 (from contrib dir) and running into very strange problems: 1. # /usr/bin/setup /usr/bin/setup : line 263: syntax error near unexpected token 'else' Problem place is at line 253 though: ' ) > $tmpfile 2>&1' Apparently the piping is not liked by bash ??? Well, I did following: # cp /usr/bin/setup /tmp/ # vi /tmp/setup (removed the piping) # /tmp/setup This allowed package installation to go fine. 2. # setup-chroot # cd /usr/src/linux-2.6.20.3 # make menuconfig Makefile:278: /usr/src/linuc-2.6.20.3/scripts/Kbuild.include: No such file or directory /bin/sh: line 0: [: -lt: unary operator expected make: Warning: File: '/usr/src/linux-2.6.20.3/arch/i386/makefile.cpu' has modification time 8.4e+07 s in the future make: *** No rule to make target '/usr/src/linux- 2.6.20.3/scripts/Kbuild.include'. Stop. Now, the very same iso installs just fine under qemu (cpu emulation as an athlon). http://gentoo-wiki.com/Safe_Cflags#VIA_Processors says that this processor reports wrongly i686, instead should be i586. # cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu_family : 6 model : 7 model name : VIA Samuel 2 stepping : 3 cpu MHz : 599.90 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow bogomips : 1201.07 clflush size : 32 # uname -p i686 Any suggestions are warmly welcome! fikin
Hi, fikin! fikin schrieb:
i'm trying to cd-install crux2.3-i586 (from contrib dir) and running into very strange problems:
1. # /usr/bin/setup /usr/bin/setup : line 263: syntax error near unexpected token 'else'
Problem place is at line 253 though: ' ) > $tmpfile 2>&1'
Apparently the piping is not liked by bash ???
Well, I did following: # cp /usr/bin/setup /tmp/ # vi /tmp/setup (removed the piping) # /tmp/setup
This allowed package installation to go fine.
I didn't use setup for quite some time... however the CRUX2.3-i686 CD was working last time, IIRC.
2. # setup-chroot # cd /usr/src/linux-2.6.20.3 <http://2.6.20.3> # make menuconfig Makefile:278: /usr/src/linuc-2.6.20.3/scripts/Kbuild.include <http://2.6.20.3/scripts/Kbuild.include>: No such file or directory
make mrproper?
/bin/sh: line 0: [: -lt: unary operator expected
Hmm... bashism?
make: Warning: File: '/usr/src/linux-2.6.20.3/arch/i386/makefile.cpu <http://2.6.20.3/arch/i386/makefile.cpu>' has modification time 8.4e+07 s in the future make: *** No rule to make target '/usr/src/linux-2.6.20.3/scripts/Kbuild.include <http://2.6.20.3/scripts/Kbuild.include>'. Stop.
Did you check your system time? Propably the 2.6.20.3 doesn't have the right RTC settings enabled for your not so standard VIA platform. Try to optimize your kernel .config. I also recommend you to try the latest kernel from kernel.org. If the problem persists, contact the guys at / report the bug to the LKML (the kernel mailing list). Regards, -- Clemens Koller __________________________________ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com
fikin [2007-08-10 16:37]:
# /usr/bin/setup /usr/bin/setup : line 263: syntax error near unexpected token 'else' [...]
Now, the very same iso installs just fine under qemu (cpu emulation as an athlon).
Strange indeed. Maybe first try Clemens' suggestion and verify that your burned CD is okay. You could start by md5sum'ing the bash executable and the setup script. If the md5sums in the running installation are differing from the ones in qemu, the CD is probably b0rked. Or maybe the binaries on the ISO just don't work properly on your processor. Otherwise I don't see why it would work in qemu but not on the real thing :/ Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Well, the CD isn't broken, Nikolai? it is ok.
this is most peculiar indeed. i've spent quite some time with this, basically booting, trying various options and again. also i was testing with another motherboard: via kt333 (featuring vt8233 chipset). first error comes only under epia motherboard. and the bazaar think is that occasionally it would work fine. no explanations on my side. second error is a due to failed bunziping of the kernel tar (which btw does not alter setup's exit status, errors are only mentioned in the log file). this error is reproducible reliably on both motherboards. no exceptions. if it wasn't for qemu i'd claim a broken tar file is used. is there something special about via support in crux installation kernel? fikin
I'm not sure if it's related, but I seem to remember that VIA cpus not always are 100% i686 compatible. Have you tried the i586 version? Just an idea. // treach
fikin [2007-08-12 04:40]:
second error is a due to failed bunziping of the kernel tar (which btw does not alter setup's exit status, errors are only mentioned in the log file). this error is reproducible reliably on both motherboards. no exceptions. if it wasn't for qemu i'd claim a broken tar file is used.
is there something special about via support in crux installation kernel?
I don't think so. I think the next step would be to compile a custom boot kernel and try that. Q: Do we have a step-by-step explanation of how to do that? %) Are you positive that the hardware (especially RAM) is okay? Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Hello, Nikolai! fikin schrieb:
Well, the CD isn't broken, Nikolai? it is ok. this is most peculiar indeed.
i've spent quite some time with this, basically booting, trying various options and again. also i was testing with another motherboard: via kt333 (featuring vt8233 chipset).
first error comes only under epia motherboard. and the bazaar think is that occasionally it would work fine. no explanations on my side.
second error is a due to failed bunziping of the kernel tar (which btw does not alter setup's exit status, errors are only mentioned in the log file).
Did you check your memory with memtest86? Please post the dmesg output of the failing kernel.
this error is reproducible reliably on both motherboards. no exceptions. if it wasn't for qemu i'd claim a broken tar file is used.
I just tried a standard CRUX-2.2 once within qemu... about a year ago. It just worked.
is there something special about via support in crux installation kernel?
There is no intention to do something special there. It's just a plain vanilla kernel, configured for some more or less standard i686(i585) configurations. Your EPIA M might not be standard enough for that case. IIRC there are some config options for some VIA Cx CPU's. As mentioned, I would try the latest kernel. Use a minimum configuration and post the dmesg output to the list if possible. I (or you) can also check with some guys at the linux kernel mailing list (LKML) if you are running into troubles with a current kernel. [10mins later] Okay, I checked some list archives (Note: This information is second hand, YMMV): - There are patched -epia kernels out there... so there is something special. - Some VIA CPUs are detected as i686 CPUs which is basically fine because they have the i.e. 3dnow and mmx instructions, however they are missing the "cmov" instructions, which might also get used by the glibc... The following compile options should be fine for "VIA-Boards", (I think that should read "VIA-CPUs"): CFLAGS="-march=i586 -m3dnow -mmmx -Os -pipe" CHOST="i586-pc-linux-gnu" - Try the kernel options: apm=off and acpi=off - see: http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-08/2745.html So your system seems to be indeed special and needs some manual work to get it running if you want to use a i686 distro. And fixing your kernel might not fix your system, if you have your binaries using some stuff your CPU can't deal with. (Maybe the CRUX-2.3-i586 isn't i586'ish enough?) For further reference, see: http://witch.muensterland.org/stories/27.html Regards, -- Clemens Koller _______________________________ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19
ok fellas, i think there is a simple answer to all these problems: high speed cd burning. given the fact that i'm using two separate cdrom drives with the two motherboards, and given the fact that one of them actually burned the cd in question, and given the fact that bash/bunzip errors did not indicate any disk io error, it comes as a rather unexpected surprise to me but : epia system was occasionally hanging right after loading udev. i always though it was due to the very same reason bash/unzip were failing. after all, there were no disk io errors, and the errors were repeatable. so, at some point i though i should also give a try with some other cdrom. just for any case. and imagine my surprise, the result was a perfectly working installation. i guess this settles the whole affair. happily ;) to me, it is still hard to connect the bash broken pipes with faulty cd reading ... thanks for the help guys fikin p.s. apparently via chipset is supported just fine in 2.6.20. and yes, via Samuel chipset (epia m) reports i686 but in fact has to be threated as i586. http://gentoo-wiki.com/Safe_Cflags
Hi, Nikolai! fikin schrieb:
ok fellas, i think there is a simple answer to all these problems: high speed cd burning.
Glad you solved it... :-) That wasn't the first time, I received strange error reports due to broken CDs (and I got bitten, too). Is there actually some method to read from a broken CD where the kernel actually complains loud and clear (to the console) that the CD is broken? Regards, -- Clemens Koller _______________________________ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19
#!/bin/bash ISO=`md5sum your.iso` CDR=`md5sum /dev/cdrom` if [ "$ISO" != "$CDR" ]; then echo "CD IS BROKEN!!!" else echo "Might work, go ahead" fi How does that work for you? :p Obviously preferably exectute right after you create your cd. ;) //treach
Hi, treach! treach schrieb:
#!/bin/bash
ISO=`md5sum your.iso` CDR=`md5sum /dev/cdrom`
if [ "$ISO" != "$CDR" ]; then echo "CD IS BROKEN!!!" else echo "Might work, go ahead" fi
How does that work for you? :p Obviously preferably exectute right after you create your cd. ;)
Hmm... that's not really what I'm looking for. CD's burnt with one drive don't necessarily work on other drives. Who is doing checksums and error correction while reading from media anyway? I would expect that the kernel should complain loud and clear on a read error... to console. Any Ideas? -- Clemens Koller __________________________________ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com
participants (4)
-
Clemens Koller -
fikin -
Tilman Sauerbeck -
treach