8,288
edits
Changes
Jump to navigation
Jump to search
Line 78:
Line 78: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
no edit summary
The remix building of a LiveOS image is also a good way to maintain and distribute system updates. Many software security, enhancement, and bug fixes are distributed through PackageKit (Software Update) or Yum update, which are turned off by default on LiveOS installations like SoaS. After manually running an update, the image can be remixed to incorporate the changes into a new Updated-SoaS.iso file. This process could be migrated to the Sugar BuildBot service to provide the Community with an up-to-date Sugar on a Stick image.
The remix building of a LiveOS image is also a good way to maintain and distribute system updates. Many software security, enhancement, and bug fixes are distributed through PackageKit (Software Update) or Yum update, which are turned off by default on LiveOS installations like SoaS. After manually running an update, the image can be remixed to incorporate the changes into a new Updated-SoaS.iso file. This process could be migrated to the Sugar BuildBot service to provide the Community with an up-to-date Sugar on a Stick image.
===Overlay recovery===
{{Note/warning|Test and practice the following|This procedure is not thoroughly validated, and may destroy your data.}}
If one 'exhausts' the limited storage capacity of a LiveOS overlay, Device-mapper will mark the filesystem as 'Invalid', as shown by the {{Code|dmsetup status}} command executed in Terminal or a console (if you haven't crashed):
# dmsetup status
live-osimg-min: 0 8388608 snapshot 2464/2464 24
live-rw: 0 8388608 snapshot Invalid
The invalid bit is 00 at byte 5 of the overlay. You might try to recover the overlay by switching it to 01 with the following command line:
# echo $'\x01' | dd of=/path/to/overlay-file bs=1 count=1 seek=4 conv=notrunc
where /path/to/overlay may be /mnt/live/LiveOS/overlay-devicename-discUUID or<br>/media/devicename/LiveOS/overlay-devicename-discUUID for an attached device.
Follow this by mounting the LiveOS image:
# mount /media/devicename/LiveOS/squashfs.img /mnt/some_mountpoint
# losetup /dev/loop1 /mnt/some_mountpoint/LiveOS/ext3fs.img -r
# losetup /dev/loop2 /media/devicename/LiveOS/overlay-devicename-discUUID
# dmsetup create devicename --table "0 8388608 snapshot 7:1 7:2 P 8"
* devicename in the last line may be any string.
* loop1 and loop2 (and the corresponding 7:1 7:2) may be any free loop devices; just substitute the appropriate numbers.
* 8388608 is the size of the ext3fs.img file in 512 byte units. This can be read by the following command:
# blockdev -q --getsz /dev/loop1
Execute
# dmsetup status
to check the the virtual filesystem has been configured.
Then try to repair any damage with the following command:
# e2fsck -f -y /dev/mapper/devicename
where devicename is the string you used in the dmsetup create command.
Run a second check,
# e2fsck -p /dev/mapper/devicename
to verify if the filesystem could be repaired.
At this point you will want to enlarge the overlay, or backup or rebuild the image.
Remove the virtual filesystem registration,
# dmsetup remove devicename
Determine the size of the overlay file:
# blockdev -q --getsz /dev/loop2
# losetup -d /dev/loop2
# losetup -d /dev/loop1
# dd if=/dev/zero of=/path/to/overlay-file seek=overlay_size count=size_increase
where overlay_size and size_increase are now 512 byte units.
==References==
==References==
<references />
<references />
:: See this [http://thread.gmane.org/gmane.linux.kernel.device-mapper.devel/14644 dm-devel thread].
:: See this [http://thread.gmane.org/gmane.linux.kernel.device-mapper.devel/14644 dm-devel thread].