imgcreate/fs.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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
@@ -201,7 +201,7 @@ class SparseExtLoopbackMount(SparseLoopbackMount):
rc = subprocess.call(["/sbin/mkfs." + self.fstype,
"-F", "-L", self.fslabel,
- "-m", "1", "-b", str(self.blocksize),
+ "-m", "1", "-b", str(self.blocksize), "-I128",
str(self.size / self.blocksize)])
if rc != 0:
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.
Never miss a thing. Make Yahoo your homepage.
I'm running anaconda-184.108.40.206 (+ patches from git to handle
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?
Gary Thomas | Consulting for the
MLB Associates | Embedded world
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,
after creation of a live cd I get the
EXT3-fs error (device loop0): ext3_xattr_block_get: inode 114831: bad
EXT3-fs error (device loop0): ext3_xattr_delete_inode: inode 114831: bad
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
selinux is in enforcing mode both on the build system as for the live
The used kickstart configuration worked fine on Fedora 7 and 6 (with
disabled selinux) so what changes are important to fc8?
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?
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
> >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.
|=- 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 -=|