On 01/03/2016 09:35 PM, Christian Seiler wrote:
> Well, just for the heck of it I wrote a braindead-simple initrd
> implementation in just 300 LOC:
>
> https://gist.github.com/chris-se/e0fbc073fcbd9ac2d7ae
>
> [...]
>
> This is just a proof of concept, [...]
Well, in
man.net/wiki/debirf
* License : GPLv3
Programming Lang: Bash
Description : Build a kernel and initrd to run Debian from RAM
debirf (DEBian on Initial Ram Filesystem) is a set of tools designed
to create and prepare a kernel and initial ram filesystem that can
run a full-blown Debian
On Wed, Mar 22, 2006 at 03:01:29PM +0100, Jose Luis Ayala wrote:
> Hi guys! I don't know if you are working on the ata_piix bug that
> prevents me from using the IDE CDROM with the ATA HD... but it's making
> me
> going crazy! :)
>
> I've following the recommenda
Hi guys! I don't know if you are working on the ata_piix bug that
prevents me from using the IDE CDROM with the ATA HD... but it's making
me
going crazy! :)
I've following the recommendations of making a new initrd file with the
modules ide-generic ata_piix sd_mod and ordered i
On Tuesday 18 January 2005 09:03, Brian May <[EMAIL PROTECTED]> wrote:
> I guess this means sarge won't work "out-of-the-box" with 2.6.11 and
> LVM unless you compile your own kernel (one that doesn't require an
> initrd image), or fix this initrd image.
LVM
On Wed, Jan 19, 2005 at 01:19:39AM +0100, Goswin von Brederlow wrote:
> Without devfs the syntax of e.g. /proc/partitions changes and anything
> parsing those files needs to adapt back to the old syntax.
That was a bad bug in Linux 2.4 and has been fixed in Linux 2.6 already,
there even devfs kern
ate to LVM2 during
> the lifetime of sarge (and probably 2.6 kernels too).
Debian kernels (2.4.x) are already patched with the device mapper
patches and are fully lvm2 capable. Since lvm2 understands lvm1
metadata you can just update to lvm2 userspace tools, create a new
initrd and reboot.
> D
Christoph Hellwig wrote:
> so unless Debian wants to stay with stoneage kernels you're better of
> starting to fix D-I.
We're not going to destabalise d-i by beginning to make large changes to
it, like not using devfs, until sarge is released.
FWIW, the main current d-i release blocker is a lack
etch (ie when etch is "testing") debian will hit
this "removal of devfs" problem... this will not affect sarge (Assuming sarge
_IS_ released by then). etch is the place to fix the problem. The fix will
be in 4 parts...
(1) the kernel package will have no devfs!
(2) initrd-to
LVM unless you compile your own kernel (one that doesn't require an
> initrd image), or fix this initrd image.
If a 2.6.11 kernel makes it into sarge, then yes, someone'll have to
fix up initrd-tools for sarge as well. Since the Debian kernel team
also maintains initrd-tools, I don&
On Mon, Jan 17, 2005 at 10:34:06AM +0100, Christoph Hellwig wrote:
>
> so unless Debian wants to stay with stoneage kernels you're better of
> starting to fix D-I. That beeing said D-I people have been told
> repeatedly that basing an installer on devfs is a bad idea long time
> ago, but let's no
ot;out-of-the-box" with 2.6.11 and
LVM unless you compile your own kernel (one that doesn't require an
initrd image), or fix this initrd image.
--
Brian May <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Mon, Jan 17, 2005 at 09:29:41PM +1100, Russell Coker wrote:
> On Monday 17 January 2005 20:34, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > so unless Debian wants to stay with stoneage kernels you're better of
> > starting to fix D-I. That beeing said D-I people have been told
> > repeatedl
On Mon, Jan 17, 2005 at 10:34:06AM +0100, Christoph Hellwig wrote:
> Documentation/feature-removal-schedule.txt in 2.6.11-rc1:
>
> What: devfs
> When: July 2005
> Files: fs/devfs/*, include/linux/devfs_fs*.h and assorted devfs
> function calls throughout the kernel tree
> Why:It h
On Monday 17 January 2005 20:34, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> so unless Debian wants to stay with stoneage kernels you're better of
> starting to fix D-I. That beeing said D-I people have been told
> repeatedly that basing an installer on devfs is a bad idea long time
> ago, but
> In that case, we should probably drop debian-installer altogether, as it
> uses DevFS throughout :-)
Documentation/feature-removal-schedule.txt in 2.6.11-rc1:
What: devfs
When: July 2005
Files: fs/devfs/*, include/linux/devfs_fs*.h and assorted devfs
function calls throughout the k
Op ma, 17-01-2005 te 20:03 +1100, schreef Russell Coker:
> Devfs is regarded as obsolete in the kernel source.
>
> The current initrd images produced by initrd-tools does the following for a
> LVM system:
> mount -nt devfs devfs /dev
> vgchange -a y
> umount /dev
>
&
On Mon, Jan 17, 2005 at 08:03:42PM +1100, Russell Coker wrote:
> Devfs is regarded as obsolete in the kernel source.
>
> The current initrd images produced by initrd-tools does the following for a
> LVM system:
> mount -nt devfs devfs /dev
> vgchange -a y
> umount /dev
Devfs is regarded as obsolete in the kernel source.
The current initrd images produced by initrd-tools does the following for a
LVM system:
mount -nt devfs devfs /dev
vgchange -a y
umount /dev
This relies on a kernel with devfs compiled in to boot a system with an LVM
root file system.
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Eric,
most cc:s removed - and I'm still thinking wether I should send this as a
private mail... anyway:
I'm sorry if I offended you with my summary mail about the current status of
quik and initrd-support. My aim is to help to g
Ce jour Fri, 03 Dec 2004, Holger Levsen a dit:
i'd appreciate not having it hijacked from under me. i don't mind
getting help, and i do appreciate that, but i get the feeling it's being
hijacked from me. you could at least tell me WTF is going on.
eric
(the current quik maintainer)
--
Microsoft
clude
> documentation of the initrd option? I'd be more comfortable with
> modifying quik-installer to match then.
i meant to do some doc updates in my last update, but i ran out of time (was
leaving
for ottawa), so i didn't get a chance to do so :(. in my next "upload"
Ce jour Tue, 30 Nov 2004, Simon Vallet a dit:
> On Mon, 29 Nov 2004 23:05:03 +0100
> Peter 'p2' De Schrijver <[EMAIL PROTECTED]> wrote:
>
> > The quik.conf should be :
> >
> > image=/boot/vmlinux-2.6.9-powerpc
> > append="root=/dev/
Ce jour Sun, 28 Nov 2004, Simon Vallet a dit:
> On Fri, 26 Nov 2004 10:58:48 +0100
> Holger Levsen <[EMAIL PROTECTED]> wrote:
>
> kernel-image-2.6.9-powerpc and initrd : I get stuck at
> VFS : Unable to mount root fs on unknown-block (1,0),
> which is what I experi
Ce jour Sun, 28 Nov 2004, Christian Leimer a dit:
> Hi!
>
> Can someone please post a sample quik.conf?
>
> Do you use the ramdisk option or the append string one, any other settings?
>
> I have an Umax S900 and it does not work here.
> Says something about can not find the root device.
>
> I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Peter 'p2' De Schrijver has made some new updates to the quik - you can get it
(.deb and source) at the http://www.ulyssis.org/~p2/debjes/
changes include:
- manpage tells about initrd
- compiles with gcc3
- sprintf bug fixed
Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 10, 2003 at 09:48:55AM +0100, Florent Rougon wrote:
>> autodetection to manual setting in my GRUB config files and am happy
>> with this setup (I hate black magic).
>
> Black magic can be good for multi path io, sans and generally for a
> un
On Wed, Dec 10, 2003 at 09:26:39PM +1100, Herbert Xu wrote:
> If you don't have the underlying devices there RAID autodetection
> will not work.
Well, if you have no devices, you cant detect them. However, on boot you
most likely do have the devices.
Greetings
Bernd
--
(OO) -- [EMAIL PROT
On Wed, Dec 10, 2003 at 09:48:55AM +0100, Florent Rougon wrote:
> autodetection to manual setting in my GRUB config files and am happy
> with this setup (I hate black magic).
Black magic can be good for multi path io, sans and generally for a
unattended reboot on hardware changes.
Greetings
Bernd
On Wed, Dec 10, 2003 at 09:32:16AM +1100, Brian May wrote:
> I believe the kernel raid1 autodetection only works if raid1 is
> compiled into the kernel.
>
> In anycase, initrd images generated from mkinitrd in Debian do not
> autodetect.
It is possible to invite the autodetect
details)
It would be interesting to at least report it on linux-raid (perhaps you
did before I subscribed, which happened about 1.5 years ago...), since
Neil Brown seems to take good care of mdadm (in contrast to the
raidtools---some of which, namely raidstart IIRC, are "broken by design&qu
> this, but when I asked the initrd maintainer I was given a good reason
> > why it was not used (sorry; I can't remember what this was now; it might
> > simply be that the mdadm code is unreliable, inefficient, or buggy).
>
> I think this is unlikely, since (-s = --scan) is w
Brian May <[EMAIL PROTECTED]> wrote:
>
> IIRC, There is a parameter to mdadm (--scan?) that could be used for
> this, but when I asked the initrd maintainer I was given a good reason
> why it was not used (sorry; I can't remember what this was now; it might
> simply
as modules, you need to
apply an md patch from Paul Clements (I never tried this patch).
BTW, linux-raid seems not to be archived on mlist.linux.raid any more
since about August 2002 which, uhm, sucks.
> In anycase, initrd images generated from mkinitrd in Debian do not
> autodetect.
Also, pe
oes that only work with
> build-in drivers?
I believe the kernel raid1 autodetection only works if raid1 is compiled
into the kernel.
In anycase, initrd images generated from mkinitrd in Debian do not
autodetect.
IIRC, There is a parameter to mdadm (--scan?) that could be used for
this, b
age so I have chosen not to bother.
>
> This seems strange, perhaps the process is not entirely obvious,
> but I wouldn't have thought it be too difficult.
>
> However, I have been disappointed with the initrd script for Debian in
> that support for autodetecting software RAI
rhaps the process is not entirely obvious,
but I wouldn't have thought it be too difficult.
However, I have been disappointed with the initrd script for Debian in
that support for autodetecting software RAID1 is poor (read:
non-existant), and while RAID1 will work if the harddisks are plugged in
ex
On Sun, 7 Dec 2003 12:02, Chad Walstrom <[EMAIL PROTECTED]> wrote:
> That's sad. initrd saved my bacon more than once. ;-) If you like to
Initrd broke my systems more than once.
The recent versions of the package have significant problems if you want to
convert to or from devf
On Sat, Dec 06, 2003 at 05:11:50PM +1100, Russell Coker wrote:
> What is needed for initrd-tools? I've given up on using initrd's for
> kernels I compile.
That's sad. initrd saved my bacon more than once. ;-) If you like to
compile vanilla kernels, either find the Debian c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> If you're using busybox then try regenerating the initrd image with
>> BUSYBOX=no.
> I did not generate the image, i'm using a stock kernel-image-2.4.22-1-k7
> package, no trace of busybox in the initrd image, and it&#x
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks for the attention, Herbert.
> If you're using busybox then try regenerating the initrd image with
> BUSYBOX=no.
I did not generate the image, i'm using a stock kernel-image-2.4.22-1-k7
package, no trace of busybox in the i
Nicola Larosa <[EMAIL PROTECTED]> wrote:
>
> RAMDISK: cramfs filesystem found at block 0
> RAMDISK: Loading 3532 blocks [1 disk] into ram disk... done.
> Freeing initrd memory: 3532k freed
> VFS: mounted root (cramfs filesystem).
> mount: Usage: mount [-t filesystemtype]
lilo:
boot=/dev/hda
root=/dev/hda5
# compact
install=/boot/boot-menu.b
map=/boot/map
image=/boot/vmlinuz-2.4.22-1-k7
label=linux
initrd=/boot/initrd.img-2.4.22-1-k7
read-only
Relevant parameters for grub:
title Debian GNU/Linux, kernel 2.4.22-1-k7
root(hd0,4)
k
On Mon, 14 Jul 2003 00:42, Nenad Antonic wrote:
> However, it looks like initrd/cramfs is not yet stable enough, and
> building a number of different kernels for different architectures might
> be simpler solution for my needs at the moment.
The main problem with the initrd is t
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Why are you trying to use initrd anyway? It's much easier to build
> the drivers into the kernel.
Now, I must agree with that.
At the begining, it looked as a good idea to compile one kernel which
can be used on scsi and
On Sat, Jul 12, 2003 at 06:04:41PM +1000, Herbert Xu wrote:
> Nenad Antonic <[EMAIL PROTECTED]> wrote:
> > Apparently, there is a bug (at least from my perspective) which
> > prevents initrd/cramfs in stock kernels, which has been arround for
> > years. On the other h
Nenad Antonic <[EMAIL PROTECTED]> wrote:
>Apparently, there is a bug (at least from my perspective) which
> prevents initrd/cramfs in stock kernels, which has been arround for
> years. On the other hand, this bug gets fixed in every version of debian
Why are you tryin
he right place to start
learning. Kernel has to be reliable.
Apparently, there is a bug (at least from my perspective) which
prevents initrd/cramfs in stock kernels, which has been arround for
years. On the other hand, this bug gets fixed in every version of debian
kernel-sources (I kn
Nenad Antonic <[EMAIL PROTECTED]> écrivait (wrote) :
> RAMDISK: cramfs filesystem found at block 0
initrd detected.
> RAMDISK: loading 1032 blocks [1 disk] into ram disk... done.
initrd mounted, scripts executed.
> Freeing initrd memory: 1032k freed
initrd u
On Mon, Jul 07, 2003 at 08:41:43PM +0200, Nenad Antonic wrote:
> On # Mon, 7 Jul 2003 13:38:35 -0400, Matt Zimmerman wrote:
> > Neither does kernel.org source, and you can patch both of them easily.
>
> Could I just use acpi-20030619 patch from ACPI project page, and apply
> it to kernel-so
On # Mon, 7 Jul 2003 13:38:35 -0400, Matt Zimmerman wrote:
>> RAMDISK: cramfs filesystem found at block 0
>> RAMDISK: loading 1032 blocks [1 disk] into ram disk... done.
>> Freeing initrd memory: 1032k freed
>> cramfs: wrong magic
>> Kern
s, and for 2.4.22-pre3, while
> using debian kernel-package 8.041, testing cramfsprogs 1.1-4 and
> initrdtools (both 0.1.47 and 0.1.48), I was not able to boot:
> RAMDISK: cramfs filesystem found at block 0
> RAMDISK: loading 1032 blocks [1 disk] into ram disk... done.
&
> Since it is a moving target, kernel compilation is a difficult
> subject that may confuse even the most admired developer:
> [Debian Reference]
What is the status of initrd kernel building process (only on i386),
while using stock kernels (from kernel.org)?
Kern
Hi,
The way I've always broken into a Linux box when it's been seriously
broken or the root password's been forgotten is to go "linux init=/bin/sh"
at the LILO prompt.
However, this doesn't appear to have the desired effect when you've got a
system tha
|| On Sun, 21 Apr 2002 15:00:44 -0400
|| Bill Jonas <[EMAIL PROTECTED]> wrote:
bj> have LILO installed.) If you're using GRUB, be sure the 'kernel' line
bj> includes 'initrd=/path' somewhere in it. (See
bj> /usr/src/linux/Documentation/initrd.t
On Mon, Apr 22, 2002 at 12:01:17AM +0530, Ramakrishnan M wrote:
> Any idea what is happening?
Do you have an 'initrd=' line in lilo.conf? (I believe that's the
correct setting; I can't easily verify as I'm using GRUB now and don't
have LILO installed.) If you&#
Hi,
I am trying to make a kernel with initrd support (just to understand how to make
an kernel with initrd support and how initrd works with it).
I built the kernel with initrd support, and made an initrd image (using the
excellent
initrd-tools package) and using the modules of the same above
.17-586tsc version 2.4.17-1 from the distribution.
> The loadmodules script in the initrd does not load ext3. When I added
> modprobe -k ext3 my problem was solved. I'd like to ask you if it is
> the right way how to solve the problem.
1. Make sure you've got initrd-tools 0.1.14
On Fri, Jan 11, 2002 at 07:17:13PM +0100, Eduard Bloch wrote:
>
> > if not, the i would not recommend the use of auto in that case.
>
> It is a patch for mkinitrd
well, you answered my questions! it seems then ``type auto'' would be
fine, especially since the patches in question don't affect the
#include
John H. Robinson, IV wrote on Fri Jan 11, 2002 um 09:49:12AM:
> > All this will be easier if you use "auto" as fs type and WHEN Herbert
> > Xu finally applies MY PATCH submitted a while ago.
>
> would type auto work with a fresh, hand compiled kernel from kernel.org?
Why not? On mounti
On Fri, Jan 11, 2002 at 03:44:54PM +0100, Eduard Bloch wrote:
>
> All this will be easier if you use "auto" as fs type and WHEN Herbert
> Xu finally applies MY PATCH submitted a while ago.
would type auto work with a fresh, hand compiled kernel from kernel.org?
if not, the i would not recommend t
o problem except that root fs was still mounted as ext2. Kernel
Do you know for sure? Did you trust "mount" output or /proc/mounts
content?
> is kernel-image-2.4.17-586tsc version 2.4.17-1 from the distribution.
> The loadmodules script in the initrd does not load ext3. When I ad
script in the initrd does not load ext3. When I added
modprobe -k ext3 my problem was solved. I'd like to ask you if it is
the right way how to solve the problem.
--
Marek, http://m-a.sk
Following the advice from some people here (thanks in particular to Thierry
Laronde) I have got initrd and NFS root working so that I can use the same
kernel binary for hard drives, RAID, and NFS root without making the kernel
excessively large.
I have written a document on what I have done
64 matches
Mail list logo
