[PATCH 6/6] Several Kernels
by Jeroen van Meeuwen
A patch which allows multiple kernels to be installed on the live media,
giving boot options in the syslinux menu for all of them.
In addition, this patch adds an optional timeout parameter for the boot
menu. It also adds a cli parameter for appending boot options.
Kind regards,
Jeroen van Meeuwen
-kanarip
14 years, 1 month
[PATCH 5/6] Optionally prevent killing application
by Jeroen van Meeuwen
A patch to prevent livecd-creator from also killing the application that
is build on top of livecd-tools, while not changing the default behaviour.
Kind regards,
Jeroen van Meeuwen
-kanarip
14 years, 1 month
[PATCH 2/6] Setting the install_root
by Jeroen van Meeuwen
A patch to enable changing the install_root from default.
This enables other applications using livecd-creator as a backend
application, while already having initialized a yum object configured
with a certain installroot (which once the yum object is initialized,
cannot be changed). Matching the build environment to what
livecd-creator expects results in trouble with other builds running
(eg., symlinking the actual yum installroot to "%s/install_root" %
self.build_dir).
We have not found loop-mounting the ext3 filesystem to be a problem.
Kind regards,
Jeroen van Meeuwen
-kanarip
14 years, 1 month
[PATCH 4/6] Translation
by Jeroen van Meeuwen
A patch which is enabling translation in the python code, but is not
including that what builds livecd-tools or it's RPMs.
If you have a clue about what else I would need to patch to fully enable
translation, please let me know because I don't have the slightest idea
at this moment.
Kind regards,
Jeroen van Meeuwen
-kanarip
14 years, 1 month
Re: LiveCD wiping root partition?
by Douglas McClendon
Michel Salim wrote:
> On 01/08/07, Douglas McClendon <dmc.fedora(a)filteredperception.org> wrote:
>> Rahul Sundaram wrote:
>>> Michel Salim wrote:
>>>
>>>> Anyway, hard lesson learned. I wonder how Ubuntu does their live CD
>>>> install. openSUSE is introducing one too, hopefully for their users
>>>> the same bug does not occur.
>>> Pretty much every live cd does a dd afaik.
>> ubuntu 7.04 keeps their rootfs natively on squashfs (versus fedora which
>> keeps
>> it natively on an ext3 image which lives on a squashfs).
>>
>> Therefore they can't be doing a dd for the install.
>
>
> Any reason why dd is preferred over, say, tar? The latter would be much
> safer. And files would not have to be moved to their final partitions after
> 'dd' too.
seeking (cdrom and disk). Lots slower (5X?). I suspect that file level copy
(tar) will be the long term answer for the flexible general case. Though I also
suspect the much faster dd will be part of the long term answer as well for the
typical case (i.e. formatting / as ext3, and no separate /usr).
For example, on my system, using the existing 4.0G dd, the copy takes 299s.
Using my turboLiveInst patch, I can shave that down to 250s. Using tar however
to copy the 85896 files, took 1247s. And you also need to throw in another 30s
or so for the format that isn't required in the dd case. Maybe(??) there is
some more efficient way to copy those 85K files than the ( tar cpsf - | tar xpsf
- ) that I used for that trial.
Lastly safety has nothing to do with the tar vs dd issue. The safety issue had
to do with the bug of the user interface not accurately reflecting what was
happening. fyi, I did go ahead and file the bug, and even submit a patch which
might fix it.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250301
That doesn't mean of course that you don't have every right and justification to
be cursing the bits of the F7 livecd while watching it spark in a microwave.
-dmc
14 years, 1 month
RFE- kickstart and package selection support for livecd installs
by Douglas McClendon
After having fully grokked the livecd-creator code, it occurs to me that it may
not be such a completely crazy idea to bring full package selection and even
kickstart support to the livecd installer.
The main constraint of course is having access to the 'core' or full repo,
either via network or existing disk filesystem.
The key aspect of feasibility I see, is how similar the task would be to the
existing livecd-creator base-on-iso code path. I.e. that code path already
takes as input, a livecd type installation, and then effectively applies a
kickstart configuration to it.
If similar code were in anaconda, it could act on the on-disk installed system
after the normal liveinst/anaconda-livecd-backend installation.
Just a thought... Probably more for F9 timeframe...
-dmc
14 years, 1 month
LiveUSB to LiveUSB with F7?
by C S
All references I can find for spinning have a running
host(with rpm, yum, etc) as a requirement to build
live's upon. But is it possible to have
livecd-creator spin a new CD off of F7's Live itself?
I assume Revisor would only build upon this.
Being a newbie I didn't know if it's in the design,
plan or not possible at all...
cs
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545433
14 years, 1 month
[PATCH] Run post after having configured the network
by Jeroen van Meeuwen
As proposed earlier, a patch to run %post only after configureNetwork()
has run because %post network configuration may override
configureNetwork() configuration, but vice-versa just seems wrong as you
cannot do everything with kickstart network configuration directives.
Thanks to Mads Kiilerich for pointing this out.
Kind regards,
Jeroen van Meeuwen
-kanarip
14 years, 1 month
