Re: "mount" bug

jb1
2002-10-26T08:55:09Z

On 25 Oct 2002, Harry Kalogirou wrote:

> > /dev/fd1 seems to mount, but be inaccessible.
> >
> > After booting ELKS 0.1.1 from a 3-1/2" diskette in /dev/fd0, "mkdir /mnt",
> > "ls -l /" shows 2 hard links and a 32-byte size for mnt.
> >
> > "mount /dev/fd1 /mnt", when /dev/fd1 contains a 5-1/4" ELKS diskette,
> > shows:
> > fd: probing disc in /dev/fd1
> > fd: /dev/fd1 probably has 15 sectors and 80 cylinders
> > MINIX-fs: mounting unchecked file system, running fsck is recommended.
> >
> > "ls -l /" now shows 10 hard links and a 160-byte size for mnt.
> >
> > "ls /mnt" now shows:
> > /mnt:
> > /mnt/in/sh
> > : No such file or directory
> >
> > After this point, "meminfo" shows *more* free and the system rapidly
> > deteriorates ("Cannot fork", a blank commandline prompt, a garbage
> > commandline prompt, etc.)
> >
> > Changing /mnt's permissions, owner and group don't help. Interchanging the
> > 3-1/2" and 5-1/4" drives didn't help, although there were more error
> > messages from mount. Using 5-1/4" drives for both /dev/fd0 and /dev/fd1
> > (with an ELKS 0.1.0 diskette in /dev/fd1) didn't help.
> >
>
> I tried it on my machine, but with 2 3-1/2 drives and it works fine.

This was my fault; since the machine was happily using both floppy drives
under Windows 95 I didn't bother to run the BIOS Setup program. While
checking the "impossible" I discovered that it was set up for only for a
1.2M first drive. After correcting this to 1.44M first drive and 1.2M
second drive, it worked.

This leads to an interesting question: is the fact the floppy mounted, but
was otherwise inaccessible a bug or a feature? If ELKS should be handling
all possible low-level functions then it's a bug in the mount() function
(presumably in the kernel). If mount invokes the ROM BIOS to reduce the
size of the kernel then it's a feature, and perhaps it could be reduced
further by using the ROM BIOS for more of the diskette-handling (which
might have made the diskette accessible despite my incorrect settings).

I now think the "Cannot fork", reduced free memory and deteriorating
system are *not* diagnostic of an incorrect BIOS setup, but rather a
hardware incompatibility and maybe an ELKS bug revealed by the
incompatibility. The system on which this occurred has a VL-Bus/EISA
motherboard and a "bootable" EISA SCSI card. I noticed that when I
repeated "ps" its process ID jumped by large amounts, and the problems
occurred when the process ID was displayed as a negative number, after
which the init process disappeared entirely; I also saw two "init" entries
once. I suspect the hardware is somehow spawning, then killing new init
processes frequently, and that when the process ID is negative (or maybe
when it rolls over to positive again) killing the second init also kills
the first. "Cannot fork" seems to appear when there's no active init
process. I'll investigate further, but these should have their own threads
in the mailing list.