Config file format proposal
by Darko Ilic
Here`s my livecd config file format proposal.
We`ve been talking about reusing kickstart file format, but I found
out that it`s not so good solution. Kickstart file doesn`t include
complete list of packages but keeps only list of groups to be included
and relies on comps.xml file and definitions of group members. Since
it`s very important for config files to be compatibile with different
versions of FC, we have to have the complete list of packages in our
config file (for example, some 100MB big package could be added to
some group we included, and the size of our livecd iso image would
change dramaticly without a reason). Again, for compatibility reasons,
we have to keep the list of packages _without_ version numbers
inluded.
Many repositories can be listed in config file, but only one (named
"default") is essential. URL parameter for repositories is read from
conf file by default, but can be overriden with command line parameter
(for example: buildlivecd -f ./fc4livecd.conf -r
default=http://bla.bla/fedora/core/4 ).
I think that layout used in this example that I`m sending is not the
best choise, and the reason I used it is to describe the hierarchy of
the file. So, please, propose some file layout that could have similar
structure but that can be easily parsed by both python application
that is supposed to generate it and bash script that is supposed to
read information from it. And, yes, feel free to post your comments :)
Darko
18 years, 9 months
Article for fedoranews.org ...
by Dirk Westfal
Hi gentlemen,
Thomas Chung of fedoranews.org asked me to write an article about how to
create a fedora core 4 based livecd.
Since a short tutorial/some kind of proper design document was overdue, i
agreed.
The article describes the concept i currently use as well as the buildprocess
(using a free harddisk partition - everything else seemed to dangerous ...
don`t want to be responsible for a hosed buildsystem because of some package
relocations running wild ...)
For the article i`ve also recreated a basic set of (unsigned) rpms and moved
all modifications that are made to the system to per-package
install/uninstall.sh scripts as well as improving the integration into the
fedora core init process.
I`ve also included a reference to the fedora livecd project.
URL: http://fedoranews.org/mediawiki/index.php/Creating_a_Fedora_Core_4_livecd
hoping not having done something inappropiate,
Dirk
--
Dirk Westfal /Admin/RHCE/QAR
Frankfurter Verein / Edv Abteilung / Netzwerkverwaltung
Fon: + 49 69 79405 447 Fax: + 49 69 79405 301 Mobile: 0172 61 989 51
'Protego et servio'
18 years, 10 months
wiki page updated
by Darko Ilic
OK people,
I`ve just updated http://fedoraproject.org/wiki/LiveCD page. Please take a
look and suggest modifications. And also please point out any obvious
language mistakes, cause I'm not a native english speaker.
Config file proposal comming soon!
Darko Ilic
18 years, 10 months
Moving forward with Fedora LiveCD
by Greg DeKoenigsberg
So there's been a fair bit of email back and forth, but nothing's really
"caught" yet, it seems. So let me sum up where I think we are:
We've got a handful of people with code. Here's the summary, as I see it:
a. Rookery, by Steve Grubb. Intended for building distros in general,
but also has a tool for building a LiveCD in particular.
b. Stateless Linux plus mklivecd, by Alex Larsson. Falls out of the
Stateless Linux work that Red Hat R&D was doing, but is now in
stasis, I believe.
c. ADIOS, by Neville Richter.
So I think it's time to pick at least one of these platforms and "get a
move on". Unless I hear MASSIVE DISAGREEMENT :) here's the way I'd like
to proceed:
1. GET CODE INTO CVS. If you want your solution to be considered, ack the
list, and we'll make sure that you've got a place to put your code. I'll
work with Elliott (guru of Fedora CVS) to make sure that we have modules
in CVS for all of this code.
2. WEEKLY MEETING. A mailing list is good, but it's not very high
bandwidth, and when we need to debate about something, IRC is much
quicker. Therefore, I propose:
a. DATE/TIME. Always hard to get global meeting times that work for
all. I've seen the most traffic from US and Australia, so I propose
as the first meeting time:
THURSDAY JULY 7, 23:00 GMT. Which is:
THURSDAY JULY 7, 19:00 Eastern US. Which is:
FRIDAY JULY 8, 09:00 Eastern Australia.
b. VENUE. #fedora-livecd on freenode.
c. FREQUENCY. Weekly or bi-weekly, depending -- but for now, let's
just have the first one first and see how it goes. :)
3. WIKI. We've got wiki space available to us on fedoraproject.org. When
the time comes, we'll need something, and this wiki is being well-used for
the Extras and Docs projects.
--g
_____________________ ____________________________________________
Greg DeKoenigsberg ] [ the future masters of technology will have
Community Relations ] [ to be lighthearted and intelligent. the
Red Hat ] [ machine easily masters the grim and the
] [ dumb. --mcluhan
18 years, 10 months
Re: Q: Should the CD automatically look at floppy, usb or hdd for saved session/override data?
by Dirk Westfal
Hi,
On Saturday 16 July 2005 13:51, you wrote:
> Am Samstag, den 16.07.2005, 19:47 +0200 schrieb Thorsten Leemhuis:
..
> > > >Q: Should the CD automatically look at floppy, usb or hdd for saved
> > > session/override data?
> > > Imho: yes - one of the functions most requested by my users: if a usb
> > > device with an file like 'livecd-<usrname>' is present, it should be
> > > extracted just after login in. (and revers on logoff)
> >
> > This should be a config *and* runtime-option. If someone wants to ship a
> > Knoppix like Rescue-CD/DVD based on Fedora you don't want it to touch
> > all filesystems. It could do damage to those (even if it is mounted ro
> > only -- there *could* be a old 'livecd-<usrname>' file that was
> > forgotten)
Ack.
My livecd systems never ever touch a harddisk by themself .... :)
That`s the 'big red line' to step over ... and why i specifically wrote 'usb
device' which is more like a floppy (well, there might be a prob with
external usb-hdd`s, but luckily those aren`t that common ...)
Access to harddisk should never be enabled by default - autodetection/usage of
usb storage: well - this seemed to be a decent way to allow auto-save/restore
while minimizing the risk of corrupting user data.
The problem with old/obsolete profiles isn`t easely solveable - but if it`s
read from a ro-mounted media, this shouldn`t be much of a problem.
At least distinguishing between different livecd versions could be done using
a 'track' file.
A combination of bootprompt argument, sysv service (toggled by config option
set at buildtime) and an icon (for the gui version) seems to be ideal,
perhaps with also 'tagging' the storage device as profile/session media.
> Private followup to myself:
>
> Wir hatten angeblich (sagte mir ein Kollege) mit einem Knoppix in der
> c't mal ein paar solche Fälle, wo Knoppix ungewollt Dateisysteme
> mountete, die eigentlich gerade repariert werden sollten. Das hat dann
> wohl die schon bestehenden Probleme mit dem Dateisystem noch
> verschlimmert...
Yupp - habe aehnliches gehoert.
Das ist so eine Knoppixangewohnheit die ich absolut nicht leiden kann: alles
mounten was bei drei nicht auf den Baeumen ist UND auch gleich noch ein
Swapfile anlegen.
Die Festplatte eines Anwenders darf man nur dann anfassen, wenn dieser es
ausdruecklich wuenscht und eigenhaendig anfordert.
Einen Usbstoepsel kann der Anwender erheblich besser kontrollieren.
Alles andere ist gefaehrlich (und imho ziemlich unanstaendig).
Dirk
18 years, 10 months