On Sat, 2005-04-16 at 22:15 +0200, gabriel wrote:
> Yeah.. but it shouldn't matter much since I've not been able to load the
> initrd
> yet?
>
I had just a look at all those things... It simply was a question coming
into my mind...
> My kernel never complains about root= bla it only says
On Sat, 2005-04-16 at 22:15 +0200, gabriel wrote:
Yeah.. but it shouldn't matter much since I've not been able to load the
initrd
yet?
I had just a look at all those things... It simply was a question coming
into my mind...
My kernel never complains about root= bla it only says unable
Have you edit the build-initrd.sh script to fit your needs?
Does
http://featherlinux.berlios.de/usb-instructions.htm or
http://www.ussg.iu.edu/hypermail/linux/kernel/0211.1/0551.html help?)
Totally different Q's:
Have you called syslinux with the correct parameter to find your
initrd.gz?
On Fri, 2005-04-15 at 09:27 +0200, gabriel wrote:
> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
Hi Gabriel!
It looks like initrd.gz could not be mounted. The unknown-block(1,0)
is /dev/ram0 (and has normally initrd attached to it) as specified on
kernel command
On Fri, 2005-04-15 at 09:27 +0200, gabriel wrote:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
Hi Gabriel!
It looks like initrd.gz could not be mounted. The unknown-block(1,0)
is /dev/ram0 (and has normally initrd attached to it) as specified on
kernel command
Have you edit the build-initrd.sh script to fit your needs?
Does
http://featherlinux.berlios.de/usb-instructions.htm or
http://www.ussg.iu.edu/hypermail/linux/kernel/0211.1/0551.html help?)
Totally different Q's:
Have you called syslinux with the correct parameter to find your
initrd.gz?
> checking if image is initramfs...it isn't (ungzip failed); looks like an
> initrd
> Freeing initrd memory: 32768K
Hi!
Have you gzipped your initrd image? (if yes, the ungzip failed would be
a problem... btw. initramfs is a smarter way to perform the same)
regards
-
To unsubscribe from this
checking if image is initramfs...it isn't (ungzip failed); looks like an
initrd
Freeing initrd memory: 32768K
Hi!
Have you gzipped your initrd image? (if yes, the ungzip failed would be
a problem... btw. initramfs is a smarter way to perform the same)
regards
-
To unsubscribe from this
memory available to
the PC should still be enough to hold both systems and also the DOS -
Ramdisk in memory.
Other Question: is (could) DOS-Ramdisk (be) available to Kernel? Maybe
as MTD?
regards
Bernhard Schauer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
should still be enough to hold both systems and also the DOS -
Ramdisk in memory.
Other Question: is (could) DOS-Ramdisk (be) available to Kernel? Maybe
as MTD?
regards
Bernhard Schauer
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
other question:
Is there any size-limit on initramfs image? I found out that after
reducing the image size it is loaded & /init executed as expected...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
other question:
Is there any size-limit on initramfs image? I found out that after
reducing the image size it is loaded /init executed as expected...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
looked at Documentation/early-
userspace) Can someone please point me into the right direction?
best regards,
Bernhard Schauer
ACOUSTA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vg
-
userspace) Can someone please point me into the right direction?
best regards,
Bernhard Schauer
ACOUSTA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
As far as I understand the numbering scheme, the 2.5 kernel leads to 2.6
series.
Why not just reactivate the 2.5 kernel (Starting with i.e. 2.5.112 which
will lead to 2.6.12)?
There will be no change visible to end-users and developers - IMO - are
more flexible in any case.
(I know I totally
As far as I understand the numbering scheme, the 2.5 kernel leads to 2.6
series.
Why not just reactivate the 2.5 kernel (Starting with i.e. 2.5.112 which
will lead to 2.6.12)?
There will be no change visible to end-users and developers - IMO - are
more flexible in any case.
(I know I totally
I'd like to "register" some ioctl numbers for driver development.
Attached is a patch for ioctl-numbers.txt, as requested in the same file.
regards
Bernhard Schauer
diff -ur ./linux-2.6.10-org/Documentation/ioctl-number.txt
./linux-2.6.10/Documentation/ioctl-number.txt
--- ./linux-
I'd like to register some ioctl numbers for driver development.
Attached is a patch for ioctl-numbers.txt, as requested in the same file.
regards
Bernhard Schauer
diff -ur ./linux-2.6.10-org/Documentation/ioctl-number.txt
./linux-2.6.10/Documentation/ioctl-number.txt
--- ./linux-2.6.10-org
> And almost all of them are pure software-patents and probably prior art.
> Thus they are - at least in Europe - not relevant and actually illegal
> if you believe in the current European patent law as defined by the
> European Patent Convention (see Â52(2) for details).
Hopefully nothing will
And almost all of them are pure software-patents and probably prior art.
Thus they are - at least in Europe - not relevant and actually illegal
if you believe in the current European patent law as defined by the
European Patent Convention (see 52(2) for details).
Hopefully nothing will change
20 matches
Mail list logo
