Adding files into the CD root file system
by Alexandre Magaz Graça
Hi,
I'm making a LiveCD that I want to autorun (from Windows and Linux) to
open a browser showing some help about how it works. So I added a new
option that lets add to the CD root file system.
If someone finds it useful, the attached patch adds this option to
pilgrim. The patch is for the latest git version.
Cheers,
Àlex
16 years, 8 months
installer efficiency - sparse hackery
by Douglas McClendon
Out of curiosity Jeremy, in your envisioned sparse-feature method
alternative to turboLiveInst-
How do you envision detecting which 0s in the file are legitimate data
that needs to get written to disk, and which are unnecessary unwritten
parts of the file?
I took a look at the tar --sparse documentation, which suggests that it
handles sparseness by doing a complete extra read of the whole file, to
detect 0s. As mentioned, because what you are talking about is _not_ an
actual sparse copy, there may be legitimate 0s that need to be written
in our case.
It seems the only way would be to write a tool, which utilizes "intimate
knowledge of ext3fs filesystem internals" to detect the appropriate
place of holes in the file.
Can I just ask you - please - until you have a specific complete plan
for an alternate solution, just go ahead and commit turboLiveInst for
f8test2. If you come up with a better cleaner solution (even if only in
your opinion), I promise not to utter one word of complaint after you
remove turboLiveInst.
I mean, you've already been down the path of suggesting a file-level
copy. That turned out to have a 5X slowdown performance penalty. Now
you are going down the path of this sparse copy, which is an incomplete
solution, that despite what you've said, is not simply an elegant
implementation of sparse support in python's shutil.copy. Rather, it is
at least as much of a hack as what I did. And I maintain that
turboLiveInst is not a hack, but an elegant use of devicemapper
snapshot, which is the same elegant mechanism responsible for the
fedora7 livecd in the first place. Getting more exposure to
devicemapper shapshot usage in the developer community - is a good
thing. It is a wonderful tool, that I'm sure will see many elegant uses
in the coming years.
Regards,
-dmc
16 years, 8 months
LiveCD as Xen Guest, existence proof?
by Jon Steer
Has anyone managed to boot an F7 LiveCD as an F7 Xen Guest?
I can boot an F6 LiveCD, but not F7.
I can also boot the F7 LiveCD on VirtualBox, but not on F7
thanks,
jon
--
"Whereever you go, there you are"
16 years, 8 months
Re: livecd persistence
by Douglas McClendon
Jeremy Katz wrote:
> Had a chance to look at cleaning up the patches any? If not, I'll take
> a stab the first of next week as I really want to get the basic bits in
> for test2 :)
I've been waiting to put turboLiveInst to rest, as my approach may
involve devicemapper tricks, which I need to make sure you are
comfortable with reviewing before I waste any time implementing them.
Also, I need to make sure that this asdas(a)redhat.com person doesn't have
useful persistence code, which I would be wasting my time duplicating if
not necessary.
Lastly, wouldn't test2 require an approved feature? I've been holding
off myself due to no feedback regarding the attached mail
-dmc
----
On Mon, 13 Aug 2007, Douglas McClendon wrote:
> Any progress on this front? The F8 feature freeze is rapidly
approaching.
>
> If I don't hear back about this issue, I'll just solicit people who
have signed the CLA to put up a couple placeholder features, just so
they are in place before the freeze.
>
> 1) livecd persistence, as mentioned on fedora livecd wishlist
>
> 2) improve livecd boot speed dramatically
It was Luis Villa's last act before he left to draft changes to the CLA.
I'll find out what the status of those changes are -- and it seems that
counsel agreed to them. Max, do you know where this stands?
--g
----
Greg Dekoenigsberg wrote:
> On Thu, 19 Jul 2007, Douglas McClendon wrote:
>
>> Yeah, I figured out the CLA issue. I still haven't signed it. I
hate legaleze. Maybe you can clarify- By signing that, and submitting
works via channels under that umbrella, am I giving RH a license to
modify my work, distribute those modifications to others, and not be
obliged (ala GPL) to submit modifications back to me? Thats sort of
what it sounds like, i.e. that they get as many rights as the original
copyright holder (which would be those aforementioned rights).
>>
>> I'm sure this has been talked to death on some mailinglist or FAQ,
any pointer to such a thread would be appreciated.
>
> You know, I'm not sure this particular reading has ever been
discussed. I know that we want to make super-sure that (a) you actually
*have* the right to share code with us, and (b) you can't take your ball
and go home, and the CLA is structured to do that.
>
> I've never interpreted the CLA as giving us the right to take your
work, modify it, and not give the modifications back -- but yeah, on a
closer reading, that looks possible. I'll check it out with legal.
Any progress on this front? The F8 feature freeze is rapidly approaching.
If I don't hear back about this issue, I'll just solicit people who have
signed the CLA to put up a couple placeholder features, just so they are
in place before the freeze.
1) livecd persistence, as mentioned on fedora livecd wishlist
2) improve livecd boot speed dramatically
-dmc
>
> I can assure you that's not our intent, but contracts don't really
care much about intent. :)
>
> --g
>
16 years, 8 months
Is it possible to use yum setup on build host?
by Lars Bjørndal
Hello!
I wonder if it's possible to use the yum setup on the machine you're
using to build the livecd, instead of using the "repo" commands in the
.ks file? In case it is, how do you do it?
In case I need to use the repo command in the .ks file, I would like
to know if it's possible to use "includepkgs=" in any way.
Thank you!
Lars
16 years, 8 months
Get an error message with Revisor
by Lars Bjørndal
The command I ran was:
revisor --cli --kickstart=/etc/livecd-console-rev.ks --optical\
--model=lrs
After package download, and creating the file image, I got:
Setting interval between checks to 0 seconds
Traceback (most recent call last):
File "/usr/sbin/revisor", line 203, in <module>
revisorBase.run()
File "/usr/lib/python2.5/site-packages/revisor/cli.py", line 48, in run
self.base.lift_off()
File "/usr/lib/python2.5/site-packages/revisor/base.py", line 532, in lift_off
self.buildLiveMedia()
File "/usr/lib/python2.5/site-packages/revisor/base.py", line 904, in buildLiveMedia
if not liveImage.setup(livemedia_targetsize, build_dir="/var/tmp/revisor-livecd", yum_installroot=self.cfg.yumobj.conf.installroot, yum_cachedir=self.cfg.yumobj.conf.cachedir):
File "/usr/lib/python2.5/site-packages/revisor/pilgrim.py", line 448, in setup
os.symlink("../proc/mounts", self.build_dir + "/install_root/etc/mtab")
OSError: [Errno 17] File exists
What could I do to fix this?
Thanks!
Lars
16 years, 8 months
[PATCH] overlay/persistence second pass - for developer reference only
by Douglas McClendon
Attached (for real this time) 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, 8 months
[PATCH] overlay/persistence second pass - for developer reference only
by Douglas McClendon
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, 8 months
How to install one package from a specific repo?
by Lars Bjørndal
Hello!
I need to install clamav from the development repository. I tried to
do "yum --enablerepo=development -y install clamav" in the %post
section of the .ks file, but it didn't work.
BTW: I tried to set keepcache=1 in the yum.conf file on the build
system, but the packages are lost after the livecd is built. So next
time, they need to be refetched... Is it possible to keep them for
future use?
Lars
16 years, 8 months
