April 2007 - livecd - Fedora Mailing-Lists

liveinst/anaconda crashes after setting root password

by Sebastian Vahl

Hi. An actual spin of kde-livecd crashes after setting root password. Log is attached. Versions: - anaconda-11.2.0.42-1 (inserted " --interface org.freedesktop.Hal.Device.Storage" manually in /usr/sbin/liveinst) - livecd-creator from git (checkout from today and patched to mount bindmounts) Wanted to post this here first before creating a bug. Am I missing something or is this really a bug that should be filled? Sebastian

17 years

2
4
0 / 0

Live USB converter script

by Jeremy Katz

When thinking about what we want for booting a live image with a USB stick, I realized that realistically, we don't want to be distributing a "live USB" image. Because that requires running dd and destroying whatever data you already happen to have on your USB stick. A better choice is to take the live CD image and copy the bits from it to your USB stick. The result is the attached script. Run it with arguments of the live CD iso image and the device of your USB key and it copies over the bits of the live CD onto your USB stick and makes it bootable. Supported filesystems for your USB stick are vfat/msdos and ext23. What do people think? It seems to work from some quick testing and it's impressive just how much faster it is going from a USB stick. Jeremy

17 years

9
18
0 / 0

Space savings discussed on fedora-packaging-list

by Thorsten Leemhuis

Hi, below discussion from Fedora Packaging FYI, in case the space saving discussed there are of interest for you. Original thread starts at: https://www.redhat.com/archives/fedora-packaging/2007-April/msg00003.html CU thl ------- Original-Nachricht -------- Betreff: [Fedora-packaging] Hardlinking *.pyc and *.pyo Datum: Tue, 3 Apr 2007 13:42:24 +0300 Von: Ville Skyttä <ville.skytta(a)iki.fi> Antwort an: Discussion of RPM packaging standards and practices for Fedora Extras <fedora-packaging(a)redhat.com> An: fedora-packaging Mailing List <fedora-packaging(a)redhat.com> Hello, Related to recent space saving discussions, I came across PLD's rpm-build-macros package recently, and found that they hardlink identical *.pyc and *.pyo. In a lot of cases, they're the same, and there's some potential for saving some MB "for free", on my FC6 x86_64 box: $ /usr/sbin/hardlink -ncv /usr/lib*/python2.4 2>&1 | tail -n 1 Would save 11116544 The PLD implementation looks like this: # Hardlink binary identical .pyc and .pyo files # (idea by glen <at> pld-linux <dot> org) %__spec_install_post_py_hardlink {\ %{!?no_install_post_py_hardlink: __spec_install_post_py_hardlink() { \ [ ! -d "$RPM_BUILD_ROOT" ] || find "$RPM_BUILD_ROOT" -name '*.pyc' | while read a; do \ b="$(echo $a|sed -e 's/.pyc$/.pyo/')"; \ if cmp -s "$a" "$b"; then \ ln -f "$a" "$b"; \ fi; \ done \ }; __spec_install_post_py_hardlink } } The use of "cmp" would require diffutils installed. Or the above could be converted to use hardlink instead (which would have to be made sure to be around) or maybe sha1sum (in coreutils, pretty much always around in buildroots). I suppose something like the above could be easily added to redhat-rpm-config or rpm, eg. embedded in brp-python-bytecompile or run after it in %__os_install_post. Worth it? Other comments? -------- Original-Nachricht -------- Return-Path: <Thorsten_Leemhuis(a)gmx.de> X-Original-To: rpmbuild@localhost Delivered-To: rpmbuild(a)localhost.thl.home Received: by truhe.thl.home (Postfix, from userid 500) id 67F1B8110; Tue, 3 Apr 2007 13:24:27 +0200 (CEST) X-Original-To: thl@localhost Delivered-To: thl(a)localhost.thl.home Received: from truhe.thl.home (localhost [127.0.0.1]) by truhe.thl.home (Postfix) with ESMTP id 510D280AD for <thl@localhost>; Tue, 3 Apr 2007 13:24:27 +0200 (CEST) X-Original-To: fedora(a)leemhuis.info Delivered-To: web550p1(a)basicbox7.server-home.net Received: from leemhuis.info [195.137.212.29] by truhe.thl.home with POP3 (fetchmail-6.3.6) for <thl@localhost> (single-drop); Tue, 03 Apr 2007 13:24:27 +0200 (CEST) Received: from hormel.redhat.com (hormel.redhat.com [209.132.177.30]) by basicbox7.server-home.net (Postfix) with ESMTP id 1B0C63741D9 for <fedora(a)leemhuis.info>; Tue, 3 Apr 2007 13:17:29 +0200 (CEST) Received: from listman.util.phx.redhat.com (listman.util.phx.redhat.com [10.8.4.110]) by hormel.redhat.com (Postfix) with ESMTP id B188E72E40; Tue, 3 Apr 2007 07:17:30 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id l33BHSHq025579 for <fedora-packaging(a)listman.util.phx.redhat.com>; Tue, 3 Apr 2007 07:17:28 -0400 Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l33BHSBL023395 for <fedora-packaging(a)redhat.com>; Tue, 3 Apr 2007 07:17:28 -0400 Received: from TZMXR01.htp-tel.de (tzmxr01.htp-tel.de [81.14.243.17]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l33BHM8I029053 for <fedora-packaging(a)redhat.com>; Tue, 3 Apr 2007 07:17:23 -0400 Received: from TZMXR01.htp-tel.de (localhost [127.0.0.1]) by TZMXR01.htp-tel.de with ESMTP id l33BHGYK029546 for <fedora-packaging(a)redhat.com>; Tue, 3 Apr 2007 13:17:16 +0200 (CEST) Received: from truhe.thl.home (a81-14-184-169.net-htp.de [81.14.184.169]) by TZMXR01.htp-tel.de with ESMTP id l33BHF0E029531 for <fedora-packaging(a)redhat.com>; Tue, 3 Apr 2007 13:17:16 +0200 (CEST) Received: from thl.ct.heise.de (localhost [127.0.0.1]) by truhe.thl.home (Postfix) with ESMTP id 70DC580AD for <fedora-packaging(a)redhat.com>; Tue, 3 Apr 2007 13:17:15 +0200 (CEST) Message-ID: <461237BB.5050700(a)leemhuis.info> Date: Tue, 03 Apr 2007 13:17:15 +0200 From: Thorsten Leemhuis <fedora(a)leemhuis.info> User-Agent: Thunderbird 2.0b2 (X11/20070308) MIME-Version: 1.0 To: Discussion of RPM packaging standards and practices for Fedora Extras <fedora-packaging(a)redhat.com> Subject: Re: [Fedora-packaging] Hardlinking *.pyc and *.pyo References: <200704031342.25238.ville.skytta(a)iki.fi> In-Reply-To: <200704031342.25238.ville.skytta(a)iki.fi> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-RedHat-Spam-Score: 0 X-loop: fedora-packaging(a)redhat.com X-BeenThere: fedora-packaging(a)redhat.com X-Mailman-Version: 2.1.5 Precedence: junk Reply-To: Discussion of RPM packaging standards and practices for Fedora Extras <fedora-packaging(a)redhat.com> List-Id: Discussion of RPM packaging standards and practices for Fedora Extras <fedora-packaging.redhat.com> List-Unsubscribe: <https://www.redhat.com/mailman/listinfo/fedora-packaging>, <mailto:fedora-packaging-request@redhat.com?subject=unsubscribe> List-Archive: <https://www.redhat.com/archives/fedora-packaging> List-Post: <mailto:fedora-packaging@redhat.com> List-Help: <mailto:fedora-packaging-request@redhat.com?subject=help> List-Subscribe: <https://www.redhat.com/mailman/listinfo/fedora-packaging>, <mailto:fedora-packaging-request@redhat.com?subject=subscribe> Sender: fedora-packaging-bounces(a)redhat.com Errors-To: fedora-packaging-bounces(a)redhat.com X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on basicbox7.server-home.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL autolearn=disabled version=3.0.3 X-UIDL: dg:!!WW-!!BIp"!23Y"! On 03.04.2007 12:42, Ville Skyttä wrote: > Worth it? Other comments? Hehe, sounds interesting. Did you tell the Live-CD guys about it? I'd say they will probably very interested in something like this (they could run hardlink directly for now until we decide what we want to do). CU thl -------- Original-Nachricht -------- Return-Path: <Thorsten_Leemhuis(a)gmx.de> X-Original-To: rpmbuild@localhost Delivered-To: rpmbuild(a)localhost.thl.home Received: by truhe.thl.home (Postfix, from userid 500) id DB9EB8110; Tue, 3 Apr 2007 13:54:57 +0200 (CEST) X-Original-To: thl@localhost Delivered-To: thl(a)localhost.thl.home Received: from truhe.thl.home (localhost [127.0.0.1]) by truhe.thl.home (Postfix) with ESMTP id C928480AD for <thl@localhost>; Tue, 3 Apr 2007 13:54:57 +0200 (CEST) X-Original-To: fedora(a)leemhuis.info Delivered-To: web550p1(a)basicbox7.server-home.net Received: from leemhuis.info [195.137.212.29] by truhe.thl.home with POP3 (fetchmail-6.3.6) for <thl@localhost> (single-drop); Tue, 03 Apr 2007 13:54:57 +0200 (CEST) Received: from hormel.redhat.com (hormel.redhat.com [209.132.177.30]) by basicbox7.server-home.net (Postfix) with ESMTP id 1EF8C374D37 for <fedora(a)leemhuis.info>; Tue, 3 Apr 2007 13:45:41 +0200 (CEST) Received: from listman.util.phx.redhat.com (listman.util.phx.redhat.com [10.8.4.110]) by hormel.redhat.com (Postfix) with ESMTP id AAF3D73009; Tue, 3 Apr 2007 07:45:42 -0400 (EDT) Received: from int-mx2.corp.redhat.com (nat-pool.util.phx.redhat.com [10.8.5.200]) by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id l33Bjfnb029939 for <fedora-packaging(a)listman.util.phx.redhat.com>; Tue, 3 Apr 2007 07:45:41 -0400 Received: from mx2.redhat.com (mx2.redhat.com [10.255.15.25]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l33Bje9H030402 for <fedora-packaging(a)redhat.com>; Tue, 3 Apr 2007 07:45:40 -0400 Received: from smtp5.pp.htv.fi (smtp5.pp.htv.fi [213.243.153.39]) by mx2.redhat.com (8.13.1/8.13.1) with ESMTP id l33BjcSD019557 for <fedora-packaging(a)redhat.com>; Tue, 3 Apr 2007 07:45:39 -0400 Received: from viper.localdomain (cs181043142.pp.htv.fi [82.181.43.142]) by smtp5.pp.htv.fi (Postfix) with ESMTP id B4D425BC1E9 for <fedora-packaging(a)redhat.com>; Tue, 3 Apr 2007 14:45:37 +0300 (EEST) From: Ville Skyttä <ville.skytta(a)iki.fi> To: Discussion of RPM packaging standards and practices for Fedora Extras <fedora-packaging(a)redhat.com> Subject: Re: [Fedora-packaging] Hardlinking *.pyc and *.pyo Date: Tue, 3 Apr 2007 14:45:37 +0300 User-Agent: KMail/1.9.6 References: <200704031342.25238.ville.skytta(a)iki.fi> <461237BB.5050700(a)leemhuis.info> In-Reply-To: <461237BB.5050700(a)leemhuis.info> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200704031445.37318.ville.skytta(a)iki.fi> X-RedHat-Spam-Score: 0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by listman.util.phx.redhat.com id l33Bjfnb029939 X-loop: fedora-packaging(a)redhat.com X-BeenThere: fedora-packaging(a)redhat.com X-Mailman-Version: 2.1.5 Precedence: junk Reply-To: Discussion of RPM packaging standards and practices for Fedora Extras <fedora-packaging(a)redhat.com> List-Id: Discussion of RPM packaging standards and practices for Fedora Extras <fedora-packaging.redhat.com> List-Unsubscribe: <https://www.redhat.com/mailman/listinfo/fedora-packaging>, <mailto:fedora-packaging-request@redhat.com?subject=unsubscribe> List-Archive: <https://www.redhat.com/archives/fedora-packaging> List-Post: <mailto:fedora-packaging@redhat.com> List-Help: <mailto:fedora-packaging-request@redhat.com?subject=help> List-Subscribe: <https://www.redhat.com/mailman/listinfo/fedora-packaging>, <mailto:fedora-packaging-request@redhat.com?subject=subscribe> Sender: fedora-packaging-bounces(a)redhat.com Errors-To: fedora-packaging-bounces(a)redhat.com X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on basicbox7.server-home.net X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL autolearn=disabled version=3.0.3 X-UIDL: GSK"!`f=!!:Wi"!p1+"! On Tuesday 03 April 2007, Thorsten Leemhuis wrote: > On 03.04.2007 12:42, Ville Skyttä wrote: > > Worth it? Other comments? > > Hehe, sounds interesting. Did you tell the Live-CD guys about it? I'd > say they will probably very interested in something like this (they > could run hardlink directly for now until we decide what we want to do). Nope, just brought it up in last week's packaging meeting and now posted here. Feel free to forward. Another thing they could be interested in (again on my FC6 x86_64): $ /usr/sbin/hardlink -ncv /usr/share/doc 2>&1 | tail -n 1 Would save 6692864 (of which COPYING's share is about 3.2M) -------- Original-Nachricht -------- Return-Path: <Thorsten_Leemhuis(a)gmx.de> X-Original-To: rpmbuild@localhost Delivered-To: rpmbuild(a)localhost.thl.home Received: by truhe.thl.home (Postfix, from userid 500) id EF7088117; Tue, 3 Apr 2007 14:05:05 +0200 (CEST) X-Original-To: thl@localhost Delivered-To: thl(a)localhost.thl.home Received: from truhe.thl.home (localhost [127.0.0.1]) by truhe.thl.home (Postfix) with ESMTP id D99CE80DE for <thl@localhost>; Tue, 3 Apr 2007 14:05:05 +0200 (CEST) X-Original-To: fedora(a)leemhuis.info Delivered-To: web550p1(a)basicbox7.server-home.net Received: from leemhuis.info [195.137.212.29] by truhe.thl.home with POP3 (fetchmail-6.3.6) for <thl@localhost> (single-drop); Tue, 03 Apr 2007 14:05:05 +0200 (CEST) Received: from hormel.redhat.com (hormel.redhat.com [209.132.177.30]) by basicbox7.server-home.net (Postfix) with ESMTP id BE818374D4B for <fedora(a)leemhuis.info>; Tue, 3 Apr 2007 14:01:32 +0200 (CEST) Received: from listman.util.phx.redhat.com (listman.util.phx.redhat.com [10.8.4.110]) by hormel.redhat.com (Postfix) with ESMTP id 93CE072FB4; Tue, 3 Apr 2007 08:01:33 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id l33C1VoW032671 for <fedora-packaging(a)listman.util.phx.redhat.com>; Tue, 3 Apr 2007 08:01:32 -0400 Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l33C1UEY004042 for <fedora-packaging(a)redhat.com>; Tue, 3 Apr 2007 08:01:30 -0400 Received: from junior.physik.fu-berlin.de (IDENT:U2FsdGVkX184gQ/KwtoT7+xBQgH3zjb63w3ZGzlWGD4@junior.physik.fu-berlin.de [130.133.35.30]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l33C1RN5026158 for <fedora-packaging(a)redhat.com>; Tue, 3 Apr 2007 08:01:27 -0400 Received: from neu-vpn.physik.fu-berlin.de ([160.45.32.209] helo=neu.nirvana) by mail2.atrpms.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.66) id 1HYhhE-0001uV-06; Tue, 03 Apr 2007 14:01:25 +0200 Received: from thimm by neu.nirvana with local (Exim 4.66) (envelope-from <Axel.Thimm(a)ATrpms.net>) id 1HYhhC-0001x3-TQ; Tue, 03 Apr 2007 14:01:06 +0200 Date: Tue, 3 Apr 2007 14:01:06 +0200 From: Axel Thimm <Axel.Thimm(a)ATrpms.net> To: Discussion of RPM packaging standards and practices for Fedora Extras <fedora-packaging(a)redhat.com> Message-ID: <20070403120106.GD29856(a)neu.nirvana> References: <200704031342.25238.ville.skytta(a)iki.fi> MIME-Version: 1.0 In-Reply-To: <200704031342.25238.ville.skytta(a)iki.fi> User-Agent: Mutt/1.5.13 (2006-08-11) X-Scanned: No viruses found. X-Scan-Signature: fe522d7d72b3ce68d16a3279c0f8f490 X-RedHat-Spam-Score: 0 X-loop: fedora-packaging(a)redhat.com Subject: [Fedora-packaging] Re: Hardlinking *.pyc and *.pyo X-BeenThere: fedora-packaging(a)redhat.com X-Mailman-Version: 2.1.5 Precedence: junk Reply-To: Discussion of RPM packaging standards and practices for Fedora Extras <fedora-packaging(a)redhat.com> List-Id: Discussion of RPM packaging standards and practices for Fedora Extras <fedora-packaging.redhat.com> List-Unsubscribe: <https://www.redhat.com/mailman/listinfo/fedora-packaging>, <mailto:fedora-packaging-request@redhat.com?subject=unsubscribe> List-Archive: <https://www.redhat.com/archives/fedora-packaging> List-Post: <mailto:fedora-packaging@redhat.com> List-Help: <mailto:fedora-packaging-request@redhat.com?subject=help> List-Subscribe: <https://www.redhat.com/mailman/listinfo/fedora-packaging>, <mailto:fedora-packaging-request@redhat.com?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1626666452==" Sender: fedora-packaging-bounces(a)redhat.com Errors-To: fedora-packaging-bounces(a)redhat.com X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on basicbox7.server-home.net X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL autolearn=disabled version=3.0.3 X-UIDL: ff="!/9`"!@MP!!34]!! On Tue, Apr 03, 2007 at 01:42:24PM +0300, Ville Skyttä wrote: > Related to recent space saving discussions, I came across PLD's > rpm-build-macros package recently, and found that they hardlink > identical *.pyc and *.pyo. In a lot of cases, they're the same, > and there's some potential for saving some MB "for free", > on my FC6 x86_64 box: > > $ /usr/sbin/hardlink -ncv /usr/lib*/python2.4 2>&1 | tail -n 1 > Would save 11116544 I get more than twice as much on a typical FC6/x86_64 system: 27275264. That's 26 MB on 166MB total, e.g. saving 16%. # du -sc /usr/lib*/python2.4| tail -n 1 170200 total On another system I get 21MB of 144MB total, e.g about 15%. > The PLD implementation looks like this: > > # Hardlink binary identical .pyc and .pyo files > # (idea by glen <at> pld-linux <dot> org) > %__spec_install_post_py_hardlink {\ > %{!?no_install_post_py_hardlink: __spec_install_post_py_hardlink() { \ > [ ! -d "$RPM_BUILD_ROOT" ] || find "$RPM_BUILD_ROOT" -name '*.pyc' | while read a; do \ > b="$(echo $a|sed -e 's/.pyc$/.pyo/')"; \ > if cmp -s "$a" "$b"; then \ > ln -f "$a" "$b"; \ > fi; \ > done \ > }; __spec_install_post_py_hardlink } } > > The use of "cmp" would require diffutils installed. Or the above > could be converted to use hardlink instead (which would have to be made > sure to be around) or maybe sha1sum (in coreutils, pretty much always > around in buildroots). > > I suppose something like the above could be easily added to > redhat-rpm-config or rpm, eg. embedded in brp-python-bytecompile > or run after it in %__os_install_post. brp-python-bytecompile sounds like the best spot since the pyc/pyos are created there. Maybe we should ship an improved brp-python-bytecompile in redhat-rpm-config while lobbying rpm upstream to adopt it? > Worth it? Other comments? A 15% space gain (under python) w/o any drawbacks? Always worth it. :)

17 years

2
1
0 / 0

bindmounts not mounted

by Alexandre Magaz Graça

Hi, I've been trying to build a live cd with the last pilgrim version (git) and it seems that bindmounts doesn't get mounted. This is the output I get at the package installing stage: [...] Installing: gnome-panel ##################### [426/620] /proc is empty (not mounted ?) Installing: rpm ##################### [427/620] Installing: gnome-python2-gconf ##################### [428/620] Installing: gnome-python2-desktop ##################### [429/620] Installing: tomcat5-servlet-2.4-api ##################### [430/620] GC Warning: Couldn't read /proc/stat GC Warning: GC_get_nprocs() returned -1 dirname: missing operand [...] This patch solved the problem: diff --git a/creator/livecd-creator b/creator/livecd-creator index 9a00946..7eac113 100755 --- a/creator/livecd-creator +++ b/creator/livecd-creator @@ -409,6 +409,9 @@ class InstallationTarget: (self.build_dir + "/yum-cache", "/var/cache/yum")]: self.bindmounts.append(BindChrootMount(f, self.build_dir + "/install_root", dest)) + for b in self.bindmounts: + b.mount() + # make sure /etc/mtab is current inside install_root os.symlink("../proc/mounts", self.build_dir + "/install_root/etc/mtab") Cheers, Alex

17 years

3
2
0 / 0

Re: [Fedora-livecd-list] [patch 00/20] Fix error handling and misc. cleanups

by David Zeuthen

Hey Mark, Sorry for the lag - been busy trying to get a new HAL release out, On Tue, 2007-03-27 at 15:14 +0100, Mark McLoughlin wrote: > Hi, > Apologies for spamming the list with 20 mails, but hopefully > it'll make it easier to review the patches. Yeah, it did make it easier although I'm always slighty scared when seeing a bunch of patches ;-) - would you happen to have a git repo handy that I can pull from? > The background to this is that I was suprised to see that > livecd-creator had rather poor error handling (e.g. not unmounting > stuff after certain errors, obscure error messages etc.) since > I thought that was the main reason to re-write pilgrim in python :-) > > It's understandable, though. Because Python has exceptions, > it's easy to be fooled into thinking you have error conditions > under control, but in reality, exceptions probably makes it easier > to screw up error handling. > > So, here's an attempt to fix it based on the following > guidelines: > > - don't intercept an exception if you can't do something useful > with it. Corollary: intercept an exception if you can do something > useful with it. > > - anticipate user errors or user-fixable system errors in a user > friendly manner. Corollary: allow other types of exceptions > to be passed to the toplevel. > > - i.e. there are 3 types of errors/exceptions, and 3 different > strategies for handling them: > > 1) errors which we can handle ourselves without ever telling > the user - e.g. a directory which we wish to create already > exists > > 2) user errors, or predictable system errors, which we > should do our best to help the user out with - e.g. > a busted kickstart file or running out of loop devices > > 3) pathological system errors or programmer errors, all > of which can be just allowed to propogate up to the > toplevel where an ugly traceback will be printed - > e.g creating a dir under the temporary build dir > fails or an unmount fails because we didn't close > the rpmdb > > - whatever the error, we should do our best to clean up files, > directories, mounts, etc. which we created > > - bear in mind that e.g. Ctrl-C can happen at any time > > Also, I've cleanup up various parts of the code as I > worked on the error handling. Those patches come first. This is really good stuff, thanks a bunch for working on it. I just read through all the patches and from a cursory look they look good to me; tomorrow I'm going to try and actually apply them to the code [1]. I'd also like for Jeremy to sign them off as he was the last one before you to fix up my, uh, rough bash->python conversion of the pilgrim shell script plus he's the main guy working on this stuff these days. Thanks again, Cheers, David [1] : As a practical thing would you happen to have a git repo stashed somewhere that I can pull form?

17 years

4
3
0 / 0

[PATCH] Add support for prelinking the system

by Jeremy Katz

prelink the system after packages are installed. This should lead to some speed-ups at runtime. Allow skipping prelink by passing --no-prelink --- creator/livecd-creator | 16 +++++++++++++++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/creator/livecd-creator b/creator/livecd-creator index c7232e0..84a8f67 100755 --- a/creator/livecd-creator +++ b/creator/livecd-creator @@ -601,6 +601,14 @@ class InstallationTarget: preexec_fn=self.run_in_root) return True + def prelinkSystem(self): + # prelink the system + instroot = "%s/install_root" %(self.build_dir,) + if os.path.exists("%s/usr/sbin/prelink" %(instroot,)): + subprocess.call(["/usr/sbin/prelink", "-mRavN"], + preexec_fn=self.run_in_root) + return True + def launchShell(self): print "Launching shell. Exit to continue." print "----------------------------------" @@ -737,6 +745,7 @@ def main(): base_on = None kscfg = None skip_compression = False + skip_prelink = False uncompressed_size = 3072 give_shell = False @@ -745,7 +754,7 @@ def main(): ["help", "repo=", "base-on=", "package=", "exclude-package=", "fslabel=", "config=", "skip-compression", "uncompressed-size=", - "shell"]) + "shell", "no-prelink"]) except getopt.GetoptError: usage() sys.exit(2) @@ -761,6 +770,9 @@ def main(): if o in ("-s", "--skip-compression"): skip_compression = True continue + if o in ("--no-prelink",): + skip_prelink = True + continue if o in ("-u", "--uncompressed-size"): uncompressed_size = int(a) continue @@ -842,6 +854,8 @@ def main(): sys.exit(1) target.configureSystem(ksparser) target.createInitramfs() + if not skip_prelink: + target.prelinkSystem() if ksparser.handler.selinux.selinux: target.relabelSystem() target.configureBootloader() -- 1.5.0.5

17 years

2
2
0 / 0

boot speed optomization (Qs for DZ mainly)

by Jane Dogalt

David, I just read the historic readahead post you referenced. I haven't really spent any effort thinking about massaging readahead into a boot speed optomization for a livecd (I'm guessing you have?). But it happens to be very similar to the 'early boot file seperation' methods I've described here relating to livecds. I have a couple questions about your 2004 post- " I've made the following observations 1. The kernel patch, linux-2.6.3-printopen.patch, wasn't really working well for me - it reported far to few files - instead I added a printk() to fs/namei.c:link_path_walk() (disclaimer: I don't know much about the kernel so there may be a better solution than this). " The method that I was planning on implementing, was to boot a livecd(-to-be) under qemu, then use file access times to construct a list of files that should be precached (same thing as readahead afaict). (And then by hand figure out files that are specific to the hardware platform, and make sure that their cousins get included in the list) What are your thoughts on this? Any quick reason why this wasn't used for readahead (I'm fairly ignorant of the internals of readahead). And do any of the reasons why it wasn't used for readahead apply to livecd optomization case? FYI- I see 2 obvious ways to do readahead in the livecd case. One, which I've outlined here before, would be to use unionfs, and seperate the filesystem images into "files that should be read ahead" and "the rest". Obviously unionfs, while it may eventually get into fedora, isn't the way to go. Its only a minor modifcation to do the same thing with devicemapper snapshots however. (i.e. you create the filesystem populating it with the files to be read-ahead, then you dm-snapshot it, and copy the rest of the files in. The resulting original fsimage(sparse ext3) along with the devicemapper snapshot device (damage/cow) image file, constitute the same effective thing as above with unionfs. Thus all your early read-ahead files, go in a single file/track on your cd/dvd, reducing seek times. Additionally, you can just read the read-ahead section into ram in one big chunk. (that would waste some ram, however with md-mirror tricks, you can work around that) Another minor question- " b. ext3 should support operations for moving blocks around; e.g. optimize around the readahead fileset - when idle the system should rearrange the files to facilitate faster booting " Has anything happened with that in the last 3 years? Sounds like a decent idea, that might be adaptable to the livecd boot optomization case. Final question: Have you had any other ideas on how livecd boot speed might be improved? -dmc/jdog ____________________________________________________________________________________ 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news

17 years

4
3
0 / 0

Re: [Fedora-livecd-list] [patch 06/20] Cleanup unmount() and teardown()

by David Zeuthen

On Tue, 2007-03-27 at 15:14 +0100, Mark McLoughlin wrote: > - # TODO: need to handle when unmount fails because of lingering > - # processes that has open files > + self.bindmounts.reverse() > + for b in self.bindmounts: > + b.umount() > + Is the idea here that an exception is thrown all the way up to the user if unmount fails because some process in the chroot have open files? I guess that's fine; long term I'm hoping we can slay them somehow.. it does happens from time to time since that packages inevitably do a 'service foo restart' instead of 'service foo condrestart'... David

17 years

2
1
0 / 0

Re: [Fedora-livecd-list] [patch 09/20] Consolidate bindmounts creation

by David Zeuthen

On Tue, 2007-03-27 at 15:14 +0100, Mark McLoughlin wrote: > plain text document attachment (livecd-bindmounts-consolidation.patch) > No reason why the /var/cache/yum bindmount shouldn't be > created in the same loop as the rest of the bindmounts Yeah; mostly historical from when I wrote the original pilgrim code; it took me a while to figure out why we ran out of space. I guess this is fine although it's a bit weird to see /var/cache/yum along with the "special directories" that we normally bindmount to /. David

17 years

1
0
0 / 0

Caching downloaded RPMs

by J. Christopher Pereira Z.

Hi: 1) I'm building a LiveCD using a remote repository. Everytime I restart the task, the packages are being redownloaded into the temporal/mounted dir. Is there any option for caching the downloaded packages? PS: I'm on FC6 building a FC7 live CD. 2) If there is no option or trick for caching, how can I download only some packages (+ dependencies) into my local repository for building a minimal LiveCD. Thanks. J. Christopher Pereira Area Informática IMATRONIX S.A. (08) 573 45 18 -------------------------------------------------------------------------------- I am using the free version of SPAMfighter for private users. It has removed 11972 spam emails to date. Paying users do not have this message in their emails. Try SPAMfighter for free now!

17 years

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

livecd April 2007