From: Dumas Patrice ([email protected])
Date: Tue Nov 21 2000 - 17:43:06 CET
Hi,
Sorry, it is a very long mail.
Oh, it seems that I am a little late 11r0 is soon released, oh and 11r1
too !!...
I have pushed mulinux 10r5 to it's limits, trying to use it with a 2.2.x
kernel with an old ide interface...
I have updated my files with the 11r1 version but not tested with that
version, only with 10r5. Nevertheless, I looked whether there was
conflicts and it seems there are none.
I have joined
a version of /rc/startup that stops scanning hardware as soon as
it has found a suitable /startup filesystem (the scan caused the kernel
to hang, because of fdisk, and surely the old ide interface. I haven't
fully test the stuff hardware as I have only used an in-ram mulinux)
a version of login that test whether ile runs or not. (with my
2.2.x kernel, ile doesn't work, and it is fatal, as it happens before
login.)
a setup with error check. In order to achieve that, I had to set
the return of ask_the_user in the case where the user doesn't want a
ressource to 0. It doesn't seem to break anything, but I warn because it
isn't easy to see that change in the setup script. I haven't tested all
the return values of the .fun, I tested keymap.fun and as it didn't
include an error reporting, I added that feature and I joined this
version of keymap.fun.
I report a bug (for 10r5).
the new way to detect the cdrom support in kernel is quite broken. In
fact the way it is done it only detects if, there is support for the ide
interface in the kernel and in the same time there is an ide device on
the second ide slot.
My cd-rom is in the first, so it wasn't detected. And if there is an
hd on the second ide slot, it will be taken as a cdrom.
In the 2.2 kernel serie, it is better to look in /proc/ide0/hdx/media.
In 2.0.36, there isn't such a thing. I propose to test
wether there is an ide interface, and then to look at dmesg. It should
be good to store dmesg boot output in var (maybe it is allready done ?),
at boot time, maybe in mount_root() ?.
I report a "bug" for 11r1:
the mu script doesn't detect the loop device because it is not compiled
in the kernel but is a module. I have to insmod it or cause kmod to
automatically load it, then the mu script recognize it. With the
functionnal detection that was in the previous mu there wasn't such a
problem. Michele, I suggest you to come back to that way of detecting
the loop device.
I made a detection of the -O feature that worked with my mke2fs but it
isn't really useful now as the mke2fs of mu is taken instead. But if you
want, I can give it to you.
generally speaking, I think that functionnal tests are more robust with
regard to false output, but can be dangerous sometimes, if they fail.
And now some remarks.
* in mu, the -r switch leads to the building of a BOOT.raw file (which
contains the /startup dir). The -i switch instead use BOOT. Is it a
feature or a bug ?
* my 2.2 kernel tries to use modprobe to load modules because of kmod.
It is of no use in the case of mulinux. So, an advice if you use a 2.2
kernel with mulinux, don't compile in kmod support.
* with the 2.2 kernel, the initrd stuff isn't used. So /linuxrc is
skipped. It is not that bad with a ram mulinux, but it could become with
other kinds. I have looked into documentation, it seems that in order
for the boot loader to use initrd with a ram disk mounted as real root,
the argument root=/dev/ram should be passed to the kernel. I tried, it
doesn't work.
In muLinux a trick is used, the real root is set to the same ramdisk
which is the actual root.
It also seems to me that the argument "initrd=" should be given to lilo
in order to have an initrd. But it seems to work without that in mulinux
????
I will experiment, but advice is welcome.
Pat
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:16 CET