Re: some reports and files

From: Michele Andreoli (
Date: Wed Nov 22 2000 - 21:13:42 CET

On Wed, Nov 22, 2000 at 03:01:48PM +0100, Dumas Patrice nicely wrote:
> >
> > This (rustic) detection relie on a messaged in the boot log.
> I don't think so. I copied from
> supported device 22 ide1 || abort "Kernel lack CDROM support."
> I looked at supported in /setup/lib/basic, and it looks at /proc/devices.

Mmmm .... a recent invention of mine, that. I assumed the CDROM
alway on the secondary ide. I do not remember why: maybe, some
problem using strings from boot log. You can replace "abort" with "echo".

> > It is saved by /bin/scan, but I'm not sure.
> Hum, as I disabled /bin/scan, as because of the old-ide interface compiled in
> the kernel, fdisk freezed the computer.

I need of /bin/scan: it is required in

1) Dos installer: it gets a list of partitions and try to
   locate the images mulinux.tgz etc.
2) El-Torito muLinux: it try to figure out where is the cdrom
   with the images.

> > The "mu" script detect the loop-device with looking in the /proc/devices:
> > it find something like:
> >
> > Block devices:
> > ...
> > 7 loop
> > ....
> >
> > This is OK also for 2.2.* serie, or not?
> Yes, that's allright. I didn't explain myself correctly.
> In my case, the loop device is a module. So, if not in use it is not in
> /proc/devices. But if a program try to use it, kmod insmod the module
> automatically, so that it is now in /proc/devices.
> With the old way, there was a try to mount loop device, so it worked (and as
> a side effect, it appeared in /proc/devices, but it was of no use, as it
> wasn't used to detect whether loop was available).

I have to do the test two times, forcing the "loop" module in the
kernel of the user? A kind of violence :-)

> So I also think that a 2.2 kernel on mu
> disk isn't a good thing.

Not for the base disk, sure. You know my basic nightmare: future kernel
and future libc, simply do not fit together in a single floppy disk.

> But nevertheless, it could be interesting for mu to be the more indepenndant
> of the kernel serie, so that there is nothing to change in mu-scripts with
> another kernel.
> I am also of your advice about kernel upgrade.

This is the best, for mulinux. I agree totally. We have to
specialize the scripts with a lot of switch like:

        case `uname -r` in
        2.0.*) .....
        2.2.*) .....

After all, they are only scripts!


In summing up, I wish I had some kind of affirmative message to leave
you with, I don't. Would you take two negative messages? - Woody Allen
To unsubscribe, e-mail:
For additional commands, e-mail:

This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:16 CET