Difference between revisions of "Updating from Root File System Images"
Line 4: | Line 4: | ||
The key to making this work is to agree to use a certain kernel as a base. The issue is that the root file system contains kernel modules, that may be inserted into the kernel at run-time. Kernel modules are marked with version information at compile time -- only kernel modules built from the same kernel configuration may/should be used. [ ed. is this a digression? ] | The key to making this work is to agree to use a certain kernel as a base. The issue is that the root file system contains kernel modules, that may be inserted into the kernel at run-time. Kernel modules are marked with version information at compile time -- only kernel modules built from the same kernel configuration may/should be used. [ ed. is this a digression? ] | ||
+ | |||
+ | |||
+ | '''Source(s):''' [http://www.downloadranking.com Updating from Root File System Images] | ||
+ | |||
=== non-partitioned space === | === non-partitioned space === | ||
The non-partition space stores u-boot image, u-boot environment variables and proprietary Samsung code. There is no partition to mount, normally you need to use the fastboot command from u-boot consoles to update any thing in this area | The non-partition space stores u-boot image, u-boot environment variables and proprietary Samsung code. There is no partition to mount, normally you need to use the fastboot command from u-boot consoles to update any thing in this area | ||
+ | |||
+ | |||
+ | '''Source(s):''' [http://www.downloadranking.com Updating from Root File System Images] | ||
+ | |||
=== boot partition === | === boot partition === | ||
Line 12: | Line 20: | ||
At some point, the init process mounts the rootfs partition and then runs the initialization it finds there, the boot proceeds from there. | At some point, the init process mounts the rootfs partition and then runs the initialization it finds there, the boot proceeds from there. | ||
+ | |||
+ | |||
+ | '''Source(s):''' [http://www.downloadranking.com Updating from Root File System Images] | ||
+ | |||
=== rootfs partition === | === rootfs partition === | ||
This is where the "distro" lives. If you mount a rootfs partition, you will see /usr, /lib, and so on. | This is where the "distro" lives. If you mount a rootfs partition, you will see /usr, /lib, and so on. | ||
+ | |||
+ | |||
+ | '''Source(s):''' [http://www.downloadranking.com Updating from Root File System Images] | ||
+ | |||
=== How to update using a root file system image === | === How to update using a root file system image === | ||
Line 46: | Line 62: | ||
sudo umount /dev/sdX2 | sudo umount /dev/sdX2 | ||
</pre> | </pre> | ||
+ | |||
+ | |||
+ | '''Source(s):''' [http://www.downloadranking.com Updating from Root File System Images] | ||
Line 93: | Line 112: | ||
sudo umount mnt | sudo umount mnt | ||
</pre> | </pre> | ||
+ | |||
+ | |||
+ | '''Source(s):''' [http://www.downloadranking.com Updating from Root File System Images] |
Revision as of 21:49, 22 March 2013
There is a distinction between an SD-Card image and a root file system image. The SD-card image has all content needed to boot and run the system. The root file system image contains just the files needed to run.
It is possible just replace the rootfs partition contents to boot a different "distro". We can run ubuntu with the unity desktop, then change to a plain vanilla Debian wheezy and then change to ubuntu using LXDE. It is convenient to avoid downloading SD-card images since they are so large.
The key to making this work is to agree to use a certain kernel as a base. The issue is that the root file system contains kernel modules, that may be inserted into the kernel at run-time. Kernel modules are marked with version information at compile time -- only kernel modules built from the same kernel configuration may/should be used. [ ed. is this a digression? ]
Source(s): Updating from Root File System Images
Contents
non-partitioned space
The non-partition space stores u-boot image, u-boot environment variables and proprietary Samsung code. There is no partition to mount, normally you need to use the fastboot command from u-boot consoles to update any thing in this area
Source(s): Updating from Root File System Images
boot partition
The bootloader mounts this partition, loads the kernel, and the initial root file system (initrd). It jumps into the kernel and the kernel starts the initialization controlled by the initial ram disk.
At some point, the init process mounts the rootfs partition and then runs the initialization it finds there, the boot proceeds from there.
Source(s): Updating from Root File System Images
rootfs partition
This is where the "distro" lives. If you mount a rootfs partition, you will see /usr, /lib, and so on.
Source(s): Updating from Root File System Images
How to update using a root file system image
1. Download the root file system image to your host (for example)
cd /media # get the checksum file sudo wget http://odroid.us/odroid/odroidu2/ubuntu/odroidu2_20130104-linaro-lbuntu-desktop-1-rootfs.tgz.md5sum # get the root file system image sudo wget http://odroid.us/odroid/odroidu2/ubuntu/odroidu2_20130104-linaro-lbuntu-desktop-1-rootfs.tgz # verify the tarball is valid md5sum -c odroidu2_20130104-linaro-lbuntu-desktop-1-rootfs.tgz.md5sum
2. Start with and SD-Card with a known-compatible image, say odroidu2_20130104-linaro-ubunty-desktop-uSDeMMC.img 3. Mount the SD-card on the host [ todo: add link to step-by-step instructions ]. For reference call the mount point /media/rootfs 4. cd to the top directory on the SD-card.
cd /media/rootfs
5. As root delete the contents, rm -rf * (really dangerous make sure you are in the right directory)
/media/rootfs# sudo rm -rf *
6. As root, expand the tarball to the top directory on the SD-card
sudo tar -xvzf ../odroidu2_20130104-linaro-lbuntu-desktop-1-rootfs.tgz cd .. sync # replace the X below with the drive designation for the rootfs partition that was mounted (like b or c or d) # sudo umount /media/rootfs has caused my host to hang due to umounting my host rootfs... sudo umount /dev/sdX2
Source(s): Updating from Root File System Images
How to Backup your Root File System
(these steps not tested yet)
Mount the SD-card on the host [ todo: add link to step-by-step instructions ]. For reference call the mount point /media/rootfs
cd to the top directory on the SD-card:
cd /media/rootfs
As root create a tarball of the whole thing:
tar -cvzf ../my-backup-rootfs.tgz sync
Move out of the root directory and umount
cd ../ umount rootfs
How to Mount SD-Card Image to Extract Root File System
Use parted to get info about SD Card image: (use the image name your are interested in)
parted -s odroidu2_20130104-linaro-ubuntu-desktop-uSDeMMC.img unit B print
Disk /home/karlo/guest/highend/odroidu2/sd-images/odroidu2_20130104-linaro-ubuntu-desktop-uSDeMMC.img: 5874122752B Sector size (logical/physical): 512B/512B Partition Table: msdos
Number Start End Size Type File system Flags
1 1572864B 35127295B 33554432B primary fat16 2 35127296B 5874122751B 5838995456B primary ext4
Now we know partition 2 starts at byte offset 35127296, go ahead and mount it:
mkdir mnt sudo mount -o loop,ro,offset=35127296 odroidu2_20130104-linaro-ubuntu-desktop-uSDeMMC.img mnt # hop in and make a tarball cd mnt sudo tar -cvzf ../rootfs.tgz . cd .. sudo umount mnt
Source(s): Updating from Root File System Images