livecd February 2008

livecd@lists.fedoraproject.org

35 participants
63 discussions

Novell's "Split Image" LiveCD
by Warren Togami 27 Feb '08

27 Feb '08

http://lists.berlios.de/pipermail/kiwi-devel/2008-February/000324.html Due to the unavailability of aufs or unionfs, apparently Novell is using something they call "split image" where every directory is writable. I didn't look into the details yet. Anybody have any clue how this works? Warren Togami wtogami(a)redhat.com

2 1

imgcreate/fs.py
by Jeremy Katz 26 Feb '08

26 Feb '08

imgcreate/fs.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit 04298ddc7bb8f0aef55a54b6c2367a6387c8100a Author: Jeremy Katz <katzj(a)redhat.com> Date: Tue Feb 26 22:27:45 2008 -0500 Temporarily use 128 byte inodes to avoid hitting #434893 256 byte inodes are currently causing the loss of xattrs on resize. esandeen is working on a fix, but to keep things from being broken for now, let's just fall back diff --git a/imgcreate/fs.py b/imgcreate/fs.py index 9ca3a3e..2dafd4b 100644 --- a/imgcreate/fs.py +++ b/imgcreate/fs.py @@ -201,7 +201,7 @@ class SparseExtLoopbackMount(SparseLoopbackMount): def __format_filesystem(self): rc = subprocess.call(["/sbin/mkfs." + self.fstype, "-F", "-L", self.fslabel, - "-m", "1", "-b", str(self.blocksize), + "-m", "1", "-b", str(self.blocksize), "-I128", self.lofile, str(self.size / self.blocksize)]) if rc != 0:

1 0

livecd-tools failed on fc7 due to can't stat /etc/hosts and /etc/sysconfig/network
by jie sun 26 Feb '08

26 Feb '08

Hi Jeremy, livecd-creator always failed on fc7 because it can not access/update /etc/hosts and /etc/sysconfig/network files to figure out the ip address so it can't set up the mysql database connection correctly. So even though it can create iso image file but it won't work because the mysql connection is not set up. livecd-creator on fc8 work fine without problem. Regards, Jie --------------------------------- Never miss a thing. Make Yahoo your homepage.

2 1

Using kickstart
by Gary Thomas 24 Feb '08

24 Feb '08

I'm running anaconda-11.4.0.37 (+ patches from git to handle custom/fixed partitioning). I can see from the scripts that 'liveinst' is supposed to handle kickstart files. However, when I try it, anaconda doesn't seem to even care... # liveinst --text ks=nfs:192.168.1.101:/tftpboot/ks/custom.ks Looking at the install log (/tmp/anaconda.log), I can see this get passed into anaconda, but no other mention of it. The install process just simply carries on just like I never used the ks= option at all. Am I missing something [fundamental] here? Thanks -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------

2 1

Could you please take me out of your mail list
by Mustafa AL 21 Feb '08

21 Feb '08

Could you please take me out of your mail list --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search.

2 1

Cannot boot properly - can't find root, no job controll
by Dimitar Uzunov 21 Feb '08

21 Feb '08

Hello! I downloaded and burned the XFCE spin, but unfortunatelly the loading process suddenly stops and I get a complaint that it cannot find the root file system and that the shell has no job controll and I'm left with just a shell - what do I need to do to boot properly? I'm including a VM screenshot (same result as booting from the CD). Thanks in advance, --Dimitar

1 0

Whats the story with compressed caching?
by Rahul Sundaram 21 Feb '08

21 Feb '08

Hi http://linuxcompressed.sourceforge.net/ Are we using it in Fedora? Any plans to? Rahul

3 3

ext3 issues
by Timo Penndorf 21 Feb '08

21 Feb '08

Hi, after creation of a live cd I get the error messages: EXT3-fs error (device loop0): ext3_xattr_block_get: inode 114831: bad block 655877 EXT3-fs error (device loop0): ext3_xattr_delete_inode: inode 114831: bad block 655877 These messages are repeated in a long sequence of entries with different inodes. The file system on the live cd is corrupted. I use a standard fedora installation with the follwoing package versions livecd-tools-013-1.fc8 e2fsprogs-1.40.4-1.fc8 libselinux-2.0.43-1.fc8 selinux-policy-3.0.8-84.fc8 selinux is in enforcing mode both on the build system as for the live cd. The used kickstart configuration worked fine on Fedora 7 and 6 (with disabled selinux) so what changes are important to fc8? Timo

2 2

Simple persistence idea, /home only
by Kai Engert 21 Feb '08

21 Feb '08

I've seen messages about complete persistence, which is, make sure all changes to the filesystem are persistent. However, for end user tasks it might be sufficient to offer persistence of the /home directory. Has the following idea been proposed already? I figure it would be easy to do. During boot, scan for a partition with a given label, say, "fedoralivehome". If present, that partition gets mounted as /home. As a consequence, all user settings and documents are kept across boots. An usb stick could be partitioned to have the second partition as /home. Does this idea make sense? Thanks, Kai

2 2

Re: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool
by Daniel P. Berrange 20 Feb '08

20 Feb '08

On Wed, Feb 20, 2008 at 09:49:57PM -0600, Douglas McClendon wrote: > Daniel P. Berrange wrote: > > > >Some other examples of scenarios where you want to build appliance images > >but > >do not have virtualization capabilities directly accessible. > > > > - Machines where the user's primary OS is running under an embedded > > hypervisor. > > QEMU is tolerable for booting an image to verify that it works, but > > building > > the image in QEMU is too slow to be practical. > > > Obviously, since my project uses precisely that (qemu) I'll defend a > bit: Some examples of where 'too slow to be practical' is IMHO an > oversweeping generalization- > > - when a few hours or overnight is not a big deal Yes it is a big deal because it directly impacts the amount of development and testing I can do in any single day. If it takes 15 minutes to build an image I can get through many many build & test cycles in a day. If it takes overnight then I can only do one build & test. For some people it may not be a big deal to wait overnight, but for many people it it totally impractical to wait this long. > - in the future, when qemu, either via kvm/kqemu or just plain faster > hardware, reduces the install time from hours to minutes, and the > simplicity and security of no-root-privs becomes more valuable than the > time saved using alternate methods (at least for some usage cases). KQEMU is essentially unmaintained & you can't assume access to KVM since it requires hardeware virtualization & even if your hardware has such capabilities there are plenty of scenarios where the end user will not be able to use them. > Naturally these might not be situations you are interested in, but I > think your statement of 'too slow to be practical' was an > oversimplification which you knew I would take the bait and defend ;) You're imagining things - if you choose to use QEMU for your project I've no problem with that - that's your choice to make. It is simply not practical for my day-to-day work to wait for installs inside QEMU emulator to complete. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

livecd February 2008