5:36 p.m.
Hi,
while working on creating some images, I've encountered something strange
and was wondering if anyone could help? This relates to iso's created
with livecd-tools-013-8.el5.1 from epel.
I've been playing with making .ks's for machines of different
characteristics (like different amounts of memory installed). I'd assumed
I'd need to make images with defined fs's of <= installed system memory. I
was surprised to find I did not? I was able to boot an image w/ an 8GB /
on a machine with 4GB memory. I encountered problems if I used more than
1GB of fs space on /.
So I created an image with a 3GB /, and tried the same test on the same
machine with 4GB memory, but encountered the same problem if I tried to
use >1GB of /.
It's like the block device that lives under the filesystem isn't actually
"as big" as the fs that's layed down on top of it?
I get I/O errors, and kjournald complaining about not being able to talk
to the device; and then the kernel drops / to read-only.
Any ideas?
Thanks!
U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is,
or may be, covered by electronic communications privacy laws, and is also confidential and
proprietary in nature. If you are not the intended recipient, please be advised that you
are legally prohibited from retaining, using, copying, distributing, or otherwise
disclosing this information in any manner. Instead, please reply to the sender that you
have received this communication in error, and then immediately delete it. Thank you in
advance for your cooperation.
---------------------------------------------------------------------
9:41 a.m.
On Thu, Jul 29, 2010 at 17:36:16 -0500,
paul.armor(a)usbank.com wrote:
It's like the block device that lives under the filesystem isn't actually
"as big" as the fs that's layed down on top of it?
This is done with an overlay. The base file system is readonly. If you
aren't using a disk based overlay (for USB devices), you'll be limited to
whatever is used for the ramfs overlay. I don't know exactly how that is
sized, but it is probably some minimum and a fraction of your ram. So it
doesn't seem surprising that you get the same limit even with different sizes
for the image saved on the cd, dvd or usb device.
10:37 a.m.
On Sat, Jul 31, 2010 at 4:41 PM, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Thu, Jul 29, 2010 at 17:36:16 -0500,
paul.armor(a)usbank.com wrote:
>
> It's like the block device that lives under the filesystem isn't actually
> "as big" as the fs that's layed down on top of it?
This is done with an overlay. The base file system is readonly. If you
aren't using a disk based overlay (for USB devices), you'll be limited to
whatever is used for the ramfs overlay. I don't know exactly how that is
sized, but it is probably some minimum and a fraction of your ram. So it
doesn't seem surprising that you get the same limit even with different sizes
for the image saved on the cd, dvd or usb device.
Right, in EL-5 version there's older livecd initrd generator script
called "mayflower" which is limited to in-memory overlay (sparse file
in initramfs).
It does not support disk based overlay, that was added later in Fedora
mkliveinitrd after RHEL5 branched.
This is the relevant excerpt from mayflower:
do_live_from_base_loop() {
# create a sparse file for the overlay
dd if=/dev/null of=/overlay bs=1024 count=1 seek=$((512*1024)) 2> /dev/null
OVERLAY_LOOPDEV=$( losetup -f )
losetup $OVERLAY_LOOPDEV /overlay
# set up the snapshot
echo 0 `blockdev --getsize $BASE_LOOPDEV` snapshot $BASE_LOOPDEV
$OVERLAY_LOOPDEV p 8 | dmsetup create live-rw
...
So you could edit this script before creating the ISO and increase
seek offset to make overlay bigger, but remember that writing to
live-rw is not safe, rootfs will get corrupted when it runs out of
space, see https://bugzilla.redhat.com/show_bug.cgi?id=465725
Union mounts is the solution, we'll use it when it hits
upstream/Fedora kernel. In the meantime be careful and watch overlay
usage with dmsetup status live-rw
BTW in >=F13 initramfs generator is dracut, if you want to look what
F13 livecd does see
/usr/share/dracut/modules.d/90dmsquash-live/dmsquash-live-root
Cheers,
Alan
9:23 a.m.
On Sat, Jul 31, 2010 at 4:41 PM, Bruno Wolff III
<bruno(a)wolff.to> wrote:
On Thu, Jul 29, 2010 at 17:36:16 -0500,
> paul.armor(a)usbank.com wrote:
>>
>> It's like the block device that lives under the filesystem isn't
actually
>> "as big" as the fs that's layed down on top of
it?
>
> This is done with an overlay. The base file system is readonly. If you
> aren't using a disk based overlay (for USB devices), you'll be limited
to
> whatever is used for the ramfs overlay. I don't know exactly
how that
is
> sized, but it is probably some minimum and a fraction of your
ram. So
it
> doesn't seem surprising that you get the same limit even with
different
sizes
> for the image saved on the cd, dvd or usb device.
Right, in EL-5 version there's older livecd initrd generator script
called "mayflower" which is limited to in-memory overlay (sparse file
in initramfs).
It does not support disk based overlay, that was added later in Fedora
mkliveinitrd after RHEL5 branched.
Ahhh, and this would be a limitation based on physical memory in the
machine where the iso is being created? So it would be suicidal to try
creating a 4GB root fs on a machine with only 2GB physical ram?
Perhaps I'll try using a newer version...
Thanks!
Paul Armor
U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is,
or may be, covered by electronic communications privacy laws, and is also confidential and
proprietary in nature. If you are not the intended recipient, please be advised that you
are legally prohibited from retaining, using, copying, distributing, or otherwise
disclosing this information in any manner. Instead, please reply to the sender that you
have received this communication in error, and then immediately delete it. Thank you in
advance for your cooperation.
---------------------------------------------------------------------
5009
days inactive
5013
days old
livecd@lists.fedoraproject.org
3 comments
3 participants
participants (3)
-
Alan Pevec -
Bruno Wolff III -
paul.armor＠usbank.com