> I've found the main error, and it was mine.
> If /sbin/init is dependant on shared libraries (and also
> /bin/sh), and those libraries and the loader reside on /lib,
> which is on /dev/ram2, then by re-mounting the root device
> /dev/ram1 while not having /dev/ram2 no dynamically linked
> program could be started. The ram disk itself was completely
> correct.
I have to admit that I should've noticed that - aeons ago, somebody
pointed out to me that the following directories and their contents
MUST all reside in the root partition...
/bin
/lib
/sbin
...and it's for this reason that the following directories exist...
/usr/bin
/usr/lib
/usr/sbin
...as the former should only contain those files necessary for
booting, with the latter containing the remaining files of each type.
> It's sometime so easy and hard to find such an error !
Who was it said that maintenance is 10% inspiration and 90%
persperation? Whoever it was certainly got things right...
> After I've shuffled the programs and libraries a bit, now
> booting works as never having done something else. The ramdisk
> version now works.
Good...
> What's persisting now is the difference between 2.2.1 and 2.2.5
> with d_count and re-mounting the initial ramdisk, but that's an
> error which I will report seperately into linux-kernel. Maybe I
> will report the solution, too.
Let's hope so...
> Thanks for your help and your ideas. If I could help you, feel
> free to ask, too.
There is one problem you may be able to help with, but it's not
directly kernel related so I'll email re it separately...
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/