similar to: PXE and initramfs

Yes, I found the root of the problem... it's hotplug, which shouldn't be enabled during the early boot. So, I just "chmod 644 /sbin/hotplug", then I created /init: ************* #!/bin/sh echo "Running networkboot prescript" /bin/chmod 755 /sbin/hotplug exec /sbin/init </dev/console >/dev/console 2>&1 ********* and made initramfs with it. Vlad. On

According to "initramfs buffer format -- third draft" http://lwn.net/2002/0117/a/initramfs-buffer-format.php3 "the cpio "TRAILER!!!" entry (cpio end-of-archive) is optional, but is not ignored" The kernel handling does not follow this spec. If you add null padding after an uncompressed cpio without TRAILER!!! the kernel complains "no cpio magic". In a

Harcoding default content of initramfs in the gen_initramfs_list.sh script seems ackward. Move it to a file named: usr/initramfs.default This also fixes a small bug when no arguments was passed to CONFIG_INITRAMFS_SOURCE (-d was passed twice to the script) Idea and bug report from: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> ---

Harcoding default content of initramfs in the gen_initramfs_list.sh script seems ackward. Move it to a file named: usr/initramfs.default This also fixes a small bug when no arguments was passed to CONFIG_INITRAMFS_SOURCE (-d was passed twice to the script) Idea and bug report from: "H. Peter Anvin" <hpa at zytor.com> Signed-off-by: Sam Ravnborg <sam at ravnborg.org>

I've been having an exchange of e-mails with Bryan O'Sullivan regarding this problem. I thought it time to bring it to the list. I've run into a problem where my initramfs archives get this during bootup: checking if image is initramfs...it isn't (ungzip failed); looks like an initrd The same .cpio archive works if I don't gzip it. I stuck a bunch of debug statements into

This fix has been implemented in preparation for the upcoming klibc merge in -mm. But as it fixes a real (but rare I hope) bug in vanilla kernel it will be added to my pending 2.6.17 kbuild queue. I've done quite some changes to the gen_initramfs script and being shell programming newbie review by more experienced shell hackers would be appreciated. I did a git mv

Last patch for now. This gets gen_init_cpio into a state where it can pick up a "kinit" binary from usr and stuff it into the cpio archive as /sbin/init. This is obviously a crock, but it suffices for testing until something sane is done about integrating klibc into the kernel tree. The patch also adds a bit of instrumentation to initramfs.c, to try to help flush out bug 740.

--32u276st3Jlj2kUU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all (two) klibc hackers! 8) Here's the stuff I've been using to build an initramfs image and run it on one of my machines. Unfortunately, the "init" script contains hard coded information about where to find the root, etc, but it should give people a working base to start from. It

hpa notified me in private mail that we have an issue that when building initramfs - if the content changes (say kinit) then the initramfs will not be rebuild. The solution I have come up with is to let make check all the files included in the initramfs and rebuild it if any files are newer than the initramfs and also rebuild if arguments changes (root_uid). In same process the usr/Kbuild file

Hi, Here's a try at writing an initramfs HOWTO. This is basically a write-up of a number of interesting emails I collected over time. It could probably use an editor, more fact-checking and a bunch of other good things, but it should be better than nothing ;-) Daniel -------------- next part -------------- INITRAMFS HOWTO 0) What are klibc and initramfs? Initramfs is a ramfs into which

Hi , One of the things I am working on requires me to have a kernel and an initrd (as root filesystem , based on busybox) in one single image. I am trying to use initramfs for this, but there are a few things that I just can't figure out. As a test, I made a cpio archive of my own for the kernel source (plain 2.6.0-test5). Everything gets unpacked just fine during boot. Somehow I was

Hi, The attached patch is an update to the latest klibc (I just checked a few bits into CVS) which adds support for initramfs. Since it contains bits that aren't available yet on the main site, I've also put a tarball up which contains only what's in the latest CVS. The initramfs stuff is what I use here to boot one of my machines; it works for me, but probably won't work

> Am 26.02.2018 um 06:46 schrieb wuzhouhui <wuzhouhui14 at mails.ucas.ac.cn>: > >> -----Original Messages----- >> From: "Steven Tardy" <sjt5atra at gmail.com> >> Sent Time: 2018-02-26 10:48:48 (Monday) >> To: "CentOS mailing list" <centos at centos.org> >> Cc: >> Subject: Re: [CentOS] How to update modules in

> -----Original Messages----- > From: "Steven Tardy" <sjt5atra at gmail.com> > Sent Time: 2018-02-26 10:48:48 (Monday) > To: "CentOS mailing list" <centos at centos.org> > Cc: > Subject: Re: [CentOS] How to update modules in iniramfs fastly > > On Sun, Feb 25, 2018 at 8:29 PM wuzhouhui <wuzhouhui14 at mails.ucas.ac.cn> > wrote:

Hi, I 'am trying to launch linux kernel 2.6.7 with initramfs. My pxelinux.cfg/default file looks as follows: default a1 prompt 1 timeout 600 label a1 kernel vmlinuz-2.6.7-1 append initrd=initramfs_data.cpio.gz root=/dev/ram0 init=/linuxrc Kernel image vmlinuz-2.6.7-1 and initramfs_data.cpio.gz was loaded succesfully by pxelinux. Kernel says: checking if image is initramfs... it is but

At present the configuration items for initramfs is located in: Device drivers | Block Drivers | xxx This is maybe not the most natural place to have it. So with the following patch it is moved below "General setup", and relevant config items are collected in a file with a new home in usr/. The original reason why I looked into this is the upcoming merge of klibc and I missed a good

I converted my lvm root initrd to an initramfs by putting glibc, lvm, pivot_root, my linuxrc, etc. in my initramfs source file. I use ash compiled against klibc to run my linuxrc Unfortunately - pivot_root . initrd - complains - pivot_root: Invalid argument I suspect this may be because you can't pivot_root using a cpio initramfs root? If so, what should I do instead? Should I

The following patch unlinks (deletes) files, symlinks, FIFOs, devices etc before writing them when extracting CPIOs. It doesn't delete directories. This stops weird behaviour like: 1) writing through symlinks created in earlier CPIOs. eg foo->bar in the first CPIO. Having foo as a non link in a subsequent CPIO, results in bar being written and foo remaining as a symlink. 2)

Unlink files, symlinks, FIFOs, devices etc. (except directories) before writing them when extracting CPIOs. This stops weird behaviour like: 1) writing through symlinks created in earlier CPIOs. eg foo->bar in the first CPIO. Having foo as a non-link in a subsequent CPIO, results in bar being written and foo remaining as a symlink. 2) if the first version of file foo is larger

On Mon, 26 Feb 2018, wuzhouhui wrote: > > -----Original Messages----- > > From: "Steven Tardy" <sjt5atra at gmail.com> > > Sent Time: 2018-02-26 10:48:48 (Monday) > > To: "CentOS mailing list" <centos at centos.org> > > Cc: > > Subject: Re: [CentOS] How to update modules in iniramfs fastly > > > > On Sun, Feb 25, 2018