help with getting sarge cds to boot
Hi! We need a little help with getting sarge cds to boot on sparc, we are receiving reports like this one: http://bugs.debian.org/243122 but the thing is that we seem to be using the right parameters on the cds, at least acording to this bugreports. This is the silo.conf we are using right now in the cds: partition=1 timeout=600 read-only message=/boot/debian.txt default=linux append="cdrom devfs=mount" initrd=/boot/initrd.gz root=/dev/rd/0 # Standard boot images image[sun4c,sun4d,sun4m]=/boot/sparc32 label=linux image[sun4u]=/boot/sparc64 label=linux # Rescue boots image[sun4c,sun4d,sun4m]=/boot/sparc32 label=rescue append="init=/bin/sh" image[sun4u]=/boot/sparc64 label=rescue append="init=/bin/sh" Can anybody see anything wrong here? Any sugestion will be welcome. Regards... -- Manty/BestiaTester -> http://manty.net
Re: Sparc CD images
> I've been trying to get information as to where I can download an ISO of the > Sparc port of Debian. I've tried google but I can't seem to get any working > sites/valid pages & cdimage.debian.org doesn't respond :( Umm, it is working ok from here, just in case you cannot still get it I'm sending you some of the mirrors pointed on cdimage.d.o here in europe: Austria, Vienna cdimage.at.debian.org::debian-cd/ Denmark sunsite.dk::ftp/pub/os/linux/debian-cdimage/ Finland (funet.fi) ftp.funet.fi::ftp/pub/Linux/mirrors/debian-cdimage/ Finland, Tampere ftp.fi.debian.org::debian-cd/ Germany (rfc822.org = de.kernel.org) ftp.rfc822.org::publicftp/mirror/debian-cd/ Hungary ftp.fsn.hu::cdimages/debian/ If you are searching for woody unofficial images you will find sparc ones if you read cdimage-unofficial.debian.net Regards... -- Manty/BestiaTester -> http://manty.net
Re: Woody ISO Images
> unsuccessful. I am looking for .iso images to install Woody on a http://cdimage-unofficial.debian.net Regards... -- Manty/BestiaTester -> http://manty.net
Re: sparc woody rescue.bin > 1440k
> I could burn a CD, but I have no idea how to make a sparc-bootable CD > image, and there don't seem to be (?) any woody sparc images > pre-made. You can download the first image of the unofficial woody iso cd images for sparc that I'm making and burn it with cdrecord. For instructions on how to download it go to cdimage-unofficial.debian.net. Be aware, that the quality of this images is alpha, so they may work or not, last time they were tried they didn't work, but I have fixed a couple of things since them with help from BenC, so this ones might boot. If you do try them, please report back directly to me, here or on [EMAIL PROTECTED] Regards... -- Manty/BestiaTester -> http://manty.net
2.4.9 not booting on Sun Enterprise 3000 (was: Sun Enterprise 3000 and 2.4.7 + others)
Hi! Sorry it took so long to reply to this, but I don't go where the machine is too much, and I've been busy lately, anyway, I repeated the tests with 2.4.9 both normal and smp. Just to recall things a bit, the machine is a dual procesor Sun Enterprise 3000 with 256 megs of run and now runs a 2.2.20pre6 from vger cvs with Debian testing smoothly. >> but today I wanted to test 2.4 again, so I got both the normal and smp >> versions of the 2.4.7 kernel on debian and I installed it. > Thanks for testing this. You welcome. >> The result, the machine boots a little farther than before, but also gets >> stuck, this are the final lines it prints on the console: > Could you possibly provide the full text of the bootup? It may contain > some other clues. Sure, this time I got the minicom on the console to gather all the stuff when booting. Well, I hope this can help put some light in why this machine doesn't like 2.4 kernels but works ok with 2.2 ones. It always hangs when doing disk operations, I don't know if this could mean anything or not, you'll see more in the capture I'm attaching. Thank you for your job and your help with this! Regards... -- Manty/BestiaTester -> http://manty.net 2.4.9-bootfailure.txt.bz2 Description: Binary data
problem with rsync
I'm having problems with rsync running on a sparc using woody, if I use rsync from woody it doesn't work, but if I use the one from potato it works ok. I have tested the same configuration on i386 and it works ok, so maybe this problem is related to the kernel or something, here is my config: timeout = 1800 dont compress = *.zip *.z *.bz2 *.rar *.gz *.tgz *.deb *.rpm uid = nobody gid = nogroup max connections = 10 [tmpcd] path = /usr/debian-tmp/images comment = Temp cd image building dir auth users = manty read only = true list = false secrets file = /etc/rsyncd.seci [unofficial-debian-cds] path = /home/ftp/unofficial-debian-cds comment = Unofficial Debian woody cd images export area read only = true The machine runs kernel 2.2.20pre6 from the cvs on vger, as 2.4 doesn't want to run on it. Machine is a 4 slot Sun Enterprise 3000 with two ultrasparc processors. I'm getting this error when I try to access the tmpcd module, not the other one, and it outputs the error before even prompting for the password or anything. This is the error: @ERROR: max connections (10) reached - try again later The maximum connections is in fact 10, but there is nobody connected at all, I have tried increasing the number but I only got the increased number on the error. Machine works ok and I have not seen any other weird behaviour besides on the ftp servers, where if I download big files (cd images) using an ftp server different from the wu-ftpd data is corrupted, and I have tried almost all the ftp servers on testing. Well, I'd like to know if anybody with a similar machine/similar kernel can give this a try or something. Thank you very much on advance. Regards... -- Manty/BestiaTester -> http://manty.net
Sun Enterprise 3000 and 2.4.7 + others
Hi! Some time ago I installed debian on this machine, wich has got two microprocessors. By that time and as I wanted raid, I was told to try a 2.4 kernel and I did but I could not get it to boot, it was then that I was pointed to the cvs 2.2.20 kernel from vger and it worked. Since then the machine has been running 2.2.20pre1-cvs without any problem, but today I wanted to test 2.4 again, so I got both the normal and smp versions of the 2.4.7 kernel on debian and I installed it. The result, the machine boots a little farther than before, but also gets stuck, this are the final lines it prints on the console: IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 2048 buckets, 32Kbytes TCP: Hash tables configured (established 16384 bind 16384) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (ext2 filesystem) readonly. Ive ActiAdding Swap: 765680k swap-space (priority -1) vating swap... Checking root file system... Paloop: loaded (max 8 devices) rallelizing fsck version 1.18 (11-Nov-1999) e2fsck 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 /dev/sdd1: clean, 2670/63744 files, When it prints that Ive it gets stuck there for a while before continuing, I have waited at the end to see if it continued but it doesn't seem to continue. This is a Debian Potato, with modutils 2.4.6, I'm gonna try to upgrade to woody, but I don't hope this will change anything on this behaviour. Any ideas on what I could test? Regards... -- Manty/BestiaTester -> http://manty.net
Re: Debian 2.2r3 on Sun Enterprise 3500
Hi! > I have an Enterprise 3500 machine that I am trying to install Debian on. I installed on a Enterprise 3000 without any problem, then having raid took me more, but installing was flawless > Unfortunately, it does not seem to be able to access the scsi drives > during install. It sees the CDROM, but none of the six scsi drives in > the system. No errors about unrecognized scsi controller or anything. Is the cd on the same controller as the disks? The 3000 has this controller: esp0: IRQ 7,db SCSI ID 7 Clk 40MHz CCF=8 TOut 167 NCR53C9XF(espfast) ESP: Total of 1 ESP hosts found, 1 actually in use. scsi0 : Sparc ESP366-HME As I tell you, no problem at all with it. Regards... -- Manty/BestiaTester -> http://manty.net
Re: RAID again
> Ok, some of the ioctl translations aren't done for raid it seems. I > suggest trying a 2.4.x kernel (especially on sparc64). I could check Well, as I told you on a previous message 2.4.5, either smp or non-smp won't boot on this machine. However when I was trying to see wich translations needed to be made, at 2.2.19 I realised that the code on 2.2.20test1 cvs for the mbr translations was like the one on 2.4, so I looked at the raid driver and found that it was not using the old driver that was being used on 2.2 but the new one 0.90 one that is being used on 2.4. Hey, I just had to intall raidtools2 and it was done, I have tested raid0 for a bit on read and write, with no problems, now I'm testing raid5 with no problems till now, everything looks fine. Thanks a lot, Ben, this guys are gonna be happy, and I've got a machine where to compile for the Fujitsu stuff if we finally get it and it is needed :-) Sorry for not realicing before O:-) Regards... -- Manty/BestiaTester -> http://manty.net
Re: RAID again
> Ok, some of the ioctl translations aren't done for raid it seems. I > suggest trying a 2.4.x kernel (especially on sparc64). I could check > into the translations for you if they don't work on 2.4.x. If you want > to check yourself, look at arch/sparc64/kernel/ioctl32.c I'm afraid trying 2.4 was even worst, ok, at first I tried to compile 2.4 to get a simple kernel, but I just couldn't get it to compile under potato on the sparc, this is the error I got when making it... /bin/sh ./check_asm.sh -data thread tmp.i check_asm_data.c sparc64-linux-gcc -D__KERNEL__ -I/usr/src/kernel-source-2.4.5/include -m64 -mcmodel=medlow -ffixed-g4 -S -o check_asm_data.s check_asm_data.c In file included from /usr/src/kernel-source-2.4.5/include/linux/wait.h:13, from /usr/src/kernel-source-2.4.5/include/linux/fs.h:12, from /usr/src/kernel-source-2.4.5/include/linux/capability.h:17, from /usr/src/kernel-source-2.4.5/include/linux/binfmts.h:5, from /usr/src/kernel-source-2.4.5/include/linux/sched.h:9, from check_asm_data.c:4: /usr/src/kernel-source-2.4.5/include/linux/kernel.h:132: size of array f' is too large Well, so I said I'm gonna install one of our binary kernels, and I chose the 2.4.5 kernel for the usparc with smp support, I rebooted and 2.4.5 came up smoothly, untill I saw the line that showed that it had mounted the root fs and then it died, this are the last lines I can see on the serial console: VFS: Mounted root (ext2 filesystem) readonly. Ive Ica Ica Ica ... It continues ouputting that Ica stuff on and on :-( I cannot do any more tests till tomorrow, as I cannot access the PROM, I have access to the serial console, so I tried sending a Break several times from minicom, but doesn't work. Do you thing I should still try to test 2.4 again on this machine? Doesn't seem I could be getting much farther with it. Regards... -- Manty/BestiaTester -> http://manty.net
Re: Unimplemented SPARC system call 140
> I don't see how you are getting this:
> /* #define __NR_adjtime 140SunOS Specific */
Yes, I have grepped the kernel sources and I also don't see how can I be
getting this stuff.
> Something is really screwy if it's using this non-existent syscall. Is
> this coming from the raid software?
I get it when running mkraid, and I'm not running any other thing at the
same time that could be causing it.
I have straced mkraid trying and tried to trace the forks also, but the
forks don't seem to get traced, anyway, here is the last part of the output,
in case this gives any clue on what may be happening:
3908 sigreturn() = ? (mask now [QUIT KILL BUS SYS PIPE
ALRM STOP TSTP CONT LOST USR1 USR2])
3908 write(1, "\n", 1) = 1
3908 write(1, "writing raid superblock\n", 24) = 24
3908 time(NULL)= 991565803
3908 write(1, "MD ID: a92b4ef"..., 34) = 34
3908 write(1, "Conforms to MD version: 0.36.4\n", 32) = 32
3908 write(1, "Raid set ID: 851cd82"..., 34) = 34
3908 open("/etc/localtime", O_RDONLY) = 11
3908 read(11, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\10"..., 44)
= 44
3908 read(11, "\234\363\360p\235\276\367p\236\272\305\360\237\240*\360"...,
815) = 815
3908 fstat(11, {st_mode=S_IFREG|0644, st_size=946, ...}) = 0
3908 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7001e000
3908 read(11, "\0\0\16\20\1\0\0\0\0\0\0\5\0\0\34 \1\t\0\0\16\20\1\0\0"...,
8192) = 87
3908 close(11) = 0
3908 munmap(0x7001e000, 8192) = 0
3908 write(1, "Creation time: Sun Jun"..., 50) = 50
3908 write(1, "Update time: Sun Jun"..., 50) = 50
3908 write(1, "State: 1 (clea"..., 35) = 35
3908 write(1, "Raid level: 5\n", 27) = 27
3908 write(1, "Individual disk size:4091MB "..., 44) = 44
3908 write(1, "Chunk size: 16kB\n", 30) = 30
3908 write(1, "Parity algorithm:2 (left"..., 44) = 44
3908 write(1, "Total number of disks: 4\n", 27) = 27
3908 write(1, "Number of raid disks:4\n", 27) = 27
3908 write(1, "Number of active disks: 4\n", 27) = 27
3908 write(1, "Number of working disks: 4\n", 27) = 27
3908 write(1, "Number of failed disks: 0\n", 27) = 27
3908 write(1, "Number of spare disks: 0\n", 27) = 27
3908 write(1, "\n", 1) = 1
3908 write(1, "Disk 0: raid_disk 0, state: 6 (o"..., 58) = 58
3908 write(1, "Disk 1: raid_disk 1, state: 6 (o"..., 58) = 58
3908 write(1, "Disk 2: raid_disk 2, state: 6 (o"..., 58) = 58
3908 write(1, "Disk 3: raid_disk 3, state: 6 (o"..., 58) = 58
3908 open("/dev/sda1", O_WRONLY) = 11
3908 adjtime({...}, 0) = -1 ENOSYS (Function not implemented)
3908 write(2, "mkraid: aborted\n", 16) = 16
3908 close(4) = 0
3908 munmap(0x7001c000, 8192) = 0
3908 write(7, "p\4\230 \0\0\0\2\0\0\0\1\0\1\10\235\0\0\0\3\0\0\0\0\0?"...,
148) = 148
3908 rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 8) = 0
3908 rt_sigsuspend([]
3908 --- SIGRT_0 (Real-time signal 0) ---
3908 <... rt_sigsuspend resumed> ) = -1 EPIPE (Broken pipe)
3908 sigreturn() = ? (mask now [QUIT KILL BUS SYS PIPE
ALRM STOP TSTP CONT LOST USR1 USR2])
3908 wait4(3909, NULL, __WCLONE, NULL) = 3909
3908 munmap(0x7001a000, 8192) = 0
3908 exit(1) = ?
Regards...
--
Manty/BestiaTester -> http://manty.net
RAID again
Hi! I was full of testing the raid5 stuff without getting nowhere, so I tried a raid0, as this one doesn't need to run mkraid. I think I don't have to repeat the configuration, but just in case... The machine is a Sun Enterprise 3000 with 2 micros and 256 megs of ram, It currently runs 2.2.19 with SMP support, the distribution is Debian Potato 2.2R3, raidtools version 0.42-21. So, I run mdcreate and I get my /etc/mdtab with this contents: /dev/md0 raid0,16k,0,c410a271 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd8 and then I tried: /etc/init.d/raid start but it failed, so I run mdadd -ar manually and still failed. Ok, I rebooted in case there was something wrong because of having been playing with the raid5 stuff, and this is what I get on booting the machine: Loading modules: raid0 raid0 personality registered raid5 raid5 personality registered Adding md devices. sys32_ioctl: Unknown cmd fd(8) cmd(2901) arg() /dev/sda1: Invalid argument sys32_ioctl: Unknown cmd fd(8) cmd(2901) arg() /dev/sdb1: Invalid argument sys32_ioctl: Unknown cmd fd(8) cmd(2901) arg() /dev/sdc1: Invalid argument sys32_ioctl: Unknown cmd fd(8) cmd(2901) arg() /dev/sdd8: Invalid argument sys32_ioctl: Unknown cmd fd(8) cmd(2902) arg(00020002) /dev/md0: Invalid argument As you can see I have the raid0 personality registered, the module loads perfectly, and the partitions are there and I have tried a mke2fs -c on them and they work perfectly, so I just don't know what can be going wrong here. I have set up a raid0, a raid1 and a rai5 at home on a pentium machine, no problems at all, but on the sparc I'm just getting problems all the time, any help will be appreciated, as I don't know what to test. Regards... -- Manty/BestiaTester -> http://manty.net
Re: Unimplemented SPARC system call 140
> You can ignore these on 2.2.x kernels. It's an artifact of LFS support > in the newest glibc. Basically it tries to use LFS syscalls first, and > then falls back to non LFS syscalls. The LFS syscalls does not exist on > 2.2.x kernels, which is ok. Well, the problem is that I'm using potato, so I'm using libc6 2.1.3-18, does this version make that syscall already? and another problem is that mkraid breaks and doesn't finish making the raid5, ie ckraid on the raid says that it cannot read the raid superblocks. Regards... -- Manty/BestiaTester -> http://manty.net
Unimplemented SPARC system call 140
Hi! I have seen this has been talked before on other lists, but a long time ago, for other kernels and other machines, so I'm wondering why do I get this if I'm using debian's 2.2.19 kernel, on a ultrasparc machine. I'm getting this when I try to make a raid5 raid on 4 scsi disks. the machine is a Sun Enterprise 3000 with two cpus. I'm using mkraid from raidtools 0.42-21. I have tried both debian's kernel-image kernel for the ultrasparc, both normal and smp, and one compiled by me, all of them have raid5 as a module. This is the cpu info: cpu : TI UltraSparc I (SpitFire) fpu : UltraSparc I integrated FPU promlib : Version 3 Revision 2 prom: 3.2.5 type: sun4u ncpus probed: 2 ncpus active: 2 Cpu6Bogo: 333.41 Cpu7Bogo: 333.41 MMU Type: Spitfire State: CPU6: online CPU7: online Any clue on this will be appreciated. Thanks in advance. Regards... -- Manty/BestiaTester -> http://manty.net
Fujitsu sparc based machine doesn't work with Debian
Hi! I'm completelly new to sparc, I have just helped installing one once, so my background on sparc related stuff is nearly none. The thing is that I've been requested to install Debian on a Fujitsu, this is the data I could gather on booting the machine with Debian Potato 2.2r3 FUJITSU GP7000F Model 200 Sparc 64-III 224Mhz OpenBoot 3.11H 256MB Mem. ... SCK Version 2.1.D RCI V 0.0.0.1 Boot device: /[EMAIL PROTECTED],4000/[EMAIL PROTECTED]/ldthree SILData Access Exception %TL:1 %TT:30 %TPC:380328 %TnPC: 38032c %TSTATE: 81e01 %PSTATE 1e (IE:1 PRIV:1 AM:18 EF:1) D-FAR 0 D-FTR: f675 (W:1 PRIV:1 ASI:67 FTYPE:f) I also tried boot-floppies from woody just in case but got the same result. I don't know how can I bypass this SILO problem, well at least that's what looks to me as the kernel hasn't been started, but as I told you, I know nothing about sparc stuff. So... any help would be apreciated. I think it is a good chance to get debian to boot this kind of machines, a little weird I think, or so it seems to me. If you need any more info I'll try to gather it when I'll go there again. Thank you very much in advance. Regards... -- Manty/BestiaTester -> http://manty.net
