Modify

Opened 9 years ago

Closed 7 years ago

#2752 closed enhancement (obsolete)

Improved version of mount_root

Reported by: macura@… Owned by: developers
Priority: normal Milestone:
Component: base system Version: Kamikaze trunk
Keywords: Cc: macura@…

Description (last modified by spudz76)

This mount_root enhances functionality to mount any device as overlay filesystem.
It was tested on asus wl-500gp with external USB hard drive.

During boot, normal jffs partition is mounted, then if there exists file /jffs/.moved, it's content is run and parsed. It can contain any shell script code to bring up overlay device and can set this variables:

OVERLAY_DEVICE=/dev/sda1 # (device to mount)

OVERLAY_DEVICE_MODULES="module1 module2 ..." # (modules needed to load before mounting)
  • Be aware ! If you make mistake in this file, you will have to boot using safe mode or clear your jffs partition!
  • Best and SAFE way how to enable external drive which is usb flash or hard disc, is only to touch this file. Defaults should be enaught for this.
  • You will need modules instaled in /jffs partition or in /rom to make it working.

HowTo:

  • Flash your device with clean openwrt image
  • Install modules needed to mount your extrnal drive
  • mount your drive
  • touch /jffs/.moved
  • If OK, you have your root filesystem extended to size of your external device
  • Do not forget, you have default openwrt config now!
  • Optionaly copy your old configs and data from /jffs to /

mount_root:

#!/bin/sh
# Copyright (C) 2006 OpenWrt.org
. /etc/functions.sh

jffs2_ready () {
        mtdpart="$(find_mtd_part rootfs_data)"
        magic=$(hexdump $mtdpart -n 4 -e '4/1 "%02x"')
        [ "$magic" != "deadc0de" ]
}

grep rootfs_data /proc/mtd >/dev/null 2>/dev/null && {
        . /bin/firstboot
        mtd unlock rootfs_data
        jffs2_ready && {
                mount "$(find_mtd_part rootfs_data)" /jffs -t jffs2
                if [ -f /jffs/.moved ]; then
                       echo "loading user script /jffs/.moved"
                       . /jffs/.moved
                        if [ -z "$OVERLAY_DEVICE" ]; then
                                OVERLAY_DEVICE=/dev/sda1
                        fi
                        if [ -z "$OVERLAY_DEVICE_MODULES" ]; then
                                OVERLAY_DEVICE_MODULES="usbcore jbd ext2 ext3 ohci-hcd uhci-hcd ehci-hcd scsi_mod sd_mod usb-storage"
                        fi
                        echo "loading USB and ext3 modules"
                        MODPATH1=/lib/modules/`uname -r`/
                        MODPATH2=/jffs/lib/modules/`uname -r`/
                        for m in $OVERLAY_DEVICE_MODULES; do
                                if [ -f ${MODPATH1}/${m}.*o ]; then
                                        (insmod ${MODPATH1}/${m}.*o; true)
                                else
                                        (insmod ${MODPATH2}/${m}.*o; true)
                                fi
                        done
                        sleep 4
                        mknod /dev/sda b 8 0
                        mknod /dev/sda1 b 8 1
                        mknod /dev/sda2 b 8 2
                        mknod /dev/sdb b 8 16
                        mknod /dev/sdb1 b 8 17
                        mknod /dev/sdb2 b 8 18
                        echo "switching to external drive"
                        mount $OVERLAY_DEVICE /mnt && fopivot /mnt /rom
                else
                        echo "switching to jffs2"
                        fopivot /jffs /rom
                fi
        } || {
                echo "jffs2 not ready yet; using ramdisk"
                ramoverlay
        }
} || {
        mtd unlock rootfs
        mount -o remount,rw /dev/root /
}

Attachments (1)

mount_root.patch (3.1 KB) - added by lschweiss 9 years ago.
patch file for mount_root also works with 2.6 kernel

Download all attachments as: .zip

Change History (8)

comment:1 Changed 9 years ago by anonymous

Based on [http://forum.openwrt.org/viewtopic.php?id=10816
Changing mini_fo's storage directory (/jffs on external media) ]

If this script (or similar) will be included in base openwrt distribution, there is no need to compile image for this functionality, and anybody can use it without bigger problems. Should not conflicts or do some problems until .moved file is on jffs.

comment:2 Changed 9 years ago by lschweiss

I too have been toying with the same idea. However, my thoughts were to make mount_root look for a file on external device to determine if it should be mounted as an overlay. This way if any errors happen in loading, you still don't need safe mode to fix it.

Another direction to avoid the possibility of requiring a boot into safe mode would be to drop out of mounting the external overlay should any step fail and mounting jffs2 overlay as normal. This way mounting external storage can be debugged much easier.

comment:3 Changed 9 years ago by macura@…

Yes, you are true. It is realy hard to debug.. And looking into external device is nice idea. But it brakes possibility to have same "lite" firmware without usb modules etc. Because you must load all modules before making decsision, which device to use as overlay. This script utilises /jffs as "external storage drivers" and all other config is in real overlay device. With this script, it is realy easy to make scripts "root_on_jffs.sh" and "root_on_usb.sh" which couuld do all jobs needed to change overlay device and potentialy copy data from /jffs to /mnt. Any user can download any openwrt image and use this simple scripts to extend his root. Nobody has to make new firmware with embeded drivers.

My script does support error recovery. If there is problem mounting device, it should use /jffs instead. There is only two ways, how to break entire device to need safe mode:

  • syntax problem in .moved , which could break entire mount_root (not so hard to fix using as external command, not include
  • broken libraries or directories in overlay fs (may be solved by simply removing overlay device)

Am I right ?

Changed 9 years ago by lschweiss

patch file for mount_root also works with 2.6 kernel

comment:4 Changed 9 years ago by lschweiss

The attached patch is a modified version of mount_root that works on 2.6 kernels also. Under 2.6 (I've been testing on brcm-2.6) insmod will not work when specifying a full path name.

I've also added some debugging output and support for specifying file system type. I also added a .moved.extra script option so work to be done after modules are loaded can be altered.

This may only be on 2.6 kernels, but an extra sleep was necessary after the mknod sequence or else the mount would fail.

Just testing this on one other target system, certainly shows this needs some extra testing before being merged into trunk. I only have broadcom base units with USB ports maybe some others can test other types of hardware.

comment:5 Changed 9 years ago by lschweiss

Just a brainstorm about the debugging problem of .moved script possibly breaking the whole thing.

Instead of bringing it in with ". /jffs/moved" how about something like:

[ -f /jffs/.moved ] && { /jffs/.moved } && {
 ...
}

Inside .moved the OVERLAY_DEVICE variables would have to be exported, but, if the script failed the jffs partition would simple be mounted.

The same should go for the .moved.extra script I added.

The only other thing that comes to mind about this is that even if empty .moved would need to be executable.

I'll play around with this idea tomorrow.

comment:6 Changed 7 years ago by metalxxx@…

Hello.
Is this working on 8.09.1 ??
I try but no effect... but maybe I do something wrong...
Feel free with sugestions: metalxxx@…

comment:7 Changed 7 years ago by spudz76

  • Description modified (diff)
  • Resolution set to obsolete
  • Status changed from new to closed
  • Version set to Kamikaze trunk

[patchteam] This has recently been obsoleted by similar and more complete work done by Daniel Dickinson, which it appears will be added to trunk "soon".

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.