From: Michele Andreoli (m.andreoli@tin.it)
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 cdrom.fun
> 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.*) .....
esac
After all, they are only scripts!
Michele
-- 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: mulinux-unsubscribe@sunsite.auc.dk For additional commands, e-mail: mulinux-help@sunsite.auc.dk
This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:16 CET