F7 general question about livecd-creator and timezones
by Skunk Worx
My ks scripts have the timezone set to PDT (America/Los_Angeles).
Installation to a hard drive works as expected. PDT in startup and in
shells, etc.
Creating a livecd-creator iso with the same tz setting, then booting,
shows A/L_A in the /etc/sysconfig/clock file, as expected.
However the date is always EDT in the boot messages, shells, etc.
During startup I see :
(lvm)
Press I to enter interactive startup
Setting clock (utc) Mon Jun 4 00:12:59 EDT 2007
(udev)
I'm not clear on what is happening between lvm and udev in the Linux
startup sequence.
If someone could give me a hint about what to look for and where to look
for it I would appreciate the help.
---
John
14 years, 5 months
Trimming the size of LiveCD's
by Jeroen van Meeuwen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here's a thought:
1304 random packages will install 724 MB of data in /usr/share/doc
I'm sure there is /something/ to gain here. If every package on average
installs ~0.5 MB of docs... Would it worth figuring out what docs should
be on the LiveCD in the first place? I guess removing everything RPM
calls docs is too much, as this will include man-pages as well.
Any thoughts?
- --
Kind regards,
Jeroen van Meeuwen
- -kanarip
- --
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG19BDKN6f2pNCvwgRAhhaAJ9UCH9WetRBu6foxAgztqMvg3h6OwCeLZU5
LxWzG5TBxdQOAE3VGFp400w=
=YiuK
-----END PGP SIGNATURE-----
15 years, 12 months
boot failure on VIA Epia M-6000 board
by Thorsten von Eicken
I've been trying to boot the F7 live-cd on a VIA Epia M-6000 (600Mhz
fan-less VIA C3 Eden processor). With the distributed live-cd
(Fedora-7-Live-i686.iso) the machine resets as soon as the kernel starts
(i.e right after the initrd is unpacked).
I built a custom i386 kernel with the VIA drivers and DMA turned off,
which got the kernel to boot. The problem I then have is that when init
should be executed, the system simply hangs and nothing happens. The
last line printed is "Freeing unused kernel memory".
I then built an entire livecd-fedora-minimal system from scratch and
still no joy (same problem where init doesn't run). I then replaced init
by a "hello world" program. If I statically link the hello world program
it happily prints "hello world", but if I dynamically link it it
doesn't. So it looks like /bin/bash (dynamically linked) doesn't run.
At this point I'm at the end of my fedora wisdom. I have previously
successfully booted a custom gentoo 2.6 kernel on this box, and the
ubuntu 6.06.1 system boots as well. I'd rather use fedora, though, and
would appreciate any suggestions either about what to try, or how to get
debug information about what fails when running a dyn linked executable.
Thanks!
Thorsten
NB: I was unsuccessful building the livecd-fedora-minimal system using
the provided kickstart. I had to add the following packages so that
livecd-creator could operate properly in the chrooted environment: nash,
cpio, gzip, findutils, and squashfs-tools.
16 years
Revised: [PATCH] turboLiveInst - improves livecd/usb installer speed by 15-20+%
by Douglas McClendon
Attached is a revised version of my turboLiveInst patch to livecd-tools and
anaconda.
This version is more polished. I.e. bugs have been fixed, complexity removed,
and therefore should be easier to review.
I performed some anecdotal performance tests, on a sony vaio vgn-n250e. I used
a 30G destination volume for all tests, and when using usbstick media, it was
media that reported 8.5MB/s from hdparm -t. I did have selinux disabled, and
did not use the prelink option. I'd love to hear performance numbers from
differing test rigs.
The performance results I got were-
install from cdrom without turboLiveInst:
copy: 250s
postinst: 86s
install from cdrom with turboLiveInst:
copy: 299s
postinst: 84s
install from usb without turboLiveInst:
copy: 226s
postinst: 72s
install from usb with turboLiveInst:
copy: 175s
postinst: 72s
Conclusions:
On this testrig, installing from cdrom, turboLiveInst yielded a 20% speedup in
copy, which resulted in an end to end install speedup of 15%. Installing from
usb, turboLiveInst yielded a 29% speedup in copy, which resulted in an end to
end install speedup of 20%.
I did test copy-to-ram mode, and the resulting benefits were laughably huge.
But this is only because this laptop has 1G of ram, and very strange behaviour
occurs this near the threshold of having too little ram to use this feature.
Though this is still an argument in favor of turboLiveInst, in that somehow it
found itself on the better side of the threshold. I would expect that with 2G
of ram, the benefit would be on the order of 35-50% speedup, as the main thing
masking the benefit in the cdrom case, is the slow access to install media,
which hides the benefit of cutting the needed disk writes nearly in half.
The secondary benefit of turboLiveInst is that it removes the artificial
limitation that the target rootfs must be greater than 4.0G, instead of the 2.1G
actual uncompressed size of the contents of the LiveCD.
Jeremy has pushed back against this patch because of complexity. Hopefully this
round of polishing will make the patch much easier to read and understand. In
addition, since the cleanupDeleted patch which this one depends on has already
been merged, that should also make this a bit more palatable.
Jeremy also brought up the idea of doing a file level copy installation, rather
than the current block level mechanism. This _is_ a good idea, in my opinion,
in that it will more intelligently support situations such as a separate /usr
filesystem. In addition there is no way that turboLiveInst or the existing
block level mechanism can be made to support xfs or other non-ext3 destination
filesystems chosen by the user (should those options return).
But- I would argue that file level installations may suffer badly due to cdrom
seeking. I would also argue that there is no reason why turboLiveInst, could
not be the first choice for installation technique, with fallbacks to file level
copies for the seperate /usr and xfs type scenarios.
Ultimately I just hope that turboLiveInst gets serious consideration for F8, via
performance comparison with whatever other options may exist.
Finally, here are some notes on the architecture, which may help you to
understand the code-
As I mentioned in the original patch, the basic idea is to simply, at
livecd-creator build time, use a device mapper snapshot to generate a delta file
between the 4.0G filesystem housing 2.1G of data, and a 2.1G filesystem holding
the same data. Then at anaconda/liveinst time, that delta file is used to
recreate a virtual image of the 2.1G filesystem, so that it can be copied to the
installation target, rather than the 4.0G filesystem which includes 1.9G of
zeros that needn't be written to disk.
I ended up using /dev/loop118 in the initramfs init (mayflower generated) to
expose the delta file. /dev/loop118 was mknod'd already by mayflower, but not
actually used for anything. I used it to expose the delta file (osmin.tgz),
because /dev/loop121 was being used to expose the 4.0G os.img, and it seemed
simplest to use an identical mechanism to expose that data. Because by the time
anaconda runs, the original cdrom and squashfs filesystems have been lazy
unmounted, a simple cp at that time was not an option(?).
I chose to extract the delta file (osmin, a 16MB sparse file containing 1.2M of
data, compressed to 25kb on cdrom) into /dev/shm (i.e. ram) so that reads from
it would not try to go to the cdrom. This may not have been necessary.
I chose to calculate the size of the filesystem at livecd-creator time, and
include it with osmin as osmin.size(together forming osmin.tgz). This is less
complex than what I did in the first pass, which was to use dumpe2fs to
calculate it at ananconda time.
As always, questions, comments, criticisms, and especially testers are more than
welcome.
peace...
-dmc
16 years
local caching
by Colin Walters
Hi,
What's the status of the persistent local RPM caching patches?
16 years
[PATCH] overlay/persistence second pass - for developer reference only
by Douglas McClendon
(I'm getting a sense of deja vu, that I'm learning the same lesson
someone else recently learned here. Lets see if the 3rd time is the
charm...)
Attached is a revision to the persistence implementation that I posted a
couple weeks ago. This is mainly for Jeremy, Tim, and anyone else who
is interested in working on this, or something similar. I.e. at the
very least, it is worth a read to look at the issues I've dealt with,
and the several that are in comments as TODO.
It may well be that a simpler persistence implementation that involves
just extracting tarballs from usbsticks into the normal ram overlay, may
be useful instead of (or even in addition to) this kind of
implementation. (or perhaps some implementation of unionfs will make it
into fedora eventually?)
The main points of note, since the first post are-
- all sorts of bugs fixed
- I moved the overlay storage filesystem to be visible as /mnt/overlayfs
always. This solves some aspects of the current problem of not easily
being able to see how much writable space you really have available on
the rootfs. (the real answer is a combination of the device mapper
overlay file AND the filesystem it resides on).
- I've included modified /etc/rc.d/init.d/halt and functions, to handle
getting things cleanly shutdown (which is VERY important)
- ntfs is somewhat present, but not really working. I have tested with
vfat and ext3. Note that ext3 is a PITA when not cleanly unmounted- see
TODOs.
- rudimentary testing of the choice selection when multiple possible
overlay images are detected suggests it works.
- the patch format merely reflects my educational process with git, and
not that I suggest that code this immature is anywhere near ready for
merging. (i.e. inclusion of halt&functions and the origs I based them
off of. Refer to list archives for documentation on how to use
addidir/addsdir if needed)
As always, comments/criticisms/suggestions are more than welcome.
peace...
-dmc
16 years
SRPMS for installed RPMs?
by Matt Domsch
I want to be sure, for license compliance, that all the binary bits on
the final LiveCD have corresponding source code available.
One of the "features" I'd like to see something in the stack of
livecd-tools produce is a CD/DVD/whatever of the SRPMS that match the
RPMs that go into the LiveCD. Smooge and I have both done this
ourselves, with varying degrees of ease, essentially querying all the
installed RPMs on the LiveCD after-the-fact and generating the list,
then grabbing the files etc. All very manual. I expect there's a
better way, and I'm even open to helping code it, but am looking for
direction from you - those who know the tools best...
Maybe it's really an Anaconda feature?
Advise please.
Thanks,
Matt
--
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
16 years
Revisor: Cannot setup installation target. Aborting.
by Lars Bjørndal
Hi!
With yesterday's GIT version of Revisor, I got the following error message:
Downloading Packages:
Filesystem label=livecd-20070825
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
325120 inodes, 649728 blocks
6497 blocks (1.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=666894336
20 block groups
32768 blocks per group, 32768 fragments per group
16256 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Writing inode tables:
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 38 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
tune2fs 1.40.2 (12-Jul-2007)
Setting maximal mount count to -1
Setting interval between checks to 0 seconds
Cannot setup installation target. Aborting.
Do you want to continue? [Y/n] y
What's wrong here, do you think?
Lars
16 years
kickstart file for FEL
by Chitlesh GOORAH
Hello there,
Here is some work about the Fedora Electronic Lab live image.
http://chitlesh.fedorapeople.org/FEL/livecd-fedora-electronic-lab.ks
I would like to have some feedbacks about it and how to improve it.
Will it be possible to spin a live image for FEL when F8T2 will be release?
PS: I would like to give you a complete list of rpms installed on the
livecd image. But however from today's rawhide, my spins are all
broken with the following errors during the :
file_contexts: invalid context system_u:object_r:games_exec_t:s0
file_contexts: invalid context system_u:object_r:games_exec_t:s0
Installing: filesystem #################### [
3/723]file_contexts: invalid context
system_u:object_r:games_data_t:s0
file_contexts: invalid context system_u:object_r:games_data_t:s0
Installing: ConsoleKit ################# [
73/723]file_contexts: invalid context
system_u:object_r:consolekit_exec_t:s0
Installing: GConf2 #
[133/723]file_contexts: invalid context
system_u:object_r:gconfd_exec_t:s0
Installing: pam
[173/723]file_contexts: invalid context
system_u:object_r:userhelper_conf_t:s0
Installing: usermode
[183/723]file_contexts: invalid context
system_u:object_r:userhelper_conf_t:s0
file_contexts: invalid context system_u:object_r:userhelper_conf_t:s0
file_contexts: invalid context system_u:object_r:userhelper_conf_t:s0
Installing: usermode #
[183/723]file_contexts: invalid context
system_u:object_r:userhelper_exec_t:s0
[..]
Chitlesh
--
http://clunixchit.blogspot.com
16 years, 1 month
Some problems: rootpassword and liveinst
by Sebastian Vahl
Hi.
My actual spin of the kde livecd from today has some problems:
1. It seems that the root password wasn't erased. If I boot the iso in
vmware I got the error in the attached screenshot. If I boot the iso
with enforcing=0 all is working. Is this a problem on my local machine
(if relabeld the whole filesystem before I tested this)?
2. Because of 1. I've bootet with enforcing=0. If I then want to start
liveinst I get this traceback:
> [root@localhost ~]# liveinst
> FATAL: Module md not found.
> Traceback (most recent call last):
> File "/usr/sbin/anaconda", line 550, in <module>
> import signal, traceback, string, isys, iutil, time
> File "/usr/lib/anaconda/isys.py", line 33, in <module>
> import block
> File "/usr/lib/python2.5/site-packages/block/__init__.py", line 20,
> in <module> import dm
> ImportError: /usr/lib/python2.5/site-packages/block/dmmodule.so:
> undefined symbol: dm_task_get_uuid
Any suggestions or more info needed?
Sebastian
16 years, 1 month
