CDROM

[maro]

Thanks for those details. This at least shows that an older kernel (from the 2.6.x phase) is able to handle your hardware configuration. In addition to the suggestion I already made regarding testing with the latest PlopLinux release I'd like to recommend to add TC 3.8.4 (from here) and TC 4.3.1 (from here) to the "test program". In either case I guess it would be sufficient to download the smallest ISO file (i.e. "MicroCore" or "Core") as you won't need a GUI to test how well the respective kernel (and the modules contained in the initrd) can cope with your hardware situation.

The rational for this suggestion is that TC 3.8.4 used a newer kernel (i.e. 2.6.33.3) than the one found in your older PlopLinux release. And TC 4.4 introduced a slightly later kernel (i.e. 3.0.21) than the one used previously in the TC 4.x series, plus some kernel configuration amendments that could well play a role in your case.

I realise that this might sound like a lot of testing being required, but I really don't know how to get to identify where things "broke" without going through this process.

[Tejas]

Thanks for those details. This at least shows that an older kernel (from the 2.6.x phase) is able to handle your hardware configuration.

Not only 2.6.x phase, but also 2.4.x.

Code: [Select]

dsl@antq:~$ uname -r 
2.4.31
dsl@antq:~$ uname -a
Linux antq 2.4.31 #6 SMP Fri Oct 21 15:15:54 EDT 2005 i686 unknown

dsl@antq:~$ ls /cdrom
KNOPPIX     boot        index.html  lost+found

dsl@antq:~$ mount
/dev/root on / type ext2 (rw)
/dev/scd0 on /cdrom type iso9660 (ro)
/dev/cloop on /KNOPPIX type iso9660 (ro)
/ramdisk on /ramdisk type tmpfs (rw,size=46936k,size=42595k)
/proc/bus/usb on /proc/bus/usb type usbdevfs (rw,devmode=0666)
unionfs on /KNOPPIX/bin type unionfs (rw,dirs=/ramdisk/bin=rw:/bin=ro)
unionfs on /dev type unionfs (rw,dirs=/ramdisk/dev=rw:/dev=ro)
unionfs on /etc type unionfs (rw,dirs=/ramdisk/etc=rw:/etc=rw)
unionfs on /KNOPPIX/lib type unionfs (rw,dirs=/ramdisk/lib=rw:/lib=ro)
unionfs on /KNOPPIX/sbin type unionfs (rw,dirs=/ramdisk/sbin=rw:/sbin=ro)
unionfs on /KNOPPIX/usr type unionfs (rw,dirs=/ramdisk/usr=rw:/usr=ro)
unionfs on /ramdisk/var type unionfs (rw,dirs=/ramdisk/var=rw)

Thanks for those details. .... I realise that this might sound like a lot of testing being required, but I really don't know how to get to identify where things "broke" without going through this process.

Maro, Rich thanks for taking the trouble, sure appreciate it.

[maro]

I noted that DSL was working, but I discarded that observation as to me a 2.4.x kernel (being ca. 5.5 years old) does provide very little help when trying to identify an issue with a 3.x or 2.6.x kernel. Hence all those suggestions with a view to find out under which conditions things start to fall apart. IMHO we don't yet have enough information to come up with any clear idea.

[Tejas]

I wonder how your system would get along with a more recent version of that distribution (e.g. release 4.2.1 with kernel 3.3.1).

Code: [Select]

[root@ploplinux ~]# uname -r
3.3.1
[root@ploplinux ~]# uname -a
Linux ploplinux 3.3.1 #1 SMP Sat Apr 7 15:52:01 CEST 2012 i686 GNU/Linux

mount /dev/hdb cd -t iso9660
mount: block device /dev/hdb is write-protected, mounting read-only
[root@ploplinux ~]# ls cd
KNOPPIX  boot  index.html  lost+found
[root@ploplinux ~]# umount cd

mount /dev/hdb cd -t iso9660
mount: block device /dev/hdb is write-protected, mounting read-only
[root@ploplinux ~]# ls cd
Directions  Images

[root@ploplinux ~]# mount
rootfs on / type rootfs (rw)
none on /proc type proc (rw,relatime)
none on /sys type sysfs (rw,relatime)
none on /proc/bus/usb type usbfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=620)
/dev/sda1 on /media type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/loop0 on /sbin type squashfs (ro,relatime)
/dev/loop1 on /lib type squashfs (ro,relatime)
/dev/loop2 on /bin type squashfs (ro,relatime)
/media/ploplinux/usr.sqfs on /usr type squashfs (ro,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
/dev/hdb on /root/cd type iso9660 (ro)

There is one slightly perturbing incident somewhat connected with this investigation, which you could maybe have some idea about. Upon running: 'tar xzf ploplinux-4.2.1.tgz' I got an error message to the effect that STDIN had incomplete end of file. Then verified 'md5sum' and ran 'tar xzf ploplinux-4.2.1.tgz' once more, which ran without a hitch. I have since run 'fsck' on the file system finding no corruptions. So could this error be indicative of a h/w malfunction or of a disk i/o error?

[Tejas]

In addition to the suggestion I already made regarding testing with the latest PlopLinux release I'd like to recommend to add TC 3.8.4  and TC 4.3.1 to the "test program".

TC 4.3.1 couldn't even gui! All the rest could.

[Rich]

Hi Tejas

Hang on a sec though, but isn't one of the tenets of TCB to rescue old computers from the scrap heap?

Old computers, sure. But you are asking it to boot a faulty computer.

I'm not too hot on h/w, being a s/w man myself

Fair enough. Then see if you can spot the flaw in this algorithm:

Code: [Select]

1. Select a version of Tinycore
2. Boot the computer
3. The kernel probes the computer to see what hardware is available
4. Probing the IDE port produces faulty results
5. Base on those results, the kernel determines there are no drives attached
6. You are sad because your CD drive was not detected
7. Select a different version of Tinycore
8. GOTO 2Yes, I know, GOTO statements tend to be frowned upon. But then again, I'm more of a H/W guy, so what did you expect?
In most, if not all of your attachments, the IDE interface is being detected. It is the drives connected to the other side of
that interface that don't show up. If you do not disconnect the hard drive, you can neither confirm nor deny that it's the
source of your problems, In that case, I recommend you go to step 7 and continue processing.

[Tejas]

TC 4.3

vmlinuz:   2511936
core.gz      5401101      Version 4.3

Upon scanning 'dmesg' after running PloP it seemed as though the sound card had not been detected. So I decided to compare with TC. Did simplest TC invocation by hitting grub-like menu item of kexec-loader which happened to boot the very first TC iso to be downloaded from your site. To my surprise it not only found the sound card but also the CD ROM, which I was able to mount and view. I thought it was an oversight on my part and so did not attempt to save 'dmesg', but it has turned out to have been a one-off, which I have not been able to reproduce.

I noticed it had managed to start the Uniform Multi-Platform E-IDE driver, and one does not have to be a Linux guru to realise it all hinges on (the kernel?) invoking the Uniform Multi-Platform E-IDE driver

TC 3.8.4 test results coming up next.

[Tejas]

Code: [Select]

1. Select a version of Tinycore
2. Boot the computer
3. The kernel probes the computer to see what hardware is available
4. Probing the IDE port produces faulty results
5. Base on those results, the kernel determines there are no drives attached
6. You are sad because your CD drive was not detected
7. Select a different version of Tinycore
8. GOTO 2Yes, I know, GOTO statements tend to be frowned upon. But then again, I'm more of a H/W guy, so what did you expect?
 I recommend you go to step 7 and continue processing.

Already in fourth Iteration

[Tejas]

TC 3.8.4

Something I've just realised, with all TC versions 'tested' till now, 'fd0' has been missing from the equation!
                                                                                             -------
From now on the 'mount tool' displays not just 'sda1',  |  fd0    |
                                                                                             -------
and the boot varies in behaviour depending on the CD!   |  hdb   |
                                                                                             -------
                                                                     |  sda1 |
                                                                                             -------

[Rich]

Hi Tejas
In TC3.x the drives show up as   hd
In TC4.x the drives show up as   sd

[Tejas]

Hi Rich

Post was garbled, as in the middle of composing and doing previews the text somehow got posted Thanks for info anyhow.

Giving up for time being BCC here is not behaving as it should.

[maro]

Hmmm, I've been a bit silent recently as as was hoping that TC 3.8.4 results might reveal some really useful information. Does reply #25 mean that these specific results (i.e. similar to reply #21) won't be be forthcoming?

[Tejas]

Hmmm, I've been a bit silent recently as as was hoping that TC 3.8.4 results might reveal some really useful information. Does reply #25 mean that these specific results (i.e. similar to reply #21) won't be be forthcoming?

On the contrary! I've got them all, but in the process of putting them into some sort of meaningful order, I came across a problem with {list}{/list}, in that insertion of {code}{/code} terminates 'list', at which point I went off for my 40 x

[Tejas]

Hi Tejas
In TC3.x the drives show up as   hd
In TC4.x the drives show up as   sd

Hi Rich
In TC4.3 the CD drive, the one time it showed up, showed as 'sr0', as already mentioned in your very first posting here.

[Rich]

Hi Tejas
Actually gerald_clark mentioned the CD drive is sr0. Even though you have been trying this with different versions
of Tinycore, you've reached a point where you are essentially repeating the same experiment over and over but
expecting a different result. I think it's time you bite the bullet, get a screwdriver, and unplug the cables from that
dead hard drive.