LiveOS image - Revision history

FGrose: correct Sugar Activity Storage locations

2012-08-22T13:34:40Z

correct Sugar Activity Storage locations

← Older revision		Revision as of 09:34, 22 August 2012
Line 15:		Line 15:

	==Sugar Activity Storage==		==Sugar Activity Storage==
	Activity bundles that come pre-installed with the Sugar on a Stick (SoaS) are saved in the /usr/share/sugar/activities folder of the root filesystem. ~~On first boot~~, the Activity bundles are ~~copied to~~ the /home/liveuser/~~.sugar/activities~~ folder. When an Activity ~~isrun~~, ~~all~~ Activity instance data is saved in the Sugar Journal in /home/liveuser/.sugar/datastore/<hashed folder names>		Activity bundles that come pre-installed with the Sugar on a Stick (SoaS) are saved in the /usr/share/sugar/activities folder of the root filesystem. When Activities are updated from the Sugar Control Panel, the new Activity bundles are saved in the /home/liveuser/Activities folder. When an Activity is run, Activity instance data is saved in the Sugar Journal in /home/liveuser/.sugar/default/<activity bundle_id> folder and /home/liveuser/.sugar/default/datastore/<hashed folder names>

	When additional Activity bundles are downloaded, they are saved in the /home/liveuser/~~.sugar/activities~~ folder (but not the /usr/share/sugar/activities folder).		When additional Activity bundles are downloaded, they are saved in the /home/liveuser/Activities folder (but not the /usr/share/sugar/activities folder).
	Thus, when SoaS is installed with the --home-size-mb NNN option of livecd-iso-to-disk, storage for the Activities one wants to try and, perhaps later, throw away, is made available without consuming the write-once root filesystem overlay, which can be consumed very quickly (and overlay file space is not directly reusable).		Thus, when SoaS is installed with the --home-size-mb NNN option of livecd-iso-to-disk, storage for the Activities one wants to try and, perhaps later, throw away, is made available without consuming the write-once root filesystem overlay, which can be consumed very quickly (and overlay file space is not directly reusable).

FGrose at 02:25, 22 August 2012

2012-08-22T02:25:58Z

← Older revision		Revision as of 22:25, 21 August 2012
Line 1:		Line 1:
	<noinclude>		<noinclude>[[Category:Live USB]]
	[[Category:Live USB]]
	</noinclude>		</noinclude>
			''This page has been moved to the [[fedora:Fedora_Project_Wiki\|Fedora Project Wiki]].''

			Additional information for [[Sugar on a Stick]] is available [[#Sugar Activity Storage\|below the frame]].

			The frame below is an active view of the [[fedora:LiveOS image\|LiveOS image]] page on the Fedora Project Wiki:

	This page has been moved to the Fedora Project wiki. The frame below is an active view of [[fedora:LiveOS image\|LiveOS image]] on the Fedora wiki. Additional information for [[Sugar on a Stick]] is available below the frame/
	{{#widget:Iframe		{{#widget:Iframe
	\|url=https://fedoraproject.org/wiki/LiveOS_image		\|url=https://fedoraproject.org/wiki/LiveOS_image

FGrose: transfer Fedora content to fedora:LiveOS image (offered in frame), restructure with SoaS content below frame

2012-08-22T02:11:07Z

transfer Fedora content to fedora:LiveOS image (offered in frame), restructure with SoaS content below frame

Show changes

FGrose: feedback for copy, dd to device, better cleanup

2012-08-21T02:26:02Z

feedback for copy, dd to device, better cleanup

← Older revision		Revision as of 22:26, 20 August 2012
Line 83:		Line 83:
	mkdir $TMPDIR/LiveOS 2>/dev/null		mkdir $TMPDIR/LiveOS 2>/dev/null

	# Mount, copy~~, unmount~~ the original root filesystem.		# Mount SquashFS, copy out the original root filesystem, unmount SquashFS.
	SRCMNT=$(mktemp -d /media/XXXXXX)		SRCMNT=$(mktemp -d /media/XXXXXX)
	mount $2 $SRCMNT		mount $2 $SRCMNT
	SQUASHMNT=$(mktemp -d /media/XXXXXX)		SQUASHMNT=$(mktemp -d /media/XXXXXX)
	mount $SRCMNT/LiveOS/squashfs.img $SQUASHMNT		mount $SRCMNT/LiveOS/squashfs.img $SQUASHMNT
	cp $SQUASHMNT/LiveOS/ext3fs.img $TMPDIR/LiveOS		if [[ -x /usr/bin/rsync ]]; then
			rsync --inplace --8-bit-output --progress $SQUASHMNT/LiveOS/ext3fs.img \
			$TMPDIR/LiveOS
			else
			cp $SQUASHMNT/LiveOS/ext3fs.img $TMPDIR/LiveOS
			fi
	umount $SQUASHMNT		umount $SQUASHMNT

Line 124:		Line 129:

	# Reset overlay.		# Reset overlay.
	dd if=/dev/zero of=$SRCMNT/LiveOS/overlay-* bs=64k count=1 conv=notrunc,fsync		dd if=/dev/zero of=$OVDEV bs=64k count=1 conv=notrunc,fsync

	# Clean up.		# Clean up.
			sleep 2
			losetup -d $OVDEV $FSDEV
	umount $SRCMNT		umount $SRCMNT
	rmdir $SQUASHMNT $SRCMNT</nowiki>		rmdir $SQUASHMNT $SRCMNT</nowiki>

FGrose: snapshot-merge procedure

2012-08-20T05:26:56Z

snapshot-merge procedure

@@ Line 49: / Line 49: @@
 The Fedora LiveOS uses the [[wikipedia:Device mapper|Device-mapper]] service of the Linux kernel to manage the file stores on the device.  This is the same service that is used by [[wikipedia:Logical Volume Manager (Linux)|Logical Volume Manager]] to provide disc partition services.
-One limitation, mentioned above, is that the LiveOS persistent overlay is a write-once file space.  This is related to its use of ''device mapper'' snapshots to merge a read-only file system image (copied from the compressed SquashFS.img on the read-only LiveCD or installation .iso file) with a [[wikipedia:Copy-on-write|Copy-on-write]] service that tracks only changed blocks of data in the snapshot (overlay) file and then re-referencing file pointers to the updated blocks.<ref>http://people.gnome.org/~markmc/code/merge-dm-snapshot.c</ref><ref>http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=drivers/md/dm-snap-persistent.c;hb=HEAD</ref> Any changes to the operating system files are stored as differences from the base. As such, "deletions" of files are saved as additional difference references, and the originals are hidden.  With this mechanism, physical storage space is consumed in the write-once file space rather than recovered.
+One limitation, mentioned above, is that the LiveOS persistent overlay is a write-once file space.  This is related to its use of ''device mapper'' snapshots to combine a read-only file system image (copied from the compressed SquashFS.img on the read-only LiveCD or installation .iso file) with a [[wikipedia:Copy-on-write|Copy-on-write]] service that tracks only changed blocks of data in the snapshot (overlay) file and then re-referencing file pointers to the updated blocks.<ref>http://people.gnome.org/~markmc/code/merge-dm-snapshot.c</ref><ref>http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=drivers/md/dm-snap-persistent.c;hb=HEAD</ref> Any changes to the operating system files are stored as differences from the base. As such, "deletions" of files are saved as additional difference references, and the originals are hidden.  With this mechanism, physical storage space is consumed in the write-once file space rather than recovered.
 Consumption of the space allocated for persistent storage in the snapshot overlay file may be tracked with the ''device mapper'' {{Code|dmsetup status}} report.  '''Sugar Cellar''' is a small, utility script which uses that service to allow for Learner testing and discovery. It will help Learners manage their storage resources and learn ways to economize limited resources.
@@ Line 70: / Line 70: @@
 ** there may be other good candidates...
-===Provide image recompression and overlay refreshment===
+===Image recompression and overlay refreshment===
 [[Sugar on a Stick/Sugar Clone]] provides a method to build a customized LiveOS image installation file through the [[Sugar_on_a_Stick/Sugar_Clone#SoaS-remix | SoaS-remix]] bundle.  The SoaS-remix.iso installation file can be used to redistribute the customized image.  A new installation from this .iso will have the old image recompressed and a fresh overlay. With the current version, the home.img file must be manually copied to a new installation.  One's aging SoaS image can be refreshed by an over-installation (see the instructions on the referenced page).
@@ Line 119: / Line 178: @@
 where overlay_size and size_increase are now 512 byte units.
 ==References==
 <references />
 :: See this [http://thread.gmane.org/gmane.linux.kernel.device-mapper.devel/14644 dm-devel thread].

FGrose: /* Installation options */ update space allocation for F17

2012-07-14T15:51:50Z

Installation options: update space allocation for F17

← Older revision		Revision as of 11:51, 14 July 2012
Line 35:		Line 35:

	===Installation options===		===Installation options===
	[[Sugar on a Stick]] may be installed on a 1-GB USB device using the following options with '''[[fedora:livecd-iso-to-disk\|livecd-iso-to-disk]]''' (on a single, Terminal Activity or console command line, even though the wiki may wrap the following text in accord with your browser window size):		[[Sugar on a Stick]] may be installed on a 1 GB USB device using the following options with '''[[fedora:livecd-iso-to-disk\|livecd-iso-to-disk]]''' (on a single, Terminal Activity or console command line, even though the wiki may wrap the following text in accord with your browser window size):

	:{{Code\|./livecd-iso-to-disk --reset-mbr --overlay-size-mb ~~300~~ --home-size-mb ~~200~~ --delete-home --unencrypted-home /path/to/source/iso/or/device /dev/sd'''?'''1}}		:{{Code\|./livecd-iso-to-disk --reset-mbr --overlay-size-mb '''200''' --home-size-mb '''150''' --delete-home --unencrypted-home /path/to/source/iso/or/device /dev/sd'''?'''1}}

	:: where '{{Code\|'''?'''}}' in the final parameter represents the target bootable device node, such as {{Code\|~~sdb1~~}} or {{Code\|~~sdc1~~}}, etc.		:: where '{{Code\|'''?'''}}' in the final parameter represents the target bootable device node, such as {{Code\|sd'''b'''1}} or {{Code\|sd'''c'''1}}, etc.
	~~:: (You may use '\' line-continuation symbols followed by a newline [enter or return keypress] to break a long line visually on the terminal, but not logically to the script processing software.)~~

	The above configuration would allow space for the home folder, the operating system, and a little on the device root.		The above configuration would allow space for the home folder, the operating system, and a little on the device root.

FGrose: update link

2012-07-13T19:43:20Z

update link

← Older revision		Revision as of 15:43, 13 July 2012
Line 26:		Line 26:
	The all-purpose, persistent overlay is needed for operating system changes and updates.		The all-purpose, persistent overlay is needed for operating system changes and updates.

	The file systems are prepared on each boot by the [http://git.fedorahosted.org/git/?p=spin-kickstarts.git;a=blob;f=fedora-live-base.ks~~;h=0b14feccfd99bd60d88dc55ebc32d48bc7251242~~;hb=HEAD#l63 /etc/rc.d/init.d/livesys script].		The file systems are prepared on each boot by the [http://git.fedorahosted.org/git/?p=spin-kickstarts.git;a=blob;f=fedora-live-base.ks;hb=HEAD#l63 /etc/rc.d/init.d/livesys script].

	===Home filesystem===		===Home filesystem===

FGrose: /run/initramfs/live for Fedora 17

2012-05-29T22:40:22Z

/run/initramfs/live for Fedora 17

← Older revision		Revision as of 18:40, 29 May 2012
Line 21:		Line 21:

	# An all-purpose, persistent overlay - a write-once, fixed-size file space that will save updates and changes to the LiveOS image (Activities, operating system changes, anything written in the LiveOS file space).		# An all-purpose, persistent overlay - a write-once, fixed-size file space that will save updates and changes to the LiveOS image (Activities, operating system changes, anything written in the LiveOS file space).
	# Persistent home folder - a re-writable, re-sizable (with difficulty), uncompressed, optionally-encryptable, file space for anything that goes in the Learner's /home/ folder (all the Sugar Activities, logs, and good stuff). A persistent home folder is an option that may be selected at the time of installation of the LiveOS image (although with some effort, one could manually create a home.img filesystem in /LiveOS/ and move the /home/ folder to it). This installation option is only available through the script, '[[fedora:livecd-iso-to-disk\|livecd-iso-to-disk]]'. The Windows and Fedora 'Live USB Creator' installers do not provide this option ~~as of July 2011~~.		# Persistent home folder - a re-writable, re-sizable (with difficulty), uncompressed, optionally-encryptable, file space for anything that goes in the Learner's /home/ folder (all the Sugar Activities, logs, and good stuff). A persistent home folder is an option that may be selected at the time of installation of the LiveOS image (although with some effort, one could manually create a home.img filesystem in /LiveOS/ and move the /home/ folder to it). This installation option is only available through the script, '[[fedora:livecd-iso-to-disk\|livecd-iso-to-disk]]'. The Windows and Fedora 'Live USB Creator' installers do not provide this option at present.
	# Host device file space - this is the USB stick or SD card file system that is outside of the LiveOS file tree, but which is accessible through the /mnt/live ~~folder~~ mount point of a booted LiveOS installation. There, one finds the boot configuration files and anything else one had on the device before loading the SoaS image. One may save files here without consuming the other, limited file spaces. (This file space is limited by the device capacity).		# Host device file space - this is the USB stick or SD card file system that is outside of the LiveOS file tree, but which is accessible through the /mnt/live or /run/initramfs/live (Fedora 17) mount point of a booted LiveOS installation. There, one finds the boot configuration files and anything else one had on the device before loading the SoaS image. One may save files here without consuming the other, limited file spaces. (This file space is limited by the device capacity).

	The all-purpose, persistent overlay is needed for operating system changes and updates.		The all-purpose, persistent overlay is needed for operating system changes and updates.

FGrose: update link

2012-03-29T23:26:12Z

update link

← Older revision		Revision as of 19:26, 29 March 2012
Line 16:		Line 16:

	==Storage==		==Storage==
	When a Live CD or Live DVD (a LiveOS image on read-only disc media) is booted, temporary storage is prepared for the system in RAM on each boot by [http://git.kernel.org/?p=boot/dracut/dracut.git;a=blob;f=modules.d/90dmsquash-live/dmsquash-live-root;hb=HEAD /sbin/dmsquash-live-root] in initrd0, the initial ram disk filesystem. An in-memory, copy-on-write, system overlay is used (see [[#File Systems\|File Systems]] below).		When a Live CD or Live DVD (a LiveOS image on read-only disc media) is booted, temporary storage is prepared for the system in RAM on each boot by [http://git.kernel.org/?p=boot/dracut/dracut.git;a=blob;f=modules.d/90dmsquash-live/dmsquash-live-root.sh;hb=HEAD /sbin/dmsquash-live-root] in initrd0, the initial ram disk filesystem. An in-memory, copy-on-write, system overlay is used (see [[#File Systems\|File Systems]] below).

	The Fedora LiveOS system allows for persistent storage in 3 locations:		The Fedora LiveOS system allows for persistent storage in 3 locations:

FGrose: /* File Systems */ stress block level storage

2012-02-04T03:21:49Z

File Systems: stress block level storage

← Older revision		Revision as of 23:21, 3 February 2012
Line 50:		Line 50:
	The Fedora LiveOS uses the [[wikipedia:Device mapper\|Device-mapper]] service of the Linux kernel to manage the file stores on the device. This is the same service that is used by [[wikipedia:Logical Volume Manager (Linux)\|Logical Volume Manager]] to provide disc partition services.		The Fedora LiveOS uses the [[wikipedia:Device mapper\|Device-mapper]] service of the Linux kernel to manage the file stores on the device. This is the same service that is used by [[wikipedia:Logical Volume Manager (Linux)\|Logical Volume Manager]] to provide disc partition services.

	One limitation, mentioned above, is that the LiveOS persistent overlay is a write-once file space. This is related to its use of ''device mapper'' snapshots to merge a read-only file system image (copied from the compressed SquashFS.img on the read-only LiveCD or installation .iso file) with a [[wikipedia:Copy-on-write\|Copy-on-write]] service that tracks only changed ~~bits~~ of data in the snapshot (overlay) file and then re-referencing file pointers to the updated ~~bits~~.<ref>http://people.gnome.org/~markmc/code/merge-dm-snapshot.c</ref><ref>http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=drivers/md/dm-snap-persistent.c;hb=HEAD</ref> Any changes to the operating system files are stored as differences from the base. As such, "deletions" of files are saved as additional difference references, and the originals are hidden. With this mechanism, physical storage space is consumed in the write-once file space rather than recovered.		One limitation, mentioned above, is that the LiveOS persistent overlay is a write-once file space. This is related to its use of ''device mapper'' snapshots to merge a read-only file system image (copied from the compressed SquashFS.img on the read-only LiveCD or installation .iso file) with a [[wikipedia:Copy-on-write\|Copy-on-write]] service that tracks only changed blocks of data in the snapshot (overlay) file and then re-referencing file pointers to the updated blocks.<ref>http://people.gnome.org/~markmc/code/merge-dm-snapshot.c</ref><ref>http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=drivers/md/dm-snap-persistent.c;hb=HEAD</ref> Any changes to the operating system files are stored as differences from the base. As such, "deletions" of files are saved as additional difference references, and the originals are hidden. With this mechanism, physical storage space is consumed in the write-once file space rather than recovered.

	Consumption of the space allocated for persistent storage in the snapshot overlay file may be tracked with the ''device mapper'' {{Code\|dmsetup status}} report. '''Sugar Cellar''' is a small, utility script which uses that service to allow for Learner testing and discovery. It will help Learners manage their storage resources and learn ways to economize limited resources.		Consumption of the space allocated for persistent storage in the snapshot overlay file may be tracked with the ''device mapper'' {{Code\|dmsetup status}} report. '''Sugar Cellar''' is a small, utility script which uses that service to allow for Learner testing and discovery. It will help Learners manage their storage resources and learn ways to economize limited resources.