Clone USB rootfs to internal flash - Is this right?

[digininja]

Finally got the Sheeva booting and got a base Debian installed and I'm coming to the end of these notes
http://www.openplug.org/plugwiki/index.php/Installing_Debian_To_Flash#Convert_internal_flash_root_partition_to_UBIFS
and I've got to this bit "Clone USB rootfs to internal flash"

Reading through this it reformats the internal 512M disk and then mounts it on /mnt, it then binds / to /tmp/rootfs to remove unwanted device files etc and copies all the files from /tmp/rootfs to /mnt.

Is this really the right thing to do, to copy all the files from the root on the SD card onto the internal disk including all the files in /var/cache/apt and any other bits that have been left around from the setup that aren't needed any more.

And what does this mean for the SD card that I installed on to, this now seems irrelevant as it isn't being mounted any more and isn't being used. Isn't the point of installing to SD card that you are running from a nice 4G card rather than the internal 512M.

I can kind of understand what is going on but it seems either to be missing an explanation as to why the way it is being done is better than leaving it on the SD card or some explanation as to what the role of the SD card is after all this or even why use the SD card at all, why not just install to the internal disk from the start?

[digininja]

I've just checked and the copy won't work as there isn't enough space

Code:

root@xx:/tmp/rootfs# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mmcblk0p2        1.8G  472M  1.3G  28% /
tmpfs                 251M     0  251M   0% /lib/init/rw
udev                   10M  120K  9.9M   2% /dev
tmpfs                 251M     0  251M   0% /dev/shm
/dev/mmcblk0p1         89M   19M   66M  23% /boot
ubi0:rootfs           462M   16K  457M   1% /mnt

That is with /var/cache/apt/archives/ emptied out.

[pingtoo]

I've just checked and the copy won't work as there isn't enough space

Code:

root@xx:/tmp/rootfs# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mmcblk0p2        1.8G  472M  1.3G  28% /
tmpfs                 251M     0  251M   0% /lib/init/rw
udev                   10M  120K  9.9M   2% /dev
tmpfs                 251M     0  251M   0% /dev/shm
/dev/mmcblk0p1         89M   19M   66M  23% /boot
ubi0:rootfs           462M   16K  457M   1% /mnt

That is with /var/cache/apt/archives/ emptied out.

Just for your information, UBIFS do compression by default so unless you turn off compression during mkfs.ubifs your data should be OK to load into your ubi0:rootfs.

[digininja]

Ye, there may be a bit of space left but as soon as I download a couple of packages the already compressed tarballs will fill the disk.

I don't see the point of moving from a 4G SD card to a 512M internal memory unless you are then supposed to map the SD card back in through mount points and if so then why copy the whole of its contents off onto internal rather than just the bits that are better ran from the internal disk.

[pingtoo]

It all depend on what do you want your plug do. The plug is a close and static environment; none of its internal can be upgrade like your regular PC. So your usage are limited. Without any external peripheral and only network hookup it can act as some semi-static database server like DNS/LDAP/DHCP/NTP server or a firewall.

Now if you hookup with external storage SD or USB (and esata for guruplug) than you can have some high level function performed using you plug like storage server or data collect point or media server. Still because it lack of floating point process power it cannot be transcode process or be a display server.

So imagine you want to have single purpose data collection point like environment monitor for example, you can have your monitor program plug OS fit in to NAND (internal disk in your term) and couple with a 16GB SD, setup your monitor system output its collection to SD card and once a while replace your SD with new one and take the old SD back for download to main processing computer to further process. The static part in NAND should not need to be changed as frequent as once you got in working order you really don't want to mess it again. And in my example you changing SD do not require any interrupt to your running system.

[digininja]

So basically what you are saying is build the device, fix it to a purpose and then don't really touch it. That is kind of what I was thinking of, mine is just going to be a cheap NAS with a couple of USB disks hung off it.

My only worry is that at the moment it is looking like I'll mostly fill the NAND just installing the basic packages such as Samba and NFS. If I do then when patches come out and things need upgrading then it might quickly come to a point of needing to reflash just to get the new stuff on.

I think I might go for a half way solution, install most of it to NAND but keep /var on the SD, that way I've got space to play with on the NAND and spare space on the SD in case I want to drop anything else on it. Does that sound like a reasonable option?

[pingtoo]

Absolutely, I think there are more than a few poster in this forums use similar approach.

I use Gentoo myself, it is a source based distro. so it have a bit different requirement, i.e. need a lots of space to hold source code, so I setup mine use aufs/unionfs and iscsi plus distcc for remote compile. it is a bit of complex to setup but at the end it work very will. let me know if you need more information on this setup.

As of patches/security updates this area I consider less important as if at end of setup the machine is function as planed why touch it? so unless I am looking for new feature I would not consider changes. so after long period I would build a system and just flush on top of old one as way to upgrade.

[digininja]

I was a Gentoo lover for years till they got to a period of not properly testing their releases of big things like libc which meant whole systems went down for days till someone came up with a patch, at that point I moved to a mix of Arch and Debian. I'd probably not try Gentoo on the Sheeva just because I imagine that compile time must be a killer but I would be interested to hear the way you set it up, it is always good to have more ideas even if they aren't used in the way they were originally explained.

As for patches, my job is security auditor/penetration tester so I'm one of the good guys who is always looking for security holes to squeeze through for clients so the thought of leaving an unpatched box on my own network isn't one I can consider! I've got into too many companies through small unpatched boxes in the corner that people had forgotten about to be able to ignore it.