Recent changes broke mkinitrd?

Recent changes broke mkinitrd?

[Stephen Hemminger]

Recent (post 2.5.67) versions of the kernel break the creation
of the initial ram disk. This is on RH 8.0 but probably is more
wide spread.

The failure mode is:
# mkinitrd /tmp/initrd.2.5.67 2.5.67
tar: ./bin: Cannot mkdir: No space left on device
tar: ./bin/nash: Cannot open: No such file or directory
tar: ./bin/insmod: Cannot open: No such file or directory
tar: ./bin/modprobe: Cannot open: No such file or directory
tar: ./etc: Cannot mkdir: No space left on device
tar: ./dev: Cannot mkdir: No space left on device
tar: ./dev/console: Cannot mknod: No such file or directory
tar: ./dev/null: Cannot mknod: No such file or directory
tar: ./dev/ram: Cannot mknod: No such file or directory
tar: ./dev/systty: Cannot mknod: No such file or directory
tar: ./dev/tty1: Cannot mknod: No such file or directory
tar: ./dev/tty2: Cannot mknod: No such file or directory
tar: ./dev/tty3: Cannot mknod: No such file or directory
tar: ./dev/tty4: Cannot mknod: No such file or directory
tar: ./loopfs: Cannot mkdir: No space left on device
tar: ./proc: Cannot mkdir: No space left on device
tar: ./sysroot: Cannot mkdir: No space left on device
tar: Error exit delayed from previous errors

The problem is not the increase size of modules but instead something
changed with ext2/ext3? 

                 Running kernel
                 2.5.67-bk  2.4.18
                 *-------*------*
	  2.5.67 | Fails |  Ok  |
mkinitrd         *-------*------*
          2.4.18 | Fails |  Ok  |
                 *-------*------*

2.5.67 is okay, but the latest kernel from bk is not.


	

Re: Recent changes broke mkinitrd?

[Andrew Morton]

Stephen Hemminger <shemminger@osdl.org> wrote:
>
> Recent (post 2.5.67) versions of the kernel break the creation
> of the initial ram disk.

hmm, so it did.  It'll be the ext2 changes.  mkinitrd works OK if you use
ext3:

--- mkinitrd.orig	2003-04-17 11:38:49.000000000 -0700
+++ mkinitrd	2003-04-17 11:39:01.000000000 -0700
@@ -473,7 +473,7 @@
 
 # We have to "echo y |" so that it doesn't complain about $IMAGE not
 # being a block device
-echo y | mke2fs $LODEV $IMAGESIZE >/dev/null 2>/dev/null
+echo y | mke2fs -j $LODEV $IMAGESIZE >/dev/null 2>/dev/null
 tune2fs -i0 $LODEV >/dev/null
 
 if [ -n "$verbose" ]; then
@@ -481,7 +481,7 @@
 fi
 
 mkdir -p $MNTPOINT
-mount -t ext2 $LODEV $MNTPOINT || {
+mount -t ext3 $LODEV $MNTPOINT || {
 	echo "Can't get a loopback device"
 	exit 1
 }

I'll take a look...

Re: Recent changes broke mkinitrd?

[Stephen Hemminger]

On Thu, 17 Apr 2003 11:40:16 -0700
Andrew Morton <akpm@digeo.com> wrote:

> Stephen Hemminger <shemminger@osdl.org> wrote:
> >
> > Recent (post 2.5.67) versions of the kernel break the creation
> > of the initial ram disk.
> 
> hmm, so it did.  It'll be the ext2 changes.  mkinitrd works OK if you use
> ext3:

That works for me - Thanks

[patch] Fix orlov allocator boundary case

[Andrew Morton]

Stephen Hemminger <shemminger@osdl.org> wrote:
>
> Recent (post 2.5.67) versions of the kernel break the creation
> of the initial ram disk.

OK, here be the fix.

I'm a bit peeved that this wasn't discovered until it hit Linus's tree. 
Weren't these patches in -mjb as well?





In the interests of SMP scalability the ext2 free blocks and free inodes
counters are "approximate".  But there is a piece of code in the Orlov
allocator which fails due to boundary conditions on really small
filesystems.

Fix that up via a final allocation pass which simply uses first-fit for
allocation of a directory inode.


 fs/ext2/ialloc.c |    9 +++++++++
 1 files changed, 9 insertions(+)

diff -puN fs/ext2/ialloc.c~orlov-approx-counter-fix fs/ext2/ialloc.c
--- 25/fs/ext2/ialloc.c~orlov-approx-counter-fix	2003-04-17 12:12:33.000000000 -0700
+++ 25-akpm/fs/ext2/ialloc.c	2003-04-17 12:14:09.000000000 -0700
@@ -410,6 +410,15 @@ fallback:
 			goto found;
 	}
 
+	if (avefreei) {
+		/*
+		 * The free-inodes counter is approximate, and for really small
+		 * filesystems the above test can fail to find any blockgroups
+		 */
+		avefreei = 0;
+		goto fallback;
+	}
+
 	return -1;
 
 found:

_

Re: [patch] Fix orlov allocator boundary case

[Stephen Hemminger]

On Thu, 17 Apr 2003 12:21:42 -0700
Andrew Morton <akpm@digeo.com> wrote:

> Stephen Hemminger <shemminger@osdl.org> wrote:
> >
> > Recent (post 2.5.67) versions of the kernel break the creation
> > of the initial ram disk.
> 
> OK, here be the fix.
> 
> I'm a bit peeved that this wasn't discovered until it hit Linus's tree. 
> Weren't these patches in -mjb as well?

The patch fixed the problem -- thanks again

Re: [patch] Fix orlov allocator boundary case

[Marc-Christian Petersen]

On Thursday 17 April 2003 21:21, Andrew Morton wrote:

Hi Andrew,

> OK, here be the fix.
> I'm a bit peeved that this wasn't discovered until it hit Linus's tree.
> Weren't these patches in -mjb as well?
I guess this is also true for the ext3 code?

I am using the orlov stuff for 2.4.21* maintained by Theodore and Steven.

ciao, Marc

Re: [patch] Fix orlov allocator boundary case

[Andrew Morton]

Marc-Christian Petersen <m.c.p@wolk-project.de> wrote:
>
> On Thursday 17 April 2003 21:21, Andrew Morton wrote:
> 
> Hi Andrew,
> 
> > OK, here be the fix.
> > I'm a bit peeved that this wasn't discovered until it hit Linus's tree.
> > Weren't these patches in -mjb as well?
> I guess this is also true for the ext3 code?

Only for the modified ext3 in the -mm tree.

> I am using the orlov stuff for 2.4.21* maintained by Theodore and Steven.

That kernel will not exhibit the problem - it is caused by the "fast version"
of the free inodes count being off by a few blocks, and the filesystem having
only one block group.