factory firmware move root to UBIFS
Radoslav Kolev
I just received my new bifferboard 8MB with biffboot 3.0. I have
updated the kernel image with the latest image from the factory
firmware page on the wiki.
I boots successfully and I get the openwrt initramfs as root. I can
mount the empty UBIFS partition.
Since don't have much previous experience with openWrt can someone
provide ready steps on how to use a read/write rootfs on the empty
ubifs on /dev/mtd1.
I want to have a simple standalone system booting and working
completely from the flash but also to be able to add some packages via
opkg.
Regards,
Rado
biff...@yahoo.co.uk
Radoslav Kolev
Radoslav Kolev
> 2010/3/22 biff...@yahoo.co.uk <biff...@yahoo.co.uk>:
>>
>> This may help:
>> http://sites.google.com/site/bifferboard/Home/bifferboard-mini-distribution
OK, I have a working system with root on UBIFS now. Just a couple of
things I noticeed:
If you have an initrd compiled into the kernel it always boots into it
no matter what root= option is supplied. I tried passing the noinitrd
option with no difference. Even reverting the
0001-Block-device-precedence.patch didn't help, so maybe it's not
really needed?
At least the behaviour I am seeing in my tests is that if there's an
initramfs compiled in the kernel it is always loaded - no matter what.
Is this the normal way of things, or am I doing something wrong?
When I compiled a kernel without initrd support it finally started to
try mounting the UBIFS as root, but boot failed with "Kernel panic -
not syncing: Attempted to kill init!" error message. I fixed that by
adding "exec /sbin/init" at the end of /etc/preinit.
Regards,
Rado
biff...@yahoo.co.uk
On Mar 22, 4:30 pm, Radoslav Kolev <rado...@gmail.com> wrote:
> If you have an initrd compiled into the kernel it always boots into it
> no matter what root= option is supplied. I tried passing the noinitrd
> option with no difference. Even reverting the
Interesting. I will fix this. Thanks for the bug report.
> 0001-Block-device-precedence.patch didn't help, so maybe it's not
> really needed?
This patch is needed to have the block layer enabled but still boot
from initrd.
> At least the behaviour I am seeing in my tests is that if there's an
> initramfs compiled in the kernel it is always loaded - no matter what.
> Is this the normal way of things, or am I doing something wrong?
Something is broken. I will investigate. I've definitely created
kernels that can ignore the initramfs in the past, perhaps I
configured this one wrong.
> When I compiled a kernel without initrd support it finally started to
> try mounting the UBIFS as root, but boot failed with "Kernel panic -
> not syncing: Attempted to kill init!" error message. I fixed that by
> adding "exec /sbin/init" at the end of /etc/preinit.
I guess we should only do this for ubifs root so we need to have some
kind of check. I'll investigate this as well.
As you probably worked out, I've only tested this on initrd, and am
just guessing all the rest of the stuff, but I appreciate the
feedback. Expect another kernel and also a bunch of extra packages
tonight.
regards,
Biff
biff...@yahoo.co.uk
and I can't get get pivot_root working either, fails with 'invalid
argument'. I guess the answer is to do a remount, or I think a chroot
during init is possible these days (carefully deleting the files from
ramdisk first). The alternative is to just have another kernel for
ubifs-root, which I think I'll do as a short-term work-around.
Init Scripts to achieve the above most welcome, of course!
Biff.
biff...@yahoo.co.uk
Correction: You don't need pivot_root at all unless you still want to
access your ramdisk after you've mounted ubifs.
By adding something like this:
exec ./usr/sbin/chroot . ./etc/preinit <dev/console >dev/console 2>&1
To the end of /etc/preinit on the initrd, you can 'boot' the ubifs
partition and make it root.
You need to un(re?)mount /dev /proc. /sys as well but it seems to
work.
The question now, is how to make it so the preinit script switches
between initrd or ubifs depending on the kernel command-line setting
(or something else). How do we make /etc/preinit 'know' whether it
was run from the kernel directly, or from another copy of preinit? We
only want to mount ubifs when it's running from the ramdisk.
Biff.
On Mar 23, 9:51 am, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk>
wrote:
Radoslav Kolev
>> 0001-Block-device-precedence.patch didn't help, so maybe it's not
>> really needed?
>
> This patch is needed to have the block layer enabled but still boot
> from initrd.
Can you please give just a bit more details. I just want to have an
understanding of the reason for this.
>> When I compiled a kernel without initrd support it finally started to
>> try mounting the UBIFS as root, but boot failed with "Kernel panic -
>> not syncing: Attempted to kill init!" error message. I fixed that by
>> adding "exec /sbin/init" at the end of /etc/preinit.
>
> I guess we should only do this for ubifs root so we need to have some
> kind of check. I'll investigate this as well.
Another question for educational purposes - why is the "exec
/sbin/init" line not needed when running from initrd?
biff...@yahoo.co.uk
> 2010/3/22 biffe...@yahoo.co.uk <biffe...@yahoo.co.uk>:
>
> >> 0001-Block-device-precedence.patch didn't help, so maybe it's not
> >> really needed?
>
> > This patch is needed to have the block layer enabled but still boot
> > from initrd.
>
> Can you please give just a bit more details. I just want to have an
> understanding of the reason for this.
I documented it here, along with all the other patches:
http://sites.google.com/site/bifferboard/Home/s3282-kernel-issues
Not sure how else I can explain it.
>
> >> When I compiled a kernel without initrd support it finally started to
> >> try mounting the UBIFS as root, but boot failed with "Kernel panic -
> >> not syncing: Attempted to kill init!" error message. I fixed that by
> >> adding "exec /sbin/init" at the end of /etc/preinit.
>
> > I guess we should only do this for ubifs root so we need to have some
> > kind of check. I'll investigate this as well.
>
> Another question for educational purposes - why is the "exec
> /sbin/init" line not needed when running from initrd?
I have absolutely no idea.
Biff.