[SOLVED] Making read only partitions writable

dominikabra · 09-07-2012, 08:46 AM

Hello,

First of all, I don't really know if this goes here as we are talking Debian but it's a distro customized by IOMEGA, so please feel free to move it where it would belong.

I've been fiddling with my IOMEGA IX2-200 Cloud Edition which comes with a customised Debian OS. I've managed to install Transmission and Squeezebox on it, among other things. It comes with two 2TB Samsung discs, with a 20GB partition on top and the rest used for data. It's now configured in JBOD with SSH access enabled.

Problem is this little NAS contains the boot sections in a read-only partition (it just ignores /etc/init.d or /etc/rcS.d scripts on startup) and problem comes when you want to make daemons autostart on reboot. Thing is you want to modify /mnt/apps/usr/local/cfg/sohoProcs.xml so it will launch whatever you want at startup.

Following this post works once:

http://www.chrispont.co.uk/post/1742...x2-200-nas-and

but the next time you try to modify this file (say you didn't nail it the first time) and perform the mounting procedure you will make your NAS unbootable the next time. I'm not very Linux pro, I can barely call myself a newbie, but I'm afraid there is something wrong in the mount/unmount procedure.

Code:

mknod -m0660 /dev/loop3 b 7 3
chown root.disk /dev/loop3
mkdir /tmp/apps
mount -o loop /boot/images/apps /tmp/apps

Perform changes on the sohoProcs.xml file and then unmount

Code:

umount /tmp/apps
rm /dev/loop3

Is there something obviously wrong with this procedure? Any help would be greatly appreciated.

Once the NAS is FUBAR'ed you can recover it buy using the IMAGE Recovery firmware from Iomega, or as I did, restoring the Disk Image clones of the partitions.

Thanks in advance,

jefro · 09-07-2012, 11:10 AM

The most obvious issue is you forgot to mention the backup.

These nas products may be on an embedded flash and or on some common storage. Unless you have some well written doc's where some procedure has been tested thousands of times it becomes a risk. I'd say don't do it. Consider a more conventional computer. A good choice of a used computer shouldn't cost more than $100. It'd better than bricking a $300 nas.
I think I am pretty good and linux and pretty careful after decades of mistakes but once in a while I just don't so stuff.

The best examples are the posts at dd-wrt. Many a dead product.

A better box to play with might have been the qnap line.

I don't see anything exactly wrong with those commands but it would be nice to see others reporting on its effectiveness.

dominikabra · 09-07-2012, 12:12 PM

Thanks for your response.

I did backup the OS partitions, now without upgrading the firmware (thus leaving the NAND alone) there is no chance of bricking it. The images made with Disk Image saved me a loooot of time. The NAS is new, nothing stored in it yet, so I can toy with it without fear of losing anything.

I reckon the best option would be to get a computer just for that, but if I have a nifty looking NAS that can do anything I need it to do, why would I not want to get the most out of it? I'm eager to learn and not afraid of some trial and error.

In case it helps this is how my proc/partitions looks like BEFORE the mounting procedure

Code:

root@ix2-200-TI8QDY:/# cat proc/partitions
major minor  #blocks  name

   7        0     604505 loop0
   7        1       8192 loop1
   7        2        204 loop2
   8        0 1953514584 sda
   8        1   20980888 sda1
   8        2 1932533625 sda2
   8       16 1953514584 sdb
   8       17   20980888 sdb1
   8       18 1932533625 sdb2
  31        0        768 mtdblock0
  31        1        128 mtdblock1
  31        2       3072 mtdblock2
  31        3       3072 mtdblock3
   9        0   20980800 md0
 253        0    4194304 dm-0
 253        1   16785408 dm-1
   9        1 3865067136 md1
 253        2 3865063424 dm-2

When I mount and mess with it, it looks like

Code:

root@ix2-200-TI8QDY:/# cat proc/partitions
major minor  #blocks  name

   7        0     604505 loop0
   7        1       8192 loop1
   7        2        204 loop2
   7        0     604505 loop3
   8        0 1953514584 sda
   8        1   20980888 sda1
   8        2 1932533625 sda2
   8       16 1953514584 sdb
   8       17   20980888 sdb1
   8       18 1932533625 sdb2
  31        0        768 mtdblock0
  31        1        128 mtdblock1
  31        2       3072 mtdblock2
  31        3       3072 mtdblock3
   9        0   20980800 md0
 253        0    4194304 dm-0
 253        1   16785408 dm-1
   9        1 3865067136 md1
 253        2 3865063424 dm-2

If you need something else that could be useful, please let me know.

Thanks again.

jefro · 09-07-2012, 02:43 PM

Do you know what that loop is?

dominikabra · 09-08-2012, 08:55 AM

Thanks for your response and patience. I'm sorry but I'm afraid I don't know what you mean. Aren't loops mount points for files (.ISO, for instance) to make them accessible? From the script

Code:

mknod -m0660 /dev/loop3 b 7 3
chown root.disk /dev/loop3
mkdir /tmp/apps
mount -o loop /boot/images/apps /tmp/apps

and the result I see (in my previous post) I assumed the "mount -o loop" command mounts in the first loop availabe point, therefore the "loop3" being created.

In the NAS, this makes the /boot/images/apps available for writing and once unmounted, modifications are persistent after a reboot, so I assumed the loop is just a temporary tool for creating a mount point that allows me to modify the boot script. Does it matter if it is "loop1" or "loop3"?

Thanks again in advance

dominikabra · 09-09-2012, 09:55 AM

Okay, seems I found out why things got messed up. It's just a matter of updating the proc/partitions file using "partprobe /dev/loop*" before and after unmounting and adding a bit of sleep between commands, that did the trick and my NAS is now a powerhouse capable of the unimaginable!

Adding an entry to the once read-only startup XML that points to an SH file now will allow me to start anything at boot.

Thanks for the help and I hope this helps somebody.