Jeroen van Meeuwen wrote:
Douglas McClendon wrote:
Douglas McClendon wrote:
Theoretical Workaround #1-5
-
Just curious; I like what I'm reading, although I do not follow some
parts of the theoretical workarounds, but: Is there any particular use
case for all
Jeroen van Meeuwen wrote:
Douglas McClendon wrote:
Douglas McClendon wrote:
Theoretical Workaround #1-5
-
Just curious; I like what I'm reading, although I do not follow some
parts of the theoretical workarounds, but: Is there any particular use
case for all
Jeroen van Meeuwen wrote:
Douglas McClendon wrote:
Jeroen van Meeuwen wrote:
The essence of why liveCDs are cool(==useful?) in the
first place, is because they allow users to try out the complete system,
without the traditionally complex and problematic process of installing
Douglas McClendon wrote:
Jeroen van Meeuwen wrote:
In a similar vein, I would say that, perhaps this feature, which I'm
just working on out of pure spite for unnecessary reboots will spark
someone else's imagination, and use-cases will become more evident in
the future. Don't even get me
Tim Wood wrote:
Continuing this thought- if MarkMC's dm-snapshot-merging patch was in the
kernel, there could be a button in the live session, such that at any
point
_long after_ the installation, the user could _opt_ to 'fold in' their
live-session modification. (i.e. hitting the button
Tim Wood wrote:
Before shooting from the hip anymore, I'll dig into my RHCT/CLP stuff and
see what I dig out. Homework... :-(
So have you been trolling me? Was the reference to Suse a pointer to the fact
that they have already done the rebootless install thing? (I'm too lazy to
download
Jonathan Steffan wrote:
There is my incomplete 2am reply ;-)
I might try to reply (or even read your post), but I'm at my 4:44am and
1) theoretical #5 doesn't work, as sda1 can't be both part of /dev/md7 AND part
of a devicemapper at the same time (even if both parts are working with
Douglas McClendon wrote:
Douglas McClendon wrote:
Well... Now that I understand dm-mirror (somewhat at least), it
appears the patch to livecd-tools to support rebootless installation
is 0 lines long. Hmm...
Bahh... my brain is in knots. You can't actually nest device mapper
entries
Question: Does the current livecd installer inefficiently write lots of 0's to
the destination drive that it doesn't need to?
I think it might. The os.img on the F7 livecd is a 4G sparse file with about
2.3G of data. Anaconda's livecdcopy backend uses python's os.read/write. I
would guess
Douglas McClendon wrote:
Douglas McClendon wrote:
Question: Does the current livecd installer inefficiently write lots
of 0's to the destination drive that it doesn't need to?
I think it might. The os.img on the F7 livecd is a 4G sparse file
with about 2.3G of data. Anaconda's livecdcopy
Douglas McClendon wrote:
Douglas McClendon wrote:
Question: Does the current livecd installer inefficiently write lots
of 0's to the destination drive that it doesn't need to?
I think it might. The os.img on the F7 livecd is a 4G sparse file
with about 2.3G of data. Anaconda's livecdcopy
Greg Dekoenigsberg wrote:
I see someone besides me uses mailing lists to keep public notes for
themselves to remember later. :)
Well, I would hope you do it for the same reason I do. I.e. they aren't just
personal notes, but rather technical ideas. And hopefully leveraging exposure
to
to the running system would
provide huge benefits.
-Eli
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Douglas
McClendon
Sent: Sunday, July 08, 2007 5:23 PM
To: fedora-livecd-list@redhat.com
Subject: Re: [Fedora-livecd-list] [RFC/PATCH] livecd rebootless
Jeroen van Meeuwen wrote:
It seems like a worthy feature for a livecd if one
wishes to use it a lot.
On the other hand, why not compose the live cd or dvd with all that
rightaway?
The point of persistence is to have a nice fat distro on a cute 3 dvd, combined
with a nice cute 1G usb stick,
Lane Brooks wrote:
I have a few local rpm files that are not part of a yum repo that I
would like to install on my live cd. What is the recommended way to do
that?
# on the host build system
yum install createrepo
mkdir /var/tmp/myrepo
cp /path/to/my/*.rpm /var/tmp/myrepo/
createrepo
Jeroen van Meeuwen wrote:
Douglas McClendon wrote:
Jeroen van Meeuwen wrote:
It seems like a worthy feature for a livecd if one
wishes to use it a lot.
On the other hand, why not compose the live cd or dvd with all that
rightaway?
The point of persistence is to have a nice fat distro
Lehal Parminder (GS-FI/ENG3-NA) wrote:
Hello,
How can we create a live CD containing files which are not in a RPM?
More specifically, I need to create a live CD containing tomcat and a
custom web application(jsp). The custom web application is in war
format. Is it possible to do it without
kenji izutani wrote:
Hi all,
I'd like to know how I can know the free memory left to allow a software
generate a file at var directory. As far as I tested, free command did not
to seem to show the exact number of free memory size even if I created and
deleted a file. Although I get enough free
Jeremy Katz wrote:
On Tue, 2007-08-07 at 16:42 -0500, Douglas McClendon wrote:
This might be the wrong list to be asking this, but out of curiosity-
Why can't relabeling be done if the host is running with selinux
disabled? (selinux=0)
It's just writing some metadata to the fs right? Seems
I have a few changes I'd like to request to mayflower. I'd like to get
some feedback before actually laying down the effort of producing patches.
#1 - mayflower.conf - add PROGRAMS and FILES
I'd like it if mayflower, in addition to supporting MODULES+= lines,
would also support PROGRAMS+=
Douglas McClendon wrote:
I have a few changes I'd like to request to mayflower. I'd like to get
some feedback before actually laying down the effort of producing patches.
...
#3 - optional program, sort of like existing shell cmdline arg
Have a cmdline argument of program= and eprogram
Tim Wood wrote:
The one comment I'd have is would it be possible to feed some (or all)
of these options in as a config file?
Most of my RFC was basically about extending the functionality of the
mayflower.conf config file. But currently, as far as livecd-creator
(and presumably revisor) is
ashok shankar das wrote:
Douglas McClendon wrote:
Tim Wood wrote:
The one comment I'd have is would it be possible to feed some (or
all) of these options in as a config file?
Most of my RFC was basically about extending the functionality of the
mayflower.conf config file. But currently
Douglas McClendon wrote:
Matt Domsch wrote:
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
Phillip Lougher wrote:
Douglas McClendon-2 wrote:
Douglas McClendon wrote:
Ok, so there is a negative consequence of a large container. As I alluded
to
before, mksquashfs apparently does not give any special consideration to
sparse
files. Naturally it can compress a file containing huge
Matthias Clasen wrote:
On Fri, 2007-08-17 at 16:40 -0500, Douglas McClendon wrote:
Lastly, wouldn't test2 require an approved feature?
Thats the downside of the new feature process with all the approval and
tracking and red tape. People start to think that they are not allowed
to work
Matthias Clasen wrote:
I was just referring to your question about an approved feature, but
maybe I just misunderstood what you were trying to say.
I was responding to Jeremy's original email, in which he suggested the
impetus for immediate action was to get the code into f8t2. For that
Matthias Clasen wrote:
On Fri, 2007-08-17 at 17:17 -0500, Douglas McClendon wrote:
Matthias Clasen wrote:
I was just referring to your question about an approved feature, but
maybe I just misunderstood what you were trying to say.
I was responding to Jeremy's original email, in which he
Phillip Lougher wrote:
Douglas McClendon wrote:
20% speedup of reading data into /dev/null isn't all that useful.
I could write an irritable comment here, but I won't rise to the
bait :-)
Sorry, I did not realize from your post that you were the squashfs
author. I assumed you were a more
Jeremy Katz wrote:
On Fri, 2007-08-17 at 16:02 -0500, Douglas McClendon wrote:
Phillip Lougher wrote:
Douglas McClendon-2 wrote:
Douglas McClendon wrote:
Some stats based on the Fedora-8-Test-1-Live-i686.iso
original squashfs.img 712495104 (681M)
sparse squashfs.img 709820416 (678M)
sparse
Jeremy Katz wrote:
On Mon, 2007-08-20 at 05:23 -0500, Douglas McClendon wrote:
(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...)
It looks like you're getting hit by what Colin was where the list
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
Phillip Lougher wrote:
Douglas McClendon wrote:
Finally, (for any spectators reading this far), what you mentioned
about sorting by access time, is one of a few key factors I had in
mind for drastically reducing livecd boot time. It's a bit trickier
for fedora than for kubuntu, because
Jeremy Katz wrote:
On Mon, 2007-08-20 at 05:23 -0500, Douglas McClendon wrote:
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
Jon Steer wrote:
I would like to customize the kickstart file that anaconda uses during
a liveinst install of my liveCD.
There is no kickstart. It copies the installed (ext3 file)system right
from the livecd onto the disk.
Alternately you can launch anaconda yourself with a kickstart,
The 3rd pass at my overlay/persistence patch for livecd-tools, isn't
really bigger than the 2nd, but it is fairly big, and definitely not the
final version.
So if you want it, or any further updates if and as they become
available, see
http://filteredperception.org/downloads/overlay/
Lars Bjørndal wrote:
Hello!
I still cannot manage to create a --live-optical CD with revisor.
Yesterday, I downloaded and installed both revisor and livecd-tools
from GIT.
I have next to no experience with revisor, but this is the second time
I've seen something like this on this list-
Jeremy Katz wrote:
On Fri, 2007-08-31 at 10:24 +0200, Jeroen van Meeuwen wrote:
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
Mark McLoughlin wrote:
Hi,
This doesn't actually seem so bad to me ...
Thanks for taking a look.
The main suggestion I'd have is that if the osmin.size was dropped[1],
Actually in my first iteration of the patch, I was using dumpe2fs, but
my parsing of it with awk and
Mark McLoughlin wrote:
Second patch refactors the resize2fs stuff so that it is substantially
easier to understand - e.g. trying to grok the binary search in
resize2fsToMinimal() is a lot easier than the original version in
cleanupDeleted() ...
A very minor additional comment, would
Mark McLoughlin wrote:
Second patch refactors the resize2fs stuff so that it is substantially
easier to understand - e.g. trying to grok the binary search in
resize2fsToMinimal() is a lot easier than the original version in
cleanupDeleted() ...
Couple more things, which I'm still just
John Lumby wrote:
I'm trying to upgrade an FC4 system to Fedora 7 and thought the
Fedora-7-Live-i686.iso would be the way to do it.But after booting
the Live CD, I don't see any option or instructions or application
program to upgrade. Is there one? If so - what?
Not at the moment. The
Colin Walters wrote:
On 9/4/07, John Lumby [EMAIL PROTECTED] wrote:
That's a shame, but thanks for the rapid response.
If you're using Fedora as a desktop, I've found that mostly the OS doesn't
matter and I can do upgrades just by copying my home directory. The only
thing I really change on
Jeremy Katz wrote:
On Tue, 2007-09-04 at 16:47 -0500, Douglas McClendon wrote:
Mark McLoughlin wrote:
On Mon, 2007-09-03 at 15:33 -0500, Douglas McClendon wrote:
Mark McLoughlin wrote:
What you have is mostly fine IMHO, it was the tarball I had a problem
with.
Ok, in that case
Jeremy Katz wrote:
On Wed, 2007-09-05 at 15:54 -0500, Douglas McClendon wrote:
Jeremy Katz wrote:
I think that some of the above will go a long way towards making things
look nicer which is going to make me more amenable to it. I still don't
necessarily _like_ it because I still think
I noticed the recent commit that enables usage of swap partitions
automatically. I'm not so sure this is a good idea. This seems like it
would break the case, of me having F7 installed, downloading and burning
the f8(t3)-livecd iso, doing a pm-hibernate, and then booting
f8(t3)-livecd, and
Dino Lopez wrote:
I follow the Article at:
http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo
Great job by the way, and got my 1GB USB booting the
Live Version of Fedora 7. This is after see some of
the guys at the linux meeting in Huntsville, AL
running Ubuntu in a similar way.
After add my
While I haven't by any means given up pursuit of my devicemapper
implementation of persistence, I wonder-
What do people think about using unionfs for persistence (and perhaps
Copy-On-Write in general) in Fedora LiveCDs?
I was somewhat surprised to discover a while back that ubuntu actually
Douglas McClendon wrote:
While I haven't by any means given up pursuit of my devicemapper
implementation of persistence, I wonder-
What do people think about using unionfs for persistence (and perhaps
Copy-On-Write in general) in Fedora LiveCDs?
I was somewhat surprised to discover a while
Phillip Lougher wrote:
Jeremy Katz wrote:
On Mon, 2007-09-10 at 10:15 -0500, Douglas McClendon wrote:
What do people think about using unionfs for persistence (and perhaps
Copy-On-Write in general) in Fedora LiveCDs?
The big question today is the same as the big question around using
unionfs
Jesse Keating wrote:
On Wed, 12 Sep 2007 20:50:32 -0500
Douglas McClendon [EMAIL PROTECTED] wrote:
Dumb question- What does this actually do? (e.g. an e.g.)
Sorry, so, in a kickstart file you want to actually use to install
something you have to define a method, that is a location to find
Question-
in the initramfs /init generated by mayflower-
...
export PATH=/sbin:/bin
exec /dev/console /dev/console 21
mount -n -t tmpfs -o mode=0755 udev /dev
mknod /dev/console c 5 1
mknod /dev/null c 1 3
...
Is this a bug that /dev/console is being referenced before it is
created, or
Jeremy Katz wrote:
On Thu, 2007-09-13 at 12:08 -0500, Douglas McClendon wrote:
Is this a bug that /dev/console is being referenced before it is
created, or is there some obscure magic relating to /dev/console that I
am unaware of?
Looks like a bug to me. But at the same time, it looks like
Colin Walters wrote:
On 9/13/07, Douglas McClendon [EMAIL PROTECTED] wrote:
(and no, I really don't want the mknod in the initramfs cpio, at least
until I can have an enhanced cpio that can create archives containing
device nodes, without requiring root privs...)
http://packages.debian.org
Attached is an up to date revision of my turboLiveInst patch which
incorporates the suggestions made during MarkMC's review.
Mark's executive summary of the feature:
Reduce installation time by not copying unused data to disk
We avoid copying unused data by copying a filesystem image that
Patrice Guay wrote:
This week, I attended the VMware conference in San Francisco (VMWorld
2007). I attended several conferences and a lab related to virtual
appliances (http://www.vmware.com/appliances/). These are virtual
machines containing the OS and whatever software you may want to bundle
Jon Steer wrote:
I have built a console-based LAMP LiveCD appliance. We use VMs to host the
liveCD during the testing process.
We'd like to be able to specify a kickstart file on the boot line that would
cause either puppet to run or other dynamic configuration tasks to occur
without manual
Chris Hubick wrote:
Hi,
I am having some problems with livecd-creator...
I'll answer what I can-
I am running from a Fedora 7.91 Desktop Live CD, and attempting to use a
kickstart file to generate a custom LiveCD (DVD) onto my USB hard drive:
cd /media/CHWData/chwlive/
mkdir tmp
This series of 7 patches is a pure split of the prior turboLiveInst v3
monolithic patch. (i.e. produces identical tree, therefore I have done
no further testing)
diff -Naur livecd.200709140049/README livecd.1.doctypos/README
--- livecd.200709140049/README 2007-09-14 05:49:42.0 +
this patch takes care of the anaconda side of taking advantage of
livecd's created with a livecd-tools that has
turboLiveInst/genMinInstDelta support. But the code does check for the
legacy situation, and handles it gracefully. Thus this patch is safe
even in the absence of the actual
the final piece, livecd generating an optomized image that the prior
anaconda patch can take advantage of during a livecd install.
see...
https://www.redhat.com/archives/fedora-livecd-list/2007-September/msg00101.html
for all the good details...
Enjoy...
-dmc/jdog
diff -Naur
Jeremy Katz wrote:
On Mon, 2007-09-17 at 12:24 -0500, Douglas McClendon wrote:
ignore-deleted isn't an option worth keeping around
The main (albeit, not the best in the world :) reason that I've kept it
thus far is that it speeds up builds when just testing a livecd-creator
change
Jeremy Katz wrote:
On Mon, 2007-09-17 at 13:55 -0500, Douglas McClendon wrote:
Now that you're into the guts of genMinInstDelta (patch 6/7), maybe this
topic is very timely-
Heh, indeed :-) -ENEEDMORECAFFEINE first though before I finish looking
at 6 and 7.
Yeah, I'm at the end of my
even if turboLiveInst/genMinInstDelta didn't depend on this, it is a
good idea anyway for anaconda's livecd backend to use dumpe2fs to
determine the size of data to copy during install, rather than looking
at the size of the block device holding the filesystem.
diff -Naur
Jeremy Katz wrote:
On Mon, 2007-09-17 at 12:34 -0500, Douglas McClendon wrote:
this patch takes care of the anaconda side of taking advantage of
livecd's created with a livecd-tools that has
turboLiveInst/genMinInstDelta support. But the code does check for the
legacy situation, and handles
I agree with all of these. Revised patch forthcoming.
-dmc
Jeremy Katz wrote:
On Mon, 2007-09-17 at 12:37 -0500, Douglas McClendon wrote:
diff -Naur livecd.3.resize2fsToMinimal_implicitsize/creator/livecd-creator
livecd.turboliveinst/creator/livecd-creator
--- livecd.3
revised patch attached. Not tested, but I've convinced myself it does
the same thing. Feel free to prune my verbose comments...
-dmc
Douglas McClendon wrote:
I agree with all of these. Revised patch forthcoming.
-dmc
Jeremy Katz wrote:
On Mon, 2007-09-17 at 12:37 -0500, Douglas
Jeremy Katz wrote:
On Mon, 2007-09-17 at 22:31 -0500, Douglas McClendon wrote:
Jeremy Katz wrote:
The danger would be loop117, as that is the one created at install time.
loop118 being locked up at initramfs time.
Not if new anaconda is used with old livecd-creator -- then loop118
Douglas McClendon wrote:
Jeremy Katz wrote:
On Mon, 2007-09-17 at 22:31 -0500, Douglas McClendon wrote:
Jeremy Katz wrote:
The danger would be loop117, as that is the one created at install
time. loop118 being locked up at initramfs time.
Not if new anaconda is used with old livecd
Douglas McClendon wrote:
Douglas McClendon wrote:
Jeremy Katz wrote:
On Mon, 2007-09-17 at 22:31 -0500, Douglas McClendon wrote:
Jeremy Katz wrote:
The danger would be loop117, as that is the one created at install
time. loop118 being locked up at initramfs time.
Not if new anaconda
Jeremy Katz wrote:
On Tue, 2007-09-18 at 15:09 -0500, Douglas McClendon wrote:
Douglas McClendon wrote:
Jeremy Katz wrote:
On Mon, 2007-09-17 at 22:31 -0500, Douglas McClendon wrote:
Jeremy Katz wrote:
The danger would be loop117, as that is the one created at install
time. loop118 being
Jeremy Katz wrote:
On Tue, 2007-09-18 at 15:48 -0500, Douglas McClendon wrote:
Jeremy Katz wrote:
Although then the other question is what to do when we're not squashed.
Do we just then want to put it on the ext3fs?
Here is the heart of something I think I mentioned that was wrong a long
time
The attached patch causes mayflower to use dynamically allocated loop
devices for the rootfs readonly-base, readwrite-overlay, squashfs, and
osmin loop devices, rather than /dev/loop118,119,120121.
udev rules were updated, and two new ones added, so that
/dev/live-osmin, /dev/live-squashed,
Jeremy Katz wrote:
On Thu, 2007-09-20 at 01:25 -0500, Douglas McClendon wrote:
Douglas McClendon wrote:
A downside, is that an F7 version of livecd-iso-to-disk would not work
with an F8 livecd. I think its worth it, but I admit it is a downside.
Though OTOH, an f7-updates version of livecd
Rahul Sundaram wrote:
Douglas McClendon wrote:
How about we split livecd-iso-to-disk into its own package,
specifically because of the use-case scenario of a user just wanting
to put their newly downloaded f8-livecd on usb, without any need or
interest in full-blown livecd-creation
Douglas McClendon wrote:
Rahul Sundaram wrote:
Douglas McClendon wrote:
How about we split livecd-iso-to-disk into its own package,
specifically because of the use-case scenario of a user just wanting
to put their newly downloaded f8-livecd on usb, without any need or
interest in full
This is the first in a series of patches that implements the livecd
filesystem layout changes I proposed in an RFC a couple days ago.
Please note, that I am not all that intent on pushing these on people if
they don't want them. But I'm intent enough that I felt like throwing a
working set
This patch makes the livecd filesystem layout match the layout that
currently gets put on liveusb via livecd-iso-to-disk. Namely,
/squashfs.img or /ext3fs.img
and /osmin.gz
get put under /LiveOS/
-dmc
diff -Naur livecd.1.remove_sysroot_from_iso/creator/isotostick.sh
This patch moves the /isolinux directory on the livecd to
/boot/isolinux, and the /syslinux directory on liveusb to /boot/syslinux.
I think that this will be make the livecd appear less intimidating to
new non-linux-guru users. Aesthetics.
Since I don't use ppc myself, I didn't attempt to
This patch prepends the fslabel that the user gives to livecd-creator,
to the filesystem image names on the livecd and liveusb.
This got a bit uglier than I had in mind at first, though possibly in a
way that has a beneficial side effect-
Currently in the liveusb case, instead of a CDLABEL
Colin Walters wrote:
On 9/20/07, Douglas McClendon [EMAIL PROTECTED] wrote:
Another benefit is making the iso directory structure look nicer and
more intuitively understandable for someone looking at it under windows.
[...]
This also
would make the usb/iso directory structure look cleaner
Jonathan Steffan wrote:
Jon Steer wrote:
I'd like to make the livecd create a little quieter and not have it print
out the block writing like below.
32539/32769 99%[===
]-
I can't seem to find where this is written? I added a quiet
The attached patch implements the solution recently discussed, to avoid
wasting 1.2M of ram during LiveOS sessions, during the non-install times
when the 1.2M of ram for the minimized filesystem overlay is not
actually needed.
This implementation involves putting osmin in its own squashfs, and
The attached patch moves the loop modprobe call in mayflower generated
init, to before the udevsettle call. Thus also removing the while-wait
loop that Jeremy wisely added to my dynamic loop device patch.
Theoretically, one could argue that the while-wait loop is still needed,
as the udevsettle
Jeremy recently committed a patch which changed the number of loop
devices created from 128 to 16. I don't know if there was some
measurable performance reason for this or not. I had always guessed
that the reason David chose such a large number originally was because
of the fact that unlike in
This patch introduces a global variable 'interactive' which is defined
as true if stdout of livecd-creator is attached to a tty. This global
is then used to add the -no-progress option to mksquashfs for
non-interactive sessions. Thus making logfiles created by redirecting
the output of
This patch increases the default size of the ram overlay from 512M to 1T.
I thought about adding an option in the same way as the prior
num_loopdevs option, but I don't think that controlling the overlay size
in this way is actually useful.
IMO the solution to controlling the ram overlay size,
Colin Walters wrote:
On 9/20/07, Douglas McClendon [EMAIL PROTECTED] wrote:
Another benefit is making the iso directory structure look nicer and
more intuitively understandable for someone looking at it under windows.
[...]
This also
would make the usb/iso directory structure look cleaner
Andrew Overholt wrote:
Hi,
For the past few days I've been unable to create a live image on my laptop.
Is there something wrong with my machine or with the way I'm invoking
livecd-creator? I'm on F7 i386 with some rawhide stuff.
$ sudo ../creator/livecd-creator --cache /tmp/fedoradevelcache
Alexandre Magaz Graça wrote:
En/na Douglas McClendon ha escrit:
This patch moves the /isolinux directory on the livecd to
/boot/isolinux, and the /syslinux directory on liveusb to /boot/syslinux.
I think that this will be make the livecd appear less intimidating to
new non-linux-guru users
rossini ro wrote:
I want to edit the .ks file and set homepage of firefox to www.google.com.
But I don't know how to.
So is there any suggestion?
For whatever reason, I believe in fedora this may be the config file you
want to change... (or at least understand)
Jeremy Katz wrote:
On Fri, 2007-09-21 at 05:27 -0500, Douglas McClendon wrote:
This patch moves the /isolinux directory on the livecd to
/boot/isolinux, and the /syslinux directory on liveusb to /boot/syslinux.
I think that this will be make the livecd appear less intimidating to
new non
Here is another update to my devicemapper-snapshot based LiveOS
persistence implementation.
Still developer quality, and nothing really changed since the last
version other than bringing it up to date with the current livecd-tools
git tree.
Other than what I mentioned in the prior posts,
Douglas McClendon wrote:
Here is another update to my devicemapper-snapshot based LiveOS
persistence implementation.
Actually... _here_ it is.
-dmc
diff -Naur livecd.200709260026/config/livecd-fedora-7-desktop.ks livecd.overlay/config/livecd-fedora-7-desktop.ks
--- livecd.200709260026/config
I may yet file a bug, if I can provide instructions on how to reproduce
this. But since I'm working from an extremely modified environment,
I'll just ask for general advice-
I've spun an selinux-enabled livecd, and upon starting up, and starting
udev, I get a whole bunch of 'errors' (perhaps
Alexandre Magaz Graça wrote:
Hi,
Since some days ago, livecd-creator is falling with this traceback
(latest git version):
Traceback (most recent call last):
File /usr/bin/livecd-creator, line 1503, in module
sys.exit(main())
File /usr/bin/livecd-creator, line 1483, in main
Tim Wood wrote:
Two different recommendations have been posted on what version of Fedora
to use (F7 presumably with livecd-tools 009 vs. rawhide and livecd-tools
from git). Rawhide and git (seems to me) to be a formula for a very
unstable development environment. But, livecd-tools 009 and F7
Tim Wood wrote:
+1
FWIW, some LiveCDs have an index.htm or index.html file in the root of
the cdrom that holds the readme and links to an html version of the GPL,
etc. Going off memory, there's an autorun dot something file in the
root of many windows cds that is used to automatically open
Rahul Sundaram wrote:
Hi
Would it be possible to add a boot option in the live images to directly
invoke either the graphical or console installer.
I don't see why not.
And of course at the same time, parse and use ks= from the cmdline if
present.
-dmc
Very useful for low resource
offset wrote:
Newbie alert :)
Looking to get up-to-speed on Fedora LiveCD so I can custom build my own
security tools that I can boot from cd, rather than lug around my laptop
everywhere. I did see the Security fedora livecd wiki, so I'll have to poke
around there as well.
I'm getting the
1 - 100 of 157 matches
Mail list logo
