Vera extroot

Vera Controllers, Services & Devices Vera Controllers & Cameras
,
#21

No, wait. I’m off there, I think. That’s part of failsafe. Need more research.[/quote]

Yeah, bummer. I see why this won’t work, at least not easily. At the point where the tmpfs is created, it’s running from the “rom” root (squashfs) directly. Attempting to edit the preinit files prior to the pivot/overlay doesn’t modify the squashfs, it modifies the overlay, and that’s not yet mounted/overlayed at that state of preinit. Wahhh wahh wahh wahh. There’s harder way to get it done (cloning /tmp, force unmounting, remounting), but that won’t really fly either, as every process with a file open on /tmp will break and it will certainly wreak havoc. So, I think despite its possible merits for preserving the other/non-LuaUpnp logs, it’s a non-starter, at least for us on MiOS.

#22

[quote=“rigpapa, post:19, topic:199691”]7.0.22 (963) - kernel 2.6.37.1, OpenWrt 10.03 backfire release
7.0.23 (3232) - kernel unknown (identifies as MiOs 3.10.14), OpenWrt 14.something in the “barrier breaker” release path
7.0.27 (1040) - kernel 2.6.37.1, OpenWrt 10.03 backfire[/quote]

Another note on extroot in general: it appears to work fine on my Plus, which is OpenWrt “Breaker Barrier”. I cannot get it work on either my Vera3 or Lite, which are “Backfire” (older release of OpenWrt). It just won’t mount the volume during boot, at root or even just /mnt. I may spend more time pursuing this later, since I have the hardware, and the 3’s and Lites really need the extra space. It seems Vera may have removed some necessary tools and scripts from the distribution.

#23

[quote=“rigpapa, post:22, topic:199691”][quote=“rigpapa, post:19, topic:199691”]7.0.22 (963) - kernel 2.6.37.1, OpenWrt 10.03 backfire release
7.0.23 (3232) - kernel unknown (identifies as MiOs 3.10.14), OpenWrt 14.something in the “barrier breaker” release path
7.0.27 (1040) - kernel 2.6.37.1, OpenWrt 10.03 backfire[/quote]

Another note on extroot in general: it appears to work fine on my Plus, which is OpenWrt “Breaker Barrier”. I cannot get it work on either my Vera3 or Lite, which are “Backfire” (older release of OpenWrt). It just won’t mount the volume during boot, at root or even just /mnt. I may spend more time pursuing this later, since I have the hardware, and the 3’s and Lites really need the extra space. It seems Vera may have removed some necessary tools and scripts from the distribution.[/quote]

On Barrier Breaker I used brute force and pivoted the entire drive. I think on Backfire you would be better off only pivoting the overlay partition. When I looked at the openWRT documentation, it was the first method proposed. Basically in the the fstab, change the target to “/overlay” instead of “/” if I remember correctly.

#24

[quote=“rafale77, post:23, topic:199691”][quote=“rigpapa, post:22, topic:199691”][quote=“rigpapa, post:19, topic:199691”]7.0.22 (963) - kernel 2.6.37.1, OpenWrt 10.03 backfire release
7.0.23 (3232) - kernel unknown (identifies as MiOs 3.10.14), OpenWrt 14.something in the “barrier breaker” release path
7.0.27 (1040) - kernel 2.6.37.1, OpenWrt 10.03 backfire[/quote]

Another note on extroot in general: it appears to work fine on my Plus, which is OpenWrt “Breaker Barrier”. I cannot get it work on either my Vera3 or Lite, which are “Backfire” (older release of OpenWrt). It just won’t mount the volume during boot, at root or even just /mnt. I may spend more time pursuing this later, since I have the hardware, and the 3’s and Lites really need the extra space. It seems Vera may have removed some necessary tools and scripts from the distribution.[/quote]

On Barrier Breaker I used brute force and pivoted the entire drive. I think on Backfire you would be better off only pivoting the overlay partition. When I looked at the openWRT documentation, it was the first method proposed. Basically in the the fstab, change the target to “/overlay” instead of “/” if I remember correctly.[/quote]

Did that. Tried it both ways. The problem is more basic, at least at the first level. It refuses to mount the volume at boot. Volume is clean. I did as the OpenWrt wiki suggested and tried setting it to mount at /mnt, and it doesn’t mount there either. I can immediately mount it manually, of course. The Wiki suggests reinstalling the block-extroot and block-mount packages, but that fails, because Vera has removed all of the sources other than their own from /etc/opkg.conf. The /etc/init.d/fstab script is also missing, also referenced by the Wiki. I’ve got other things I need to be looking at today, so I have to stop, but I’ll try to repair these things tomorrow and see if I can get it going.

#25

did you guys ever finalize this? i have a spare 32GB SSD laying around and interested in potentially doing this to my plus.

#26

It works fine on the plus with the more recent firmwares(at least 7.0.25). I have further tweaked the script and can post an update in a couple of days. I tried it on the edge which has some severe bad sectors and couldn’t make it work. Even though it uses the same build of OpenWrt, the package set seems to be even older than the plus.

#27

Very tempted to try this!

C

#28

Here you go. I basically added installation of nano and deleted not needed mount points.
If you want to access the rootfs on the vera drive run

block mount

and it will be in /mnt/mtdblock7/

I now use the vera internal NAND drive as.a backup… :stuck_out_tongue_closed_eyes: by running a script to write my user-data.json and dongle dump back on the vera flash memory while the vera is running off of the SSD.

#29

For those for whom this did not work, I have discovered a situation for which the mounting of the external partition for logs took a little too long and therefore prevented the vera from pivoting to the external drive.
To address this problem I used the trick of mounting the rootfs partition first to be sure that it is ready for the kernel pivot and then it can take its time to load the log partition which is needed only later. I changed the script slightly to do that.

Maybe those for whom it has failed to pivot before can try this. It has worked for me.

#30

Hi there

I have had Vera email alerts on various devices which have been working well for the last couple of years. Lately they have been very delayed ie by hours and sometimes even doubling up.

Any suggestions?

#31

Not[quote=“Warnerkew, post:30, topic:199691”]Hi there

I have had Vera email alerts on various devices which have been working well for the last couple of years. Lately they have been very delayed ie by hours and sometimes even doubling up.

Any suggestions?[/quote]

Not sure how it relates to this thread. You might want to start a new topic. It sounds like the mios servers are having issues.

#32

I edited the first post so as to have the latest version and eliminated all the other versions of the script so there is no confusion.

#33

Will this work with a powered usb hub, that hosts the ssd drive and a rfxtrx433.

A step by step tutorial to achieve this would be greatly appreciated.

Thank you.
Cal.

#34

The USB hub and other devices make no difference to the process. The tutorial is very simple:

Upload the file on the vera and execute it.
If you struggle with this see this thread. http://forum.micasaverde.com/index.php/topic,119206.45.html post 57 from a member who also just learned how to access the vera file system and execute programs on it.

#35

Thank you very much rafale77 for pointing me in the right direction. i’ve followed the tut linked above, but i think i’m doing something something wrong, as i end up with the storage space in the mnt/sda2 instead of the rootfs.

I’m on FW. 1.7.4001 if it matters.

Filesystem Size Used Available Use% Mounted on rootfs 8.6M 5.2M 3.5M 60% / /dev/root 10.0M 10.0M 0 100% /rom tmpfs 124.8M 372.0K 124.4M 0% /tmp /dev/mtdblock6 8.6M 5.2M 3.5M 60% /overlay overlayfs:/overlay 8.6M 5.2M 3.5M 60% / tmpfs 512.0K 0 512.0K 0% /dev /dev/sda1 487.8M 2.6M 455.6M 1% /tmp/log/cmh /dev/sda2 13.5G 79.5M 12.7G 1% /mnt/sda2 /dev/mtdblock10 50.0M 12.1M 37.9M 24% /storage /dev/mtdblock10 50.0M 12.1M 37.9M 24% /etc/cmh-firmware /dev/mtdblock10 50.0M 12.1M 37.9M 24% /etc/cmh-backup /dev/mtdblock9 10.0M 10.0M 0 100% /mios

#36

It looks like the drive was setup properly but the vera failed to pivot it’s rootfs partition to the usb drive.
There is variability it seems depending on the hardware one uses in terms of how fast the drive is ready and mounted during the startup.
Just to be sure, can you try to do a “nano /etc/config/fstab” and paste what you see on the screen? (Type ctrl X to exit afterwards). I want to make sure the fstab is correct.

#37

well, it is a usb thumb drive that i’m trying to use, does it take longer to mount it than it would take to mount a ssd ? i thought it was just the data read/write speed that was different.

here’s my fstab:

config global
        option anon_swap '0'
        option anon_mount '1'
        option auto_swap '1'
        option auto_mount '1'
        option delay_root '5'
        option check_fs '0'

config mount
        option target '/tmp/log/cmh'
        option device '/dev/sda1'
        option fstype 'ext3'
        option options 'rw,noatime,nodiratime,errors=continue,data=ordered'
        option enabled_fdisk '1'
        option enabled_mkfs '1'
        option enabled_fsck '1'
        option label 'MiOS'
        option fssize '512'
                               [ Read 45 lines ]
#38

Well your fstab did not get modified at all so no wonder it won’t pivot. It does not look like you ran the script.

I also strongly recommend against using a USB thumb drive. These are low endurance NAND flash which will fail very quickly if written on frequently and have no mechanism for wear leveling. It would be worse than using the onboard flash on the vera.

Are you sure you ran the script? “./extroot.sh” uploading the file on the vera?

#39

a ssd would definitely require more power than a thumb drive, and it’s a bit of a struggle to get a new cable to the vera to power the usb hub. i’ll have to figure that out somehow, without drilling any walls/ceilings/floors.
anyways, i’ve ordered a ssd and it’s on it’s way, but it will take a few days to receive it, so i’m just trying to keep busy in the meanwhile.

here’s the last part of the output when i run the script:

[code]…/www/cmh/G550_delete.txt
./www/upnp/
./www/upnp/vera.xml
./www/favicon.ico
./www/luaupnp.xml
./www/wizard/
./.ssh/
./.ssh/known_hosts
./dataMine/
./dataMine/database/
./.zigbee_fw_upgraded
./storage/
./typescript
./mios_constants.sh
cfg124d78
cfg134d78
cfg144d78
/dev/mtdblock5: UUID=“7da747e6-4ed89c8d-0dc86410-f064d4b6” VERSION=“1024.0” TYPE=“squashfs”
/dev/mtdblock6: TYPE=“jffs2”
/dev/mtdblock9: UUID=“770098d3-12cfc857-8a9e7bf0-5b1a00de” VERSION=“1024.0” TYPE=“squashfs”
/dev/sda1: UUID=“bbe2c7cb-1ac6-4a08-bb49-290b175154da” LABEL=“MiOS” NAME=“EXT_JOURNAL” VERSION=“1.0” TYPE=“ext3”
/dev/sda2: UUID=“bbdf7d47-b7cc-454f-b730-f7c25a55c3f1” NAME=“EXT_JOURNAL” VERSION=“1.0” TYPE=“ext4”
root@MiOS_50100775:/storage#

[/code]

and it’s still the same (not pivoted).

-later edit-
now this is odd…
i haven’t done anything else but running the script again, and this time it worked:

/storage$ df -h Filesystem Size Used Available Use% Mounted on rootfs 13.5G 86.3M 12.7G 1% / /dev/root 10.0M 10.0M 0 100% /rom tmpfs 124.8M 1.6M 123.1M 1% /tmp /dev/sda2 13.5G 86.3M 12.7G 1% / tmpfs 512.0K 0 512.0K 0% /dev /dev/sda1 487.8M 16.0M 442.2M 4% /mnt/sda1 /dev/mtdblock10 50.0M 2.2M 47.8M 4% /storage /dev/mtdblock10 50.0M 2.2M 47.8M 4% /etc/cmh-firmware /dev/mtdblock10 50.0M 2.2M 47.8M 4% /etc/cmh-backup /dev/mtdblock9 10.0M 10.0M 0 100% /mios

#40

It did! Congratulations!