For those wondering what's happening with klibc, here's an update...
I have it building relatively well within the kernel, and have modified
the usr/gen_init_cpio.c file to add files to the cpio "blob". That all
seems to work, but I don't seem to be able to extract the files properly
(or at least that's what I'm guessing is happening).
If anyone wants to see the current progress, there's a big patch against
2.5.59 at:
kernel.org/pub/linux/kernel/people/gregkh/klibc/klibc-2.5.59.patch.gz
and a bk tree with the different changes broken down into "logical"
chunks at:
bk://kernel.bkbits.net/gregkh/linux/klibc-2.5
Any help with trying to debug init/initramfs.c to figure out what is
going wrong would be greatly appreciated.
thanks,
greg k-h
Followup to: <[email protected]>
By author: Greg KH <[email protected]>
In newsgroup: linux.dev.kernel
>
> For those wondering what's happening with klibc, here's an update...
>
> I have it building relatively well within the kernel, and have modified
> the usr/gen_init_cpio.c file to add files to the cpio "blob". That all
> seems to work, but I don't seem to be able to extract the files properly
> (or at least that's what I'm guessing is happening).
>
> If anyone wants to see the current progress, there's a big patch against
> 2.5.59 at:
> kernel.org/pub/linux/kernel/people/gregkh/klibc/klibc-2.5.59.patch.gz
> and a bk tree with the different changes broken down into "logical"
> chunks at:
> bk://kernel.bkbits.net/gregkh/linux/klibc-2.5
>
> Any help with trying to debug init/initramfs.c to figure out what is
> going wrong would be greatly appreciated.
>
Very cool :)
I will look at your stuff some time next week when I'm in .se for
NordU2003. Until then I'm afraid I'll have my hands full with
non-Linux work :(
-hpa
P.S. klibc-0.76 removes the much-complained-about Digest::MD5
dependence.
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: cris ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
Greg KH wrote:
> Any help with trying to debug init/initramfs.c to figure out what is
> going wrong would be greatly appreciated.
I've managed to mount the initramfs with MS_BIND into my root fs and
found why /sbin/hotplug cannot be run currently. There is some
off-by-one bug during file extraction that causes the first byte
of the file to get left out. I.e. the file starts with "ELF\001"
instead of "\577ELF".
This may or may not be related to another off-by-one bug that I'm
seeing sometime when unpacking initramfs on s390x ("panic: length
error").
The patch below is how I hacked prepare_namespace() to keep
initramfs visible after boot.
Arnd <><
--- 1.33/init/do_mounts.c Sun Jan 5 16:28:41 2003
+++ edited/init/do_mounts.c Thu Feb 6 01:12:29 2003
@@ -892,6 +892,7 @@
mount_root();
out:
sys_umount("/dev", 0);
+ sys_mount("/", "./initrd", NULL, MS_BIND, NULL);
sys_mount(".", "/", NULL, MS_MOVE, NULL);
sys_chroot(".");
security_sb_post_mountroot();
--- 1.33/fs/namespace.c Thu Nov 28 00:11:14 2002
+++ edited/fs/namespace.c Thu Feb 6 01:59:20 2003
@@ -460,7 +460,7 @@
{
int err;
if (mnt->mnt_sb->s_flags & MS_NOUSER)
- return -EINVAL;
+ ; // return -EINVAL;
if (S_ISDIR(nd->dentry->d_inode->i_mode) !=
S_ISDIR(mnt->mnt_root->d_inode->i_mode))
I found what kept initramfs from working here: While creating
of initramfs_data.cpio.gz, the padding between a file header
and the file contents was wrong, which can be verified by
unpacking the archive by hand.
The trivial patch below fixed this for me.
Arnd <><
===== usr/gen_init_cpio.c 1.3 vs edited =====
--- 1.3/usr/gen_init_cpio.c Tue Feb 4 23:29:14 2003
+++ edited/usr/gen_init_cpio.c Thu Feb 6 12:32:47 2003
@@ -192,6 +192,7 @@
0); /* chksum */
push_hdr(s);
push_string(location);
+ push_pad();
for (i = 0; i < buf.st_size; ++i)
fputc(filebuf[i], stdout);
On Thu, Feb 06, 2003 at 01:07:33PM +0100, Arnd Bergmann wrote:
> I found what kept initramfs from working here: While creating
> of initramfs_data.cpio.gz, the padding between a file header
> and the file contents was wrong, which can be verified by
> unpacking the archive by hand.
>
> The trivial patch below fixed this for me.
Thanks a lot for the patch, I've added it to my tree, and verified that
the uncompressed archive works properly.
thanks again,
greg k-h