From: Michele Andreoli (m.andreoli@tin.it)
Date: Tue Nov 21 2000 - 21:30:37 CET
On Tue, Nov 21, 2000 at 05:43:06PM +0100, Dumas Patrice wrote:
> Hi,
> Sorry, it is a very long mail.
> I have pushed mulinux 10r5 to it's limits, trying to use it with a 2.2.x
> kernel with an old ide interface...
You will have some problem with tty.
>
> 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.
This (rustic) detection relie on a messaged in the boot log.
> It should
> be good to store dmesg boot output in var (maybe it is allready done ?),
> at boot time, maybe in mount_root() ?.
It is saved by /bin/scan, but I'm not sure.
>
> 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.
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?
> 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.
It is true: I removed in 11.* this detection. The "mu" script now
user directly the tree/usr/bin/mkfs.ext2 command. This save us from
future incompatibilities.
>
> 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 ?
A feature: BOOT = ROOT.raw + LILO.
>
> * 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.
I know all the subject, because I ported muLinux on 2.2.5 last year
for an embedded company.
>
> * 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 faced with the problem. The "initrd" seems to be optional for 2.0.*,
but strongly suggested for 2.2.*, but do not remember well.
Anycase, most part of the work carried out by /linuxrc is replicated
in the /etc/rc/4, after root is mounted. In this way, muLinux is able
to work either using ramdisk, either when installed. In other words,
it is double-face: ram Linux and HD Linux.
>
> I will experiment, but advice is welcome.
>
If you do this work for your own experiments, it is ok. But if you
plan to port muLinux on the 2.2.* series, I can't follow you and
I'm not interested.
In a previous email I explained my opinion about to change the kernel
in the first floppy disk. Best thing should be to down-grade it, not
to upgrade!
I prefer a patch ADDON able to upgrade the muLinux, *after* its
installation in hard-disk. All modifications have to be carried out
using the "prolog" script in the addon itself.
Example: you can call the addon K22 and the script /usr/k22/bin/prolog
should be able to
1. replace the kernel in /startup/boot/mulinuz
2. to replace modules (the list of paths is in /etc/modules.conf)
3. create the new device in /dev/ with mknod
.... etc ... etc ...
In this way, in the future we can add devolope the K24 patch-addons,
and following.
If you dislike the addon concept (and in this case I'm with you), you
can produce a simple tgz and a new commnad command like "load_patch":
the command unpack the TGZ in /tmp and starts moving material in the
real root with "cp".
Michele
-- mulinux with mutt and smail --------------------------------------------------------------------- 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