Subject: Re: Tests of mdsetimage -s
To: Marcin Jessa <lists@yazzy.org>
From: Jachym Holecek <freza@liberouter.org>
List: tech-embed
Date: 04/02/2005 04:42:39
> > As far as I understand, this is to reserve a lot of space first
> > (MEMORY_DISK_ROOT_SIZE), and then later tell the kernel how much space
> > really to allocate. Try embedding your 11MB filesystem in the 51MB kernel.
>
> OK, now I set MEMORY_DISK_ROOT_SIZE=15000 which gives 15000*512/1024 = 7500 k
> The image is 5112 k
Not sure, but it doesn't seem like memory reserved by MEMORY_DISK_ROOT_SIZE
is ever freed (mdsetimage won't do it that is). So I'd say first create
the disk image, then set MEMORY_DISK_ROOT_SIZE to match (roud up to closest
blocksize multiple).
I may be wrong on this though, didn't look too deep...
> #mdsetimage -v -s netbsd custom.img
> [... works fine ...]
>
> Running without -s gives:
> # mdsetimage -v netbsd custom.img
> [... works fine ...]
>
> Seems like -s sets the reserved space to the size of the image.
Yes, see also /usr/src/gnu/usr.sbin/mdsetimage/mdsetimage.c
> I am not sure how big the mounted memory fs is since I have problems
> with kernel refusing to execute /sbin/init
> It stops right before that.
> So I made a simple printf C code and replaced init with it
> # sbin/init
> Tell YazzY you started!
>
> exec /sbin/init: error 8
^^^^^^^
This is (from execve(2)):
[ENOEXEC] The new process file has the appropriate access per-
mission, but has an invalid magic number in its
header.
Maybe you forgot some COMPAT_<foo> in your kernel config?
Regards,
-- Jachym Holecek