From jsteer at bitscout.com Sat Sep 1 17:18:58 2007 From: jsteer at bitscout.com (Jon Steer) Date: Sat, 1 Sep 2007 13:18:58 -0400 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D8336D.8020605@nanotechnologies.qc.ca> References: <46D7D043.6030003@kanarip.com> <1188567085.4719.4.camel@localhost.localdomain> <46D826A5.9070908@filteredperception.org> <46D8336D.8020605@nanotechnologies.qc.ca> Message-ID: <74e6f65d0709011018i3ef0dfd7wa1166565e2276ebe@mail.gmail.com> I'd be interested in the "-" lines that you use to strip the files out. As the generator of a console-based server distribution I am interested in losing as many extraneous packages as possible. For me, stripping down the size of the ISO has more to do with space considerations for either USB-based distributions or when I'm booting the LiveCD into a VM and I'd like to save real memory space. jon On 8/31/07, Patrice Guay wrote: > Douglas McClendon a ?crit : > > Matthias Clasen wrote: > >> On Fri, 2007-08-31 at 10:24 +0200, Jeroen van Meeuwen wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> 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 what docs > >>> should > >>> be on the LiveCD in the first place? I guess removing everything RPM > >>> calls docs is too much, as this will include man-pages as well. > >>> > >>> Any thoughts? > >>> > >> > >> As long as you are willing to ignore the rpm verification issue that > >> gets raised every time this is mentioned (or go with Douglas' > >> fixup-script approach), > > > > Also, it occurred to me that the more complete solution to the rpm > > verification issue would be to have a (signed?) list of files that are > > expected to be missing. Then with either a wrapper, or a minor mod to > > rpm, you could have just as complete verification. > > > > Then, the solution to the inefficient fixup problem (downloading whole > > rpms just to get the small missing files), if one were serious about > > it, you could obviously for every shipped livecd, create a single > > signed package of just the missing files. > > > > > If this package is shipped as a RPM, conflict may arise with the > original RPM about file ownership. > > >> dropping language support is certainly going to give you just as much > >> if not > >> more space savings. I recently added %lang tags to most of the big > >> gnome help > >> documents in /usr/share/gnome/help. Also, dropping CJK fonts easily > >> saves some 40M. > On my current live CD release, I strip rarely used documentation files > (changelog, news, non-englist html files). This saves 7MB on the > resulting Live CD. I also remove language files and it saves 95MB of > compressed space. > > -- > Patrice > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > -- "Whereever you go, there you are" From patrice.guay at nanotechnologies.qc.ca Sat Sep 1 21:49:15 2007 From: patrice.guay at nanotechnologies.qc.ca (Patrice Guay) Date: Sat, 01 Sep 2007 17:49:15 -0400 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <74e6f65d0709011018i3ef0dfd7wa1166565e2276ebe@mail.gmail.com> References: <46D7D043.6030003@kanarip.com> <1188567085.4719.4.camel@localhost.localdomain> <46D826A5.9070908@filteredperception.org> <46D8336D.8020605@nanotechnologies.qc.ca> <74e6f65d0709011018i3ef0dfd7wa1166565e2276ebe@mail.gmail.com> Message-ID: <46D9DE5B.70204@nanotechnologies.qc.ca> Jon Steer wrote: > I'd be interested in the "-" lines that you use to strip the files out. > > As the generator of a console-based server distribution I am > interested in losing as many extraneous packages as possible. > > For me, stripping down the size of the ISO has more to do with space > considerations for either USB-based distributions or when I'm booting > the LiveCD into a VM and I'd like to save real memory space. > http://www.nanotechnologies.qc.ca/propos/linux/centos-live/i386/live/centos-livecd-desktop.ks -- Patrice From lars.bjorndal at broadpark.no Sun Sep 2 07:19:51 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Sun, 02 Sep 2007 09:19:51 +0200 Subject: [Fedora-livecd-list] Revisor: Instroot problem Message-ID: Hello! With GIT version of Revisor commit 0ad6a3da49ff75fbfcd5802c5b03de51d9d014ac, I got a problem: Initting progress bar for Configure System Configure System: Setting SELinux to: 1 Setting crypted root password /var/tmp/revisor-livecd/install_root /var/tmp/revisor-livecd/install_root /var/tmp/revisor-livecd/install_root Xorg is installed: True Traceback (most recent call last): File "/usr/sbin/revisor", line 293, in revisorBase.run() File "/usr/lib/python2.5/site-packages/revisor/cli.py", line 45, in run self.base.lift_off() File "/usr/lib/python2.5/site-packages/revisor/base.py", line 894, in lift_off self.buildLiveMedia() File "/usr/lib/python2.5/site-packages/revisor/base.py", line 1367, in buildLiveMedia liveImage.extra_configuration() File "/usr/lib/python2.5/site-packages/revisor/lm_optical.py", line 151, in extra_configuration f = open("%s/etc/inittab" %(instroot,), "rw+") NameError: global name 'instroot' is not defined [root at cd ~]# Is this a known problem/bug? Lars From kanarip at kanarip.com Sun Sep 2 18:53:48 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 02 Sep 2007 20:53:48 +0200 Subject: [Fedora-livecd-list] Revisor: Instroot problem In-Reply-To: References: Message-ID: <46DB06BC.2030006@kanarip.com> Lars Bj?rndal wrote: > Hello! > > With GIT version of Revisor commit > 0ad6a3da49ff75fbfcd5802c5b03de51d9d014ac, I got a problem: > > Initting progress bar for Configure System > Configure System: > Setting SELinux to: 1 > Setting crypted root password > /var/tmp/revisor-livecd/install_root > /var/tmp/revisor-livecd/install_root > /var/tmp/revisor-livecd/install_root > Xorg is installed: True > Traceback (most recent call last): > File "/usr/sbin/revisor", line 293, in > revisorBase.run() > File "/usr/lib/python2.5/site-packages/revisor/cli.py", line 45, in run > self.base.lift_off() > File "/usr/lib/python2.5/site-packages/revisor/base.py", line 894, in lift_off > self.buildLiveMedia() > File "/usr/lib/python2.5/site-packages/revisor/base.py", line 1367, in buildLiveMedia > liveImage.extra_configuration() > File "/usr/lib/python2.5/site-packages/revisor/lm_optical.py", line 151, in extra_configuration > f = open("%s/etc/inittab" %(instroot,), "rw+") > NameError: global name 'instroot' is not defined > [root at cd ~]# > > Is this a known problem/bug? > Yes, I know it has been a problem. So is the number of references we have to kickstart objects that do not exist anymore (at least in GUI mode) since I've moved to using another kickstart object to get Revisor going on EL5 as well. I've been having troubles at my home network; I'll be kicking this bug's ass tomorrow hopefully. Kind regards, Jeroen van Meeuwen -kanarip From markmc at redhat.com Mon Sep 3 16:55:08 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 03 Sep 2007 17:55:08 +0100 Subject: [Fedora-livecd-list] A couple of cleanup patches Message-ID: <1188838508.22245.18.camel@blaa> Hi, I've had these lying around for a while and had forgot to post them here. They apply against: commit 4bdfd71879a7634c6417d9905aa5118416d2eba0 Author: Jeremy Katz Date: Fri Aug 31 12:41:27 2007 -0400 check for isomd5sum early enough First patch just removes and unused parameter. 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() ... There shouldn't be any functional changes, though ... Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: creator-remove-unused-tmpdir.patch Type: text/x-patch Size: 1158 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: creator-refactor-cleanup-deleted.patch Type: text/x-patch Size: 6514 bytes Desc: not available URL: From tve at voneicken.com Mon Sep 3 16:57:12 2007 From: tve at voneicken.com (Thorsten von Eicken) Date: Mon, 03 Sep 2007 09:57:12 -0700 Subject: [Fedora-livecd-list] boot failure on VIA Epia M-6000 board In-Reply-To: <46D64446.7080003@voneicken.com> References: <46D25265.9080904@voneicken.com> <20070827140849.GY29579@gospo.rdu.redhat.com> <46D2F591.8030203@voneicken.com> <20070827171515.GE29579@gospo.rdu.redhat.com> <46D3AF6F.4060107@voneicken.com> <20070829152612.GA32421@gospo.rdu.redhat.com> <46D59568.4050908@voneicken.com> <20070829210001.GF32421@gospo.rdu.redhat.com> <46D64446.7080003@voneicken.com> Message-ID: <46DC3CE8.4000705@voneicken.com> Thorsten von Eicken wrote: > I'll produce a i586 kernel and see what happens. Thanks for spotting this. Still in kernel hell, but the temperature has lowered by a few degrees... Explicitly using the i586 version of the kernel-devel and i386 versions of glibc, etc. packages does the trick. Don't even have to compile the kernel for generic i586, works as cyrix too. Now I'm into the next problem, which is that I'm booting off a CF card that doesn't do DMA. More about that in a fresh thread... Andy, thanks for your help! Thorsten From tve at voneicken.com Mon Sep 3 17:00:27 2007 From: tve at voneicken.com (Thorsten von Eicken) Date: Mon, 03 Sep 2007 10:00:27 -0700 Subject: [Fedora-livecd-list] booting from non-DMA IDE CF card Message-ID: <46DC3DAB.30705@voneicken.com> I am trying to boot off a CF card plugged into an IDE adapter and the card doesn't support DMA. The problem is that with the new libata stuff, the traditional "ide-nodma" kernel option doesn't do anything. How do I turn DMA off so it boots properly. As it is, it tries MWDMA2 mode, fails a few times, switches to MWDMA1 mode, but never goes down to PIO. Apologies if this a FAQ, but couldn't find a solution anywhere. Thorsten From markmc at redhat.com Mon Sep 3 17:30:06 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 03 Sep 2007 18:30:06 +0100 Subject: [Fedora-livecd-list] Revised: [PATCH] turboLiveInst - improves livecd/usb installer speed by 15-20+% In-Reply-To: <46A9AD09.7040309@filteredperception.org> References: <46A9AD09.7040309@filteredperception.org> Message-ID: <1188840606.22245.38.camel@blaa> Hi, This doesn't actually seem so bad to me ... The main suggestion I'd have is that if the osmin.size was dropped[1], and if we could reduce the size of the COW area of the snapshot to its minimal (i.e. look at how much is used and truncate it at that point), then we can just include osmin.img directly and cut out a lot of the tricks. Also, the snapshot device created by liveinst.sh should be readonly (dmsetup -r, I think). I'd also probably move the snapshot creation code out of liveinst.sh into anaconda itself. I'd tend towards not having --cleanup-deleted and --turbo-liveinst options and just make it the default. Finally, perhaps explain this feature as: "Reduce installation time by not copying unused data to disk" And if you want to explain how it actually works: "We avoid copying unused data by copying a filesystem image that has been reduced to the minimal possible size. This minimal image is not sufficient for a running LiveCD as applications need room to write more data, but the minimal image is efficiently created just before copying by applying a pre-calculated set of deltas to the original large filesystem image." Cheers, Mark. [1] - Just change getLiveSizeMb() to always "dumpe2fs -h" to get the filesystem size From walters at redhat.com Mon Sep 3 17:46:18 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 3 Sep 2007 13:46:18 -0400 Subject: [Fedora-livecd-list] [PATCH] Re: local caching In-Reply-To: <1188227500.2365.52.camel@localhost.localdomain> References: <1188227500.2365.52.camel@localhost.localdomain> Message-ID: On 8/27/07, Jeremy Katz wrote: > > On Fri, 2007-08-24 at 18:09 -0400, Colin Walters wrote: > > Ok just to repost - here's the current delta to livecd-creator that I > > can't live without. > > > > The first part is answering "Why is my network pegged?" (though does > > anyone know if there's a nice way to use something like Wireshark to > > get this info?) > > Don't know of a good way. But like I said with the first time you > posted this, I'd much rather just one line per download rather than > multiple. It's more inline with what yum, etc do and it also means less > logs to slog through. Ok, done. > > The second is defaulting to a persistent cache for downloads. This is > > not protected against concurrent execution - should we go ahead and > > add a --nocache option for those people who have a local fedora > > mirror? > > Given the fact that concurrent operations will cause problems here and > there's no real clean-up policy, I still think that a shared cache by > default isn't the best idea. I'd be up for a cachedir that can then be > pointed to a shared location if you as the person running know that you > want to; but for the general case, I think it's a little too risky as it > stands[1] Ok. I have patches in http://submind.verbum.org/~walters/livecd.git/ (which I rebuilt because I got confused by cherrypicking) I also attached the patches manually. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: textprogress.patch Type: text/x-patch Size: 2147 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cachedir.patch Type: text/x-patch Size: 2019 bytes Desc: not available URL: From jsteer at bitscout.com Mon Sep 3 18:41:48 2007 From: jsteer at bitscout.com (Jon Steer) Date: Mon, 3 Sep 2007 14:41:48 -0400 Subject: [Fedora-livecd-list] Anaconda settings for LiveCD install Message-ID: <74e6f65d0709031141n6657af04u2f0df14059f7dce3@mail.gmail.com> I am creating a LAMP console-based livecd distro. Since this is console based, I have run the problem where anaconda assumes that the liveinst install will be X-based. I originally thought I'd solve the problem by setting up a kickstart file. Perhaps my kickstart wasn't complete, but, my results were that the kickstart was processed but no livecd install occurred. Looking further in anaconda (livecd.py) I found this piece of hardcoding anaconda.id.bootloader.args.append("rhgb quiet") anaconda.id.desktop.setDefaultRunLevel(5) Not being python-speaking folk, I don't know whether there is a parameter I can hang around this to take away rhgb and runlevel 5 when X isn't being installed. Any thoughts? jon -- "Don't stand still, if you see me running down the road, 'cause there is trouble right behind me". From dmc.fedora at filteredperception.org Mon Sep 3 20:33:13 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 03 Sep 2007 15:33:13 -0500 Subject: [Fedora-livecd-list] Revised: [PATCH] turboLiveInst - improves livecd/usb installer speed by 15-20+% In-Reply-To: <1188840606.22245.38.camel@blaa> References: <46A9AD09.7040309@filteredperception.org> <1188840606.22245.38.camel@blaa> Message-ID: <46DC6F89.6050706@filteredperception.org> 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 grep looked pretty ugly. I'm not opposed to going back to that if you tell me that is what will get accepted. Another minor justification is to minimize the work done at install time. (though I admit the bash+dumpe2fs+grep+sed is not going to add terribly significant time to the install). historically- " echo "$(( $(/sbin/dumpe2fs -h /dev/mapper/live-osimg-min 2>/dev/null | grep "^Block size:" | sed -e 's/.*:\s*//') * $(/sbin/dumpe2fs -h /dev/mapper/live-osimg-min 2>/dev/null | grep "^Block count:" | sed -e 's/.*:\s*//') / 512 ))" > /dev/shm/osmin.size " > and if we could reduce the size of the COW area of the snapshot to its > minimal (i.e. look at how much is used and truncate it at that point), This is pretty easy. In the intervening time, I am now confidently aware that I can use dmsetup status on the snapshotted device to determine how much of the file can be truncated. > then we can just include osmin.img directly and cut out a lot of the > tricks. It needs to be compressed, which is why the truncation didn't really matter. The reason it needs to be compressed, is because it can't live in the squashfs, it has to live on the iso9660. And note, that it compresses from 1.2M of actual data, to 7kb of actual data. I'm all for cutting out the tricks, if it is possible. Can you see an alternate way, with fewer tricks, to get osmin.img to be visible to anaconda? You could try to force the mounting of /dev/live onto /mnt/live, but that breaks the copy-to-ram case, because in that case, the cdrom doesn't exist. If breaking copy-to-ram is ok, and you prefer grabbing osmin.img from a mounted /dev/live, I can do that. Honestly I thought that using the exact same mechanism to propogate osmin.img as was used to propogate os.img, was not a trick, but elegant. > > Also, the snapshot device created by liveinst.sh should be readonly > (dmsetup -r, I think). Sounds good, and the loop devices for the components while we're at it. > > I'd also probably move the snapshot creation code out of liveinst.sh > into anaconda itself. I'm not so sure about this. liveinst.sh seemed appropriate, in that it was where the installable image was defined to anaconda. This also depends on any suggestions you might have about alternate ways of exposing osmin.img, so I'll wait to hear what you think about that. Thanks again for taking a look at this. I'll be happy to do whatever you suggest to get it merge-worthy, but lets at least have one back and forth to make sure you understand why I made the design choices I did. Regards, -dmc > > I'd tend towards not having --cleanup-deleted and --turbo-liveinst > options and just make it the default. > > Finally, perhaps explain this feature as: > > "Reduce installation time by not copying unused data to disk" > > And if you want to explain how it actually works: > > "We avoid copying unused data by copying a filesystem image that has > been reduced to the minimal possible size. This minimal image is not > sufficient for a running LiveCD as applications need room to write > more data, but the minimal image is efficiently created just before > copying by applying a pre-calculated set of deltas to the original > large filesystem image." > > Cheers, > Mark. > > [1] - Just change getLiveSizeMb() to always "dumpe2fs -h" to get the > filesystem size > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From dmc.fedora at filteredperception.org Mon Sep 3 23:07:11 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 03 Sep 2007 18:07:11 -0500 Subject: [Fedora-livecd-list] A couple of cleanup patches In-Reply-To: <1188838508.22245.18.camel@blaa> References: <1188838508.22245.18.camel@blaa> Message-ID: <46DC939F.5030401@filteredperception.org> Mark McLoughlin wrote: > Hi, > I've had these lying around for a while and had forgot to post them > here. They apply against: > > commit 4bdfd71879a7634c6417d9905aa5118416d2eba0 > Author: Jeremy Katz > Date: Fri Aug 31 12:41:27 2007 -0400 > > check for isomd5sum early enough > > First patch just removes and unused parameter. > > 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() ... I took a visual look at this, and it seems good to me. The only thing I would add, is that you could use dumpe2fs to implicitly get the initial block count for resize2fsToMinimal, instead of passing it as an argument. Which incidentally would be code that could be copied to anaconda for turboLiveInst :) -dmc > There shouldn't be any functional changes, though ... > Cheers, > Mark. > > > ------------------------------------------------------------------------ > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From walters at redhat.com Mon Sep 3 23:15:01 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 3 Sep 2007 19:15:01 -0400 Subject: [Fedora-livecd-list] booting recent livecd images Message-ID: Hey, Just wondering if anyone else was able to boot ISOs generated by livecd-creator recently? First off, when I try to use qemu-kvm, I get random hangs during the bootup process (in different places; last message might be SCSI or TCP congestion algorithm, etc). So, I use "qemu". The images I'm generating fail to find the root filesystem (screenshot attached). I'm building them on Fedora 7, git head livecd-tools. This used to work, so something regressed recently, and I have no idea what =) How would one go about debugging this? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-QEMU.png Type: image/png Size: 12310 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Mon Sep 3 23:26:05 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 03 Sep 2007 18:26:05 -0500 Subject: [Fedora-livecd-list] A couple of cleanup patches In-Reply-To: <1188838508.22245.18.camel@blaa> References: <1188838508.22245.18.camel@blaa> Message-ID: <46DC980D.6040101@filteredperception.org> 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 be to leave in this comment, as I think it may help future readers of the code to more easily understand what is going on- - # truncate the unused excess portion of the sparse file -dmc From dmc.fedora at filteredperception.org Tue Sep 4 03:09:22 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 03 Sep 2007 22:09:22 -0500 Subject: [Fedora-livecd-list] A couple of cleanup patches In-Reply-To: <1188838508.22245.18.camel@blaa> References: <1188838508.22245.18.camel@blaa> Message-ID: <46DCCC62.1060702@filteredperception.org> 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 going off of visual inspection of the patch- + def package(self, ignore_deleted = False): + if ignore_deleted: + self.cleanupDeleted() I think you meant "if not ignore_deleted" And I'm also confused by final_size_mb in general. + if not final_size_mb is None: + n_blocks = final_size_mb * 1024L * 1024L / self.blocksize Where does it get set to anything other than None? -dmc From markmc at redhat.com Tue Sep 4 07:57:04 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 04 Sep 2007 08:57:04 +0100 Subject: [Fedora-livecd-list] A couple of cleanup patches In-Reply-To: <46DCCC62.1060702@filteredperception.org> References: <1188838508.22245.18.camel@blaa> <46DCCC62.1060702@filteredperception.org> Message-ID: <1188892624.2727.16.camel@blaa> On Mon, 2007-09-03 at 22:09 -0500, Douglas McClendon wrote: > 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 going off of visual inspection > of the patch- > > > + def package(self, ignore_deleted = False): > + if ignore_deleted: > + self.cleanupDeleted() > > I think you meant "if not ignore_deleted" > > And I'm also confused by final_size_mb in general. > > + if not final_size_mb is None: > + n_blocks = final_size_mb * 1024L * 1024L / self.blocksize > > > Where does it get set to anything other than None? Bah, well spotted - both of these I removed before sending the patch, but then sent the wrong patch. Here's the correct patch. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: creator-refactor-cleanup-deleted.patch Type: text/x-patch Size: 5878 bytes Desc: not available URL: From markmc at redhat.com Tue Sep 4 08:03:39 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 04 Sep 2007 09:03:39 +0100 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <20070814031110.GC24149@auslistsprd01.us.dell.com> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> Message-ID: <1188893019.2727.21.camel@blaa> Hi Matt, On Mon, 2007-08-13 at 22:11 -0500, 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 that match the > RPMs that go into the LiveCD. One approach could be to first use pungi -G to compose yum repos of the minimal set of RPMs and SRPMs needed for the livecd, and then build the livecd from those repos. You could then ship those repos separately from the LiveCD. Since they both get their package lists from a kickstart file, that should be pretty straightforward. Cheers, Mark. From markmc at redhat.com Tue Sep 4 08:17:59 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 04 Sep 2007 09:17:59 +0100 Subject: Managing patches [was Re: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only] In-Reply-To: <1187727530.4781.63.camel@localhost.localdomain> References: <46C96BB7.6030400@filteredperception.org> <1187727530.4781.63.camel@localhost.localdomain> Message-ID: <1188893880.2727.30.camel@blaa> Hey, On Tue, 2007-08-21 at 16:18 -0400, Jeremy Katz wrote: > * It's good to get into the habit of doing git commits for each > separate > change. Then you can get a patch per change. And that would avoid > having the addidir/addsdir stuff being in the same changes FWIW, I don't think this approach useful, unless you're the type of person that gets every change perfect first time :-) Basically, git records a history of how you developed a set of changes, rather than allowing you to work individual changes separately. I've tried stgit (stacked git), but found it fairly cumbersome and confusing. I may try it again sometime, but right now I still use quilt for managing a set of patches ... (And yes, quilt isn't perfect either - as demonstrated by me sending an older version of a patch yesterday) Cheers, Mark. From markmc at redhat.com Tue Sep 4 08:49:17 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 04 Sep 2007 09:49:17 +0100 Subject: [Fedora-livecd-list] Revised: [PATCH] turboLiveInst - improves livecd/usb installer speed by 15-20+% In-Reply-To: <46DC6F89.6050706@filteredperception.org> References: <46A9AD09.7040309@filteredperception.org> <1188840606.22245.38.camel@blaa> <46DC6F89.6050706@filteredperception.org> Message-ID: <1188895757.2727.38.camel@blaa> On Mon, 2007-09-03 at 15:33 -0500, Douglas McClendon wrote: > Mark McLoughlin wrote: > > > > 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 grep looked pretty ugly. Something like this is nice and simple: import commands def parseField(output, field): for line in output.split("\n"): if line.startswith(field + ":"): return line[len(field) + 1:].strip() raise KeyError("Failed to find field '%s' in output" % field) (status, output) = commands.getstatusoutput("/sbin/dumpe2fs -h /dev/root") print parseField(output, "Block count") > > and if we could reduce the size of the COW area of the snapshot to its > > minimal (i.e. look at how much is used and truncate it at that point), > > This is pretty easy. In the intervening time, I am now confidently > aware that I can use dmsetup status on the snapshotted device to > determine how much of the file can be truncated. Yep. > > then we can just include osmin.img directly and cut out a lot of the > > tricks. > > It needs to be compressed, which is why the truncation didn't really > matter. The reason it needs to be compressed, is because it can't live > in the squashfs, it has to live on the iso9660. And note, that it > compresses from 1.2M of actual data, to 7kb of actual data. It can be truncated down to 1.2M, but it can still be compressed to 7kb? If so, the compression does sounds worthwhile. > Honestly I thought that using the exact same mechanism to propogate > osmin.img as was used to propogate os.img, was not a trick, but elegant. What you have is mostly fine IMHO, it was the tarball I had a problem with. Cheers, Mark. From Matt_Domsch at dell.com Tue Sep 4 11:19:15 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 4 Sep 2007 06:19:15 -0500 Subject: Managing patches [was Re: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only] In-Reply-To: <1188893880.2727.30.camel@blaa> References: <46C96BB7.6030400@filteredperception.org> <1187727530.4781.63.camel@localhost.localdomain> <1188893880.2727.30.camel@blaa> Message-ID: <20070904111915.GA16231@auslistsprd01.us.dell.com> On Tue, Sep 04, 2007 at 09:17:59AM +0100, Mark McLoughlin wrote: > Hey, > > On Tue, 2007-08-21 at 16:18 -0400, Jeremy Katz wrote: > > * It's good to get into the habit of doing git commits for each > > separate > > change. Then you can get a patch per change. And that would avoid > > having the addidir/addsdir stuff being in the same changes > > FWIW, I don't think this approach useful, unless you're the type of > person that gets every change perfect first time :-) > > Basically, git records a history of how you developed a set of changes, > rather than allowing you to work individual changes separately. Branches are "free" in git. So, you can make a branch for what you want to work on, do it there with lots of commits, then when you're really happy with the change and want to apply it as one or more commits to your master branch, you can create a new branch from master; git diff master..yourdevbranch; apply the patches and commit as you like in your new branch; git push master. So you get the best of both worlds. -Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From markmc at redhat.com Tue Sep 4 11:53:50 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 04 Sep 2007 12:53:50 +0100 Subject: Managing patches [was Re: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only] In-Reply-To: <20070904111915.GA16231@auslistsprd01.us.dell.com> References: <46C96BB7.6030400@filteredperception.org> <1187727530.4781.63.camel@localhost.localdomain> <1188893880.2727.30.camel@blaa> <20070904111915.GA16231@auslistsprd01.us.dell.com> Message-ID: <1188906830.2727.49.camel@blaa> On Tue, 2007-09-04 at 06:19 -0500, Matt Domsch wrote: > On Tue, Sep 04, 2007 at 09:17:59AM +0100, Mark McLoughlin wrote: > > Hey, > > > > On Tue, 2007-08-21 at 16:18 -0400, Jeremy Katz wrote: > > > * It's good to get into the habit of doing git commits for each > > > separate > > > change. Then you can get a patch per change. And that would avoid > > > having the addidir/addsdir stuff being in the same changes > > > > FWIW, I don't think this approach useful, unless you're the type of > > person that gets every change perfect first time :-) > > > > Basically, git records a history of how you developed a set of changes, > > rather than allowing you to work individual changes separately. > > Branches are "free" in git. So, you can make a branch for what you > want to work on, do it there with lots of commits, then when you're > really happy with the change and want to apply it as one or more > commits to your master branch, you can create a new branch from > master; git diff master..yourdevbranch; apply the patches and commit as > you like in your new branch; git push master. So you get the best of both worlds. Granted, but if you're working on a few interrelated patches, this gets seriously cumbersome. Yes, you could use branches of branches but ... Point is that git doesn't do a good job of this right now - although stgit is promising - so I think git would ultimately just discourage people from the concept of splitting their patches into nice easy-to-review chunks. It may not be terribly sophisticated, but at least quilt has the right model and is simple to use and understand. A stack of patches, each independently hackable. Cheers, Mark. From gospo at redhat.com Tue Sep 4 12:58:41 2007 From: gospo at redhat.com (Andy Gospodarek) Date: Tue, 4 Sep 2007 08:58:41 -0400 Subject: [Fedora-livecd-list] boot failure on VIA Epia M-6000 board In-Reply-To: <46DC3CE8.4000705@voneicken.com> References: <46D25265.9080904@voneicken.com> <20070827140849.GY29579@gospo.rdu.redhat.com> <46D2F591.8030203@voneicken.com> <20070827171515.GE29579@gospo.rdu.redhat.com> <46D3AF6F.4060107@voneicken.com> <20070829152612.GA32421@gospo.rdu.redhat.com> <46D59568.4050908@voneicken.com> <20070829210001.GF32421@gospo.rdu.redhat.com> <46D64446.7080003@voneicken.com> <46DC3CE8.4000705@voneicken.com> Message-ID: <20070904125841.GB17438@gospo.rdu.redhat.com> On Mon, Sep 03, 2007 at 09:57:12AM -0700, Thorsten von Eicken wrote: > Thorsten von Eicken wrote: > >I'll produce a i586 kernel and see what happens. Thanks for spotting this. > > Still in kernel hell, but the temperature has lowered by a few degrees... > > Explicitly using the i586 version of the kernel-devel and i386 versions > of glibc, etc. packages does the trick. Don't even have to compile the > kernel for generic i586, works as cyrix too. > > Now I'm into the next problem, which is that I'm booting off a CF card > that doesn't do DMA. More about that in a fresh thread... > > Andy, thanks for your help! > Thorsten > Thorsten, Excellent news! I was hoping this would be possible without rebuilding anything and glad to hear it was. -andy From alexm at asic.udl.cat Tue Sep 4 13:13:16 2007 From: alexm at asic.udl.cat (=?ISO-8859-1?Q?Alexandre_Magaz_Gra=E7a?=) Date: Tue, 04 Sep 2007 15:13:16 +0200 Subject: [Fedora-livecd-list] booting recent livecd images In-Reply-To: References: Message-ID: <46DD59EC.3010705@asic.udl.cat> En/na Colin Walters ha escrit: > Hey, > > Just wondering if anyone else was able to boot ISOs generated by > livecd-creator recently? First off, when I try to use qemu-kvm, I get > random hangs during the bootup process (in different places; last message > might be SCSI or TCP congestion algorithm, etc). > > So, I use "qemu". The images I'm generating fail to find the root > filesystem (screenshot attached). > > I'm building them on Fedora 7, git head livecd-tools. This used to work, so > something regressed recently, and I have no idea what =) How would one go > about debugging this? Hi, I also have the same problem. It seems that the ATA modules are not included in the image, so the CD device doesn't gets created. Reverting changes from commit 098ffcd52ea37d10e91265f9909380367dbf6d83 solves the problem for me. After looking at mayflower code, I think there is a bug. I've not tryed yet, but the attached patch should fix mayflower to add the ATA modules. Cheers, Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: use_right_ata_modules_file.patch Type: text/x-patch Size: 552 bytes Desc: not available URL: From walters at redhat.com Tue Sep 4 13:49:42 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 4 Sep 2007 09:49:42 -0400 Subject: [Fedora-livecd-list] Revised: [PATCH] turboLiveInst - improves livecd/usb installer speed by 15-20+% In-Reply-To: <1188895757.2727.38.camel@blaa> References: <46A9AD09.7040309@filteredperception.org> <1188840606.22245.38.camel@blaa> <46DC6F89.6050706@filteredperception.org> <1188895757.2727.38.camel@blaa> Message-ID: On 9/4/07, Mark McLoughlin wrote: > > > (status, output) = commands.getstatusoutput("/sbin/dumpe2fs -h > /dev/root") Not directly related to your discussion, but personally I am fairly fanatical about never involving /bin/sh in - well, anything if I can avoid it =) Here it will be fine, but then maybe someone comes along later and wants to add a user-passed parameter to the command, and then you need to quote (if it's even remembered, and if it's not then you have weird failures and in other software security problems). The "subprocess" module is the fix: output = subprocess.Popen(['/sbin/dumpe2fs', '-h', '/dev/root'], stdout= subprocess.PIPE).communicate()[0] -------------- next part -------------- An HTML attachment was scrubbed... URL: From markmc at redhat.com Tue Sep 4 13:56:06 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 04 Sep 2007 14:56:06 +0100 Subject: [Fedora-livecd-list] Revised: [PATCH] turboLiveInst - improves livecd/usb installer speed by 15-20+% In-Reply-To: References: <46A9AD09.7040309@filteredperception.org> <1188840606.22245.38.camel@blaa> <46DC6F89.6050706@filteredperception.org> <1188895757.2727.38.camel@blaa> Message-ID: <1188914166.2727.57.camel@blaa> On Tue, 2007-09-04 at 09:49 -0400, Colin Walters wrote: > On 9/4/07, Mark McLoughlin wrote: > > (status, output) = > commands.getstatusoutput("/sbin/dumpe2fs -h /dev/root") > > > Not directly related to your discussion, but personally I am fairly > fanatical about never involving /bin/sh in - well, anything if I can > avoid it =) Here it will be fine, but then maybe someone comes along > later and wants to add a user-passed parameter to the command, and > then you need to quote (if it's even remembered, and if it's not then > you have weird failures and in other software security problems). Fair point but ... > The "subprocess" module is the fix: > > output = subprocess.Popen(['/sbin/dumpe2fs', '-h', '/dev/root'], stdout=subprocess.PIPE).communicate()[0] ... that sucks :-) (But yeah, agreed) Cheers, Mark. From katzj at redhat.com Tue Sep 4 14:02:26 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 04 Sep 2007 10:02:26 -0400 Subject: [Fedora-livecd-list] Anaconda settings for LiveCD install In-Reply-To: <74e6f65d0709031141n6657af04u2f0df14059f7dce3@mail.gmail.com> References: <74e6f65d0709031141n6657af04u2f0df14059f7dce3@mail.gmail.com> Message-ID: <1188914546.4464.28.camel@localhost.localdomain> On Mon, 2007-09-03 at 14:41 -0400, Jon Steer wrote: > I am creating a LAMP console-based livecd distro. > > Since this is console based, I have run the problem where anaconda > assumes that the liveinst install will be X-based. liveinst itself shouldn't really be assuming that; it's not passing --graphical to anaconda and so anaconda should determine it based on whether or not DISPLAY is set. > I originally thought I'd solve the problem by setting up a kickstart > file. Perhaps my kickstart wasn't complete, but, my results > were that the kickstart was processed but no livecd install occurred. What command line arguments did you pass to anaconda? > Looking further in anaconda (livecd.py) I found this piece of hardcoding > > anaconda.id.bootloader.args.append("rhgb quiet") > anaconda.id.desktop.setDefaultRunLevel(5) > > Not being python-speaking folk, I don't know whether there is a > parameter I can hang around this to take away rhgb and runlevel 5 when > X isn't being installed. If you file an anaconda bug (mostly so I don't forget as I likely will by the time I finish getting through email :-), I can make this be a little bit smarter like the other install backends. As I think I previously mentioned here, there probably are a few shortcuts like that based mostly on the "it's what was tested on the normal path". Fixing them up should be pretty easy as they're noticed Jeremy From katzj at redhat.com Tue Sep 4 14:06:06 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 04 Sep 2007 10:06:06 -0400 Subject: [Fedora-livecd-list] booting recent livecd images In-Reply-To: References: Message-ID: <1188914766.4464.29.camel@localhost.localdomain> On Mon, 2007-09-03 at 19:15 -0400, Colin Walters wrote: > I'm building them on Fedora 7, git head livecd-tools. This used to > work, so something regressed recently, and I have no idea what =) How > would one go about debugging this? If you're running git HEAD, are you running git HEAD mayflower (ie, have it installed in /usr/lib/livecd-tools) as well? Jeremy From katzj at redhat.com Tue Sep 4 15:42:50 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 04 Sep 2007 11:42:50 -0400 Subject: [Fedora-livecd-list] [PATCH] Re: local caching In-Reply-To: References: <1188227500.2365.52.camel@localhost.localdomain> Message-ID: <1188920570.4464.58.camel@localhost.localdomain> On Mon, 2007-09-03 at 13:46 -0400, Colin Walters wrote: > I have patches in http://submind.verbum.org/~walters/livecd.git/ > (which I rebuilt because I got confused by cherrypicking) > > I also attached the patches manually. Thanks, applied Jeremy From katzj at redhat.com Tue Sep 4 15:50:07 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 04 Sep 2007 11:50:07 -0400 Subject: [Fedora-livecd-list] A couple of cleanup patches In-Reply-To: <1188838508.22245.18.camel@blaa> References: <1188838508.22245.18.camel@blaa> Message-ID: <1188921007.4464.61.camel@localhost.localdomain> On Mon, 2007-09-03 at 17:55 +0100, Mark McLoughlin wrote: > I've had these lying around for a while and had forgot to post them > here. They apply against: Applied both of them (well, the updated version of the second patch) Jeremy From walters at redhat.com Tue Sep 4 15:54:30 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 4 Sep 2007 11:54:30 -0400 Subject: [PATCH] Re: [Fedora-livecd-list] booting recent livecd images In-Reply-To: <1188914766.4464.29.camel@localhost.localdomain> References: <1188914766.4464.29.camel@localhost.localdomain> Message-ID: On 9/4/07, Jeremy Katz wrote: > > On Mon, 2007-09-03 at 19:15 -0400, Colin Walters wrote: > > I'm building them on Fedora 7, git head livecd-tools. This used to > > work, so something regressed recently, and I have no idea what =) How > > would one go about debugging this? > > If you're running git HEAD, are you running git HEAD mayflower (ie, have > it installed in /usr/lib/livecd-tools) as well? Indeed, that was the problem, thanks. This seemed like it was just waiting to bite other unaware contributors (periodic sudo cp mayflower /usr/lib/livecd-creator is not obvious), so patch in my git repository, and also attached. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: libexecdir.patch Type: text/x-patch Size: 3531 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Tue Sep 4 21:47:10 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 04 Sep 2007 16:47:10 -0500 Subject: [Fedora-livecd-list] Revised: [PATCH] turboLiveInst - improves livecd/usb installer speed by 15-20+% In-Reply-To: <1188895757.2727.38.camel@blaa> References: <46A9AD09.7040309@filteredperception.org> <1188840606.22245.38.camel@blaa> <46DC6F89.6050706@filteredperception.org> <1188895757.2727.38.camel@blaa> Message-ID: <46DDD25E.2020803@filteredperception.org> Mark McLoughlin wrote: > On Mon, 2007-09-03 at 15:33 -0500, Douglas McClendon wrote: >> Mark McLoughlin wrote: [snip] thanks for providing the dumpe2fs python code Mark and Collin, should save you a cleanup patch later on :) [snip] > It can be truncated down to 1.2M, but it can still be compressed to >7kb? If so, the compression does sounds worthwhile. Yup. I can't actually wrap my head around the 1.2M->7kb compression, but I can give a reasonable explanation about why the inverse is possible. By the inverse, I mean using a snapshot to create a delta describing the differences between the minimized-fs and the maximized-fs (not max->min as is the actual case in use). I.e. in the min->max, all that is happening is some repetitive formatting of the filesystem out in the new unused area. As a result all that repetitive stuff can compress down to next to nothing. I assume something similar is happening in the max->min case. > > What you have is mostly fine IMHO, it was the tarball I had a problem > with. Ok, in that case, it should be no sweat (relatively) to put together a new version of the patch, updated against the 30+ commits seen since the last version, which uses dumpe2fs in anaconda, no tarball, osmin.img truncation, and setting loops and dms to readonly where possible. But, before I do that, can I get feedback from one other person, preferably who has commit authority, to tell me that this will be committed? Jeremy, you mentioned objections in the past? (all my goading of said objections, was because I was so sure that there is no remotely more correct way to accomplish the task, and I would be genuinely entertained to be corrected on that fact) I would also like to grumblingly say, that I think it would have been much better if this review could have been done sooner, so that it could make it into F8T2. This seems like a significant improvement (20% install speedup), which could have easily been in F8T2, and thus out of the way as a cloud of potential problem hanging over F8T3. -dmc > Cheers, > Mark. > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From johnlumby at hotmail.com Tue Sep 4 23:02:53 2007 From: johnlumby at hotmail.com (John Lumby) Date: Tue, 04 Sep 2007 19:02:53 -0400 Subject: [Fedora-livecd-list] does Fedora-7-Live CD provide a way to upgrade existing FC system? (FC4) Message-ID: 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? I am actually running the Live CD in a vmware virtual machine with virtual CDRom mapped onto the iso image - it works fine but is rather slow, so not easy for me to try experiments. Hoping someone can simply say this is what you have to do. Pointers to relevant doc welcome. Also, if there is a way - can I run it in the old non-graphical curses mode like the older Fedora installers? Might be a bit faster than the graphical interface, nice though it looks. I saw this same question asked in the forum but with no reply, so hoping I have a better chance of answer here. I didn't see way of searching the list archives, so apologies if asked already. Thanks John _________________________________________________________________ Enter to win a night a VIP night out at TIFF http://redcarpet.sympatico.msn.ca/ From dmc.fedora at filteredperception.org Tue Sep 4 23:23:07 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 04 Sep 2007 18:23:07 -0500 Subject: [Fedora-livecd-list] does Fedora-7-Live CD provide a way to upgrade existing FC system? (FC4) In-Reply-To: References: Message-ID: <46DDE8DB.2080305@filteredperception.org> 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 second major limitation is that formatting of the root(/) volume is required. Actually that will happen if you request it or not in the f7-livecd. I have a bug outstanding suggesting that be added to the errata/known-bugs/release notes, I don't know if it has yet. -dmc From jvonau at shaw.ca Tue Sep 4 23:33:32 2007 From: jvonau at shaw.ca (Jerry Vonau) Date: Tue, 04 Sep 2007 18:33:32 -0500 Subject: [Fedora-livecd-list] does Fedora-7-Live CD provide a way to upgrade existing FC system? (FC4) In-Reply-To: References: Message-ID: <46DDEB4C.5010701@shaw.ca> John Lumby wrote: > Also, if there is a way - can I run it in the old > non-graphical curses mode like the older Fedora installers? Might be > a bit faster than the graphical interface, nice though it looks. > I'm working on that part, most of my hardware is too underpowered to run X-windows. Jerry From johnlumby at hotmail.com Wed Sep 5 02:33:16 2007 From: johnlumby at hotmail.com (John Lumby) Date: Tue, 04 Sep 2007 22:33:16 -0400 Subject: [Fedora-livecd-list] does Fedora-7-Live CD provide a way to upgrade existing FC In-Reply-To: <46DDE8DB.2080305@filteredperception.org> Message-ID: That's a shame, but thanks for the rapid response. John >From: Douglas McClendon >Reply-To: fedora-livecd-list at redhat.com >To: fedora-livecd-list at redhat.com >Subject: Re: [Fedora-livecd-list] does Fedora-7-Live CD provide a way >toupgrade existing FC system? (FC4) >Date: Tue, 04 Sep 2007 18:23:07 -0500 > >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 second major limitation is that formatting of the >root(/) volume is required. Actually that will happen if you request it or >not in the f7-livecd. I have a bug outstanding suggesting that be added to >the errata/known-bugs/release notes, I don't know if it has yet. > >-dmc > >-- >Fedora-livecd-list mailing list >Fedora-livecd-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-livecd-list _________________________________________________________________ Enter to win a night a VIP night out at TIFF http://redcarpet.sympatico.msn.ca/ From walters at redhat.com Wed Sep 5 02:39:11 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 4 Sep 2007 22:39:11 -0400 Subject: [Fedora-livecd-list] does Fedora-7-Live CD provide a way to upgrade existing FC In-Reply-To: References: <46DDE8DB.2080305@filteredperception.org> Message-ID: On 9/4/07, John Lumby 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 the system is to enable sudo. Google for "fedora upgrade copy home directory" for more information. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmc.fedora at filteredperception.org Wed Sep 5 02:43:29 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 04 Sep 2007 21:43:29 -0500 Subject: [Fedora-livecd-list] does Fedora-7-Live CD provide a way to upgrade existing FC In-Reply-To: References: <46DDE8DB.2080305@filteredperception.org> Message-ID: <46DE17D1.5090609@filteredperception.org> Colin Walters wrote: > On 9/4/07, John Lumby 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 the system is to enable sudo. Google for "fedora > upgrade copy home directory" for more information. I personally advocate that, and coin the process "wipegrade". Please note, that the aforementioned bug about root(/) being formatted regardless of user-choice in f7-livecd, was discovered by someone who had /home as a subdir on their / volume, and thought that it would survive the installation, when in fact it did not. -dmc From alexm at asic.udl.cat Wed Sep 5 10:45:55 2007 From: alexm at asic.udl.cat (=?ISO-8859-1?Q?Alexandre_Magaz_Gra=E7a?=) Date: Wed, 05 Sep 2007 12:45:55 +0200 Subject: [PATCH] Re: [Fedora-livecd-list] booting recent livecd images In-Reply-To: References: <1188914766.4464.29.camel@localhost.localdomain> Message-ID: <46DE88E3.4040300@asic.udl.cat> En/na Colin Walters ha escrit: > On 9/4/07, Jeremy Katz wrote: >> On Mon, 2007-09-03 at 19:15 -0400, Colin Walters wrote: >>> I'm building them on Fedora 7, git head livecd-tools. This used to >>> work, so something regressed recently, and I have no idea what =) How >>> would one go about debugging this? >> If you're running git HEAD, are you running git HEAD mayflower (ie, have >> it installed in /usr/lib/livecd-tools) as well? > > > Indeed, that was the problem, thanks. This seemed like it was just waiting > to bite other unaware contributors (periodic sudo cp mayflower > /usr/lib/livecd-creator is not obvious), so patch in my git repository, and > also attached. I'm still having the same problem. I already verified that it's using git HEAD mayflower. What's really making it fail, is mayflower trying to read modules.block when it doesn't exists. I can't find neither in my system nor in Live CD modules directory. It only works specifying all ATA modules in mayflower.conf or modifying mayflower to read modules.libata instead. I don't understand why it fails in my system (also Fedora 7 with latest livecd-tools from git) if it's working for you. I'm doing something wrong? Cheers, ?lex From katzj at redhat.com Wed Sep 5 13:27:53 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 05 Sep 2007 09:27:53 -0400 Subject: [Fedora-livecd-list] does Fedora-7-Live CD provide a way to upgrade existing FC system? (FC4) In-Reply-To: References: Message-ID: <1188998873.5653.19.camel@localhost.localdomain> On Tue, 2007-09-04 at 19:02 -0400, 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? Unfortunately, not really. Given the way that the live install works, it can't be used for upgrades. Jeremy From katzj at redhat.com Wed Sep 5 13:33:55 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 05 Sep 2007 09:33:55 -0400 Subject: [PATCH] Re: [Fedora-livecd-list] booting recent livecd images In-Reply-To: <46DE88E3.4040300@asic.udl.cat> References: <1188914766.4464.29.camel@localhost.localdomain> <46DE88E3.4040300@asic.udl.cat> Message-ID: <1188999235.5653.20.camel@localhost.localdomain> On Wed, 2007-09-05 at 12:45 +0200, Alexandre Magaz Gra?a wrote: > I'm still having the same problem. I already verified that it's using > git HEAD mayflower. What's really making it fail, is mayflower trying to > read modules.block when it doesn't exists. I can't find neither in my > system nor in Live CD modules directory. *sigh* The file changed between Fedora 7 and now. Just pushed a change that should work for F7 as well. Jeremy From katzj at redhat.com Wed Sep 5 13:58:25 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 05 Sep 2007 09:58:25 -0400 Subject: [Fedora-livecd-list] Revised: [PATCH] turboLiveInst - improves livecd/usb installer speed by 15-20+% In-Reply-To: <46DDD25E.2020803@filteredperception.org> References: <46A9AD09.7040309@filteredperception.org> <1188840606.22245.38.camel@blaa> <46DC6F89.6050706@filteredperception.org> <1188895757.2727.38.camel@blaa> <46DDD25E.2020803@filteredperception.org> Message-ID: <1189000705.5653.28.camel@localhost.localdomain> 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, it should be no sweat (relatively) to put together a > new version of the patch, updated against the 30+ commits seen since the > last version, which uses dumpe2fs in anaconda, no tarball, osmin.img > truncation, and setting loops and dms to readonly where possible. > > But, before I do that, can I get feedback from one other person, > preferably who has commit authority, to tell me that this will be > committed? Jeremy, you mentioned objections in the past? (all my > goading of said objections, was because I was so sure that there is no > remotely more correct way to accomplish the task, and I would be > genuinely entertained to be corrected on that fact) 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 that it makes anaconda depend a bit too much on a lot of the details; but I guess as long as it can fall back cleanly in the absence of the bits, that just means a larger testing matrix. Jeremy From katzj at redhat.com Wed Sep 5 14:03:40 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 05 Sep 2007 10:03:40 -0400 Subject: [PATCH] Re: [Fedora-livecd-list] booting recent livecd images In-Reply-To: References: <1188914766.4464.29.camel@localhost.localdomain> Message-ID: <1189001020.5653.31.camel@localhost.localdomain> On Tue, 2007-09-04 at 11:54 -0400, Colin Walters wrote: > Indeed, that was the problem, thanks. This seemed like it was just > waiting to bite other unaware contributors (periodic sudo cp > mayflower /usr/lib/livecd-creator is not obvious), so patch in my git > repository, and also attached. Pushed a patch that's along the same lines, but different implementation just now Jeremy From gary at mlbassoc.com Wed Sep 5 20:56:33 2007 From: gary at mlbassoc.com (Gary Thomas) Date: Wed, 05 Sep 2007 14:56:33 -0600 Subject: [Fedora-livecd-list] Building a LiveCD Message-ID: <46DF1801.8050107@mlbassoc.com> Folks, I follow this list and have read the README and Wiki, but I still have questions. To start, is there any documentation other than the sources (the README and Wiki are pretty sparse). Most of my questions are detailed and not x86 mainline :-) For example, I'd like to use my own local repositories (I work with custom systems that aren't 100% in the public trees). How do I modify the kickstart file to handle this? Also, I'm interested in building a LiveCD for PowerPC (that's my target base). I assume that I need to do this from a PPC host? Is there any other magic required? n.b. I'll be using the version from rawhide, as the FC7 release version is ExcludeArch ppc :-( Thanks -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From dmc.fedora at filteredperception.org Wed Sep 5 20:54:14 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 05 Sep 2007 15:54:14 -0500 Subject: [Fedora-livecd-list] Revised: [PATCH] turboLiveInst - improves livecd/usb installer speed by 15-20+% In-Reply-To: <1189000705.5653.28.camel@localhost.localdomain> References: <46A9AD09.7040309@filteredperception.org> <1188840606.22245.38.camel@blaa> <46DC6F89.6050706@filteredperception.org> <1188895757.2727.38.camel@blaa> <46DDD25E.2020803@filteredperception.org> <1189000705.5653.28.camel@localhost.localdomain> Message-ID: <46DF1776.3090203@filteredperception.org> 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, it should be no sweat (relatively) to put together a >> new version of the patch, updated against the 30+ commits seen since the >> last version, which uses dumpe2fs in anaconda, no tarball, osmin.img >> truncation, and setting loops and dms to readonly where possible. >> >> But, before I do that, can I get feedback from one other person, >> preferably who has commit authority, to tell me that this will be >> committed? Jeremy, you mentioned objections in the past? (all my >> goading of said objections, was because I was so sure that there is no >> remotely more correct way to accomplish the task, and I would be >> genuinely entertained to be corrected on that fact) > > 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 that it makes anaconda > depend a bit too much on a lot of the details; but I guess as long as it > can fall back cleanly in the absence of the bits, that just means a > larger testing matrix. I'm going to assume that that was a "yes I like what the code does, yes it will be applied" As far as the larger testing matrix- If you go by my suggestion, which markmc echoed, and make it the default path (along with removing the --ignore-deleted option in favor of it being default), then the testing matrix will be the same. The only reason I offered --turbo-liveinst and --cleanup/ignore-deleted as options was to ease their acceptance. I really believe that they are the 'one true way' and that there is no benefit gained by having the original code path as an option. As you said, it just means a larger testing matrix. -dmc From katzj at redhat.com Wed Sep 5 21:32:21 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 05 Sep 2007 17:32:21 -0400 Subject: [Fedora-livecd-list] Building a LiveCD In-Reply-To: <46DF1801.8050107@mlbassoc.com> References: <46DF1801.8050107@mlbassoc.com> Message-ID: <1189027941.5653.71.camel@localhost.localdomain> On Wed, 2007-09-05 at 14:56 -0600, Gary Thomas wrote: > I follow this list and have read the README and Wiki, but > I still have questions. To start, is there any documentation > other than the sources (the README and Wiki are pretty sparse). > Most of my questions are detailed and not x86 mainline :-) The README is really the extent of the current docs... patches cheerfully accepted :-) And there should be kickstart syntax docs floating around, although I don't remember where off-hand... I'll try to remember to ask clumens tomorrow > For example, I'd like to use my own local repositories (I > work with custom systems that aren't 100% in the public trees). > How do I modify the kickstart file to handle this? Repositories to use are defined by the 'repo' lines. You can use something like repo --name=foo --baseurl=http://some.web.site.com/path/to/my/repo repo --name=bar --baseurl=file:///path/to/a/local/one repo --name=baz --mirrorlist=http://some.site.com/path/to/mirrorlist Baseurl and mirrorlist are used exactly as they are with yum. > Also, I'm interested in building a LiveCD for PowerPC (that's > my target base). I assume that I need to do this from a PPC > host? Is there any other magic required? Correct. Also, the ppc support may have bugs and only boot on a small subset of ppc platforms. It's had very little in the way of testing. I pushed a few little fixes for it today. One little bit of "magic" which is helpful is that if you're building on a ppc64 box for a ppc32 target, you'll want to run livecd-creator under setarch. This is also applicable for building an i386 live CD on an x86_64 box. Jeremy From katzj at redhat.com Wed Sep 5 21:49:24 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 05 Sep 2007 17:49:24 -0400 Subject: [Fedora-livecd-list] Revised: [PATCH] turboLiveInst - improves livecd/usb installer speed by 15-20+% In-Reply-To: <46DF1776.3090203@filteredperception.org> References: <46A9AD09.7040309@filteredperception.org> <1188840606.22245.38.camel@blaa> <46DC6F89.6050706@filteredperception.org> <1188895757.2727.38.camel@blaa> <46DDD25E.2020803@filteredperception.org> <1189000705.5653.28.camel@localhost.localdomain> <46DF1776.3090203@filteredperception.org> Message-ID: <1189028964.5653.80.camel@localhost.localdomain> On Wed, 2007-09-05 at 15:54 -0500, Douglas McClendon wrote: > 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, it should be no sweat (relatively) to put together a > >> new version of the patch, updated against the 30+ commits seen since the > >> last version, which uses dumpe2fs in anaconda, no tarball, osmin.img > >> truncation, and setting loops and dms to readonly where possible. > >> > >> But, before I do that, can I get feedback from one other person, > >> preferably who has commit authority, to tell me that this will be > >> committed? Jeremy, you mentioned objections in the past? (all my > >> goading of said objections, was because I was so sure that there is no > >> remotely more correct way to accomplish the task, and I would be > >> genuinely entertained to be corrected on that fact) > > > > 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 that it makes anaconda > > depend a bit too much on a lot of the details; but I guess as long as it > > can fall back cleanly in the absence of the bits, that just means a > > larger testing matrix. > > I'm going to assume that that was a "yes I like what the code does, yes > it will be applied" I've been largely persuaded at least between your mails and markmc twisting my arm a little yesterday ;) > As far as the larger testing matrix- If you go by my suggestion, which > markmc echoed, and make it the default path (along with removing the > --ignore-deleted option in favor of it being default), then the testing > matrix will be the same. Well, the anaconda path still has to handle both cases as people could be using an older livecd-creator. That's really where the code-path explosion is. It definitely makes sense to make the new path the default in livecd-creator and probably not to really make it a separate option to enable/disable. As has probably been noticed, there are a lot fewer options now, and a good chunk are marked as "for debugging/development use only" with comments. I'm going to poke at optparse and hide them from --help too. Jeremy From dmc.fedora at filteredperception.org Wed Sep 5 22:49:14 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 05 Sep 2007 17:49:14 -0500 Subject: [Fedora-livecd-list] Revised: [PATCH] turboLiveInst - improves livecd/usb installer speed by 15-20+% In-Reply-To: <1189028964.5653.80.camel@localhost.localdomain> References: <46A9AD09.7040309@filteredperception.org> <1188840606.22245.38.camel@blaa> <46DC6F89.6050706@filteredperception.org> <1188895757.2727.38.camel@blaa> <46DDD25E.2020803@filteredperception.org> <1189000705.5653.28.camel@localhost.localdomain> <46DF1776.3090203@filteredperception.org> <1189028964.5653.80.camel@localhost.localdomain> Message-ID: <46DF326A.4040602@filteredperception.org> 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 that it makes anaconda >>> depend a bit too much on a lot of the details; but I guess as long as it >>> can fall back cleanly in the absence of the bits, that just means a >>> larger testing matrix. >> I'm going to assume that that was a "yes I like what the code does, yes >> it will be applied" > > I've been largely persuaded at least between your mails and markmc > twisting my arm a little yesterday ;) Ok. Now, for me to try to give a little on your points- I was thinking about what you said about "it makes anaconda depend a bit too much on the details". Can you clarify that a bit? Specifically, I can imagine one or two possible (but not entirely pretty) ways to change the patch, so that it makes 0 change to anaconda, at the expense of adding a fair amount of complexity to liveinst.sh. But I'm not sure what your long-term vision of liveinst.sh is. I.e. do you foresee it getting folded into anaconda at some point? -dmc From katzj at redhat.com Wed Sep 5 23:39:55 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 05 Sep 2007 19:39:55 -0400 Subject: [Fedora-livecd-list] Revised: [PATCH] turboLiveInst - improves livecd/usb installer speed by 15-20+% In-Reply-To: <46DF326A.4040602@filteredperception.org> References: <46A9AD09.7040309@filteredperception.org> <1188840606.22245.38.camel@blaa> <46DC6F89.6050706@filteredperception.org> <1188895757.2727.38.camel@blaa> <46DDD25E.2020803@filteredperception.org> <1189000705.5653.28.camel@localhost.localdomain> <46DF1776.3090203@filteredperception.org> <1189028964.5653.80.camel@localhost.localdomain> <46DF326A.4040602@filteredperception.org> Message-ID: <1189035595.8854.4.camel@localhost.localdomain> On Wed, 2007-09-05 at 17:49 -0500, Douglas McClendon wrote: > I was thinking about what you said about "it makes anaconda depend a bit > too much on the details". Can you clarify that a bit? Specifically, I > can imagine one or two possible (but not entirely pretty) ways to change > the patch, so that it makes 0 change to anaconda, at the expense of > adding a fair amount of complexity to liveinst.sh. But I'm not sure > what your long-term vision of liveinst.sh is. I.e. do you foresee it > getting folded into anaconda at some point? For all intents and purposes, liveinst is part of anaconda. It just does a tiny bit of setup and gives something that's useful to run. It will probably continue to exist, mostly because it gives people something nicer to tell people to run than saying "run anaconda with this set of options". But putting complexity there isn't better or worse really Jeremy From dmc.fedora at filteredperception.org Thu Sep 6 04:39:05 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 05 Sep 2007 23:39:05 -0500 Subject: [Fedora-livecd-list] enabling swaps automatically a good idea? Message-ID: <46DF8469.5040007@filteredperception.org> 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 then wanting to resume my F7 system after testing f8(t3)-livecd. Anybody else have an opinion one way or the other? ---- from /etc/rc.d/init.d/live in livecd-fedora-base-desktop.ks ---- +# enable swaps unless requested otherwise +swaps=\`blkid -t TYPE=swap -o device\` +if ! strstr "\`cat /proc/cmdline\`" noswap -a [ -n "\$swaps" ] ; then + for s in \$swaps ; do + action "Enabling swap partition \$s" swapon \$s + done +fi -dmc From markmc at redhat.com Thu Sep 6 09:42:52 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 06 Sep 2007 10:42:52 +0100 Subject: [Fedora-livecd-list] Revised: [PATCH] turboLiveInst - improves livecd/usb installer speed by 15-20+% In-Reply-To: <1189000705.5653.28.camel@localhost.localdomain> References: <46A9AD09.7040309@filteredperception.org> <1188840606.22245.38.camel@blaa> <46DC6F89.6050706@filteredperception.org> <1188895757.2727.38.camel@blaa> <46DDD25E.2020803@filteredperception.org> <1189000705.5653.28.camel@localhost.localdomain> Message-ID: <1189071772.2732.20.camel@blaa> On Wed, 2007-09-05 at 09:58 -0400, 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 that it makes anaconda > depend a bit too much on a lot of the details; but I guess as long as it > can fall back cleanly in the absence of the bits, that just means a > larger testing matrix. The extra details that anaconda will know about is "if there is an osmin.img, use that to create a snapshot device on top of os.img". That does raise an interesting question, I think ... there is a "protocol" between livecd-tools and anaconda, which would suggest that the kickstart configs should require[1] a minimal version of anaconda and, also, that anaconda needs to continue supporting older versions of the protocol for a while. Maybe a good way to express it would be for the anaconda RPM to "Provides: livecd-protocol = 1" and have livecd-creator check whether any of the repos provide the appropriate version before creating the livecd? (In this case, though, we probably wouldn't bump the protocol number since the fallbacks ensure continued compatibility) Just a thought ... Cheers, Mark. [1] - Yeah, I know kickstart can't do that. From ml at deadbabylon.de Thu Sep 6 09:55:11 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Thu, 6 Sep 2007 11:55:11 +0200 Subject: [Fedora-livecd-list] No /home/fedora/.bashrc with selinux=1 Message-ID: <20070906115511.63d3071d@htpc> Hi. I've noticed a little problem when booting with selinux enabled: /home/fedora/.bashrc would not be copied/created. When booting with enforcing=0 all would be fine so I assume this is a selinux problem. But I've found no entry in /var/log/messages or /var/log/audit/audit.log. When I create a new user with adduser the bashrc is there. Any suggestion how to debug this? I've attached audit.log and messages if I've overlooked something (booted with selinux=1). Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: audit.log Type: text/x-log Size: 4959 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: messages Type: application/octet-stream Size: 32972 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Sep 6 11:05:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 6 Sep 2007 07:05:41 -0400 Subject: [Fedora-livecd-list] enabling swaps automatically a good idea? In-Reply-To: <46DF8469.5040007@filteredperception.org> References: <46DF8469.5040007@filteredperception.org> Message-ID: <20070906070541.3f5356fd@ender> On Wed, 05 Sep 2007 23:39:05 -0500 Douglas McClendon wrote: > 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 then wanting to resume my F7 system after testing > f8(t3)-livecd. I was under the assumption that it was scanned for a suspend signature before being enabled. But I didn't look at the code to verify. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gary at mlbassoc.com Thu Sep 6 11:24:59 2007 From: gary at mlbassoc.com (Gary Thomas) Date: Thu, 06 Sep 2007 05:24:59 -0600 Subject: [Fedora-livecd-list] Building a LiveCD In-Reply-To: <1189027941.5653.71.camel@localhost.localdomain> References: <46DF1801.8050107@mlbassoc.com> <1189027941.5653.71.camel@localhost.localdomain> Message-ID: <46DFE38B.3030403@mlbassoc.com> Jeremy Katz wrote: > On Wed, 2007-09-05 at 14:56 -0600, Gary Thomas wrote: >> I follow this list and have read the README and Wiki, but >> I still have questions. To start, is there any documentation >> other than the sources (the README and Wiki are pretty sparse). >> Most of my questions are detailed and not x86 mainline :-) > > The README is really the extent of the current docs... patches > cheerfully accepted :-) And there should be kickstart syntax docs > floating around, although I don't remember where off-hand... I'll try > to remember to ask clumens tomorrow > Once I learn enough to make such comments/changes, I'll see what I can do to help improve the docs. >> For example, I'd like to use my own local repositories (I >> work with custom systems that aren't 100% in the public trees). >> How do I modify the kickstart file to handle this? > > Repositories to use are defined by the 'repo' lines. You can use > something like > repo --name=foo --baseurl=http://some.web.site.com/path/to/my/repo > repo --name=bar --baseurl=file:///path/to/a/local/one > repo --name=baz --mirrorlist=http://some.site.com/path/to/mirrorlist > > Baseurl and mirrorlist are used exactly as they are with yum. This helped and I was able to build an image. Sadly, it failed with the oft-reported problem of not finding the CDROM root device (no CDROM driver in image?) I need to investigate this some. BTW - I'm testing this on a Mac Mini and also iBook. Once I get it working, I'll move on to my custom hardware. >> Also, I'm interested in building a LiveCD for PowerPC (that's >> my target base). I assume that I need to do this from a PPC >> host? Is there any other magic required? > > Correct. Also, the ppc support may have bugs and only boot on a small > subset of ppc platforms. It's had very little in the way of testing. I > pushed a few little fixes for it today. Thanks for the info. Forgive an outsider's question, but how can I access these changes (read only GIT pull would be fine)? -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From katzj at redhat.com Thu Sep 6 14:36:34 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 06 Sep 2007 10:36:34 -0400 Subject: [Fedora-livecd-list] Building a LiveCD In-Reply-To: <46DFE38B.3030403@mlbassoc.com> References: <46DF1801.8050107@mlbassoc.com> <1189027941.5653.71.camel@localhost.localdomain> <46DFE38B.3030403@mlbassoc.com> Message-ID: <1189089394.4437.5.camel@localhost.localdomain> On Thu, 2007-09-06 at 05:24 -0600, Gary Thomas wrote: > Jeremy Katz wrote: > > On Wed, 2007-09-05 at 14:56 -0600, Gary Thomas wrote: > >> For example, I'd like to use my own local repositories (I > >> work with custom systems that aren't 100% in the public trees). > >> How do I modify the kickstart file to handle this? > > > > Repositories to use are defined by the 'repo' lines. You can use > > something like > > repo --name=foo --baseurl=http://some.web.site.com/path/to/my/repo > > repo --name=bar --baseurl=file:///path/to/a/local/one > > repo --name=baz --mirrorlist=http://some.site.com/path/to/mirrorlist > > > > Baseurl and mirrorlist are used exactly as they are with yum. > > This helped and I was able to build an image. Sadly, it failed > with the oft-reported problem of not finding the CDROM root device > (no CDROM driver in image?) I need to investigate this some. Some macs are apparently still using old IDE; I added ide-cd to the list of modules being pulled in earlier to account for this > >> Also, I'm interested in building a LiveCD for PowerPC (that's > >> my target base). I assume that I need to do this from a PPC > >> host? Is there any other magic required? > > > > Correct. Also, the ppc support may have bugs and only boot on a small > > subset of ppc platforms. It's had very little in the way of testing. I > > pushed a few little fixes for it today. > > Thanks for the info. Forgive an outsider's question, but how can I > access these changes (read only GIT pull would be fine)? You can get an anonymous clone of current git via git clone git://git.fedoraproject.org/hosted/livecd Jeremy From katzj at redhat.com Thu Sep 6 14:38:00 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 06 Sep 2007 10:38:00 -0400 Subject: [Fedora-livecd-list] enabling swaps automatically a good idea? In-Reply-To: <46DF8469.5040007@filteredperception.org> References: <46DF8469.5040007@filteredperception.org> Message-ID: <1189089480.4437.7.camel@localhost.localdomain> On Wed, 2007-09-05 at 23:39 -0500, Douglas McClendon wrote: > 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 then wanting to resume my F7 system after testing > f8(t3)-livecd. A swsusp swap shouldn't have a normal swap signature and thus shouldn't be found as a potential swap to use. Which should make things pretty safe as a default Jeremy From katzj at redhat.com Thu Sep 6 15:18:58 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 06 Sep 2007 11:18:58 -0400 Subject: [Fedora-livecd-list] No /home/fedora/.bashrc with selinux=1 In-Reply-To: <20070906115511.63d3071d@htpc> References: <20070906115511.63d3071d@htpc> Message-ID: <1189091938.4437.13.camel@localhost.localdomain> On Thu, 2007-09-06 at 11:55 +0200, Sebastian Vahl wrote: > I've noticed a little problem when booting with selinux > enabled: /home/fedora/.bashrc would not be copied/created. When booting > with enforcing=0 all would be fine so I assume this is a selinux > problem. But I've found no entry in /var/log/messages > or /var/log/audit/audit.log. This may be due to a policy problem that Dan has a new policy building for... will hopefully know more soon-ish. Jeremy From katzj at redhat.com Thu Sep 6 17:15:16 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 06 Sep 2007 13:15:16 -0400 Subject: [Fedora-livecd-list] No /home/fedora/.bashrc with selinux=1 In-Reply-To: <1189091938.4437.13.camel@localhost.localdomain> References: <20070906115511.63d3071d@htpc> <1189091938.4437.13.camel@localhost.localdomain> Message-ID: <1189098916.23094.0.camel@localhost.localdomain> On Thu, 2007-09-06 at 11:18 -0400, Jeremy Katz wrote: > On Thu, 2007-09-06 at 11:55 +0200, Sebastian Vahl wrote: > > I've noticed a little problem when booting with selinux > > enabled: /home/fedora/.bashrc would not be copied/created. When booting > > with enforcing=0 all would be fine so I assume this is a selinux > > problem. But I've found no entry in /var/log/messages > > or /var/log/audit/audit.log. > > This may be due to a policy problem that Dan has a new policy building > for... will hopefully know more soon-ish. Confirmed that new policy fixes this Jeremy From gary at mlbassoc.com Thu Sep 6 20:07:23 2007 From: gary at mlbassoc.com (Gary Thomas) Date: Thu, 06 Sep 2007 14:07:23 -0600 Subject: [Fedora-livecd-list] Building a LiveCD In-Reply-To: <1189089394.4437.5.camel@localhost.localdomain> References: <46DF1801.8050107@mlbassoc.com> <1189027941.5653.71.camel@localhost.localdomain> <46DFE38B.3030403@mlbassoc.com> <1189089394.4437.5.camel@localhost.localdomain> Message-ID: <46E05DFB.8080803@mlbassoc.com> Jeremy Katz wrote: > On Thu, 2007-09-06 at 05:24 -0600, Gary Thomas wrote: >> Jeremy Katz wrote: >>> On Wed, 2007-09-05 at 14:56 -0600, Gary Thomas wrote: >>>> For example, I'd like to use my own local repositories (I >>>> work with custom systems that aren't 100% in the public trees). >>>> How do I modify the kickstart file to handle this? >>> Repositories to use are defined by the 'repo' lines. You can use >>> something like >>> repo --name=foo --baseurl=http://some.web.site.com/path/to/my/repo >>> repo --name=bar --baseurl=file:///path/to/a/local/one >>> repo --name=baz --mirrorlist=http://some.site.com/path/to/mirrorlist >>> >>> Baseurl and mirrorlist are used exactly as they are with yum. >> This helped and I was able to build an image. Sadly, it failed >> with the oft-reported problem of not finding the CDROM root device >> (no CDROM driver in image?) I need to investigate this some. > > Some macs are apparently still using old IDE; I added ide-cd to the list > of modules being pulled in earlier to account for this > >>>> Also, I'm interested in building a LiveCD for PowerPC (that's >>>> my target base). I assume that I need to do this from a PPC >>>> host? Is there any other magic required? >>> Correct. Also, the ppc support may have bugs and only boot on a small >>> subset of ppc platforms. It's had very little in the way of testing. I >>> pushed a few little fixes for it today. >> Thanks for the info. Forgive an outsider's question, but how can I >> access these changes (read only GIT pull would be fine)? > > You can get an anonymous clone of current git via > git clone git://git.fedoraproject.org/hosted/livecd Perfect - I updated to the GIT version and now it boots on my two test systems. Now, on to the interesting work of getting it to go on my non-standard platforms :-) Thanks -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From vrusathalye at rediffmail.com Fri Sep 7 06:58:31 2007 From: vrusathalye at rediffmail.com (Vrushali Athalye) Date: 7 Sep 2007 06:58:31 -0000 Subject: [Fedora-livecd-list] (no subject) Message-ID: <20070907065831.10121.qmail@webmail58.rediffmail.com> ? Hi All, We Downloaded Live CD for Fedora 7 from fedora official website.We are trying to run the live CD from one of DELL OPTIPLEX 320 but we are unable to run successfully .Once the kernel is loading the system got hannged and keyboard not responding.We tried google to find out the errors but we didnt get any suessful solutions. IN The screen we are getting these messages Loading Vmlinuz........ Loading initrd.img................................... ................. Ready uncompressing Linux....Ok,booting the kernel. After that system got hanged.... Kindly help me in this issue.. AS it is very urgent for us .We also tried with fedora 6 and CENT-OS 4.4 live cDs but we faced the same problems... Regards., Vrushali ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From markmc at redhat.com Fri Sep 7 09:16:19 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 07 Sep 2007 10:16:19 +0100 Subject: Debug options [was Re: [Fedora-livecd-list] Revised: [PATCH] turboLiveInst - improves livecd/usb installer speed by 15-20+%] In-Reply-To: <1189028964.5653.80.camel@localhost.localdomain> References: <46A9AD09.7040309@filteredperception.org> <1188840606.22245.38.camel@blaa> <46DC6F89.6050706@filteredperception.org> <1188895757.2727.38.camel@blaa> <46DDD25E.2020803@filteredperception.org> <1189000705.5653.28.camel@localhost.localdomain> <46DF1776.3090203@filteredperception.org> <1189028964.5653.80.camel@localhost.localdomain> Message-ID: <1189156579.2732.85.camel@blaa> Hi Jeremy, On Wed, 2007-09-05 at 17:49 -0400, Jeremy Katz wrote: > As has probably been noticed, there are a lot fewer > options now, and a good chunk are marked as "for debugging/development > use only" with comments. One option that I'm missing at the moment is the "--repo" option. I know the syntax sucked, and you couldn't specify a mirror list, but I found it useful where you have default URLs of the repos in the kickstart file but you expect most users to have a more local mirror of those repos. Allowing them to just override on the command line is much nicer than requiring them to edit the kickstart file. e.g. the instructions to a developer might be: $> git-clone kickstarts $> cd kickstarts $> livecd-creator --repo fedora,file:///my/mirror -c foo.ks $> $> git-commit but now it's: $> git-clone kickstarts $> cd kickstarts $> $> livecd-creator -c foo.ks $> $> $> git-commit Cheers, Mark. From alexm at asic.udl.cat Fri Sep 7 11:01:19 2007 From: alexm at asic.udl.cat (=?ISO-8859-1?Q?Alexandre_Magaz_Gra=E7a?=) Date: Fri, 07 Sep 2007 13:01:19 +0200 Subject: [Fedora-livecd-list] bug writing isolinux menu entries Message-ID: <46E12F7F.5090102@asic.udl.cat> Hi, I've found a bug in how livecd-creator adds entries in isolinux menu. There must be a newline after the memtest entry, otherwise the next entry gets merged with this one. The attached patch fixes this. Cheers, ?lex -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-memtest-entry.patch Type: text/x-patch Size: 437 bytes Desc: not available URL: From katzj at redhat.com Fri Sep 7 13:58:32 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 07 Sep 2007 09:58:32 -0400 Subject: [Fedora-livecd-list] bug writing isolinux menu entries In-Reply-To: <46E12F7F.5090102@asic.udl.cat> References: <46E12F7F.5090102@asic.udl.cat> Message-ID: <1189173512.30553.0.camel@localhost.localdomain> On Fri, 2007-09-07 at 13:01 +0200, Alexandre Magaz Gra?a wrote: > I've found a bug in how livecd-creator adds entries in isolinux menu. > There must be a newline after the memtest entry, otherwise the next > entry gets merged with this one. The attached patch fixes this. Thanks, applied Jeremy From katzj at redhat.com Fri Sep 7 14:18:06 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 07 Sep 2007 10:18:06 -0400 Subject: [Fedora-livecd-list] Re: Debug options In-Reply-To: <1189156579.2732.85.camel@blaa> References: <46A9AD09.7040309@filteredperception.org> <1188840606.22245.38.camel@blaa> <46DC6F89.6050706@filteredperception.org> <1188895757.2727.38.camel@blaa> <46DDD25E.2020803@filteredperception.org> <1189000705.5653.28.camel@localhost.localdomain> <46DF1776.3090203@filteredperception.org> <1189028964.5653.80.camel@localhost.localdomain> <1189156579.2732.85.camel@blaa> Message-ID: <1189174686.30553.9.camel@localhost.localdomain> On Fri, 2007-09-07 at 10:16 +0100, Mark McLoughlin wrote: > On Wed, 2007-09-05 at 17:49 -0400, Jeremy Katz wrote: > > As has probably been noticed, there are a lot fewer > > options now, and a good chunk are marked as "for debugging/development > > use only" with comments. > > One option that I'm missing at the moment is the "--repo" option. > > I know the syntax sucked, and you couldn't specify a mirror list, but I > found it useful where you have default URLs of the repos in the > kickstart file but you expect most users to have a more local mirror of > those repos. Allowing them to just override on the command line is much > nicer than requiring them to edit the kickstart file. So my biggest problem with the repo option wasn't really the syntax, but more the impact on having reproducible configs. If your image is created using an arbitrary new set of repos specified on the command line, that makes it harder to pass out the configs for other people to build on top of your images. But I can see where having an override to point at a local location for a repo can be helpful. I can see two ways of doing it 1) Make another repo command with the same repo id just override the repo rather than spit an error. This would then mean you could have my-local-ks.cfg with a %include of the base config and then a repo line pointing to your local repo 2) A --repo-override that overrides a given repo id using similar syntax to the old --repo option Jeremy From jkeating at redhat.com Fri Sep 7 14:30:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 7 Sep 2007 10:30:31 -0400 Subject: [Fedora-livecd-list] Re: Debug options In-Reply-To: <1189174686.30553.9.camel@localhost.localdomain> References: <46A9AD09.7040309@filteredperception.org> <1188840606.22245.38.camel@blaa> <46DC6F89.6050706@filteredperception.org> <1188895757.2727.38.camel@blaa> <46DDD25E.2020803@filteredperception.org> <1189000705.5653.28.camel@localhost.localdomain> <46DF1776.3090203@filteredperception.org> <1189028964.5653.80.camel@localhost.localdomain> <1189156579.2732.85.camel@blaa> <1189174686.30553.9.camel@localhost.localdomain> Message-ID: <20070907103031.28a576b4@mentok.boston.redhat.com> On Fri, 07 Sep 2007 10:18:06 -0400 Jeremy Katz wrote: > So my biggest problem with the repo option wasn't really the syntax, > but more the impact on having reproducible configs. If your image is > created using an arbitrary new set of repos specified on the command > line, that makes it harder to pass out the configs for other people to > build on top of your images. Another hard thing about --repo lines is how do you express things like excludes or includes from that repo, or eventually the cost of that repo for the sake of download choice? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Fri Sep 7 14:36:45 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 07 Sep 2007 10:36:45 -0400 Subject: [Fedora-livecd-list] Re: Debug options In-Reply-To: <20070907103031.28a576b4@mentok.boston.redhat.com> References: <46A9AD09.7040309@filteredperception.org> <1188840606.22245.38.camel@blaa> <46DC6F89.6050706@filteredperception.org> <1188895757.2727.38.camel@blaa> <46DDD25E.2020803@filteredperception.org> <1189000705.5653.28.camel@localhost.localdomain> <46DF1776.3090203@filteredperception.org> <1189028964.5653.80.camel@localhost.localdomain> <1189156579.2732.85.camel@blaa> <1189174686.30553.9.camel@localhost.localdomain> <20070907103031.28a576b4@mentok.boston.redhat.com> Message-ID: <1189175805.30553.11.camel@localhost.localdomain> On Fri, 2007-09-07 at 10:30 -0400, Jesse Keating wrote: > On Fri, 07 Sep 2007 10:18:06 -0400 > Jeremy Katz wrote: > > > So my biggest problem with the repo option wasn't really the syntax, > > but more the impact on having reproducible configs. If your image is > > created using an arbitrary new set of repos specified on the command > > line, that makes it harder to pass out the configs for other people to > > build on top of your images. > > Another hard thing about --repo lines is how do you express things like > excludes or includes from that repo, or eventually the cost of that > repo for the sake of download choice? That's why I'd only be up for doing it as an explicit "override the URL for this repo" and not any of the more general pieces. Then all of the other stuff has to be in the config, you're just saying "hey, for fedora development, I have something that's a lot easier to get at located at file:///home/katzj/rawhide/i386" Jeremy From jkeating at redhat.com Fri Sep 7 15:09:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 7 Sep 2007 11:09:35 -0400 Subject: [Fedora-livecd-list] Re: Debug options In-Reply-To: <1189175805.30553.11.camel@localhost.localdomain> References: <46A9AD09.7040309@filteredperception.org> <1188840606.22245.38.camel@blaa> <46DC6F89.6050706@filteredperception.org> <1188895757.2727.38.camel@blaa> <46DDD25E.2020803@filteredperception.org> <1189000705.5653.28.camel@localhost.localdomain> <46DF1776.3090203@filteredperception.org> <1189028964.5653.80.camel@localhost.localdomain> <1189156579.2732.85.camel@blaa> <1189174686.30553.9.camel@localhost.localdomain> <20070907103031.28a576b4@mentok.boston.redhat.com> <1189175805.30553.11.camel@localhost.localdomain> Message-ID: <20070907110935.09350c98@mentok.boston.redhat.com> On Fri, 07 Sep 2007 10:36:45 -0400 Jeremy Katz wrote: > That's why I'd only be up for doing it as an explicit "override the > URL for this repo" and not any of the more general pieces. Then all > of the other stuff has to be in the config, you're just saying "hey, > for fedora development, I have something that's a lot easier to get > at located at file:///home/katzj/rawhide/i386" Yeah, I think that makes a lot of sense. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lars.bjorndal at broadpark.no Sat Sep 8 09:34:26 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Sat, 08 Sep 2007 11:34:26 +0200 Subject: [Fedora-livecd-list] Revisor: Instroot problem In-Reply-To: <46DB06BC.2030006@kanarip.com> References: <46DB06BC.2030006@kanarip.com> Message-ID: I still have problems, with commit b4f701a612fe0e89210ae06c6650478b70175d7 from yesterday evening. First, I tried revisor with the following command: revisor --model=f7-modified --live-optical and all worked fine. Then, I added the option '--kickstart=my-kickstart-file.ks', and I got the following error: /sbin/restorecon reset /var/named/chroot context root:object_r:named_zone_t:s0->system_u:object_r:named_conf_t:s0 /sbin/restorecon reset /var/named/chroot/etc context root:object_r:named_zone_t:s0->system_u:object_r:named_conf_t:s0 /sbin/restorecon reset /var/named/chroot/var context root:object_r:named_zone_t:s0->system_u:object_r:named_conf_t:s0 /sbin/restorecon reset /root/.gnome2 context root:object_r:user_home_dir_t:s0->root:object_r:user_home_t:s0 Relabel System: Initting progress bar for Configure BootLoader Configure BootLoader: Traceback (most recent call last): File "/usr/sbin/revisor", line 290, in revisorBase.run() File "/usr/lib/python2.5/site-packages/revisor/cli.py", line 42, in run self.base.lift_off() File "/usr/lib/python2.5/site-packages/revisor/base.py", line 859, in lift_off self.buildLiveMedia() File "/usr/lib/python2.5/site-packages/revisor/base.py", line 1373, in buildLiveMedia liveImage.configureBootloader() File "/usr/lib/python2.5/site-packages/revisor/pilgrim.py", line 722, in configureBootloader "%s/out/isolinux/%s" %(self.build_dir, kernel["vmlinuz"])) File "/usr/lib/python2.5/shutil.py", line 46, in copyfile fsrc = open(src, 'rb') IOError: [Errno 2] No such file or directory: '/var/tmp/revisor-livecd/install_root/boot/vmlinuz-2.6.22.1-41.fc7' Is this a problem with my kickstart file? Would you like to see it? Thanks Lars Jeroen van Meeuwen writes: > Lars Bj?rndal wrote: >> Hello! >> With GIT version of Revisor commit >> 0ad6a3da49ff75fbfcd5802c5b03de51d9d014ac, I got a problem: >> Initting progress bar for Configure System >> Configure System: >> Setting SELinux to: 1 >> Setting crypted root password >> /var/tmp/revisor-livecd/install_root >> /var/tmp/revisor-livecd/install_root >> /var/tmp/revisor-livecd/install_root >> Xorg is installed: True >> Traceback (most recent call last): >> File "/usr/sbin/revisor", line 293, in >> revisorBase.run() >> File "/usr/lib/python2.5/site-packages/revisor/cli.py", line 45, in run >> self.base.lift_off() >> File "/usr/lib/python2.5/site-packages/revisor/base.py", line 894, in lift_off >> self.buildLiveMedia() >> File "/usr/lib/python2.5/site-packages/revisor/base.py", line 1367, in buildLiveMedia >> liveImage.extra_configuration() >> File "/usr/lib/python2.5/site-packages/revisor/lm_optical.py", line 151, in extra_configuration >> f = open("%s/etc/inittab" %(instroot,), "rw+") >> NameError: global name 'instroot' is not defined >> [root at cd ~]# >> Is this a known problem/bug? >> > > Yes, I know it has been a problem. So is the number of references we > have to kickstart objects that do not exist anymore (at least in GUI > mode) since I've moved to using another kickstart object to get > Revisor going on EL5 as well. > > I've been having troubles at my home network; I'll be kicking this > bug's ass tomorrow hopefully. > > Kind regards, > > Jeroen van Meeuwen > -kanarip From bernardino.lopez at gmail.com Sun Sep 9 16:56:58 2007 From: bernardino.lopez at gmail.com (Dino Lopez) Date: Sun, 9 Sep 2007 11:56:58 -0500 Subject: [Fedora-livecd-list] Fedora 7 in 1GB USB with RW capabilities for Configuration. Message-ID: <4209097b0709090956s747eb694x730c4497444b6f65@mail.gmail.com> 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 own user and tweak the network and some minor changes and add on rpm's noticed on my next reboot the fact that the changes did not got saved. Last night talking about the subject, a friend told me he can save his data with Ubuntu and find out there is a way: "According to official web page you need to use casper-rw lable instead of casper-cow." https://wiki.ubuntu.com/LiveUsbPendrivePersistent I wonder if you have some ideas on how to get this done, I'm a RedHat Junkie, and don't like the idea to switch to another distro. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmc.fedora at filteredperception.org Sun Sep 9 19:48:01 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 09 Sep 2007 14:48:01 -0500 Subject: [Fedora-livecd-list] Fedora 7 in 1GB USB with RW capabilities for Configuration. In-Reply-To: <4209097b0709090956s747eb694x730c4497444b6f65@mail.gmail.com> References: <4209097b0709090956s747eb694x730c4497444b6f65@mail.gmail.com> Message-ID: <46E44DF1.20805@filteredperception.org> 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 own user and tweak the network and some > minor changes and add on rpm's noticed on my next > reboot the fact that the changes did not got saved. > > Last night talking about the subject, a friend told me > he can save his data with Ubuntu and find out there is > a way: > > "According to official web page you need to use > casper-rw lable instead of casper-cow." > > https://wiki.ubuntu.com/LiveUsbPendrivePersistent > > I wonder if you have some ideas on how to get this > done, I'm a RedHat Junkie, and don't like the idea to > switch to another distro. This has been discussed quite a bit, and some code does exist. Search the archives of this list for 'peristence'. But its really not ready for prime time yet. It's somewhat unclear at the moment what will actually be in F8. (*cough* *cough* not yet an official proposed feature with a wiki url I could refer Dino Lopez to *cough* *cough*) -dmc From tve at voneicken.com Mon Sep 10 07:21:31 2007 From: tve at voneicken.com (Thorsten von Eicken) Date: Mon, 10 Sep 2007 00:21:31 -0700 Subject: [Fedora-livecd-list] boot failure on VIA Epia M-6000 board In-Reply-To: <46DC3CE8.4000705@voneicken.com> References: <46D25265.9080904@voneicken.com> <20070827140849.GY29579@gospo.rdu.redhat.com> <46D2F591.8030203@voneicken.com> <20070827171515.GE29579@gospo.rdu.redhat.com> <46D3AF6F.4060107@voneicken.com> <20070829152612.GA32421@gospo.rdu.redhat.com> <46D59568.4050908@voneicken.com> <20070829210001.GF32421@gospo.rdu.redhat.com> <46D64446.7080003@voneicken.com> <46DC3CE8.4000705@voneicken.com> Message-ID: <46E4F07B.20303@voneicken.com> After a lot of back and forth I finally managed to get a good livecd image for my VIA EPIA M-6000 mini-itx board using a 1GB CF card plugged into the IDE interface. The key tricks were: - compile a custom kernel that excluded the new libata and instead contains the older ide drivers, also compile for the Cyrix-III processor instead of i686 - explicitly select i386 or i586 RPMs from the repositories where necessary (e.g. glibc, kernel-headers, openssl, etc...) - remove the explicit loading hack for the sr_mod driver in mayflower I'm attaching the kernel config file in case someone else wants to replicate the set-up. The mayflower change consists of commenting out the modprobe around line 410 of /usr/lib/livecd-creator/mayflower: # FIXME: hack since sr_mod seems to fail to get loaded sometimes (#239657) #/sbin/modprobe sr_mod The kickstart I use for a relatively small set-up follows below. Note the reference to the locally built kernel which you may have to change. I hope this helps someone... Thorsten lang en_US.UTF-8 keyboard us timezone US/Pacific auth --useshadow --enablemd5 selinux --enforcing firewall --disabled skipx repo --name=a-local --baseurl=file:///root/rpmbuild/RPMS/i386 repo --name=a-dev --baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/7/Everything/i386/os/ #repo --name=a-extras-dev --baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386 %packages bash kernel-2.6.22.4epia #kernel-2.6.21-1.3194.fc7.i586 kernel-devel-2.6.21-1.3194.fc7.i586 kernel-headers-2.6.21-1.3194.fc7.i386 glibc-2.6-3.i386 glibc-common-2.6-3.i386 glibc-devel-2.6-3.i386 glibc-headers-2.6-3.i386 syslinux passwd policycoreutils chkconfig authconfig rootfiles wget logrotate ruby* rubygems syslog-ng openssl-0.9.8b-12.fc7.i386 openssh openssh-askpass openssh-clients openssh-server curl gcc* zip unzip bison flex compat-libstdc++-296 subversion autoconf automake libtool vim-minimal yum # the following are needed to generate the iso filesystem nash cpio gzip findutils squashfs-tools genisoimage -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config-f7-20070908-epia URL: From kanarip at kanarip.com Mon Sep 10 08:18:12 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 10 Sep 2007 10:18:12 +0200 Subject: [Fedora-livecd-list] Revisor: Instroot problem In-Reply-To: References: <46DB06BC.2030006@kanarip.com> Message-ID: <46E4FDC4.5010308@kanarip.com> Lars Bj?rndal wrote: > Traceback (most recent call last): > File "/usr/sbin/revisor", line 290, in > revisorBase.run() > File "/usr/lib/python2.5/site-packages/revisor/cli.py", line 42, in run > self.base.lift_off() > File "/usr/lib/python2.5/site-packages/revisor/base.py", line 859, in lift_off > self.buildLiveMedia() > File "/usr/lib/python2.5/site-packages/revisor/base.py", line 1373, in buildLiveMedia > liveImage.configureBootloader() > File "/usr/lib/python2.5/site-packages/revisor/pilgrim.py", line 722, in configureBootloader > "%s/out/isolinux/%s" %(self.build_dir, kernel["vmlinuz"])) > File "/usr/lib/python2.5/shutil.py", line 46, in copyfile > fsrc = open(src, 'rb') > IOError: [Errno 2] No such file or directory: '/var/tmp/revisor-livecd/install_root/boot/vmlinuz-2.6.22.1-41.fc7' > Could you tell me what is in /var/tmp/revisor-livecd/install_root/boot/ after you get this error? Kind regards, Jeroen van Meeuwen -kanarip -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 From lars.bjorndal at broadpark.no Mon Sep 10 09:03:25 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Mon, 10 Sep 2007 11:03:25 +0200 Subject: [Fedora-livecd-list] Revisor: Instroot problem In-Reply-To: <46E4FDC4.5010308@kanarip.com> References: <46DB06BC.2030006@kanarip.com> <46E4FDC4.5010308@kanarip.com> Message-ID: Jeroen van Meeuwen writes: > Lars Bj?rndal wrote: >> Traceback (most recent call last): >> File "/usr/sbin/revisor", line 290, in >> revisorBase.run() >> File "/usr/lib/python2.5/site-packages/revisor/cli.py", line 42, in run >> self.base.lift_off() >> File "/usr/lib/python2.5/site-packages/revisor/base.py", line 859, in lift_off >> self.buildLiveMedia() >> File "/usr/lib/python2.5/site-packages/revisor/base.py", line 1373, in buildLiveMedia >> liveImage.configureBootloader() >> File "/usr/lib/python2.5/site-packages/revisor/pilgrim.py", line 722, in configureBootloader >> "%s/out/isolinux/%s" %(self.build_dir, kernel["vmlinuz"])) >> File "/usr/lib/python2.5/shutil.py", line 46, in copyfile >> fsrc = open(src, 'rb') >> IOError: [Errno 2] No such file or directory: '/var/tmp/revisor-livecd/install_root/boot/vmlinuz-2.6.22.1-41.fc7' >> > > Could you tell me what is in > /var/tmp/revisor-livecd/install_root/boot/ after you get this error? The boot directory does not exist. The only content in /var/tmp/revisor-livecd/install_root is: ./var ./var/run ./var/run/yum.pid ./var/lib ./var/lib/rpm ./var/lib/rpm/__db.002 ./var/lib/rpm/Providename ./var/lib/rpm/__db.003 ./var/lib/rpm/Packages ./var/lib/rpm/Basenames ./var/lib/rpm/__db.001 ./etc ./etc/yum.conf Best regards, Lars From kanarip at kanarip.com Mon Sep 10 09:35:29 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 10 Sep 2007 11:35:29 +0200 Subject: [Fedora-livecd-list] Revisor: Instroot problem In-Reply-To: References: <46DB06BC.2030006@kanarip.com> <46E4FDC4.5010308@kanarip.com> Message-ID: <46E50FE1.7060604@kanarip.com> Lars Bj?rndal wrote: > The boot directory does not exist. The only content in > /var/tmp/revisor-livecd/install_root is: > > ./var > ./var/run > ./var/run/yum.pid > ./var/lib > ./var/lib/rpm > ./var/lib/rpm/__db.002 > ./var/lib/rpm/Providename > ./var/lib/rpm/__db.003 > ./var/lib/rpm/Packages > ./var/lib/rpm/Basenames > ./var/lib/rpm/__db.001 > ./etc > ./etc/yum.conf > If that's it, something else must have gone terribly wrong. Before configuring the bootloader, at least some RPM packages should have gotten installed. Any other output I may want to know about? -- Kind regards, Jeroen van Meeuwen -kanarip -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 From dmc.fedora at filteredperception.org Mon Sep 10 15:15:01 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 10 Sep 2007 10:15:01 -0500 Subject: [Fedora-livecd-list] RFC- unionfs persistence? Message-ID: <46E55F75.1080707@filteredperception.org> 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 used devicemapper for their COW long ago (early 2005). But that they abandoned that in favor of the 'flexibility' of unionfs. I know that unionfs was ruled out as an option for Fedora, because it was being kept out of the repos. In fact, before pilgrim/livecd-creator came into existence, I posted a proof of concept fedora unionfs-based livecd infrastructure- http://www.redhat.com/archives/fedora-livecd-list/2006-April/msg00197.html But a lot has changed in the last 18 months. It seems that unionfs is in the -mm kernel tree, and between that, fuse-unionfs, and aufs, it seems pretty likely that some flavor of unionfs will make it into fedora in the foreseeable future. Given that, and given the multitude of other projects I could be working on, makes me wonder how much time I should spend working on devicemapper persistence, if the vast majority of livecds out there are using unionfs, and unionfs may become an option for fedora in the near future. Comments? Thanks, -dmc From lars.bjorndal at broadpark.no Mon Sep 10 16:30:28 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Mon, 10 Sep 2007 18:30:28 +0200 Subject: [Fedora-livecd-list] Revisor: Instroot problem In-Reply-To: <46E50FE1.7060604@kanarip.com> References: <46DB06BC.2030006@kanarip.com> <46E4FDC4.5010308@kanarip.com> <46E50FE1.7060604@kanarip.com> Message-ID: Jeroen van Meeuwen writes: > Lars Bj?rndal wrote: >> The boot directory does not exist. The only content in >> /var/tmp/revisor-livecd/install_root is: >> ./var >> ./var/run ... > If that's it, something else must have gone terribly wrong. Before > configuring the bootloader, at least some RPM packages should have > gotten installed. Any other output I may want to know about? I'll try: revisor --model=lrs --live-optical --kickstart=/etc/livecd-console-rev.ks --debug {'modrebrand': False, 'modjigdo': False, 'modcobbler': False, 'moddelta': False, 'modvirt': False} Setting default options Setting options from configuration file Reading configuration file /etc/revisor/revisor.conf Setting repos_enabledevelopment to 0 (from configuration file) Setting repos_enabletesting to 0 (from configuration file) Setting media_installation_cd to 0 (from configuration file) Setting media_installation_dvd to 0 (from configuration file) Setting mode_respin to 0 (from configuration file) Setting repos_enablesource to 0 (from configuration file) Setting media_live_optical to 0 (from configuration file) Setting dependency_resolve_allow_conflicts to 0 (from configuration file) Setting repos_enabledebuginfo to 0 (from configuration file) Setting media_live_thumb to 0 (from configuration file) Using model lrs, as specified by --model Setting architecture to 'i386' (from configuration file model lrs) Setting iso_basename to 'F' (from configuration file model lrs) Setting getsource to 0 (from configuration file model lrs) Setting version to '7' (from configuration file model lrs) Setting product_path to 'Fedora' (from configuration file model lrs) Setting product_name to 'Fedora' (from configuration file model lrs) Setting comps to '/usr/share/revisor/comps/comps-f7.xml' (from configuration file model lrs) Setting options from command-line Running Revisor in CLI mode... Running main routine... Running in CLI mode... Setting architecture to 'i386' (from configuration file model lrs) Setting iso_basename to 'F' (from configuration file model lrs) Setting getsource to 0 (from configuration file model lrs) Setting version to '7' (from configuration file model lrs) Setting product_path to 'Fedora' (from configuration file model lrs) Setting product_name to 'Fedora' (from configuration file model lrs) Setting comps to '/usr/share/revisor/comps/comps-f7.xml' (from configuration file model lrs) Checking working directories The directories Revisor uses in /var/tmp/ already exist. This could possibly hold data from a previous run. Please remove or move them to a safe location, then confirm to continue. If you do not move or remove the files, Revisor will simply delete them. Do you want to continue? [Y/n] y Checking destination directories Set destination directory to /srv/revisor/lrs The directories Revisor uses in /srv/revisor/lrs already exist. This could possibly hold data from a previous run. Please remove or move them to a safe location, then confirm to continue. If you do not move or remove the files, Revisor will simply delete them. Do you want to continue? [Y/n] y Initting progress bar for Loading Repositories Loading Repositories: See, this is our list of packages right now: [] Adding Live Media Required Packages Adding required packages for Live Media Adding req. pkg grub-0:0.97-13.i386 Adding req. pkg kernel-0:2.6.22.4-65.fc7.i686 Adding req. pkg mailx-0:8.1.1-46.fc7.i386 Adding req. pkg nano-0:2.0.3-1.fc7.i386 Adding req. pkg selinux-policy-0:2.6.4-40.fc7.noarch Adding req. pkg selinux-policy-targeted-0:2.6.4-40.fc7.noarch Adding req. pkg yum-0:3.2.4-2.fc7.noarch Overriding auto package selection with user package selection for nano... Live Media: Adding req. pkg authconfig-0:5.3.15-1.fc7.i386 Live Media: Adding req. pkg cpuspeed-1:1.2.1-2.fc7.i386 Live Media: Adding req. pkg eject-0:2.1.5-5.i386 Live Media: Adding req. pkg file-0:4.21-1.fc7.i386 Live Media: Adding req. pkg man-0:1.6e-3.fc7.i386 Live Media: Adding req. pkg openssh-clients-0:4.5p1-6.fc7.i386 Live Media: Adding req. pkg passwd-0:0.74-3.fc7.i386 Live Media: Adding req. pkg rootfiles-0:8.1-1.1.1.noarch Live Media: Adding req. pkg rpm-0:4.4.2.1-1.fc7.i386 Live Media: Adding req. pkg rsync-0:2.6.9-2.fc7.i386 Live Media: Adding req. pkg sendmail-0:8.14.1-2.i386 Live Media: Adding req. pkg shadow-utils-2:4.0.18.1-15.fc7.i386 Live Media: Adding req. pkg sudo-0:1.6.8p12-14.fc7.i386 Live Media: Adding req. pkg syslinux-0:3.36-4.fc7.i386 Live Media: Adding req. pkg tree-0:1.5.0-7.fc7.i386 Live Media: Adding req. pkg wget-0:1.10.2-15.fc7.i386 Live Media: Adding req. pkg xterm-0:227-1.fc7.i386 Building a nice package list from ksdata, and adding it to the transaction Initting progress bar for Select kickstart packages Select kickstart packages: >From Packages: Adding ConsoleKit-0:0.2.1-2.fc7.i386 to transaction Select kickstart packages: >From Packages: Adding ConsoleKit-libs-0:0.2.1-2.fc7.i386 to transaction Select kickstart packages: >From Packages: Adding ConsoleKit-x11-0:0.2.1-2.fc7.i386 to transaction Select kickstart packages: ... >From Packages: Adding kbd-0:1.12-22.fc7.i386 to transaction Select kickstart packages: >From Packages: Adding kernel-0:2.6.22.4-65.fc7.i686 to transaction Select kickstart packages: >From Packages: Adding kernel-0:2.6.22.4-65.fc7.i686 to transaction Select kickstart packages: >From Packages: Adding kernel-devel-0:2.6.22.4-65.fc7.i686 to transaction Select kickstart packages: >From Packages: Adding kernel-devel-0:2.6.22.4-65.fc7.i686 to transaction Select kickstart packages: >From Packages: Adding kernel-devel-0:2.6.22.4-65.fc7.i686 to transaction Select kickstart packages: >From Packages: Adding kernel-devel-0:2.6.22.4-65.fc7.i686 to transaction Select kickstart packages: >From Packages: Adding kernel-devel-0:2.6.22.4-65.fc7.i686 to transaction Select kickstart packages: >From Packages: Adding kernel-doc-0:2.6.22.4-65.fc7.noarch to transaction Select kickstart packages: >From Packages: Adding kernel-headers-0:2.6.22.4-65.fc7.i386 to transaction Select kickstart packages: Why so many times? Is that a problem? >From Packages: Adding kexec-tools-0:1.101-71.fc7.i386 to transaction Select kickstart packages: >From Packages: Adding keyutils-libs-0:1.2-2.fc6.i386 to transaction Select kickstart packages: ... Select kickstart packages: --> (u'ConsoleKit', u'i386', u'0', u'0.2.1', u'2.fc7') --> (u'ConsoleKit-libs', u'i386', u'0', u'0.2.1', u'2.fc7') --> (u'ConsoleKit-x11', u'i386', u'0', u'0.2.1', u'2.fc7') --> (u'GConf2', u'i386', u'0', u'2.18.0.1', u'2.fc7') --> (u'MAKEDEV', u'i386', u'0', u'3.23', u'1.2') --> (u'ORBit2', u'i386', u'0', u'2.14.7', u'3.fc7') --> (u'SDL', u'i386', u'0', u'1.2.11', u'2') ... --> (u'kernel', u'i686', u'0', u'2.6.22.4', u'65.fc7') --> (u'kernel-devel', u'i686', u'0', u'2.6.22.4', u'65.fc7') --> (u'kernel-doc', u'noarch', u'0', u'2.6.22.4', u'65.fc7') --> (u'kernel-headers', u'i386', u'0', u'2.6.22.4', u'65.fc7') --> (u'kexec-tools', u'i386', u'0', u'1.101', u'71.fc7') --> (u'keyutils-libs', u'i386', u'0', u'1.2', u'2.fc6') ... --> (u'zip', u'i386', u'0', u'2.31', u'3.fc7') --> (u'zisofs-tools', u'i386', u'0', u'1.0.7', u'1.fc7') --> (u'zlib', u'i386', u'0', u'1.2.3', u'10.fc7') Select kickstart packages: Checking dependencies - not allowing any conflicts within the package set Initting progress bar for Resolving Dependencies Resolving Dependencies: Initting progress bar for Populating statistics Populating statistics: Initting progress bar for Downloading Packages Downloading Packages: Downloading Packages: Downloading Packages: Initting progress bar for Setting up Ext3 Filesystem Setting up Ext3 Filesystem: Filesystem label=livecd-20070910 OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 325120 inodes, 649984 blocks 6499 blocks (1.00%) reserved for the super user First data block=0 Maximum filesystem blocks=666894336 20 block groups 32768 blocks per group, 32768 fragments per group 16256 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912 Writing inode tables: Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 24 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. tune2fs 1.40.2 (12-Jul-2007) Setting maximal mount count to -1 Setting interval between checks to 0 seconds Successfully set up the installation target for live media. Setting up Ext3 Filesystem: Initting progress bar for Installing Packages Installing Packages: Installing Packages: 0.0% Running package installation Succesfully built transaction: ret 2, msg Success - deps resolved Installing Packages: warning: libgcc-4.1.2-12: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 Installing Packages: Installing setup Installing Packages: Installing filesystem Installing Packages: Installing comps-extras Installing Packages: Installing basesystem Installing Packages: Installing kernel-headers Installing Packages: Installing xkeyboard-config Installing Packages: Installing tzdata Installing Packages: Installing glibc-common ... Installing libdca warning: libdca-0.0.2-3.lvn7: Header V3 DSA signature: NOKEY, key ID a109b1ec Installing Packages: Installing fuse-libs Installing Packages: ... Installing brlapi warning: brlapi-0.5.0-1: Header V3 DSA signature: NOKEY, key ID 5c43ca68 Installing Packages: Installing brltty Installing Packages: ... Installing at76_usb /var/tmp/rpm-tmp.87732: line 1: /sbin/depmod: No such file or directory error: %post(at76_usb-0.16-tn1.i386) scriptlet failed, exit status 127 Installing Packages: Installing memtest86+ Installing Packages: Installing at76_usb-firmware Installing Packages: ... Installing kernel-doc Installing Packages: ... Installing postfix postfix: fatal: config variable inet_interfaces: host not found: localhost Installing Packages: ... Installing kernel Installing Packages: Installing fuse Installing Packages: ... Installing fedora-logos No theme index file in '/usr/share/icons/Bluecurve'. If you really want to create an icon cache here, use --ignore-theme-index. No theme index file in '/usr/share/icons/Fedora'. If you really want to create an icon cache here, use --ignore-theme-index. Installing Packages: ... Installing revisor Installing Packages: Installing Packages: Installing Packages: Initting progress bar for Configuring Network Configuring Network: Initting progress bar for Configure System Configure System: Setting SELinux to: 1 Setting crypted root password /var/tmp/revisor-livecd/install_root /var/tmp/revisor-livecd/install_root /var/tmp/revisor-livecd/install_root Xorg is installed: True Default desktop is Gnome is installed: False KDE is installed: False XFCE is installed: False /var/tmp/revisor-livecd/install_root Could not retrieve mirrorlist http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=i386 error was [Errno 4] IOError: Error: Cannot retrieve repository metadata (repomd.xml) for repository: %s. Please verify its path and try again ERROR: Please edit the example config file /etc/freshclam.conf. ERROR: Can't parse the config file /etc/clamd.conf Configure System: Initting progress bar for Creating RAM Filesystem Creating RAM Filesystem: /var/tmp/revisor-livecd/install_root Building an initramfs at /boot/livecd-initramfs-2.6.22.1-41.fc7.img for kernel 2.6.22.1-41.fc7 FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory ... FATAL: Could not load /lib/modules/2.6.22.1-41.fc7/modules.dep: No such file or directory Done; initramfs is 3,6M. /var/tmp/revisor-livecd/install_root Building an initramfs at /boot/livecd-initramfs-2.6.22.4-65.fc7.img for kernel 2.6.22.4-65.fc7 FATAL: Module ide_cd not found. FATAL: Module usbhid not found. Done; initramfs is 4,4M. Creating RAM Filesystem: Initting progress bar for Relabel System Relabel System: lstat(/proc/mdstat) failed: Permission denied lstat(/proc/irq) failed: Permission denied /sbin/restorecon: unable to read directory /proc/sys/kernel /sbin/restorecon: unable to read directory /proc/sys/vm /sbin/restorecon: unable to read directory /proc/sys/net /sbin/restorecon: unable to read directory /proc/sys/dev lstat(/proc/net) failed: Permission denied lstat(/proc/kcore) failed: Permission denied lstat(/proc/kmsg) failed: Permission denied lstat(/proc/1) failed: Permission denied lstat(/proc/2) failed: Permission denied lstat(/proc/3) failed: Permission denied lstat(/proc/4) failed: Permission denied lstat(/proc/5) failed: Permission denied ... lstat(/proc/10220) failed: Permission denied /sbin/restorecon reset /var/lib/rpm/__db.001 context root:object_r:file_t:s0->system_u:object_r:rpm_var_lib_t:s0 /sbin/restorecon reset /var/lib/rpm/Triggername context root:object_r:file_t:s0->system_u:object_r:rpm_var_lib_t:s0 /sbin/restorecon reset /var/lib/rpm/Provideversion context root:object_r:file_t:s0->system_u:object_r:rpm_var_lib_t:s0 /sbin/restorecon reset /var/lib/rpm/Name context root:object_r:file_t:s0->system_u:object_r:rpm_var_lib_t:s0 /sbin/restorecon reset /var/lib/rpm/Installtid context root:object_r:file_t:s0->system_u:object_r:rpm_var_lib_t:s0 /sbin/restorecon reset /var/lib/rpm/Packages context root:object_r:file_t:s0->system_u:object_r:rpm_var_lib_t:s0 /sbin/restorecon reset /var/lib/rpm/Requireversion context root:object_r:file_t:s0->system_u:object_r:rpm_var_lib_t:s0 /sbin/restorecon reset /var/lib/rpm/__db.000 context root:object_r:file_t:s0->system_u:object_r:rpm_var_lib_t:s0 /sbin/restorecon reset /var/lib/rpm/Conflictname context root:object_r:file_t:s0->system_u:object_r:rpm_var_lib_t:s0 /sbin/restorecon reset /var/lib/rpm/__db.003 context root:object_r:file_t:s0->system_u:object_r:rpm_var_lib_t:s0 /sbin/restorecon reset /var/lib/rpm/Basenames context root:object_r:file_t:s0->system_u:object_r:rpm_var_lib_t:s0 /sbin/restorecon reset /var/lib/rpm/Sigmd5 context root:object_r:file_t:s0->system_u:object_r:rpm_var_lib_t:s0 /sbin/restorecon reset /var/lib/rpm/Pubkeys context root:object_r:file_t:s0->system_u:object_r:rpm_var_lib_t:s0 /sbin/restorecon reset /var/lib/rpm/Filemd5s context root:object_r:file_t:s0->system_u:object_r:rpm_var_lib_t:s0 /sbin/restorecon reset /var/lib/rpm/Dirnames context root:object_r:file_t:s0->system_u:object_r:rpm_var_lib_t:s0 /sbin/restorecon reset /var/lib/rpm/Sha1header context root:object_r:file_t:s0->system_u:object_r:rpm_var_lib_t:s0 /sbin/restorecon reset /var/lib/rpm/Requirename context root:object_r:file_t:s0->system_u:object_r:rpm_var_lib_t:s0 ... /sbin/restorecon reset /lost+found context system_u:object_r:file_t:s0->system_u:object_r:lost_found_t:s0 Read error on pipe. /sbin/restorecon reset /root/.gnome2 context root:object_r:user_home_dir_t:s0->root:object_r:user_home_t:s0 Relabel System: Initting progress bar for Configure BootLoader Configure BootLoader: Traceback (most recent call last): File "/usr/sbin/revisor", line 290, in revisorBase.run() File "/usr/lib/python2.5/site-packages/revisor/cli.py", line 42, in run self.base.lift_off() File "/usr/lib/python2.5/site-packages/revisor/base.py", line 859, in lift_off self.buildLiveMedia() File "/usr/lib/python2.5/site-packages/revisor/base.py", line 1373, in buildLiveMedia liveImage.configureBootloader() File "/usr/lib/python2.5/site-packages/revisor/pilgrim.py", line 722, in configureBootloader "%s/out/isolinux/%s" %(self.build_dir, kernel["vmlinuz"])) File "/usr/lib/python2.5/shutil.py", line 46, in copyfile fsrc = open(src, 'rb') IOError: [Errno 2] No such file or directory: '/var/tmp/revisor-livecd/install_root/boot/vmlinuz-2.6.22.1-41.fc7' Does this making it clearer? Thanks Lars From dmc.fedora at filteredperception.org Tue Sep 11 05:24:34 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 11 Sep 2007 00:24:34 -0500 Subject: [Fedora-livecd-list] RFC- unionfs persistence? In-Reply-To: <46E55F75.1080707@filteredperception.org> References: <46E55F75.1080707@filteredperception.org> Message-ID: <46E62692.5030506@filteredperception.org> 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 back that ubuntu actually > used devicemapper for their COW long ago (early 2005). But that they > abandoned that in favor of the 'flexibility' of unionfs. > > I know that unionfs was ruled out as an option for Fedora, because it > was being kept out of the repos. In fact, before pilgrim/livecd-creator > came into existence, I posted a proof of concept fedora unionfs-based > livecd infrastructure- > > http://www.redhat.com/archives/fedora-livecd-list/2006-April/msg00197.html > > But a lot has changed in the last 18 months. It seems that unionfs is > in the -mm kernel tree, and between that, fuse-unionfs, and aufs, it > seems pretty likely that some flavor of unionfs will make it into fedora > in the foreseeable future. > > Given that, and given the multitude of other projects I could be working > on, makes me wonder how much time I should spend working on devicemapper > persistence, if the vast majority of livecds out there are using > unionfs, and unionfs may become an option for fedora in the near future. > > Comments? Never being one to avoid conversing with myself... It occurs to me that it wouldn't be difficult at all to implement an initramfs system, that supports *BOTH* devicemapper and unionfs for COW. With nothing more than a bootarg of cowmethod= to specify changing from whatever the default method is to the other. In this fashion, you could actually keep the existing devicemapper fedora livecd infrastructure, including the nice speedy installer :), and also support persistence via unionfs on the same livecd. I still of course think that ubuntu made the wrong decision, and that devicemapper is ultimately more 'flexible' and better than unionfs. But I can't deny that unionfs works easily in a lot of ways (spec wrt livecd persistence), and has certainly enjoyed widespread usage. -dmc From tve at voneicken.com Tue Sep 11 06:29:36 2007 From: tve at voneicken.com (Thorsten von Eicken) Date: Mon, 10 Sep 2007 23:29:36 -0700 Subject: [Fedora-livecd-list] RFC- unionfs persistence? In-Reply-To: <46E62692.5030506@filteredperception.org> References: <46E55F75.1080707@filteredperception.org> <46E62692.5030506@filteredperception.org> Message-ID: <46E635D0.2050607@voneicken.com> Douglas McClendon wrote: > Never being one to avoid conversing with myself... Please keep conversing with yourself! Happy to listen! :-) It would be very helpful if you could summarize the pros and cons of each of the two approaches. This way more of us could chime in and stir in the pot. From the limited knowledge that I have: - unionfs write a regular directory/file structure to the rw device, one can easily inspect and manipulate what got written, even on a different machine. - unionfs makes it easy to fold the rw content back into the ro filesystem, it's just a cp -a onto the "master" filesystem - with unionfs one can layer, so one can add additional rw layers on top and thereby preserve a rw snapshot - devicemapper has clean semantics, with unionfs the deletion of a file in the ro filesystem is represented using basically a hack in the overlay I'm sure there's more... Thorsten From kanarip at kanarip.com Tue Sep 11 10:06:40 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 11 Sep 2007 12:06:40 +0200 Subject: [Fedora-livecd-list] Revisor: Instroot problem In-Reply-To: References: <46DB06BC.2030006@kanarip.com> <46E4FDC4.5010308@kanarip.com> <46E50FE1.7060604@kanarip.com> Message-ID: <46E668B0.6020402@kanarip.com> Lars Bj?rndal wrote: > Jeroen van Meeuwen writes: > >> Lars Bj?rndal wrote: >>> The boot directory does not exist. The only content in >>> /var/tmp/revisor-livecd/install_root is: >>> ./var >>> ./var/run > ... > >> If that's it, something else must have gone terribly wrong. Before >> configuring the bootloader, at least some RPM packages should have >> gotten installed. Any other output I may want to know about? > > I'll try: [...snip...] Thanks. I'll look into this and try to reproduce. Meanwhile, a similar conversation is going on on our own mailing-list at http://lists.fedoraunity.org/mailman/listinfo/revisor-users Thanks again! -- Kind regards, Jeroen van Meeuwen -kanarip -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 From katzj at redhat.com Tue Sep 11 12:34:18 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 11 Sep 2007 08:34:18 -0400 Subject: [Fedora-livecd-list] RFC- unionfs persistence? In-Reply-To: <46E55F75.1080707@filteredperception.org> References: <46E55F75.1080707@filteredperception.org> Message-ID: <1189514058.4971.2.camel@localhost.localdomain> 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 for anything has been for a while now -- what's the actual likelihood of an implementation ever being both upstream and stable. I'll try to corner davej when he returns from his vacation and see what his current tea leaf reading says :) Because, honestly, that's the only real blocker from my point of view to using unionfs for things Jeremy From ml at deadbabylon.de Tue Sep 11 13:13:48 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 11 Sep 2007 15:13:48 +0200 Subject: [Fedora-livecd-list] unbootable Isos with newest git Message-ID: <200709111513.54688.ml@deadbabylon.de> Hi. With the actual git version the produced livecds aren't bootable. In vmware it shows this: Loading vmlinuz........ Loading initrd.img.... Ready. Booting: ABCDEFGHIJKLMNOP After this it automatically reboots. Virtualbox or qemu are hanging at this point. I've not testet a burned iso directly. Any suggestions? Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Tue Sep 11 13:56:49 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 11 Sep 2007 09:56:49 -0400 Subject: [Fedora-livecd-list] unbootable Isos with newest git In-Reply-To: <200709111513.54688.ml@deadbabylon.de> References: <200709111513.54688.ml@deadbabylon.de> Message-ID: <1189519009.4971.6.camel@localhost.localdomain> On Tue, 2007-09-11 at 15:13 +0200, Sebastian Vahl wrote: > With the actual git version the produced livecds aren't bootable. In vmware it > shows this: > > Loading vmlinuz........ > Loading initrd.img.... > Ready. > Booting: ABCDEFGHIJKLMNOP > > After this it automatically reboots. Virtualbox or qemu are hanging at this > point. I've not testet a burned iso directly. > > Any suggestions? Kernel bustage yesterday. Supposed to be fixed today, but I haven't actually tried today's kernel yet Jeremy From phillip at lougher.demon.co.uk Tue Sep 11 15:37:11 2007 From: phillip at lougher.demon.co.uk (Phillip Lougher) Date: Tue, 11 Sep 2007 16:37:11 +0100 Subject: [Fedora-livecd-list] RFC- unionfs persistence? In-Reply-To: <1189514058.4971.2.camel@localhost.localdomain> References: <46E55F75.1080707@filteredperception.org> <1189514058.4971.2.camel@localhost.localdomain> Message-ID: <46E6B627.4010809@lougher.demon.co.uk> 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 for anything has been for a while now -- what's the actual > likelihood of an implementation ever being both upstream and stable. In Ubuntu unionfs has been used in the liveCD for a number of releases. The trick is to get a Unionfs that works and stick with it, for that reason the Ubuntu kernel has stayed with Unionfs 1.2 and 1.4 for a long time. Unfortnately we've upgraded to Unionfs 2.1.1 because Unionfs 1.x doesn't handle NFS filesystem branches correctly in recent kernels. Having moved to 2.1.1 I expect a number of issues may arise with the Ubuntu liveCD, and in fact I'm currently investigating an issue that may be caused by the move to 2.1.1. So the stability of Unionfs still appears to be a major issue for anyone using it. Phillip From ml at deadbabylon.de Tue Sep 11 16:04:47 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 11 Sep 2007 18:04:47 +0200 Subject: [Fedora-livecd-list] unbootable Isos with newest git In-Reply-To: <1189519009.4971.6.camel@localhost.localdomain> References: <200709111513.54688.ml@deadbabylon.de> <1189519009.4971.6.camel@localhost.localdomain> Message-ID: <20070911180447.04624c76@htpc> Am Tue, 11 Sep 2007 09:56:49 -0400 schrieb Jeremy Katz : > On Tue, 2007-09-11 at 15:13 +0200, Sebastian Vahl wrote: > > With the actual git version the produced livecds aren't bootable. > > In vmware it shows this: > > > > Loading vmlinuz........ > > Loading initrd.img.... > > Ready. > > Booting: ABCDEFGHIJKLMNOP > > > > After this it automatically reboots. Virtualbox or qemu are hanging > > at this point. I've not testet a burned iso directly. > > > > Any suggestions? > > Kernel bustage yesterday. Supposed to be fixed today, but I haven't > actually tried today's kernel yet It's fixed. I've done a spin with the newer kernel some minutes ago. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ml at deadbabylon.de Tue Sep 11 16:05:20 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 11 Sep 2007 18:05:20 +0200 Subject: [Fedora-livecd-list] No /home/fedora/.bashrc with selinux=1 In-Reply-To: <1189098916.23094.0.camel@localhost.localdomain> References: <20070906115511.63d3071d@htpc> <1189091938.4437.13.camel@localhost.localdomain> <1189098916.23094.0.camel@localhost.localdomain> Message-ID: <20070911180520.1b1dccce@htpc> Am Thu, 06 Sep 2007 13:15:16 -0400 schrieb Jeremy Katz : > On Thu, 2007-09-06 at 11:18 -0400, Jeremy Katz wrote: > > On Thu, 2007-09-06 at 11:55 +0200, Sebastian Vahl wrote: > > > I've noticed a little problem when booting with selinux > > > enabled: /home/fedora/.bashrc would not be copied/created. When > > > booting with enforcing=0 all would be fine so I assume this is a > > > selinux problem. But I've found no entry in /var/log/messages > > > or /var/log/audit/audit.log. > > > > This may be due to a policy problem that Dan has a new policy > > building for... will hopefully know more soon-ish. > > Confirmed that new policy fixes this Here too. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bernardino.lopez at gmail.com Tue Sep 11 19:54:10 2007 From: bernardino.lopez at gmail.com (Dino Lopez) Date: Tue, 11 Sep 2007 14:54:10 -0500 Subject: [Fedora-livecd-list] Running Fedora 7 LiveCD from Windows with qemu fail Message-ID: <4209097b0709111254y21ab2241q16a4577e0a5bbb92@mail.gmail.com> Based on the article: http://www.pendrivelinux.com/2007/03/26/portable-qemu-persistent-ubuntu-linux/ It worked, a bit slow but It worked, I also mail some typo err on the relative path for the kqemu called from the ubuntu.bat file need's to be ..\kqemu\.... on line 17. Anyway, since the script is pretty straight forward and just call the iso, I figure will be possible to replace the Ubuntu image with the Fedora image. To my surprise the emulation worked and boot and show the first Fedora graphic interface to choose how to boot the image, as soon as I select run from Image, try to boot and get a Kernel Panic error. Any suggestions on how to get the Fedora 7 LIveCD running from Windows with qemu ??? THX in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nd_stew at yahoo.com Tue Sep 11 20:52:14 2007 From: nd_stew at yahoo.com (C S) Date: Tue, 11 Sep 2007 13:52:14 -0700 (PDT) Subject: [Fedora-livecd-list] Running Fedora 7 LiveCD from Windows with qemu fail In-Reply-To: <4209097b0709111254y21ab2241q16a4577e0a5bbb92@mail.gmail.com> Message-ID: <104917.73754.qm@web32011.mail.mud.yahoo.com> Try this to start (within cygwin): ./qemu-img.exe create -f raw 7Vanilla.img 7G ./qemu.exe -L c:\\cygwin\\usr\\local\\qemu-0.9.0-windows -boot d -cdrom e:\\live\\7\\iso\\Fedora-7-Live-i686.iso -m 1280 -hda c:\\cygwin\\usr\\local\\qemu-0.9.0-windows\\7Vanilla.img & cs --- Dino Lopez wrote: > Based on the article: > http://www.pendrivelinux.com/2007/03/26/portable-qemu-persistent-ubuntu-linux/ > > It worked, a bit slow but It worked, I also mail > some typo err on the > relative path for the kqemu called from the > ubuntu.bat file need's to be > ..\kqemu\.... on line 17. Anyway, since the script > is pretty straight > forward and just call the iso, I figure will be > possible to replace the > Ubuntu image with the Fedora image. > > To my surprise the emulation worked and boot and > show the first Fedora > graphic interface to choose how to boot the image, > as soon as I select run > from Image, try to boot and get a Kernel Panic > error. > > Any suggestions on how to get the Fedora 7 LIveCD > running from Windows with > qemu ??? > > THX in advance. > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > ____________________________________________________________________________________ Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/ From dmc.fedora at filteredperception.org Tue Sep 11 23:10:38 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 11 Sep 2007 18:10:38 -0500 Subject: [Fedora-livecd-list] RFC- unionfs persistence? In-Reply-To: <46E6B627.4010809@lougher.demon.co.uk> References: <46E55F75.1080707@filteredperception.org> <1189514058.4971.2.camel@localhost.localdomain> <46E6B627.4010809@lougher.demon.co.uk> Message-ID: <46E7206E.9000106@filteredperception.org> 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 for anything has been for a while now -- what's the actual >> likelihood of an implementation ever being both upstream and stable. > > In Ubuntu unionfs has been used in the liveCD for a number of releases. > The trick is to get a Unionfs that works and stick with it, for that > reason the Ubuntu kernel has stayed with Unionfs 1.2 and 1.4 for > a long time. Unfortnately we've upgraded to Unionfs 2.1.1 because > Unionfs 1.x doesn't handle NFS filesystem branches correctly in > recent kernels. > > Having moved to 2.1.1 I expect a number of issues may arise with > the Ubuntu liveCD, and in fact I'm currently investigating an issue that > may be caused by the move to 2.1.1. > > So the stability of Unionfs still appears to be a major issue for > anyone using it. Thanks for the war stories. Bummer. I had been hoping that the answer would be a little more like "yeah, with the widespread usage in ubuntu, and the 2.0 rewrite, and the 8 months in -mm, it's now rock solid". But maybe it'll get there soon. I am interested to hear what davej says and if it'll make it into fedora anytime soon, even given current lack of rock-solidness. The more I think about it, the more I like my idea of having an initramfs that supports both dm and unionfs for cow... -dmc From jkeating at redhat.com Wed Sep 12 21:46:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Sep 2007 17:46:55 -0400 Subject: [Fedora-livecd-list] [PATCH] Make use of "url" methods as a repo to get packages from Message-ID: <20070912174655.449eec85@lumos.localdomain> This requires a new pykickstart which is about to be built. Same code snippit has just been applied to pungi -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-use-method-as-repo.patch Type: text/x-patch Size: 953 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Wed Sep 12 21:53:14 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 12 Sep 2007 23:53:14 +0200 Subject: [Fedora-livecd-list] [PATCH] Make use of "url" methods as a repo to get packages from In-Reply-To: <20070912174655.449eec85@lumos.localdomain> References: <20070912174655.449eec85@lumos.localdomain> Message-ID: <46E85FCA.8070909@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > This requires a new pykickstart which is about to be built. Same code > snippit has just been applied to pungi > How come it would now /require/ pykickstart >= 1.13 if it's a try/except/pass for pykickstart < 1.13? - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG6F/JKN6f2pNCvwgRAiL2AKCUWhLW1VNaM8LOleO5qwC7oigk6ACcD2cv qgNYybBAPvmNYTy0/Hbs+z0= =UTSq -----END PGP SIGNATURE----- From dmc.fedora at filteredperception.org Thu Sep 13 01:50:32 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 12 Sep 2007 20:50:32 -0500 Subject: [Fedora-livecd-list] [PATCH] Make use of "url" methods as a repo to get packages from In-Reply-To: <20070912174655.449eec85@lumos.localdomain> References: <20070912174655.449eec85@lumos.localdomain> Message-ID: <46E89768.7040002@filteredperception.org> Jesse Keating wrote: > This requires a new pykickstart which is about to be built. Same code > snippit has just been applied to pungi Dumb question- What does this actually do? (e.g. an e.g.) -dmc From jkeating at redhat.com Thu Sep 13 02:16:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Sep 2007 22:16:51 -0400 Subject: [Fedora-livecd-list] [PATCH] Make use of "url" methods as a repo to get packages from In-Reply-To: <46E85FCA.8070909@kanarip.com> References: <20070912174655.449eec85@lumos.localdomain> <46E85FCA.8070909@kanarip.com> Message-ID: <20070912221651.0fe33a10@lumos.localdomain> On Wed, 12 Sep 2007 23:53:14 +0200 Jeroen van Meeuwen wrote: > How come it would now /require/ pykickstart >= 1.13 if it's a > try/except/pass for pykickstart < 1.13? Well, the try/except/pass wasn't for backwards compat, it was because if you ask pykickstart to do a methodToRepo and your method is anything other than "url" you'll get a traceback. Although I suppose that this will work for backwards compat too, it's just a different failure mode, one hidden by my lazyness in just excepting everything there. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Sep 13 02:20:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Sep 2007 22:20:45 -0400 Subject: [Fedora-livecd-list] [PATCH] Make use of "url" methods as a repo to get packages from In-Reply-To: <46E89768.7040002@filteredperception.org> References: <20070912174655.449eec85@lumos.localdomain> <46E89768.7040002@filteredperception.org> Message-ID: <20070912222045.65c2a701@lumos.localdomain> On Wed, 12 Sep 2007 20:50:32 -0500 Douglas McClendon 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 the packages, or find stage2 if you started with boot.iso or pxe boot or something like that. This is akin to the boot time argument "method=". One such method is "url" which can be http/ftp. Since this is a popular network install method, and since installs generate a kickstart file from the install, it would be handy to be able to take that kickstart file and shove it directly into either livecd-tools or pungi. Instead of adding a repo line and duplicating some information, the kickstart parsing code should be able to take that url definition and turn it into a repo to be used later. Since this only really makes sense in compose tools, but we want the code to do this to be in a shared location, pykickstart grew a method to turn the url method into a repo and add it to the repo list. If your method was anything but url, pykickstart will raise a generic error, which is why I just have an empty except:pass. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Thu Sep 13 03:09:46 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 12 Sep 2007 23:09:46 -0400 Subject: [Fedora-livecd-list] [PATCH] Make use of "url" methods as a repo to get packages from In-Reply-To: <20070912221651.0fe33a10@lumos.localdomain> References: <20070912174655.449eec85@lumos.localdomain> <46E85FCA.8070909@kanarip.com> <20070912221651.0fe33a10@lumos.localdomain> Message-ID: <20070912230946.76364f08@Nokia-N800-26> On Wed, 12 Sep 2007 22:16:51 -0400 Jesse Keating wrote: > On Wed, 12 Sep 2007 23:53:14 +0200 > Jeroen van Meeuwen wrote: > > How come it would now /require/ pykickstart >= 1.13 if it's a > > try/except/pass for pykickstart < 1.13? > > Well, the try/except/pass wasn't for backwards compat, it was because > if you ask pykickstart to do a methodToRepo and your method is > anything other than "url" you'll get a traceback. > > Although I suppose that this will work for backwards compat too, it's > just a different failure mode, one hidden by my lazyness in just > excepting everything there. One example where laziness has a positive side-effect :) Looks fine, though I'm going to drop the requires bump. Forcing an upgrade for it just feels unnecessary. Jeremy From dmc.fedora at filteredperception.org Thu Sep 13 03:39:17 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 12 Sep 2007 22:39:17 -0500 Subject: [Fedora-livecd-list] [PATCH] Make use of "url" methods as a repo to get packages from In-Reply-To: <20070912222045.65c2a701@lumos.localdomain> References: <20070912174655.449eec85@lumos.localdomain> <46E89768.7040002@filteredperception.org> <20070912222045.65c2a701@lumos.localdomain> Message-ID: <46E8B0E5.6020500@filteredperception.org> Jesse Keating wrote: > On Wed, 12 Sep 2007 20:50:32 -0500 > Douglas McClendon 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 the > packages, or find stage2 if you started with boot.iso or pxe boot or > something like that. This is akin to the boot time argument > "method=". One such method is "url" which can be http/ftp. > Since this is a popular network install method, and since installs > generate a kickstart file from the install, it would be handy to be > able to take that kickstart file and shove it directly into either > livecd-tools or pungi. Instead of adding a repo line and duplicating > some information, the kickstart parsing code should be able to take > that url definition and turn it into a repo to be used later. Since > this only really makes sense in compose tools, Makes sense. Methinks the time may be nearing for more comprehensive/unified documentation. No, I'm not volunteering ;) -dmc but we want the code to > do this to be in a shared location, pykickstart grew a method to turn > the url method into a repo and add it to the repo list. If your method > was anything but url, pykickstart will raise a generic error, which is > why I just have an empty except:pass. > > > > ------------------------------------------------------------------------ > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From jsteer at bitscout.com Thu Sep 13 16:08:30 2007 From: jsteer at bitscout.com (Jon Steer) Date: Thu, 13 Sep 2007 12:08:30 -0400 Subject: [Fedora-livecd-list] specifying kickstart file upon boot of liveCD Message-ID: <74e6f65d0709130908y76a1293cnbc8fc1371bf9c97d@mail.gmail.com> Although I suspect this is a naive question, Is it possible to specify a kickstart file upon boot of the liveCD? I am interested in doing some non-interactive post-boot. Or, should I be using something like cobbler/koan? jon -- "Don't stand still, if you see me running down the road, 'cause there is trouble right behind me". -------------- next part -------------- An HTML attachment was scrubbed... URL: From katzj at redhat.com Thu Sep 13 17:03:19 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 13 Sep 2007 13:03:19 -0400 Subject: [Fedora-livecd-list] specifying kickstart file upon boot of liveCD In-Reply-To: <74e6f65d0709130908y76a1293cnbc8fc1371bf9c97d@mail.gmail.com> References: <74e6f65d0709130908y76a1293cnbc8fc1371bf9c97d@mail.gmail.com> Message-ID: <1189702999.16586.43.camel@localhost.localdomain> On Thu, 2007-09-13 at 12:08 -0400, Jon Steer wrote: > Although I suspect this is a naive question, > > Is it possible to specify a kickstart file upon boot of the liveCD? I > am interested in doing some non-interactive post-boot. Or, should I be > using something like cobbler/koan? If you're creating your own live CD, then you can make it do whatever you want from the live init script. Just add the appropriate parsing of /proc/cmdline and then kick off whatever. Generally, the shipped Fedora live images don't do anything specific with install-related arguments as the installability isn't something that's really seen as wanting to be automated. Just out of curiosity, what are you actually trying to do? Jeremy From dmc.fedora at filteredperception.org Thu Sep 13 17:08:57 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 13 Sep 2007 12:08:57 -0500 Subject: [Fedora-livecd-list] mayflower exec < /dev/console before /dev/console exists??? Message-ID: <46E96EA9.20208@filteredperception.org> Question- in the initramfs /init generated by mayflower- ... " export PATH=/sbin:/bin exec < /dev/console > /dev/console 2>&1 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 is there some obscure magic relating to /dev/console that I am unaware of? -dmc From katzj at redhat.com Thu Sep 13 17:31:50 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 13 Sep 2007 13:31:50 -0400 Subject: [Fedora-livecd-list] mayflower exec < /dev/console before /dev/console exists??? In-Reply-To: <46E96EA9.20208@filteredperception.org> References: <46E96EA9.20208@filteredperception.org> Message-ID: <1189704710.16586.45.camel@localhost.localdomain> 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 a bug that's not been affecting anything. Jeremy From dmc.fedora at filteredperception.org Thu Sep 13 17:42:58 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 13 Sep 2007 12:42:58 -0500 Subject: [Fedora-livecd-list] mayflower exec < /dev/console before /dev/console exists??? In-Reply-To: <1189704710.16586.45.camel@localhost.localdomain> References: <46E96EA9.20208@filteredperception.org> <1189704710.16586.45.camel@localhost.localdomain> Message-ID: <46E976A2.8080105@filteredperception.org> 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 a bug > that's not been affecting anything. That's pretty much my reaction to. But what I really want to know is what its trying to do, and why the bug doesn't matter (academic curiosity primarily). Would the technically right(tm) thing to do be- mknod /dev/console c 5 1 exec < /dev/console > /dev/console 2>&1 mount -n -t tmpfs -o mode=0755 udev /dev mknod /dev/console c 5 1 mknod /dev/null c 1 3 ... ? (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...) -dmc From walters at redhat.com Thu Sep 13 18:31:52 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 13 Sep 2007 14:31:52 -0400 Subject: [Fedora-livecd-list] mayflower exec < /dev/console before /dev/console exists??? In-Reply-To: <46E976A2.8080105@filteredperception.org> References: <46E96EA9.20208@filteredperception.org> <1189704710.16586.45.camel@localhost.localdomain> <46E976A2.8080105@filteredperception.org> Message-ID: On 9/13/07, Douglas McClendon 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/unstable/utils/fakeroot ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmc.fedora at filteredperception.org Thu Sep 13 18:36:53 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 13 Sep 2007 13:36:53 -0500 Subject: [Fedora-livecd-list] mayflower exec < /dev/console before /dev/console exists??? In-Reply-To: References: <46E96EA9.20208@filteredperception.org> <1189704710.16586.45.camel@localhost.localdomain> <46E976A2.8080105@filteredperception.org> Message-ID: <46E98345.2070001@filteredperception.org> Colin Walters wrote: > On 9/13/07, Douglas McClendon 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/unstable/utils/fakeroot > > ? That wins. But then again, so would have "yum info fakeroot" :) thx... -dmc From dmc.fedora at filteredperception.org Fri Sep 14 20:07:51 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 14 Sep 2007 15:07:51 -0500 Subject: [Fedora-livecd-list] [PATCH] v3 turboLiveInst Message-ID: <46EAEA17.3020307@filteredperception.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 has been reduced to the minimal possible size. This minimal image is not sufficient for a running LiveCD as applications need room to write more data, but the minimal image is efficiently created just before copying by applying a pre-calculated set of deltas to the original large filesystem image." 2nd revision post with performance numbers and decent descritpion: (first two copy times are typo swapped) http://www.redhat.com/archives/anaconda-devel-list/2007-July/msg00065.html Mark's comments thread: http://www.redhat.com/archives/fedora-livecd-list/2007-September/msg00007.html The anaconda patch applies on top of the selinux bugfix I sent to anaconda-devel this morning, but there is no overlap. The main things I'll mention that aren't directly related to the review thread above- - I included a couple typo fixes to the documentation, as well as adding what seemed to be some appropriate additions. - I included a slight cleanup of livecd-creator's resize2fsToMinimal. As discussed in the above thread, since the dumpe2fs code is going into anaconda for this patch, it seems to make sense to go ahead and include it in livecd-creator as well to remove the blocksize argument to resize2fsToMinimal, and have it calculate implicitly instead. - I had to move the anaconda resize2fs invocation, as now the filesystem starts out full, and before resize2fs cannot even have mountpoint directories made in it. Even outside turboLiveInst this is a valid thing to do. - renamed the main function from turboLiveInst to genMinInstDelta - removed option for ignore-deleted, and didn't bother with option for turboliveinst. The liveinst.sh code gracefully handles the legacy configuration of no delta file. - still not yet being a rawhide user, I tested this on an F7 livecd spin, generated with this git livecd-tools. I used the patch to patch the installed anaconda. It worked in a test under qemu. (sparse disk file with du -cms showed that only ~2.2G of data was written). - I expect, that even just looking at it myself over the next couple days I'll probably find one or two things to change. Please give me any feedback about any possible improvements you can think of. If you have a rawhide livecd spinning enironment handy and want to test it, that would be greatly appreciated. Enjoy... -dmc/jdog -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-tools.turboliveinst.v3.patch Type: text/x-patch Size: 11132 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: anaconda.turboliveinst.v3.patch Type: text/x-patch Size: 4470 bytes Desc: not available URL: From patrice.guay at nanotechnologies.qc.ca Fri Sep 14 21:29:22 2007 From: patrice.guay at nanotechnologies.qc.ca (Patrice Guay) Date: Fri, 14 Sep 2007 17:29:22 -0400 Subject: [Fedora-livecd-list] Live CD vs virtual appliance Message-ID: <46EAFD32.6010109@nanotechnologies.qc.ca> 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 on top of it. Due to licensing issues, almost nobody uses Microsoft Windows as the base for their virtual appliance. Microsoft ties its license to the hardware. This means that a license for the Microsoft OS must be purchased for every physical machine where the virtual appliance may be used. The license can not be bundled with the virtual appliance. VMware has developed tools to create Linux-based virtual appliances. They use a stripped down version of Ubuntu as the base OS. From what I saw, livecd-tools offers a simpler and more powerful approach to create an OS + application bundle. The virtual appliance creation involves several steps and configuration files. Using livecd-creator, only one configuration file is involved and only one command line is required to create the iso image. The only advantage of virtual appliances is persistence. If this could be solved for livecd-tools, I foresee an increased interest from those planning to create virtual appliances for the livecd-tools project. Regards, -- Patrice Guay From dmc.fedora at filteredperception.org Fri Sep 14 21:35:55 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 14 Sep 2007 16:35:55 -0500 Subject: [Fedora-livecd-list] Live CD vs virtual appliance In-Reply-To: <46EAFD32.6010109@nanotechnologies.qc.ca> References: <46EAFD32.6010109@nanotechnologies.qc.ca> Message-ID: <46EAFEBB.1060804@filteredperception.org> 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 > on top of it. > > Due to licensing issues, almost nobody uses Microsoft Windows as the > base for their virtual appliance. Microsoft ties its license to the > hardware. This means that a license for the Microsoft OS must be > purchased for every physical machine where the virtual appliance may be > used. The license can not be bundled with the virtual appliance. > > VMware has developed tools to create Linux-based virtual appliances. > They use a stripped down version of Ubuntu as the base OS. From what I > saw, livecd-tools offers a simpler and more powerful approach to create > an OS + application bundle. The virtual appliance creation involves > several steps and configuration files. Using livecd-creator, only one > configuration file is involved and only one command line is required to > create the iso image. > > The only advantage of virtual appliances is persistence. If this could > be solved for livecd-tools, I foresee an increased interest from those > planning to create virtual appliances for the livecd-tools project. Setting asside the persistence patch I'm working on, how about an optional bootarg of rebootless_liveos_installer=go_for_it, which could be a default isolinux menu entry ala how run-from-ram used to be. (or just _the_ default if you choose to spin it that way) Where the arg merely automatically invokes a rebootless installer https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01042.html Thus if you boot qemu(or vmware or whatever) with the "appliance master livecd" attached as cdrom, and a fresh virtual disk as hard drive, you get your newly provisioned persistent appliance. $0.02... (I'm sure some sort of cobbler+koan+revisor can probably do the same thing in a different way. We're all headed in vaguely the same direction) -dmc From jsteer at bitscout.com Fri Sep 14 23:28:44 2007 From: jsteer at bitscout.com (Jon Steer) Date: Fri, 14 Sep 2007 19:28:44 -0400 Subject: [Fedora-livecd-list] specifying kickstart file upon boot of liveCD In-Reply-To: <1189702999.16586.43.camel@localhost.localdomain> References: <74e6f65d0709130908y76a1293cnbc8fc1371bf9c97d@mail.gmail.com> <1189702999.16586.43.camel@localhost.localdomain> Message-ID: <74e6f65d0709141628i12f0aec1se889b5f619abac7a@mail.gmail.com> 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 intervention. On normal bootup of the liveCD, we would expect manual intervention. jon On 9/13/07, Jeremy Katz wrote: > > On Thu, 2007-09-13 at 12:08 -0400, Jon Steer wrote: > > Although I suspect this is a naive question, > > > > Is it possible to specify a kickstart file upon boot of the liveCD? I > > am interested in doing some non-interactive post-boot. Or, should I be > > using something like cobbler/koan? > > If you're creating your own live CD, then you can make it do whatever > you want from the live init script. Just add the appropriate parsing > of /proc/cmdline and then kick off whatever. > > Generally, the shipped Fedora live images don't do anything specific > with install-related arguments as the installability isn't something > that's really seen as wanting to be automated. > > Just out of curiosity, what are you actually trying to do? > > Jeremy > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > -- "Don't stand still, if you see me running down the road, 'cause there is trouble right behind me". -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmc.fedora at filteredperception.org Sat Sep 15 18:45:43 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sat, 15 Sep 2007 13:45:43 -0500 Subject: [Fedora-livecd-list] specifying kickstart file upon boot of liveCD In-Reply-To: <74e6f65d0709141628i12f0aec1se889b5f619abac7a@mail.gmail.com> References: <74e6f65d0709130908y76a1293cnbc8fc1371bf9c97d@mail.gmail.com> <1189702999.16586.43.camel@localhost.localdomain> <74e6f65d0709141628i12f0aec1se889b5f619abac7a@mail.gmail.com> Message-ID: <46EC2857.8050501@filteredperception.org> 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 intervention. This seems like it's just a matter of adding a new custom service to /etc/rc.d/init.d/ which would do something with /proc/cmdline. Take a look at how the current /etc/rc.d/init.d/fedora-live generated in the %post of the standard livecd-fedora-base-desktop.ks, deals with the possible liveimg argument that might be in /proc/cmdline. You could easily enough cause stuff to happen there (after fedora user is added), including something like (this is untested, just idea fodder, most likely missing quite a few needed things)- kickstart=$( cat /proc/cmdline | \ sed -e 's/\s/\n/g' | \ grep "^ks" | \ sed -e 's/ks=//' ) if [ "x${kickstart}" != "x" ]; then mkdir -p /home/fedora/.config/autostart cat < /home/fedora/.config/autostart/kabluiprogs.desktop [Desktop Entry] Name=No name Encoding=UTF-8 Version=1.0 Exec=/usr/bin/handlekickstart EOF cat < /usr/sbin/handlekickstart #!/bin/bash /usr/sbin/anaconda --kickstart=$kickstart EOF chmod +x /usr/bin/handlekickstart cp -a /etc/pam.d/liveinst /etc/pam.d/handlekickstart ln -s consolehelper /usr/bin/handlekickstart > > On normal bootup of the liveCD, we would expect manual intervention. Not sure what you mean by this, or really if what I suggested above was the sort of thing you had in mind. -dmc From jsteer at bitscout.com Sat Sep 15 19:28:10 2007 From: jsteer at bitscout.com (Jon Steer) Date: Sat, 15 Sep 2007 15:28:10 -0400 Subject: [Fedora-livecd-list] specifying kickstart file upon boot of liveCD In-Reply-To: <46EC2857.8050501@filteredperception.org> References: <74e6f65d0709130908y76a1293cnbc8fc1371bf9c97d@mail.gmail.com> <1189702999.16586.43.camel@localhost.localdomain> <74e6f65d0709141628i12f0aec1se889b5f619abac7a@mail.gmail.com> <46EC2857.8050501@filteredperception.org> Message-ID: <74e6f65d0709151228u6c3a64e5xdeb8c1999df7fb@mail.gmail.com> We have several use cases for the liveCD/liveUSB. Some of the use cases require that there is manual intervention after boot up for configuring the system and application evironment . But we have at least two use cases where both system and application configuration is done post-boot with no manual intervention. The no-manual intervention is a precanned configuration for known system enviroments (like a QA lab or marketing demo) that turns the machine into an appliance. We have several applications on the box that all require (for example) the same sql authentication. Rather than have the user type it once (or several times) we use precanned setup scripts or puppet. You are right, I can add an init.d/foo that looks at /proc/cmdline. I just thought that I'd try to reuse kickstart for that functionality. Kickstart provided most of what I needed like network setup and authentication setup. thanks, jon On 9/15/07, Douglas McClendon wrote: > > 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 intervention. > > This seems like it's just a matter of adding a new custom service to > /etc/rc.d/init.d/ which would do something with /proc/cmdline. Take a > look at how the current /etc/rc.d/init.d/fedora-live generated in the > %post of the standard livecd-fedora-base-desktop.ks, deals with the > possible liveimg argument that might be in /proc/cmdline. > > You could easily enough cause stuff to happen there (after fedora user > is added), including something like (this is untested, just idea fodder, > most likely missing quite a few needed things)- > > kickstart=$( cat /proc/cmdline | \ > sed -e 's/\s/\n/g' | \ > grep "^ks" | \ > sed -e 's/ks=//' ) > if [ "x${kickstart}" != "x" ]; then > mkdir -p /home/fedora/.config/autostart > cat < /home/fedora/.config/autostart/kabluiprogs.desktop > [Desktop Entry] > Name=No name > Encoding=UTF-8 > Version=1.0 > Exec=/usr/bin/handlekickstart > EOF > > cat < /usr/sbin/handlekickstart > #!/bin/bash > /usr/sbin/anaconda --kickstart=$kickstart > EOF > chmod +x /usr/bin/handlekickstart > > cp -a /etc/pam.d/liveinst /etc/pam.d/handlekickstart > ln -s consolehelper /usr/bin/handlekickstart > > > > > > On normal bootup of the liveCD, we would expect manual intervention. > > Not sure what you mean by this, or really if what I suggested above was > the sort of thing you had in mind. > > -dmc > > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > -- "Don't stand still, if you see me running down the road, 'cause there is trouble right behind me". -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at hubick.com Sat Sep 15 23:38:56 2007 From: chris at hubick.com (Chris Hubick) Date: Sat, 15 Sep 2007 19:38:56 -0400 (EDT) Subject: [Fedora-livecd-list] livecd-creator problems/questions Message-ID: Hi, I am having some problems with livecd-creator... 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 livecd-creator --config=/media/CHWData/chwlive/chwlive.ks --fslabel=CHWLive --tmpdir=/media/CHWData/chwlive/tmp 1) Note that if the path to the tmpdir is too long, /sbin/losetup -a will truncate the path in it's output, and livecd-creator will fail (after tweaking, mine above is *just* short enough). 2) I want a pure x86_64 system with no multilib. It took me some time to figure out to include --exclude=*.i?86 on the repo line in my kickstart file. Is that the best way to do this? 3) Is there any way to find out the final list of packages for a kickstart file after dependency resolution against a given set of repositories? I keep tweaking my kickstart file to get things to fit within the required size, but somehow I mistakenly add a package with a million dependencies I didn't know about, and livecd-creator then goes to download them all. It would be nice if there were an option, or separate tool, to print a list of packages for approval first, or at least a summary and size? 4) How do I build a LiveCD based on a specific (stableish) test release (7.91)? Given two repos: repo --exclude=*.i?86 --name=f8t2 --baseurl=http://fedora.mirror.iweb.ca/development/x86_64/os/ repo --exclude=*.i?86 --name=f8t2 --baseurl=http://fedora.mirror.iweb.ca/releases/test/7.91/Fedora/x86_64/os/ The first one will work, but the second will fail, because the release folder doesn't contain all the same packages (ie, rdesktop) (why)? 5) /usr/share/livecd-tools/livecd-fedora-desktop.ks has a directive: %include livecd-fedora-base-desktop.ks Where is that include file located? With the Fedora 7 setup examples, everything is in the one kickstart file, and easy to reference, but I have no idea how to find that information now? 6) How do I customize what user is created, auto-login, etc? That used to be in the bottom of the kickstart as well, but is gone now? 7) Is there any easy way to tell what is being downloaded and how fast? As it stands now, I have to browse into the tmpdir with Nautilus and watch. 8) I waited hours while it downloaded my packages, and then finally I came back to see this error: tune2fs 1.40.2 (12-Jul-2007) Setting maximal mount count to -1 Setting interval between checks to 0 seconds No Repositories Available to Set Up No Repositories Available to Set Up Excluding Packages from None Finished Installation target uncompressed data size is 136 MB umount: /media/CHWData/chwlive/tmp/livecd-creator-DTaMtf/install_root: device is busy umount: /media/CHWData/chwlive/tmp/livecd-creator-DTaMtf/install_root: device is busy ioctl: LOOP_CLR_FD: Device or resource busy Traceback (most recent call last): File "/usr/bin/livecd-creator", line 1341, in sys.exit(main()) File "/usr/bin/livecd-creator", line 1315, in main target.install() File "/usr/bin/livecd-creator", line 849, in install self.installPackages() File "/usr/bin/livecd-creator", line 535, in installPackages self.ayum.runInstall() File "/usr/bin/livecd-creator", line 316, in runInstall return self.runTransaction(cb) File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 581, in runTransaction raise Errors.YumBaseError, errors yum.Errors.YumBaseError: [('installing package gnome-power-manager-2.19.92-1.fc8 needs 6MB on the /media/CHWData/chwlive/tmp/livecd-creator-DTaMtf/install_root filesystem', (9, '/media/CHWData/chwlive/tmp/livecd-creator-DTaMtf/install_root', 5480448L)), ('installing package gnome-utils-2.19.92-1.fc8 needs 19MB on the /media/CHWData/chwlive/tmp/livecd-creator-DTaMtf/install_root filesystem',.... [...on and on and on with every package until a command prompt] 9) It deleted everything it downloaded! Gah! How do I stop this? So If I want to try again after the above crash, I have to wait hours? If the final iso doesn't fit on my disc or SD card, I have to download everything again for each attempt I want to make? Do you see how much of a problem this is when combined with the fact there is no way to tell how large it's going to be ahead of time? Can we make it so if you specify a tmpdir, that it just reuses that directory directly, along with any existing yum-cache, and doesn't delete it after? Help much appreciated, thanks!! --- Chris Hubick mailto:chris at hubick.com http://www.hubick.com/ From dmc.fedora at filteredperception.org Sun Sep 16 23:25:43 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 16 Sep 2007 18:25:43 -0500 Subject: [Fedora-livecd-list] livecd-creator problems/questions In-Reply-To: References: Message-ID: <46EDBB77.2020501@filteredperception.org> 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 > livecd-creator --config=/media/CHWData/chwlive/chwlive.ks --fslabel=CHWLive --tmpdir=/media/CHWData/chwlive/tmp > > 1) Note that if the path to the tmpdir is too long, /sbin/losetup -a will > truncate the path in it's output, and livecd-creator will fail (after > tweaking, mine above is *just* short enough). Interesting bug. It'll get fixed soon (answer is to rewrite the code so that it uses the output of losetup -f to determine the loop device to use before setting it up, rather than setting it up and then using losetup -a to figure out which one it automatically used.). > 2) I want a pure x86_64 system with no multilib. It took me some time to > figure out to include --exclude=*.i?86 on the repo line in my kickstart > file. Is that the best way to do this? I'm a 32bit luddite/cheapskate, can't help with this one. > 3) Is there any way to find out the final list of packages for a kickstart > file after dependency resolution against a given set of repositories? I've got a use for this, so I'm hoping someone else answers. I vaguely recall past threads that might be related to this. > I keep tweaking my kickstart file to get things to fit within the required > size, but somehow I mistakenly add a package with a million dependencies > I didn't know about, and livecd-creator then goes to download them all. > It would be nice if there were an option, or separate tool, to print a > list of packages for approval first, or at least a summary and size? This isn't exactly what you want, but here is a tool I use after a test spin, to determine what I want to remove for the next spin- http://www.mail-archive.com/fedora-livecd-list at redhat.com/msg00085.html > 4) How do I build a LiveCD based on a specific (stableish) test release > (7.91)? Given two repos: > > repo --exclude=*.i?86 --name=f8t2 --baseurl=http://fedora.mirror.iweb.ca/development/x86_64/os/ > repo --exclude=*.i?86 --name=f8t2 --baseurl=http://fedora.mirror.iweb.ca/releases/test/7.91/Fedora/x86_64/os/ > > The first one will work, but the second will fail, because the release > folder doesn't contain all the same packages (ie, rdesktop) (why)? > > 5) /usr/share/livecd-tools/livecd-fedora-desktop.ks has a directive: > %include livecd-fedora-base-desktop.ks > > Where is that include file located? With the Fedora 7 setup examples, > everything is in the one kickstart file, and easy to reference, but I have > no idea how to find that information now? Should be in /usr/share/livecd-tools/ as well. The change is that now inheritance/nested-kickstart-parsing is used. I've been meaning to try writing a hello world tool with pykickstart that will read a nested kickstart and output an un-nested kickstart... > > 6) How do I customize what user is created, auto-login, etc? That used to > be in the bottom of the kickstart as well, but is gone now? This is directly related to the previous question. If you find the livecd-fedora-base-desktop.ks you should find what you were familiar with. Hopefully other people can address the rest. Good luck... -dmc > 7) Is there any easy way to tell what is being downloaded and how fast? > As it stands now, I have to browse into the tmpdir with Nautilus and > watch. > > 8) I waited hours while it downloaded my packages, and then finally I came > back to see this error: > > tune2fs 1.40.2 (12-Jul-2007) > Setting maximal mount count to -1 > Setting interval between checks to 0 seconds > No Repositories Available to Set Up > No Repositories Available to Set Up > Excluding Packages from None > Finished > Installation target uncompressed data size is 136 MB > umount: /media/CHWData/chwlive/tmp/livecd-creator-DTaMtf/install_root: > device is busy > umount: /media/CHWData/chwlive/tmp/livecd-creator-DTaMtf/install_root: > device is busy > ioctl: LOOP_CLR_FD: Device or resource busy > Traceback (most recent call last): > File "/usr/bin/livecd-creator", line 1341, in > sys.exit(main()) > File "/usr/bin/livecd-creator", line 1315, in main > target.install() > File "/usr/bin/livecd-creator", line 849, in install > self.installPackages() > File "/usr/bin/livecd-creator", line 535, in installPackages > self.ayum.runInstall() > File "/usr/bin/livecd-creator", line 316, in runInstall > return self.runTransaction(cb) > File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 581, in > runTransaction > raise Errors.YumBaseError, errors > yum.Errors.YumBaseError: [('installing package > gnome-power-manager-2.19.92-1.fc8 needs 6MB on the > /media/CHWData/chwlive/tmp/livecd-creator-DTaMtf/install_root filesystem', > (9, '/media/CHWData/chwlive/tmp/livecd-creator-DTaMtf/install_root', > 5480448L)), ('installing package gnome-utils-2.19.92-1.fc8 needs 19MB on > the /media/CHWData/chwlive/tmp/livecd-creator-DTaMtf/install_root > filesystem',.... > > [...on and on and on with every package until a command prompt] > > 9) It deleted everything it downloaded! Gah! How do I stop this? > > So If I want to try again after the above crash, I have to wait hours? If > the final iso doesn't fit on my disc or SD card, I have to download > everything again for each attempt I want to make? Do you see how much of > a problem this is when combined with the fact there is no way to tell how > large it's going to be ahead of time? Can we make it so if you specify a > tmpdir, that it just reuses that directory directly, along with any > existing yum-cache, and doesn't delete it after? > > Help much appreciated, thanks!! > > --- > Chris Hubick > mailto:chris at hubick.com > http://www.hubick.com/ > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From dmc.fedora at filteredperception.org Mon Sep 17 03:56:55 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 16 Sep 2007 22:56:55 -0500 Subject: [Fedora-livecd-list] [PATCH] bugfix- losetup truncation problem Message-ID: <46EDFB07.1010501@filteredperception.org> attached patch fixes the losetup truncation problem brought up by Chris Hubick. -dmc -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.bugfix_losetupa.patch Type: text/x-patch Size: 1717 bytes Desc: not available URL: From ml at deadbabylon.de Mon Sep 17 14:17:43 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Mon, 17 Sep 2007 16:17:43 +0200 Subject: [Fedora-livecd-list] traceback after creation of initrd Message-ID: <20070917161743.3ca006d7@htpc> Since saturday I get the following error after the creation of the initrd: Building an initramfs at /boot/livecd-initramfs.img for kernel 2.6.23-0.184.rc6.git4.fc8 Done; initramfs is 4,5M. Traceback (most recent call last): File "/usr/bin/livecd-creator", line 1394, in sys.exit(main()) File "/usr/bin/livecd-creator", line 1387, in main target.teardown() File "/usr/bin/livecd-creator", line 507, in teardown self.unmount() File "/usr/bin/livecd-creator", line 489, in unmount self.ayum.close() File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 92, in close self._repos.close() File "/usr/lib/python2.5/site-packages/yum/repos.py", line 76, in close repo.close() File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 257, in close self.sack.close() File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 233, in close del self.pkgobjlist AttributeError: pkgobjlist livecd-tools from git and rawhide are up-to-date (an hour ago). Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Mon Sep 17 17:23:31 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Sep 2007 13:23:31 -0400 Subject: [Fedora-livecd-list] Live CD vs virtual appliance In-Reply-To: <46EAFD32.6010109@nanotechnologies.qc.ca> References: <46EAFD32.6010109@nanotechnologies.qc.ca> Message-ID: <1190049811.21026.26.camel@localhost.localdomain> On Fri, 2007-09-14 at 17:29 -0400, Patrice Guay wrote: > VMware has developed tools to create Linux-based virtual appliances. > They use a stripped down version of Ubuntu as the base OS. From what I > saw, livecd-tools offers a simpler and more powerful approach to create > an OS + application bundle. The virtual appliance creation involves > several steps and configuration files. Using livecd-creator, only one > configuration file is involved and only one command line is required to > create the iso image. There are patches floating around on the list from Mark McLoughlin to add support for generating more than just ISO images. I've mostly held off on applying them because they raise some interesting (to me at least) questions about code duplication and how to manage some of the code sharing that really needs to happen between livecd-creator and anaconda. That said, I think that after Fedora 8, it's going to be time to tackle those issues a bit more. > The only advantage of virtual appliances is persistence. If this could > be solved for livecd-tools, I foresee an increased interest from those > planning to create virtual appliances for the livecd-tools project. Well, the way that you solve persistence for appliances is (I think) just to to make it a non-issue. ie, don't use an iso + squashfs, instead maybe just have a qcow image with the ext3 filesystem on it. As above, the code isn't hard... just a question of what to do around a few abstractions Jeremy From dmc.fedora at filteredperception.org Mon Sep 17 17:22:56 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 17 Sep 2007 12:22:56 -0500 Subject: [Fedora-livecd-list] [PATCH 1/7] livecd: documentation typos Message-ID: <46EEB7F0.6050504@filteredperception.org> 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) -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-tools.1.doctypos.patch Type: text/x-patch Size: 939 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Mon Sep 17 17:24:25 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 17 Sep 2007 12:24:25 -0500 Subject: [Fedora-livecd-list] [PATCH 2/7] livecd: remove ignore-deleted option Message-ID: <46EEB849.9060204@filteredperception.org> ignore-deleted isn't an option worth keeping around -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-tools.2.remove_ignoredeleted_option.patch Type: text/x-patch Size: 964 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Mon Sep 17 17:26:47 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 17 Sep 2007 12:26:47 -0500 Subject: [Fedora-livecd-list] [PATCH 3/7] livecd: use dumpe2fs for resize2fsToMinimal instead of extra arg Message-ID: <46EEB8D7.3040004@filteredperception.org> logically there is no reason why resize2fsToMinimal should require an argument of the size in blocks of the filesystem that is passed in as it's first argument, when that can be calculated by pointing dumpe2fs at that first argument. -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-tools.3.resize2fsToMinimal_implicitsize.patch Type: text/x-patch Size: 1942 bytes Desc: not available URL: From katzj at redhat.com Mon Sep 17 17:30:53 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Sep 2007 13:30:53 -0400 Subject: [Fedora-livecd-list] [PATCH] bugfix- losetup truncation problem In-Reply-To: <46EDFB07.1010501@filteredperception.org> References: <46EDFB07.1010501@filteredperception.org> Message-ID: <1190050253.21026.28.camel@localhost.localdomain> On Sun, 2007-09-16 at 22:56 -0500, Douglas McClendon wrote: > attached patch fixes the losetup truncation problem brought up by Chris > Hubick. Looks good; applied. Thanks! Jeremy From katzj at redhat.com Mon Sep 17 17:31:43 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Sep 2007 13:31:43 -0400 Subject: [Fedora-livecd-list] traceback after creation of initrd In-Reply-To: <20070917161743.3ca006d7@htpc> References: <20070917161743.3ca006d7@htpc> Message-ID: <1190050303.21026.30.camel@localhost.localdomain> On Mon, 2007-09-17 at 16:17 +0200, Sebastian Vahl wrote: > Since saturday I get the following error after the creation of the > initrd: [snip] > livecd-tools from git and rawhide are up-to-date (an hour ago). *sigh* yum bug that only gets hit by livecd-creator. Fixed in upstream yum and yum-3.2.5-3.fc8 that I built an hour or so ago. Should be grabbable from koji at this point Jeremy From dmc.fedora at filteredperception.org Mon Sep 17 17:29:42 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 17 Sep 2007 12:29:42 -0500 Subject: [Fedora-livecd-list] [PATCH 4/7] anaconda: livecd.py: use dumpe2fs for getLiveSizeMB Message-ID: <46EEB986.5010605@filteredperception.org> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: anaconda.4.getLiveSizeMB_use_dumpe2fs.patch Type: text/x-patch Size: 1903 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Mon Sep 17 17:31:53 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 17 Sep 2007 12:31:53 -0500 Subject: [Fedora-livecd-list] [PATCH 5/7] anaconda: livecd.py: invoke resize2fs earlier Message-ID: <46EEBA09.6070907@filteredperception.org> even if turboLiveInst/genMinInstDelta didn't depend on this, it is not a bad idea to move resize2fs earlier in the anaconda livecd backend. Though practically, this is entirely for the benefit of turboLiveInst. -------------- next part -------------- A non-text attachment was scrubbed... Name: anaconda.5.earlier_resize2fs.patch Type: text/x-patch Size: 978 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Mon Sep 17 17:34:57 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 17 Sep 2007 12:34:57 -0500 Subject: [Fedora-livecd-list] [PATCH 6/7] anaconda: liveinst.sh: support turboLiveInst/genMinInstDelta Message-ID: <46EEBAC1.1050204@filteredperception.org> 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 beneficial final patch to livecd-tools. -------------- next part -------------- A non-text attachment was scrubbed... Name: anaconda.6.turboLiveInst.patch Type: text/x-patch Size: 1846 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Mon Sep 17 17:37:31 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 17 Sep 2007 12:37:31 -0500 Subject: [Fedora-livecd-list] [PATCH 7/7] livecd: improve livecd install speed by about 20%: turboLiveInst/genMinInstDelta Message-ID: <46EEBB5B.2030600@filteredperception.org> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.7.turboLiveInst.patch Type: text/x-patch Size: 9311 bytes Desc: not available URL: From katzj at redhat.com Mon Sep 17 17:55:06 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Sep 2007 13:55:06 -0400 Subject: [Fedora-livecd-list] livecd-creator problems/questions In-Reply-To: References: Message-ID: <1190051706.21026.49.camel@localhost.localdomain> On Sat, 2007-09-15 at 19:38 -0400, Chris Hubick wrote: > 1) Note that if the path to the tmpdir is too long, /sbin/losetup -a will > truncate the path in it's output, and livecd-creator will fail (after > tweaking, mine above is *just* short enough). dmc just sent a patch for this and I pulled it in, so this should be resolved in the next release. > 2) I want a pure x86_64 system with no multilib. It took me some time to > figure out to include --exclude=*.i?86 on the repo line in my kickstart > file. Is that the best way to do this? Either doing that or -*.i?86 in your %packages section are the way to go. The difference is with your approach there is _no_ way the package will get pulled in and you could end up having the build fail due to broken deps. But if you want to be absolutely certain there are no x86 packages, then that's probably more what you want. > 3) Is there any way to find out the final list of packages for a kickstart > file after dependency resolution against a given set of repositories? > > I keep tweaking my kickstart file to get things to fit within the required > size, but somehow I mistakenly add a package with a million dependencies > I didn't know about, and livecd-creator then goes to download them all. > It would be nice if there were an option, or separate tool, to print a > list of packages for approval first, or at least a summary and size? Not right now -- it could be relatively easily added, but that brings to mind questions for me of how you present it. Presenting the list of ~850 packages isn't going to be something which you can easily scroll through and say "yes, this is good". And size is also tricky as finding the final size really requires the install + compression pass. We could potentially give an estimate of the installed size minus the compression. But then I wonder if you want a prompt or a --dont-do-if-larger-than=size-MiB debug option. > 4) How do I build a LiveCD based on a specific (stableish) test release > (7.91)? Given two repos: > > repo --exclude=*.i?86 --name=f8t2 --baseurl=http://fedora.mirror.iweb.ca/development/x86_64/os/ > repo --exclude=*.i?86 --name=f8t2 --baseurl=http://fedora.mirror.iweb.ca/releases/test/7.91/Fedora/x86_64/os/ > > The first one will work, but the second will fail, because the release > folder doesn't contain all the same packages (ie, rdesktop) (why)? Given that we don't do the "everything" tree for test releases, it's a bit tricky, unfortunately :( > 5) /usr/share/livecd-tools/livecd-fedora-desktop.ks has a directive: > %include livecd-fedora-base-desktop.ks > > Where is that include file located? With the Fedora 7 setup examples, > everything is in the one kickstart file, and easy to reference, but I have > no idea how to find that information now? It was (mistakenly) not installed by the Makefile. You can grab it from git[1] or it'll be in the next build. > 6) How do I customize what user is created, auto-login, etc? That used to > be in the bottom of the kickstart as well, but is gone now? It's in the base-desktop config. The idea being that -desktop (and -kde) inherit from the base config and have the same bits there so copying and pasting is for the lose. > 7) Is there any easy way to tell what is being downloaded and how fast? > As it stands now, I have to browse into the tmpdir with Nautilus and > watch. What's being downloaded will be shown as of the next livecd-tools build thanks to a patch from Colin. Not sure if we can really get rate from urlgrabber easily. > 8) I waited hours while it downloaded my packages, and then finally I came > back to see this error: [snip] This means there isn't enough space in the root filesystem. The default rootfs is 4 gigs. If you want larger (or smaller), you can add a line part / --size 8192 or whatever to your config. I just committed a change to make this more explicit in the config. > 9) It deleted everything it downloaded! Gah! How do I stop this? You can now pass a cachedir to use with --cachedir=/path/to/my/cache and it won't get deleted. That said, you'll want to be extremely careful in doing so as multiple runs can stomp over each other as there's no locking of the cache. Jeremy From katzj at redhat.com Mon Sep 17 18:02:47 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Sep 2007 14:02:47 -0400 Subject: [Fedora-livecd-list] [PATCH 1/7] livecd: documentation typos In-Reply-To: <46EEB7F0.6050504@filteredperception.org> References: <46EEB7F0.6050504@filteredperception.org> Message-ID: <1190052167.21026.53.camel@localhost.localdomain> On Mon, 2007-09-17 at 12:22 -0500, Douglas McClendon wrote: > 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) (Reply for each individually as I look over and apply...) This one is obvious enough; applied. Thanks Jeremy From katzj at redhat.com Mon Sep 17 18:12:07 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Sep 2007 14:12:07 -0400 Subject: [Fedora-livecd-list] [PATCH 2/7] livecd: remove ignore-deleted option In-Reply-To: <46EEB849.9060204@filteredperception.org> References: <46EEB849.9060204@filteredperception.org> Message-ID: <1190052727.21026.57.camel@localhost.localdomain> 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. But assuming the rest requires this, looks fine and I'll just deal with the time hit. And maybe try to beat up some ext3 people about implementing 'resize2fs --minimal' :) Jeremy From katzj at redhat.com Mon Sep 17 18:19:44 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Sep 2007 14:19:44 -0400 Subject: [Fedora-livecd-list] [PATCH 3/7] livecd: use dumpe2fs for resize2fsToMinimal instead of extra arg In-Reply-To: <46EEB8D7.3040004@filteredperception.org> References: <46EEB8D7.3040004@filteredperception.org> Message-ID: <1190053184.21026.59.camel@localhost.localdomain> On Mon, 2007-09-17 at 12:26 -0500, Douglas McClendon wrote: > logically there is no reason why resize2fsToMinimal should require an > argument of the size in blocks of the filesystem that is passed in as > it's first argument, when that can be calculated by pointing dumpe2fs at > that first argument. Looks good; applied Jeremy From chris at hubick.com Mon Sep 17 18:21:06 2007 From: chris at hubick.com (Chris Hubick) Date: Mon, 17 Sep 2007 14:21:06 -0400 (EDT) Subject: [Fedora-livecd-list] livecd-creator problems/questions In-Reply-To: <1190051706.21026.49.camel@localhost.localdomain> References: <1190051706.21026.49.camel@localhost.localdomain> Message-ID: On Mon, 17 Sep 2007, Jeremy Katz wrote: > dmc just sent a patch for this and I pulled it in, so this should be > resolved in the next release. Thanks to you and DMC! :) > > 3) Is there any way to find out the final list of packages for a kickstart > > file after dependency resolution against a given set of repositories? > > Not right now -- it could be relatively easily added, but that brings to > mind questions for me of how you present it. Presenting the list of > ~850 packages isn't going to be something which you can easily scroll > through and say "yes, this is good". And size is also tricky as finding > the final size really requires the install + compression pass. > > We could potentially give an estimate of the installed size minus the > compression. But then I wonder if you want a prompt or a > --dont-do-if-larger-than=size-MiB debug option. I don't mind seeing a big huge package list (incl arch) dump if I ask for it. You could put them all on one line and let terminal wrapping take care of it, to at least minimize the output size. > > 4) How do I build a LiveCD based on a specific (stableish) test release > > (7.91)? Given two repos: > > Given that we don't do the "everything" tree for test releases, it's a > bit tricky, unfortunately :( Ok, well, I guess I will just have to live dangerously :) I don't know if this kind of thing is a suitable use case for providing an "everything" tree. > > 5) /usr/share/livecd-tools/livecd-fedora-desktop.ks has a directive: > > %include livecd-fedora-base-desktop.ks > > > > Where is that include file located? With the Fedora 7 setup examples, > > everything is in the one kickstart file, and easy to reference, but I have > > no idea how to find that information now? > > It was (mistakenly) not installed by the Makefile. You can grab it from > git[1] or it'll be in the next build. Excellent, thanks! > > 7) Is there any easy way to tell what is being downloaded and how fast? > > As it stands now, I have to browse into the tmpdir with Nautilus and > > watch. > > What's being downloaded will be shown as of the next livecd-tools build > thanks to a patch from Colin. Not sure if we can really get rate from > urlgrabber easily. Excellent, thanks! Does the output print the size of the package being downloaded? That way I could use mental/gut-feel rate monitoring to know if I have a sucky/overloaded mirror. > > 8) I waited hours while it downloaded my packages, and then finally I came > > back to see this error: > [snip] > > This means there isn't enough space in the root filesystem. The default > rootfs is 4 gigs. If you want larger (or smaller), you can add a line > part / --size 8192 > or whatever to your config. I just committed a change to make this more > explicit in the config. Ahh! Ok, thanks! My first thought is to wonder if setting the default to a size which is closer in alignment to a DVD would be better. But then I start wondering about dual-layer, etc, and think probably not. Another thought - if you integrate the functionality to build directly to a usb-thumb-drive or other such filesystem, it could then examine that device to provide more sensible defaults for this, as well as more intelligable errors if your package selections are too large. > > 9) It deleted everything it downloaded! Gah! How do I stop this? > > You can now pass a cachedir to use with --cachedir=/path/to/my/cache and > it won't get deleted. That said, you'll want to be extremely careful in > doing so as multiple runs can stomp over each other as there's no > locking of the cache. Oooh! Most excellent, thanks! :) And I don't think too many 'ordinary' users such as myself would have multiple simultaneous runs happening. --- Chris Hubick mailto:chris at hubick.com http://www.hubick.com/ From dmc.fedora at filteredperception.org Mon Sep 17 18:29:50 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 17 Sep 2007 13:29:50 -0500 Subject: [Fedora-livecd-list] [PATCH 2/7] livecd: remove ignore-deleted option In-Reply-To: <1190052727.21026.57.camel@localhost.localdomain> References: <46EEB849.9060204@filteredperception.org> <1190052727.21026.57.camel@localhost.localdomain> Message-ID: <46EEC79E.3080604@filteredperception.org> 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. > > But assuming the rest requires this, It does require it. But in a prior version of the patch, I had both ignore-deleted and turbo-liveinst as options which were mutually exclusive. Thus if you really wanted to, you could keep the ignore-deleted option, as long as you made the genMinInstDelta call conditional upon it. Thus making the code in liveinst.sh that detects the absence of the delta technically not purely legacy. The sentence at the top there does not reflect a strong opinion. I can see value in speeding up the build (~20-25% if I recall). But there is also some value in the removed complexity. Your call. -dmc looks fine and I'll just deal with > the time hit. And maybe try to beat up some ext3 people about > implementing 'resize2fs --minimal' :) > > Jeremy > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From katzj at redhat.com Mon Sep 17 18:41:28 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Sep 2007 14:41:28 -0400 Subject: [Fedora-livecd-list] [PATCH 4/7] anaconda: livecd.py: use dumpe2fs for getLiveSizeMB In-Reply-To: <46EEB986.5010605@filteredperception.org> References: <46EEB986.5010605@filteredperception.org> Message-ID: <1190054488.21026.61.camel@localhost.localdomain> On Mon, 2007-09-17 at 12:29 -0500, Douglas McClendon wrote: > 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. Applied, thanks. Jeremy From katzj at redhat.com Mon Sep 17 18:41:56 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Sep 2007 14:41:56 -0400 Subject: [Fedora-livecd-list] [PATCH 2/7] livecd: remove ignore-deleted option In-Reply-To: <46EEC79E.3080604@filteredperception.org> References: <46EEB849.9060204@filteredperception.org> <1190052727.21026.57.camel@localhost.localdomain> <46EEC79E.3080604@filteredperception.org> Message-ID: <1190054516.21026.63.camel@localhost.localdomain> On Mon, 2007-09-17 at 13:29 -0500, Douglas McClendon wrote: > 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. > > > > But assuming the rest requires this, > > It does require it. But in a prior version of the patch, I had both > ignore-deleted and turbo-liveinst as options which were mutually > exclusive. Thus if you really wanted to, you could keep the > ignore-deleted option, as long as you made the genMinInstDelta call > conditional upon it. Thus making the code in liveinst.sh that detects > the absence of the delta technically not purely legacy. > > The sentence at the top there does not reflect a strong opinion. I can > see value in speeding up the build (~20-25% if I recall). But there is > also some value in the removed complexity. Your call. For now, I've removed it. If I get annoyed at the time hit, I might change my mind in the future :) Jeremy From katzj at redhat.com Mon Sep 17 18:43:38 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Sep 2007 14:43:38 -0400 Subject: [Fedora-livecd-list] [PATCH 5/7] anaconda: livecd.py: invoke resize2fs earlier In-Reply-To: <46EEBA09.6070907@filteredperception.org> References: <46EEBA09.6070907@filteredperception.org> Message-ID: <1190054618.21026.65.camel@localhost.localdomain> On Mon, 2007-09-17 at 12:31 -0500, Douglas McClendon wrote: > even if turboLiveInst/genMinInstDelta didn't depend on this, it is not a > bad idea to move resize2fs earlier in the anaconda livecd backend. > Though practically, this is entirely for the benefit of turboLiveInst. Applied, thanks Jeremy From ml at deadbabylon.de Mon Sep 17 18:51:54 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Mon, 17 Sep 2007 20:51:54 +0200 Subject: [Fedora-livecd-list] traceback after creation of initrd In-Reply-To: <1190050303.21026.30.camel@localhost.localdomain> References: <20070917161743.3ca006d7@htpc> <1190050303.21026.30.camel@localhost.localdomain> Message-ID: <20070917205154.01a3948e@htpc> Am Mon, 17 Sep 2007 13:31:43 -0400 schrieb Jeremy Katz : > On Mon, 2007-09-17 at 16:17 +0200, Sebastian Vahl wrote: > > Since saturday I get the following error after the creation of the > > initrd: > [snip] > > livecd-tools from git and rawhide are up-to-date (an hour ago). > > *sigh* yum bug that only gets hit by livecd-creator. Fixed in > upstream yum and yum-3.2.5-3.fc8 that I built an hour or so ago. > Should be grabbable from koji at this point Confirmed. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Mon Sep 17 18:55:56 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 17 Sep 2007 13:55:56 -0500 Subject: [Fedora-livecd-list] related to 6/7, mayflower loop device cleanup proposal Message-ID: <46EECDBC.3030907@filteredperception.org> Jeremy, Now that you're into the guts of genMinInstDelta (patch 6/7), maybe this topic is very timely- I've recently (like finished this morning) done a personal rewrite of the functionality of mayflower. Setting asside why I did that, here is a proposal/notation relating that 6/7 patch. All those hard coded (117/118/119/120/121) loop devices used are very ugly. Probably they should get replaced with dynamic choices via losetup -f, as my recent livecd-creator patch did (though it was already using dynamic via losetup -a prior, different issue). I think I can put together a patch that does this. Will probably even look pretty slick, as they info would get conveyed via udev rules dynamically generated in mayflower-init (just like existing loop120 and loop121 rules, but based on dynamic rather than hard-coded loop devices). The other thing, is I seemed to notice that, at least for my test cases, the mknod-s of the /dev/loop??? devices in the mayflower-initramfs seem unnecessary, as udev seems to create them just fine. Anybody (david? jeremy?) know of why they are perhaps needed? I know you mentioned Jeremy, about merging mayflower into mkinitrd. In fact, that is one reason why I did the rewrite, as I need for it to remain runnable as non-root. You should probably get mkinitrd that way too, but...? But my point is that it's still probably good to do these cleanups to mayflower, as they will make the merge into mkinitrd that much easier/better. Just an idea... And I will post that rewrite soon enough, in case other parts of it are useful idea fodder... -dmc From katzj at redhat.com Mon Sep 17 19:01:57 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Sep 2007 15:01:57 -0400 Subject: [Fedora-livecd-list] livecd-creator problems/questions In-Reply-To: References: <1190051706.21026.49.camel@localhost.localdomain> Message-ID: <1190055717.21026.72.camel@localhost.localdomain> On Mon, 2007-09-17 at 14:21 -0400, Chris Hubick wrote: > On Mon, 17 Sep 2007, Jeremy Katz wrote: > > > 3) Is there any way to find out the final list of packages for a kickstart > > > file after dependency resolution against a given set of repositories? > > > > Not right now -- it could be relatively easily added, but that brings to > > mind questions for me of how you present it. Presenting the list of > > ~850 packages isn't going to be something which you can easily scroll > > through and say "yes, this is good". And size is also tricky as finding > > the final size really requires the install + compression pass. > > > > We could potentially give an estimate of the installed size minus the > > compression. But then I wonder if you want a prompt or a > > --dont-do-if-larger-than=size-MiB debug option. > > I don't mind seeing a big huge package list (incl arch) dump if I ask for > it. You could put them all on one line and let terminal wrapping take > care of it, to at least minimize the output size. It's still going to be a massive list. And for consistency, it would make sense to show in the same output format as yum. Not difficult and I'd probably take the patch. I'm likely to get to it ... ermm, not for a while :-/ > > > 7) Is there any easy way to tell what is being downloaded and how fast? > > > As it stands now, I have to browse into the tmpdir with Nautilus and > > > watch. > > > > What's being downloaded will be shown as of the next livecd-tools build > > thanks to a patch from Colin. Not sure if we can really get rate from > > urlgrabber easily. > > Excellent, thanks! Does the output print the size of the package being > downloaded? That way I could use mental/gut-feel rate monitoring to know > if I have a sucky/overloaded mirror. Right now, the output is just "Downloading foo..." and then "OK" when the download completes. Again, accepting patches :) > > > 8) I waited hours while it downloaded my packages, and then finally I came > > > back to see this error: > > [snip] > > > > This means there isn't enough space in the root filesystem. The default > > rootfs is 4 gigs. If you want larger (or smaller), you can add a line > > part / --size 8192 > > or whatever to your config. I just committed a change to make this more > > explicit in the config. > > Ahh! Ok, thanks! > > My first thought is to wonder if setting the default to a size which is > closer in alignment to a DVD would be better. But then I start wondering > about dual-layer, etc, and think probably not. Yeah, picking a default is always a bit tricky. I think by making it explicitly obvious in the config, it'll go a long way towards letting people think "oh, I want this to be bigger". We can also think a bit about somewhat separating out the "minimum" and the "available" size as the turboliveinst stuff gets merged. But I don't know that I really want to rock the boat in that way before F8. > Another thought - if you integrate the functionality to build directly to > a usb-thumb-drive or other such filesystem, it could then examine > that device to provide more sensible defaults for this, as well as more > intelligable errors if your package selections are too large. Yeah, there's definitely this. Although that gets into some of the other weird big questions (see my reply from earlier today about appliance images) Jeremy From katzj at redhat.com Mon Sep 17 19:07:43 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Sep 2007 15:07:43 -0400 Subject: [Fedora-livecd-list] related to 6/7, mayflower loop device cleanup proposal In-Reply-To: <46EECDBC.3030907@filteredperception.org> References: <46EECDBC.3030907@filteredperception.org> Message-ID: <1190056063.21026.79.camel@localhost.localdomain> 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. > All those hard coded (117/118/119/120/121) loop devices used are very ugly. > > Probably they should get replaced with dynamic choices via losetup -f, > as my recent livecd-creator patch did (though it was already using > dynamic via losetup -a prior, different issue). Agreed. Given that most people don't use loop devs explicitly, I can't see how this would be problematic. Too bad losetup doesn't have a "find the first available loopdev backwards" option, though. Because that would be even slicker as if there _are_ things lying around with loopdevs hard-coded, they wouldn't break. > I think I can put together a patch that does this. Will probably even > look pretty slick, as they info would get conveyed via udev rules > dynamically generated in mayflower-init (just like existing loop120 and > loop121 rules, but based on dynamic rather than hard-coded loop devices). *nod* > The other thing, is I seemed to notice that, at least for my test cases, > the mknod-s of the /dev/loop??? devices in the mayflower-initramfs seem > unnecessary, as udev seems to create them just fine. Anybody (david? > jeremy?) know of why they are perhaps needed? pre-udev version I suspect. There shouldn't be a need for it any more that I can see > I know you mentioned Jeremy, about merging mayflower into mkinitrd. In > fact, that is one reason why I did the rewrite, as I need for it to > remain runnable as non-root. You should probably get mkinitrd that way > too, but...? But my point is that it's still probably good to do these > cleanups to mayflower, as they will make the merge into mkinitrd that > much easier/better. FWIW, I have a branch of mkinitrd up that has the changes so that booting a live image with an initrd generated by it "works". The caveat being that some things like the udev rules aren't currently there and I sort of want to figure out a different way of conveying that. But ran out of time. For anyone interested, 'git clone http://katzj.fedorapeople.org/git/mkinitrd.git'. And yeah, the amount of mkinitrd requiring being run as root is so small and piddly that it really is quite annoying. Just haven't had the round tuits to fix them. > Just an idea... And I will post that rewrite soon enough, in case other > parts of it are useful idea fodder... Sure, sounds good. Jeremy From dmc.fedora at filteredperception.org Mon Sep 17 19:37:53 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 17 Sep 2007 14:37:53 -0500 Subject: [Fedora-livecd-list] related to 6/7, mayflower loop device cleanup proposal In-Reply-To: <1190056063.21026.79.camel@localhost.localdomain> References: <46EECDBC.3030907@filteredperception.org> <1190056063.21026.79.camel@localhost.localdomain> Message-ID: <46EED791.7060601@filteredperception.org> 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 caffeine run, so I'll respond to further stuff much later tonight or tomorrow. > >> All those hard coded (117/118/119/120/121) loop devices used are very ugly. >> >> Probably they should get replaced with dynamic choices via losetup -f, >> as my recent livecd-creator patch did (though it was already using >> dynamic via losetup -a prior, different issue). > > Agreed. Given that most people don't use loop devs explicitly, I can't > see how this would be problematic. Too bad losetup doesn't have a "find > the first available loopdev backwards" option, though. Because that > would be even slicker as if there _are_ things lying around with > loopdevs hard-coded, they wouldn't break. Between that and the *nod* I'll take that as "go ahead and make the patch, and for the rare people that have broken hardcoded loop stuff that can't handle taken low-numbered loop devices, *and* want to run those broken things in a LiveOS environment, too bad" > >> I think I can put together a patch that does this. Will probably even >> look pretty slick, as they info would get conveyed via udev rules >> dynamically generated in mayflower-init (just like existing loop120 and >> loop121 rules, but based on dynamic rather than hard-coded loop devices). > > *nod* > >> The other thing, is I seemed to notice that, at least for my test cases, >> the mknod-s of the /dev/loop??? devices in the mayflower-initramfs seem >> unnecessary, as udev seems to create them just fine. Anybody (david? >> jeremy?) know of why they are perhaps needed? > > pre-udev version I suspect. There shouldn't be a need for it any more > that I can see > >> I know you mentioned Jeremy, about merging mayflower into mkinitrd. In >> fact, that is one reason why I did the rewrite, as I need for it to >> remain runnable as non-root. You should probably get mkinitrd that way >> too, but...? But my point is that it's still probably good to do these >> cleanups to mayflower, as they will make the merge into mkinitrd that >> much easier/better. > > FWIW, I have a branch of mkinitrd up that has the changes so that > booting a live image with an initrd generated by it "works". The caveat > being that some things like the udev rules aren't currently there and I > sort of want to figure out a different way of conveying that. But ran > out of time. For anyone interested, 'git clone > http://katzj.fedorapeople.org/git/mkinitrd.git'. > > And yeah, the amount of mkinitrd requiring being run as root is so small > and piddly that it really is quite annoying. Just haven't had the round > tuits to fix them. Is it anything that can't be handled by the fakeroot tool that Colin recently pointed me at? (and perhaps mtools?) -dmc From katzj at redhat.com Mon Sep 17 19:47:18 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Sep 2007 15:47:18 -0400 Subject: [Fedora-livecd-list] related to 6/7, mayflower loop device cleanup proposal In-Reply-To: <46EED791.7060601@filteredperception.org> References: <46EECDBC.3030907@filteredperception.org> <1190056063.21026.79.camel@localhost.localdomain> <46EED791.7060601@filteredperception.org> Message-ID: <1190058438.21026.102.camel@localhost.localdomain> On Mon, 2007-09-17 at 14:37 -0500, Douglas McClendon wrote: > Jeremy Katz wrote: > > On Mon, 2007-09-17 at 13:55 -0500, Douglas McClendon wrote: > >> All those hard coded (117/118/119/120/121) loop devices used are very ugly. > >> > >> Probably they should get replaced with dynamic choices via losetup -f, > >> as my recent livecd-creator patch did (though it was already using > >> dynamic via losetup -a prior, different issue). > > > > Agreed. Given that most people don't use loop devs explicitly, I can't > > see how this would be problematic. Too bad losetup doesn't have a "find > > the first available loopdev backwards" option, though. Because that > > would be even slicker as if there _are_ things lying around with > > loopdevs hard-coded, they wouldn't break. > > Between that and the *nod* I'll take that as "go ahead and make the > patch, and for the rare people that have broken hardcoded loop stuff > that can't handle taken low-numbered loop devices, *and* want to run > those broken things in a LiveOS environment, too bad" Yeah, I think that's pretty much where I sit :) > > And yeah, the amount of mkinitrd requiring being run as root is so small > > and piddly that it really is quite annoying. Just haven't had the round > > tuits to fix them. > > Is it anything that can't be handled by the fakeroot tool that Colin > recently pointed me at? (and perhaps mtools?) To be honest, the only things that are there are a few mknods. And I can't see any good reason why those have to be done at initrd creation rather than at run-time Jeremy From katzj at redhat.com Mon Sep 17 21:35:30 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Sep 2007 17:35:30 -0400 Subject: [Fedora-livecd-list] [PATCH 6/7] anaconda: liveinst.sh: support turboLiveInst/genMinInstDelta In-Reply-To: <46EEBAC1.1050204@filteredperception.org> References: <46EEBAC1.1050204@filteredperception.org> Message-ID: <1190064930.21026.123.camel@localhost.localdomain> 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 it gracefully. Thus this patch is safe > even in the absence of the actual beneficial final patch to livecd-tools. So as you alluded in your later mail, this looks like it could be confused if something else ended up using loop118 instead. Is there a good reason not to just set up the minimal snapshot from the initrd and then just use it if it exists? That would then make the anaconda side super-crazy-simple (look for /dev/mapper/live-osimg-min and use it if it exists). The only downside I can see is that the snapshot is always set up which probably has some resource cost, but I can't see it being that high. Jeremy From katzj at redhat.com Mon Sep 17 21:40:09 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Sep 2007 17:40:09 -0400 Subject: [Fedora-livecd-list] [PATCH 7/7] livecd: improve livecd install speed by about 20%: turboLiveInst/genMinInstDelta In-Reply-To: <46EEBB5B.2030600@filteredperception.org> References: <46EEBB5B.2030600@filteredperception.org> Message-ID: <1190065209.21026.129.camel@localhost.localdomain> 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.resize2fsToMinimal_implicitsize/creator/livecd-creator 2007-09-17 17:09:57.000000000 +0000 > +++ livecd.turboliveinst/creator/livecd-creator 2007-09-14 17:40:21.000000000 +0000 > + def genMinInstDelta(self):' [snip] > + # associate os image with loop device > + osloop = LoopbackMount("%s/data/os.img" %(self.build_dir,), > + "not_going_to_actually_get_mounted") Maybe just use None here instead of that. But nitpicky and not a big deal > + # calculate how much delta data to keep [snip] > + try: > + minInstDeltaDataLength = int((dmsetupOutput.split()[3]).split('/')[0]) Ugh, depending on dmsetup's output to not change scares me. But I don't see any alternative. Probably worth giving an example output of what's being split apart just so that when it _does_ change, it's easier to figure out what we were using. > diff -Naur livecd.3.resize2fsToMinimal_implicitsize/creator/mayflower livecd.turboliveinst/creator/mayflower > --- livecd.3.resize2fsToMinimal_implicitsize/creator/mayflower 2007-09-14 05:49:42.000000000 +0000 > +++ livecd.turboliveinst/creator/mayflower 2007-09-14 18:28:20.000000000 +0000 > @@ -625,6 +625,24 @@ > mount -n -o ro,remount /sysroot > } > > +modprobe loop max_loop=128 > + > +# we might have a genMinInstDelta delta file for anaconda to take advantage of > +if [ -e /sysroot/LiveOS/osmin.gz ]; then > + mknod /dev/loop118 b 7 118 > + # note: osmin.gz should typically only be about 7kb. > + dd if=/sysroot/LiveOS/osmin.gz of=/osmin.gz bs=512 2> /dev/null > + # pad to at least next sector boundry > + dd if=/dev/zero of=/osmin.gz bs=512 count=1 oflag=append conv=notrunc 2> /dev/null > + losetup /dev/loop118 /osmin.gz > +elif [ -e /sysroot/osmin.gz ] ; then > + mknod /dev/loop118 b 7 118 > + dd if=/sysroot/osmin.gz of=/osmin.gz bs=512 2> /dev/null > + # pad to at least next sector boundry > + dd if=/dev/zero of=/osmin.gz bs=512 count=1 oflag=append conv=notrunc 2> /dev/null > + losetup /dev/loop118 /osmin.gz > +fi Better to check for the existence of the files and then set $MINIMG or similar. That way, the rest of the check can avoid suffering cut and paste problems Jeremy From dmc.fedora at filteredperception.org Tue Sep 18 03:31:15 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 17 Sep 2007 22:31:15 -0500 Subject: [Fedora-livecd-list] [PATCH 6/7] anaconda: liveinst.sh: support turboLiveInst/genMinInstDelta In-Reply-To: <1190064930.21026.123.camel@localhost.localdomain> References: <46EEBAC1.1050204@filteredperception.org> <1190064930.21026.123.camel@localhost.localdomain> Message-ID: <46EF4683.3090902@filteredperception.org> 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 it gracefully. Thus this patch is safe >> even in the absence of the actual beneficial final patch to livecd-tools. > > So as you alluded in your later mail, this looks like it could be > confused if something else ended up using loop118 instead. Is there a > good reason not to just set up the minimal snapshot from the initrd and > then just use it if it exists? That would then make the anaconda side > super-crazy-simple (look for /dev/mapper/live-osimg-min and use it if it > exists). The danger would be loop117, as that is the one created at install time. loop118 being locked up at initramfs time. The reason why I think it should stay as is, instead of setting everything up at initramfs time, is because the loop117 gets associated with the decompressed-into-devshm contents of loop118. The decompression being 7kb->1.2M in the typical case. I'd say that the 1.2M ram hit should only be taken during install, and that outweighs the benefits of moving the complexity from liveinst.sh to initramfs. And as for the theoretical possibility that loop117 could be in use, that should be addressed by a forthcoming patch which removes all the hardcoded loop device usage. -dmc > The only downside I can see is that the snapshot is always set up which > probably has some resource cost, but I can't see it being that high. > > Jeremy > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From dmc.fedora at filteredperception.org Tue Sep 18 03:33:20 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 17 Sep 2007 22:33:20 -0500 Subject: [Fedora-livecd-list] [PATCH 7/7] livecd: improve livecd install speed by about 20%: turboLiveInst/genMinInstDelta In-Reply-To: <1190065209.21026.129.camel@localhost.localdomain> References: <46EEBB5B.2030600@filteredperception.org> <1190065209.21026.129.camel@localhost.localdomain> Message-ID: <46EF4700.8060901@filteredperception.org> 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.resize2fsToMinimal_implicitsize/creator/livecd-creator 2007-09-17 17:09:57.000000000 +0000 >> +++ livecd.turboliveinst/creator/livecd-creator 2007-09-14 17:40:21.000000000 +0000 >> + def genMinInstDelta(self):' > [snip] >> + # associate os image with loop device >> + osloop = LoopbackMount("%s/data/os.img" %(self.build_dir,), >> + "not_going_to_actually_get_mounted") > > Maybe just use None here instead of that. But nitpicky and not a big > deal > >> + # calculate how much delta data to keep > [snip] >> + try: >> + minInstDeltaDataLength = int((dmsetupOutput.split()[3]).split('/')[0]) > > Ugh, depending on dmsetup's output to not change scares me. But I don't > see any alternative. Probably worth giving an example output of what's > being split apart just so that when it _does_ change, it's easier to > figure out what we were using. > >> diff -Naur livecd.3.resize2fsToMinimal_implicitsize/creator/mayflower livecd.turboliveinst/creator/mayflower >> --- livecd.3.resize2fsToMinimal_implicitsize/creator/mayflower 2007-09-14 05:49:42.000000000 +0000 >> +++ livecd.turboliveinst/creator/mayflower 2007-09-14 18:28:20.000000000 +0000 >> @@ -625,6 +625,24 @@ >> mount -n -o ro,remount /sysroot >> } >> >> +modprobe loop max_loop=128 >> + >> +# we might have a genMinInstDelta delta file for anaconda to take advantage of >> +if [ -e /sysroot/LiveOS/osmin.gz ]; then >> + mknod /dev/loop118 b 7 118 >> + # note: osmin.gz should typically only be about 7kb. >> + dd if=/sysroot/LiveOS/osmin.gz of=/osmin.gz bs=512 2> /dev/null >> + # pad to at least next sector boundry >> + dd if=/dev/zero of=/osmin.gz bs=512 count=1 oflag=append conv=notrunc 2> /dev/null >> + losetup /dev/loop118 /osmin.gz >> +elif [ -e /sysroot/osmin.gz ] ; then >> + mknod /dev/loop118 b 7 118 >> + dd if=/sysroot/osmin.gz of=/osmin.gz bs=512 2> /dev/null >> + # pad to at least next sector boundry >> + dd if=/dev/zero of=/osmin.gz bs=512 count=1 oflag=append conv=notrunc 2> /dev/null >> + losetup /dev/loop118 /osmin.gz >> +fi > > Better to check for the existence of the files and then set $MINIMG or > similar. That way, the rest of the check can avoid suffering cut and > paste problems > > Jeremy > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From dmc.fedora at filteredperception.org Tue Sep 18 06:55:49 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 18 Sep 2007 01:55:49 -0500 Subject: [Fedora-livecd-list] [Revised PATCH 7/7] livecd: improve livecd install speed by about 20%: turboLiveInst/genMinInstDelta In-Reply-To: <46EF4700.8060901@filteredperception.org> References: <46EEBB5B.2030600@filteredperception.org> <1190065209.21026.129.camel@localhost.localdomain> <46EF4700.8060901@filteredperception.org> Message-ID: <46EF7675.4090602@filteredperception.org> 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 McClendon wrote: >>> diff -Naur >>> livecd.3.resize2fsToMinimal_implicitsize/creator/livecd-creator >>> livecd.turboliveinst/creator/livecd-creator >>> --- >>> livecd.3.resize2fsToMinimal_implicitsize/creator/livecd-creator >>> 2007-09-17 17:09:57.000000000 +0000 >>> +++ livecd.turboliveinst/creator/livecd-creator 2007-09-14 >>> 17:40:21.000000000 +0000 + def genMinInstDelta(self):' >> [snip] >>> + # associate os image with loop device >>> + osloop = LoopbackMount("%s/data/os.img" %(self.build_dir,), >>> + "not_going_to_actually_get_mounted") >> >> Maybe just use None here instead of that. But nitpicky and not a big >> deal >> >>> + # calculate how much delta data to keep >> [snip] >>> + try: >>> + minInstDeltaDataLength = >>> int((dmsetupOutput.split()[3]).split('/')[0]) >> >> Ugh, depending on dmsetup's output to not change scares me. But I don't >> see any alternative. Probably worth giving an example output of what's >> being split apart just so that when it _does_ change, it's easier to >> figure out what we were using. >> >>> diff -Naur livecd.3.resize2fsToMinimal_implicitsize/creator/mayflower >>> livecd.turboliveinst/creator/mayflower >>> --- livecd.3.resize2fsToMinimal_implicitsize/creator/mayflower >>> 2007-09-14 05:49:42.000000000 +0000 >>> +++ livecd.turboliveinst/creator/mayflower 2007-09-14 >>> 18:28:20.000000000 +0000 >>> @@ -625,6 +625,24 @@ >>> mount -n -o ro,remount /sysroot >>> } >>> >>> +modprobe loop max_loop=128 >>> + >>> +# we might have a genMinInstDelta delta file for anaconda to take >>> advantage of >>> +if [ -e /sysroot/LiveOS/osmin.gz ]; then >>> + mknod /dev/loop118 b 7 118 >>> + # note: osmin.gz should typically only be about 7kb. + dd >>> if=/sysroot/LiveOS/osmin.gz of=/osmin.gz bs=512 2> /dev/null >>> + # pad to at least next sector boundry >>> + dd if=/dev/zero of=/osmin.gz bs=512 count=1 oflag=append >>> conv=notrunc 2> /dev/null >>> + losetup /dev/loop118 /osmin.gz >>> +elif [ -e /sysroot/osmin.gz ] ; then >>> + mknod /dev/loop118 b 7 118 >>> + dd if=/sysroot/osmin.gz of=/osmin.gz bs=512 2> /dev/null >>> + # pad to at least next sector boundry >>> + dd if=/dev/zero of=/osmin.gz bs=512 count=1 oflag=append >>> conv=notrunc 2> /dev/null >>> + losetup /dev/loop118 /osmin.gz >>> +fi >> >> Better to check for the existence of the files and then set $MINIMG or >> similar. That way, the rest of the check can avoid suffering cut and >> paste problems >> >> Jeremy >> >> -- >> Fedora-livecd-list mailing list >> Fedora-livecd-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.7.turboLiveInst.revised.patch Type: text/x-patch Size: 10394 bytes Desc: not available URL: From katzj at redhat.com Tue Sep 18 14:46:15 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 18 Sep 2007 10:46:15 -0400 Subject: [Fedora-livecd-list] [Revised PATCH 7/7] livecd: improve livecd install speed by about 20%: turboLiveInst/genMinInstDelta In-Reply-To: <46EF7675.4090602@filteredperception.org> References: <46EEBB5B.2030600@filteredperception.org> <1190065209.21026.129.camel@localhost.localdomain> <46EF4700.8060901@filteredperception.org> <46EF7675.4090602@filteredperception.org> Message-ID: <1190126775.4377.14.camel@localhost.localdomain> On Tue, 2007-09-18 at 01:55 -0500, Douglas McClendon wrote: > revised patch attached. Not tested, but I've convinced myself it does > the same thing. Feel free to prune my verbose comments... Applied with some verbosity pruned :) Jeremy From katzj at redhat.com Tue Sep 18 17:16:28 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 18 Sep 2007 13:16:28 -0400 Subject: [Fedora-livecd-list] [PATCH 6/7] anaconda: liveinst.sh: support turboLiveInst/genMinInstDelta In-Reply-To: <46EF4683.3090902@filteredperception.org> References: <46EEBAC1.1050204@filteredperception.org> <1190064930.21026.123.camel@localhost.localdomain> <46EF4683.3090902@filteredperception.org> Message-ID: <1190135788.15490.7.camel@localhost.localdomain> On Mon, 2007-09-17 at 22:31 -0500, Douglas McClendon wrote: > 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 it gracefully. Thus this patch is safe > >> even in the absence of the actual beneficial final patch to livecd-tools. > > > > So as you alluded in your later mail, this looks like it could be > > confused if something else ended up using loop118 instead. Is there a > > good reason not to just set up the minimal snapshot from the initrd and > > then just use it if it exists? That would then make the anaconda side > > super-crazy-simple (look for /dev/mapper/live-osimg-min and use it if it > > exists). > > 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 wouldn't have been used and something else could use it while the live system is running. > The reason why I think it should stay as is, instead of setting > everything up at initramfs time, is because the loop117 gets associated > with the decompressed-into-devshm contents of loop118. The > decompression being 7kb->1.2M in the typical case. > > I'd say that the 1.2M ram hit should only be taken during install, and > that outweighs the benefits of moving the complexity from liveinst.sh to > initramfs. But the time that the memory hit matters the _most_ is during the install as we have to have swap disabled during parts of it. Otherwise, swap is available and can be used. It also means that there's less need to worry about the cleanup case in anaconda. Also, it takes care of my biggest complaint from the past (anaconda having to know too many details of how things are setup -- I _really_ like that right now, anaconda just needs to know to look at block device that's already set up and nothing more is needed) Patch ends up being the attached plus the teensy change so that anaconda will check /dev/mapper/live-osimg-min Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: osmin-in-initrd.patch Type: text/x-patch Size: 2362 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Tue Sep 18 18:45:25 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 18 Sep 2007 13:45:25 -0500 Subject: [Fedora-livecd-list] [PATCH 6/7] anaconda: liveinst.sh: support turboLiveInst/genMinInstDelta In-Reply-To: <1190135788.15490.7.camel@localhost.localdomain> References: <46EEBAC1.1050204@filteredperception.org> <1190064930.21026.123.camel@localhost.localdomain> <46EF4683.3090902@filteredperception.org> <1190135788.15490.7.camel@localhost.localdomain> Message-ID: <46F01CC5.3010408@filteredperception.org> 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 > wouldn't have been used and something else could use it while the live > system is running. This is true, albeit unlikely as well. But also fixable by addressing the hardcoded loop device issue across the board. > >> The reason why I think it should stay as is, instead of setting >> everything up at initramfs time, is because the loop117 gets associated >> with the decompressed-into-devshm contents of loop118. The >> decompression being 7kb->1.2M in the typical case. >> >> I'd say that the 1.2M ram hit should only be taken during install, and >> that outweighs the benefits of moving the complexity from liveinst.sh to >> initramfs. > > But the time that the memory hit matters the _most_ is during the > install as we have to have swap disabled during parts of it. Obviously this is your call, and from my perspective not a big deal either way. My own personal preference still remains freeing up the 1.2M of ram during all times other than the install, at the expense of the complexity being in anaconda/liveinst.sh, versus being in initramfs. Perhaps by F9 I'll find a mechanism to achieve this that you like... Otherwise, > swap is available and can be used. It also means that there's less need > to worry about the cleanup case in anaconda. Also, it takes care of my > biggest complaint from the past (anaconda having to know too many > details of how things are setup -- I _really_ like that right now, > anaconda just needs to know to look at block device that's already set > up and nothing more is needed) > > Patch ends up being the attached plus the teensy change so that anaconda > will check /dev/mapper/live-osimg-min Looks fine to me. Thanks for the merge work. Now I'll move on to seeing what I can do in the next couple days with that persistence patch. And maybe some other interesting things after that... ;) peace... -dmc P.S.- I'm still curious on that davej ping regarding unionfs. From dmc.fedora at filteredperception.org Tue Sep 18 20:09:36 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 18 Sep 2007 15:09:36 -0500 Subject: [Fedora-livecd-list] [PATCH 6/7] anaconda: liveinst.sh: support turboLiveInst/genMinInstDelta In-Reply-To: <46F01CC5.3010408@filteredperception.org> References: <46EEBAC1.1050204@filteredperception.org> <1190064930.21026.123.camel@localhost.localdomain> <46EF4683.3090902@filteredperception.org> <1190135788.15490.7.camel@localhost.localdomain> <46F01CC5.3010408@filteredperception.org> Message-ID: <46F03080.9050702@filteredperception.org> 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-creator -- then loop118 >> wouldn't have been used and something else could use it while the live >> system is running. > > This is true, albeit unlikely as well. But also fixable by addressing > the hardcoded loop device issue across the board. > >> >>> The reason why I think it should stay as is, instead of setting >>> everything up at initramfs time, is because the loop117 gets >>> associated with the decompressed-into-devshm contents of loop118. >>> The decompression being 7kb->1.2M in the typical case. >>> >>> I'd say that the 1.2M ram hit should only be taken during install, >>> and that outweighs the benefits of moving the complexity from >>> liveinst.sh to initramfs. >> >> But the time that the memory hit matters the _most_ is during the >> install as we have to have swap disabled during parts of it. > > Obviously this is your call, and from my perspective not a big deal > either way. My own personal preference still remains freeing up the > 1.2M of ram during all times other than the install, at the expense of > the complexity being in anaconda/liveinst.sh, versus being in initramfs. > > Perhaps by F9 I'll find a mechanism to achieve this that you like... Or maybe in significantly less time than that... How's this- 1) In initramfs, instead of lazy unmounting the squashfs, bindmount it to /sysroot/mnt/.LiveOS/squashfs 2) store osmin 'uncompressed' on the squashfs 3) in initramfs, set up the osimg-min device, but now with the loop118 pointing at /sysroot/mnt/.LiveOS/squashfs/osmin The result- All the same low-impact that the current method has with anaconda, but the 1.2M of ram will only get used when anaconda actually starts touching /dev/mapper/live-osimg-min And given that it is a 1.2M file that compresses to 7kb, I'm assuming that squashfs will basically read and uncompress it only once. (and if memory is so constrained that during installation it gets swapped out, it's probably a good thing that that is possible and squashfs may read and uncompress it again). By jeeves, I think we've got it. (correct me if I'm wrong or missing something) Thanks for being so stubborn :) -dmc > Otherwise, >> swap is available and can be used. It also means that there's less need >> to worry about the cleanup case in anaconda. Also, it takes care of my >> biggest complaint from the past (anaconda having to know too many >> details of how things are setup -- I _really_ like that right now, >> anaconda just needs to know to look at block device that's already set >> up and nothing more is needed) >> >> Patch ends up being the attached plus the teensy change so that anaconda >> will check /dev/mapper/live-osimg-min > > Looks fine to me. Thanks for the merge work. > > Now I'll move on to seeing what I can do in the next couple days with > that persistence patch. And maybe some other interesting things after > that... ;) > > peace... > > -dmc > > P.S.- I'm still curious on that davej ping regarding unionfs. > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From dmc.fedora at filteredperception.org Tue Sep 18 20:15:30 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 18 Sep 2007 15:15:30 -0500 Subject: [Fedora-livecd-list] [PATCH 6/7] anaconda: liveinst.sh: support turboLiveInst/genMinInstDelta In-Reply-To: <46F03080.9050702@filteredperception.org> References: <46EEBAC1.1050204@filteredperception.org> <1190064930.21026.123.camel@localhost.localdomain> <46EF4683.3090902@filteredperception.org> <1190135788.15490.7.camel@localhost.localdomain> <46F01CC5.3010408@filteredperception.org> <46F03080.9050702@filteredperception.org> Message-ID: <46F031E2.8080302@filteredperception.org> 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 is used with old livecd-creator -- then loop118 >>> wouldn't have been used and something else could use it while the live >>> system is running. >> >> This is true, albeit unlikely as well. But also fixable by addressing >> the hardcoded loop device issue across the board. >> >>> >>>> The reason why I think it should stay as is, instead of setting >>>> everything up at initramfs time, is because the loop117 gets >>>> associated with the decompressed-into-devshm contents of loop118. >>>> The decompression being 7kb->1.2M in the typical case. >>>> >>>> I'd say that the 1.2M ram hit should only be taken during install, >>>> and that outweighs the benefits of moving the complexity from >>>> liveinst.sh to initramfs. >>> >>> But the time that the memory hit matters the _most_ is during the >>> install as we have to have swap disabled during parts of it. >> >> Obviously this is your call, and from my perspective not a big deal >> either way. My own personal preference still remains freeing up the >> 1.2M of ram during all times other than the install, at the expense of >> the complexity being in anaconda/liveinst.sh, versus being in initramfs. >> >> Perhaps by F9 I'll find a mechanism to achieve this that you like... > > Or maybe in significantly less time than that... > > How's this- > > 1) In initramfs, instead of lazy unmounting the squashfs, bindmount it > to /sysroot/mnt/.LiveOS/squashfs bindmount/movemount, whatever... > > 2) store osmin 'uncompressed' on the squashfs > > 3) in initramfs, set up the osimg-min device, but now with the loop118 > pointing at /sysroot/mnt/.LiveOS/squashfs/osmin > > The result- All the same low-impact that the current method has with > anaconda, but the 1.2M of ram will only get used when anaconda actually > starts touching /dev/mapper/live-osimg-min > > And given that it is a 1.2M file that compresses to 7kb, I'm assuming > that squashfs will basically read and uncompress it only once. (and if > memory is so constrained that during installation it gets swapped out, > it's probably a good thing that that is possible and squashfs may read > and uncompress it again). swapout/dropped-from-buffer/squashfs/page-cache, whatever... > By jeeves, I think we've got it. (correct me if I'm wrong or missing > something) > > Thanks for being so stubborn :) > > -dmc > > >> Otherwise, >>> swap is available and can be used. It also means that there's less need >>> to worry about the cleanup case in anaconda. Also, it takes care of my >>> biggest complaint from the past (anaconda having to know too many >>> details of how things are setup -- I _really_ like that right now, >>> anaconda just needs to know to look at block device that's already set >>> up and nothing more is needed) >>> >>> Patch ends up being the attached plus the teensy change so that anaconda >>> will check /dev/mapper/live-osimg-min >> >> Looks fine to me. Thanks for the merge work. >> >> Now I'll move on to seeing what I can do in the next couple days with >> that persistence patch. And maybe some other interesting things after >> that... ;) >> >> peace... >> >> -dmc >> >> P.S.- I'm still curious on that davej ping regarding unionfs. >> >> -- >> Fedora-livecd-list mailing list >> Fedora-livecd-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From katzj at redhat.com Tue Sep 18 20:34:38 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 18 Sep 2007 16:34:38 -0400 Subject: [Fedora-livecd-list] [PATCH 6/7] anaconda: liveinst.sh: support turboLiveInst/genMinInstDelta In-Reply-To: <46F03080.9050702@filteredperception.org> References: <46EEBAC1.1050204@filteredperception.org> <1190064930.21026.123.camel@localhost.localdomain> <46EF4683.3090902@filteredperception.org> <1190135788.15490.7.camel@localhost.localdomain> <46F01CC5.3010408@filteredperception.org> <46F03080.9050702@filteredperception.org> Message-ID: <1190147678.15490.17.camel@localhost.localdomain> 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 locked up at initramfs time. > >> > >> Not if new anaconda is used with old livecd-creator -- then loop118 > >> wouldn't have been used and something else could use it while the live > >> system is running. > > > > This is true, albeit unlikely as well. But also fixable by addressing > > the hardcoded loop device issue across the board. > > > >> > >>> The reason why I think it should stay as is, instead of setting > >>> everything up at initramfs time, is because the loop117 gets > >>> associated with the decompressed-into-devshm contents of loop118. > >>> The decompression being 7kb->1.2M in the typical case. > >>> > >>> I'd say that the 1.2M ram hit should only be taken during install, > >>> and that outweighs the benefits of moving the complexity from > >>> liveinst.sh to initramfs. > >> > >> But the time that the memory hit matters the _most_ is during the > >> install as we have to have swap disabled during parts of it. > > > > Obviously this is your call, and from my perspective not a big deal > > either way. My own personal preference still remains freeing up the > > 1.2M of ram during all times other than the install, at the expense of > > the complexity being in anaconda/liveinst.sh, versus being in initramfs. > > > > Perhaps by F9 I'll find a mechanism to achieve this that you like... > > Or maybe in significantly less time than that... > > How's this- > > 1) In initramfs, instead of lazy unmounting the squashfs, bindmount it > to /sysroot/mnt/.LiveOS/squashfs > > 2) store osmin 'uncompressed' on the squashfs > > 3) in initramfs, set up the osimg-min device, but now with the loop118 > pointing at /sysroot/mnt/.LiveOS/squashfs/osmin > > The result- All the same low-impact that the current method has with > anaconda, but the 1.2M of ram will only get used when anaconda actually > starts touching /dev/mapper/live-osimg-min Okay, one better -- what if we just delay the lazy unmount of /squashfs until after we've done the osimg-min setup. There's no reason it has to be mounted under the sysroot, we just have to wait to unmount the squashed copy. 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? Jeremy From dmc.fedora at filteredperception.org Tue Sep 18 20:48:29 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 18 Sep 2007 15:48:29 -0500 Subject: [Fedora-livecd-list] [PATCH 6/7] anaconda: liveinst.sh: support turboLiveInst/genMinInstDelta In-Reply-To: <1190147678.15490.17.camel@localhost.localdomain> References: <46EEBAC1.1050204@filteredperception.org> <1190064930.21026.123.camel@localhost.localdomain> <46EF4683.3090902@filteredperception.org> <1190135788.15490.7.camel@localhost.localdomain> <46F01CC5.3010408@filteredperception.org> <46F03080.9050702@filteredperception.org> <1190147678.15490.17.camel@localhost.localdomain> Message-ID: <46F0399D.30805@filteredperception.org> 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 locked up at initramfs time. >>>> Not if new anaconda is used with old livecd-creator -- then loop118 >>>> wouldn't have been used and something else could use it while the live >>>> system is running. >>> This is true, albeit unlikely as well. But also fixable by addressing >>> the hardcoded loop device issue across the board. >>> >>>>> The reason why I think it should stay as is, instead of setting >>>>> everything up at initramfs time, is because the loop117 gets >>>>> associated with the decompressed-into-devshm contents of loop118. >>>>> The decompression being 7kb->1.2M in the typical case. >>>>> >>>>> I'd say that the 1.2M ram hit should only be taken during install, >>>>> and that outweighs the benefits of moving the complexity from >>>>> liveinst.sh to initramfs. >>>> But the time that the memory hit matters the _most_ is during the >>>> install as we have to have swap disabled during parts of it. >>> Obviously this is your call, and from my perspective not a big deal >>> either way. My own personal preference still remains freeing up the >>> 1.2M of ram during all times other than the install, at the expense of >>> the complexity being in anaconda/liveinst.sh, versus being in initramfs. >>> >>> Perhaps by F9 I'll find a mechanism to achieve this that you like... >> Or maybe in significantly less time than that... >> >> How's this- >> >> 1) In initramfs, instead of lazy unmounting the squashfs, bindmount it >> to /sysroot/mnt/.LiveOS/squashfs >> >> 2) store osmin 'uncompressed' on the squashfs >> >> 3) in initramfs, set up the osimg-min device, but now with the loop118 >> pointing at /sysroot/mnt/.LiveOS/squashfs/osmin >> >> The result- All the same low-impact that the current method has with >> anaconda, but the 1.2M of ram will only get used when anaconda actually >> starts touching /dev/mapper/live-osimg-min > > Okay, one better -- what if we just delay the lazy unmount of /squashfs > until after we've done the osimg-min setup. There's no reason it has to > be mounted under the sysroot, we just have to wait to unmount the > squashed copy. Yeah. The thought occurred to me because I was doing the movemounting myself for other reasons. You are right, movemounting has nothing to do with the issue. > > 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 ago. I mentioned something like "osmin can't live on the squashfs for obvious reasons". Actually, the truth is "osmin can't live on the ext3 for obvious reasons". And the subtle error there kept the idea out of my mind. In case it's not obvious- osmin must be created after os.img is final. But... It occurs to me that because of what anaconda is doing, I.e. a big 2G dd, it may actually be problematic that squashfs pages out(?) the osmin data, and needs to reread it from cdrom often, thus screwing up a nice big linear seek-free read. My first thought is to do a performance test, and see what happens and if it matters. For now, as is, is good enough. We'll see if it can be made better. -dmc From katzj at redhat.com Tue Sep 18 21:05:59 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 18 Sep 2007 17:05:59 -0400 Subject: [Fedora-livecd-list] [PATCH 6/7] anaconda: liveinst.sh: support turboLiveInst/genMinInstDelta In-Reply-To: <46F0399D.30805@filteredperception.org> References: <46EEBAC1.1050204@filteredperception.org> <1190064930.21026.123.camel@localhost.localdomain> <46EF4683.3090902@filteredperception.org> <1190135788.15490.7.camel@localhost.localdomain> <46F01CC5.3010408@filteredperception.org> <46F03080.9050702@filteredperception.org> <1190147678.15490.17.camel@localhost.localdomain> <46F0399D.30805@filteredperception.org> Message-ID: <1190149559.15490.22.camel@localhost.localdomain> 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 ago. I mentioned something like "osmin can't live on the squashfs > for obvious reasons". Actually, the truth is "osmin can't live on the > ext3 for obvious reasons". And the subtle error there kept the idea out > of my mind. The simple answer is just don't do the osmin bits if you're not using squashfs. Given that it's a debug option only, that's probably not crazy > But... > > It occurs to me that because of what anaconda is doing, I.e. a big 2G > dd, it may actually be problematic that squashfs pages out(?) the osmin > data, and needs to reread it from cdrom often, thus screwing up a nice > big linear seek-free read. Famous last words are "it shouldn't really make a difference" ;) Jeremy From dmc.fedora at filteredperception.org Wed Sep 19 00:12:21 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 18 Sep 2007 19:12:21 -0500 Subject: [Fedora-livecd-list] [PATCH 6/7] anaconda: liveinst.sh: support turboLiveInst/genMinInstDelta In-Reply-To: <1190149559.15490.22.camel@localhost.localdomain> References: <46EEBAC1.1050204@filteredperception.org> <1190064930.21026.123.camel@localhost.localdomain> <46EF4683.3090902@filteredperception.org> <1190135788.15490.7.camel@localhost.localdomain> <46F01CC5.3010408@filteredperception.org> <46F03080.9050702@filteredperception.org> <1190147678.15490.17.camel@localhost.localdomain> <46F0399D.30805@filteredperception.org> <1190149559.15490.22.camel@localhost.localdomain> Message-ID: <46F06965.4090600@filteredperception.org> 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 ago. I mentioned something like "osmin can't live on the squashfs >> for obvious reasons". Actually, the truth is "osmin can't live on the >> ext3 for obvious reasons". And the subtle error there kept the idea out >> of my mind. > > The simple answer is just don't do the osmin bits if you're not using > squashfs. Given that it's a debug option only, that's probably not > crazy Thats the answer to...? to not having the --ignore-deleted and --turbo-liveinst options? I agree. One big problem with skip-compression as is, is that when the ext3 image lives natively on the iso9660 1) iso9660 does not(?) support sparse files, so currently with your 4.0G ext3 image containing 2.2G of data, you have to store 4.0G data. 2) iso9660 sortof has 2G filesize limits (apparently 2G->4.2G might work, and 4.2G->8TB could theoretically work...) One possible solution for 1), might be to house the sparse file in a container filesystem (either squashfs, or a properly minimized ext2). One possible solution for 2) would be to split the container filesystem (1.75G chunks?), and then associate a loop device with each, and use a devicemapper linear device to stitch them all together into one big image. > >> But... >> >> It occurs to me that because of what anaconda is doing, I.e. a big 2G >> dd, it may actually be problematic that squashfs pages out(?) the osmin >> data, and needs to reread it from cdrom often, thus screwing up a nice >> big linear seek-free read. > > Famous last words are "it shouldn't really make a difference" ;) Ok, now I think I've _really_ got it figured out- 1) at livecd creator time, put the osmin in it's own squashfs. I just tried this, and it produces a 12kb squashfs image. 2) now, at initramfs time, copy the squashfs image to tmpfs, loop mount it, associate the loop118 device with the file inside that squashfs, and then build the devicemapper minimized device *NOW*, osmin once again only lives in tmpfs, *AND* ram is only used for its 1.2M of data during anaconda install time. -dmc From jvonau at shaw.ca Wed Sep 19 00:50:56 2007 From: jvonau at shaw.ca (Jerry Vonau) Date: Tue, 18 Sep 2007 19:50:56 -0500 Subject: [Fedora-livecd-list] [PATCH 6/7] anaconda: liveinst.sh: support turboLiveInst/genMinInstDelta In-Reply-To: <46F06965.4090600@filteredperception.org> References: <46EEBAC1.1050204@filteredperception.org> <1190064930.21026.123.camel@localhost.localdomain> <46EF4683.3090902@filteredperception.org> <1190135788.15490.7.camel@localhost.localdomain> <46F01CC5.3010408@filteredperception.org> <46F03080.9050702@filteredperception.org> <1190147678.15490.17.camel@localhost.localdomain> <46F0399D.30805@filteredperception.org> <1190149559.15490.22.camel@localhost.localdomain> <46F06965.4090600@filteredperception.org> Message-ID: <46F07270.40500@shaw.ca> Douglas McClendon wrote: > 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 ago. I mentioned something like "osmin can't live on the >>> squashfs for obvious reasons". Actually, the truth is "osmin can't >>> live on the ext3 for obvious reasons". And the subtle error there >>> kept the idea out of my mind. >> >> The simple answer is just don't do the osmin bits if you're not using >> squashfs. Given that it's a debug option only, that's probably not >> crazy > > Thats the answer to...? to not having the --ignore-deleted and > --turbo-liveinst options? I agree. > > One big problem with skip-compression as is, is that when the ext3 image > lives natively on the iso9660 > > 1) iso9660 does not(?) support sparse files, so currently with your 4.0G > ext3 image containing 2.2G of data, you have to store 4.0G data. > > 2) iso9660 sortof has 2G filesize limits (apparently 2G->4.2G might > work, and 4.2G->8TB could theoretically work...) > > One possible solution for 1), might be to house the sparse file in a > container filesystem (either squashfs, or a properly minimized ext2). > > One possible solution for 2) would be to split the container filesystem > (1.75G chunks?), and then associate a loop device with each, and use a > devicemapper linear device to stitch them all together into one big image. This sounds interesting, would is be possible to do something like have a "base" image and add let's say a snapshot between gnome or kde and "base" in a second image file? If that is possible, then using "base" in place of stage2.img looks promising for a combined live/install/rescue cdrom. Thoughts anyone? Jerry From dmc.fedora at filteredperception.org Wed Sep 19 01:40:50 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 18 Sep 2007 20:40:50 -0500 Subject: [Fedora-livecd-list] [PATCH 6/7] anaconda: liveinst.sh: support turboLiveInst/genMinInstDelta In-Reply-To: <46F07270.40500@shaw.ca> References: <46EEBAC1.1050204@filteredperception.org> <1190064930.21026.123.camel@localhost.localdomain> <46EF4683.3090902@filteredperception.org> <1190135788.15490.7.camel@localhost.localdomain> <46F01CC5.3010408@filteredperception.org> <46F03080.9050702@filteredperception.org> <1190147678.15490.17.camel@localhost.localdomain> <46F0399D.30805@filteredperception.org> <1190149559.15490.22.camel@localhost.localdomain> <46F06965.4090600@filteredperception.org> <46F07270.40500@shaw.ca> Message-ID: <46F07E22.6050602@filteredperception.org> Jerry Vonau wrote: > Douglas McClendon wrote: >> 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 ago. I mentioned something like "osmin can't live on the >>>> squashfs for obvious reasons". Actually, the truth is "osmin can't >>>> live on the ext3 for obvious reasons". And the subtle error there >>>> kept the idea out of my mind. >>> The simple answer is just don't do the osmin bits if you're not using >>> squashfs. Given that it's a debug option only, that's probably not >>> crazy >> Thats the answer to...? to not having the --ignore-deleted and >> --turbo-liveinst options? I agree. >> >> One big problem with skip-compression as is, is that when the ext3 image >> lives natively on the iso9660 >> >> 1) iso9660 does not(?) support sparse files, so currently with your 4.0G >> ext3 image containing 2.2G of data, you have to store 4.0G data. >> >> 2) iso9660 sortof has 2G filesize limits (apparently 2G->4.2G might >> work, and 4.2G->8TB could theoretically work...) >> >> One possible solution for 1), might be to house the sparse file in a >> container filesystem (either squashfs, or a properly minimized ext2). >> >> One possible solution for 2) would be to split the container filesystem >> (1.75G chunks?), and then associate a loop device with each, and use a >> devicemapper linear device to stitch them all together into one big image. > > This sounds interesting, would is be possible to do something like have > a "base" image and add let's say a snapshot between gnome or kde and > "base" in a second image file? If that is possible, then using "base" in > place of stage2.img looks promising for a combined live/install/rescue > cdrom. > > Thoughts anyone? I think you are thinking more here about devicemapper snapshot devices. I was talking about something that just split up one logical filesystem into parts that needed to all be put back together before having something useful. But yes, one could do something like like that with snapshot devices. But I think there is an easier way to get what you described. If you just took the existing livecd image, and copied the contents of the traditional installer DVD into it (either the whole iso, or just the /Fedora (or /Packages if its called that now) directory). Then you could have a boot argument, which would be used in place of the existing 'live' boot argument, say 'installer'. Then where the current 'live' argument is detected, it would detect 'installer', and run an environment like the stage2 that you are thinking of. But, I have pondered other similar uses of snapshots which are very much like what you suggested. One thing you could do, is have the base, and then a snapshot for the gnome livecd, a different snapshot for the kde livecd, another for FEL and development, etc... and then at the boot menu, let the user choose which spin to boot up, and at install time, let the user choose which spin to install. Of course this mostly makes sense for a LiveDVD where you have that kind of room to spare. But there may be better ways to get the same functionality without using dm-snapshots. $0.02... -dmc From katzj at redhat.com Wed Sep 19 01:53:47 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 18 Sep 2007 21:53:47 -0400 Subject: [Fedora-livecd-list] [PATCH 6/7] anaconda: liveinst.sh: support turboLiveInst/genMinInstDelta In-Reply-To: <46F06965.4090600@filteredperception.org> References: <46EEBAC1.1050204@filteredperception.org> <1190064930.21026.123.camel@localhost.localdomain> <46EF4683.3090902@filteredperception.org> <1190135788.15490.7.camel@localhost.localdomain> <46F01CC5.3010408@filteredperception.org> <46F03080.9050702@filteredperception.org> <1190147678.15490.17.camel@localhost.localdomain> <46F0399D.30805@filteredperception.org> <1190149559.15490.22.camel@localhost.localdomain> <46F06965.4090600@filteredperception.org> Message-ID: <1190166827.4372.1.camel@localhost.localdomain> On Tue, 2007-09-18 at 19:12 -0500, Douglas McClendon wrote: > 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 ago. I mentioned something like "osmin can't live on the squashfs > >> for obvious reasons". Actually, the truth is "osmin can't live on the > >> ext3 for obvious reasons". And the subtle error there kept the idea out > >> of my mind. > > > > The simple answer is just don't do the osmin bits if you're not using > > squashfs. Given that it's a debug option only, that's probably not > > crazy > > Thats the answer to...? to not having the --ignore-deleted and > --turbo-liveinst options? I agree. To where to put the osmin image in the case of not having a squashfs. > One big problem with skip-compression as is, is that when the ext3 image > lives natively on the iso9660 Yeah, I don't see --skip-compression as something that's ever that interesting for "real" uses. > >> But... > >> > >> It occurs to me that because of what anaconda is doing, I.e. a big 2G > >> dd, it may actually be problematic that squashfs pages out(?) the osmin > >> data, and needs to reread it from cdrom often, thus screwing up a nice > >> big linear seek-free read. > > > > Famous last words are "it shouldn't really make a difference" ;) > > Ok, now I think I've _really_ got it figured out- > > 1) at livecd creator time, put the osmin in it's own squashfs. I just > tried this, and it produces a 12kb squashfs image. > > 2) now, at initramfs time, copy the squashfs image to tmpfs, loop mount > it, associate the loop118 device with the file inside that squashfs, and > then build the devicemapper minimized device > > *NOW*, osmin once again only lives in tmpfs, *AND* ram is only used for > its 1.2M of data during anaconda install time. Could work too -- I'm not sure it's better or worse than just sticking it in the squashfs, though. Jeremy From dmc.fedora at filteredperception.org Wed Sep 19 07:08:54 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 19 Sep 2007 02:08:54 -0500 Subject: [Fedora-livecd-list] [PATCH] mayflower: use dynamically allocated loop devices Message-ID: <46F0CB06.3060603@filteredperception.org> 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,120&121. udev rules were updated, and two new ones added, so that /dev/live-osmin, /dev/live-squashed, /dev/live-osimg, and /dev/live-overlay links will be created by udev. Also, the unnecessary mknod calls referencing those devices were removed. I tested with a minimal spin under qemu, and everything appeared as it should. I could mount /dev/mapper/live-osimg-min and it looked fine. I did another minimal spin with --skip-compression. For some reason I had to hit ctrl-c at to get past udev starting. I'm pretty sure I've seen this before and it has nothing to do with this patch. After doing that, and logging in, I verified that it correctly handled the absence of a squashfs loop device. Comments? -dmc -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.dynamic_loop_devices.patch Type: text/x-patch Size: 4359 bytes Desc: not available URL: From katzj at redhat.com Wed Sep 19 13:54:22 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 19 Sep 2007 09:54:22 -0400 Subject: [Fedora-livecd-list] [PATCH] mayflower: use dynamically allocated loop devices In-Reply-To: <46F0CB06.3060603@filteredperception.org> References: <46F0CB06.3060603@filteredperception.org> Message-ID: <1190210062.4456.2.camel@localhost.localdomain> On Wed, 2007-09-19 at 02:08 -0500, Douglas McClendon wrote: > 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,120&121. Looks good; I'll give it a quick try after the meeting I'm about to run to and then commit it. Thanks for cleaning this up! Jeremy From dmc.fedora at filteredperception.org Thu Sep 20 05:56:19 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 20 Sep 2007 00:56:19 -0500 Subject: [Fedora-livecd-list] RFC- proposal for livecd filesystem layout changes Message-ID: <46F20B83.6080403@filteredperception.org> This is a (set of) proposal(s) that I don't feel too strongly about, but if people agree, I wouldn't mind implementing. First, I'd like to put together and submit a patch, that moves the placement of /squashfs.img in the livecd iso to /LiveOS/squashfs.img This would have the benefit of cleaning up some code that differentiates between that placement on live-usb, and the current /squashfs.img on current live-isos. Another benefit is making the iso directory structure look nicer and more intuitively understandable for someone looking at it under windows. 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. Also, livecd-iso-to-disk would look a bit uglier, if it needed to maintain the ability to support livecds made with the current scheme. Along the same lines, I also suggest moving /isolinux(livecd) and /syslinux(liveusb) to /boot/isolinux and /boot/syslinux. This also would make the usb/iso directory structure look cleaner and more intuitively understandable to less linux-guru users when they look at the directory structure under windows (or anywhere) And because it is somewhat on-topic, I would also suggest changing the current squashfs.img:/os.img to be squashfs.img:/ext3fs.img, as that would be consistent with what it is named in the --skip-compression case. Also, I would modify the above to be ext3.img instead of ext3fs.img, such that the naming convention is consistent with squashfs.img (i.e. name of filesystem as passed to mount -t). Finally, I would suggest changing squashfs.img:/ext3.img to squashfs.img:/LiveOS/ext3.img, such that the general idea is that a container filesystem such as squashfs presents the result in the same place you would look for it without the extra container filesystem. $0.02... -dmc From dmc.fedora at filteredperception.org Thu Sep 20 06:25:43 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 20 Sep 2007 01:25:43 -0500 Subject: [Fedora-livecd-list] RFC- proposal for livecd filesystem layout changes In-Reply-To: <46F20B83.6080403@filteredperception.org> References: <46F20B83.6080403@filteredperception.org> Message-ID: <46F21267.1090101@filteredperception.org> 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-tools mitigates this. Also, one more addition to the scheme, would be prepending the fslabel to the fstype.img syntax, e.g. for f7 it would become iso9660:/LiveOS/Fedora-7-Live-i386.squashfs.img This would potentially facilitate a nice directory structure for LiveDVDs and LiveUSBs that could boot more than one LiveOS image. I don't think there are any issues with that syntax regarding vfat/iso9660/syslinux filename limitations (?) -dmc From asmith11 at cox.net Thu Sep 20 13:33:53 2007 From: asmith11 at cox.net (asmith11 at cox.net) Date: Thu, 20 Sep 2007 9:33:53 -0400 Subject: [Fedora-livecd-list] LiveCD Issues Message-ID: <22912788.1190295238096.JavaMail.root@eastrmwml14.mgt.cox.net> Hello, I've been using the LiveCD tools for some time with a good deal of success. Kudos to all of the developers that have put together these tools. I have run into a few problems recently and was hoping for some guidance. If anyone can help with these it is much appreciated. 1) Installing to Live Image vs. Installing to System Is there a good way (or best practice) in my kickstart %post section to determine whether I am installing to a live image vs. installing to a system (or said differently whether the installation is happening via the GUI installer vs. the livecd-creator? We have certain operations we'd like to perform (format some large partitions, etc.) that don't really make sense for the live image but we would like installed on the real target system as part of a "real" installation. 2) Redhat Enterprise 5 Problem We've been able to successfully bundle RHEL5 as a live image. Things are generally working pretty well. We have been using LiveCD Tools 008 and 009 up till now. When we tried to upgrade to LiveCD tools 011 the images we created would no longer boot (in QEMU or via CD/DVD if burned to a disk). The error we see at boot is the one where it says that "/dev/root" is missing and that we should create the link and then exit the shell. This has normally been working fine. Is this a problem with a missing kernel module? Any ideas on how to fix this? Thanks, -Andy From asmith11 at cox.net Thu Sep 20 13:34:47 2007 From: asmith11 at cox.net (asmith11 at cox.net) Date: Thu, 20 Sep 2007 9:34:47 -0400 Subject: [Fedora-livecd-list] LiveCD Issues Message-ID: <23911628.1190295296083.JavaMail.root@eastrmwml14.mgt.cox.net> Hello, I've been using the LiveCD tools for some time with a good deal of success. Kudos to all of the developers that have put together these tools. I have run into a few problems recently and was hoping for some guidance. If anyone can help with these it is much appreciated. 1) Installing to Live Image vs. Installing to System Is there a good way (or best practice) in my kickstart %post section to determine whether I am installing to a live image vs. installing to a system (or said differently whether the installation is happening via the GUI installer vs. the livecd-creator? We have certain operations we'd like to perform (format some large partitions, etc.) that don't really make sense for the live image but we would like installed on the real target system as part of a "real" installation. 2) Redhat Enterprise 5 Problem We've been able to successfully bundle RHEL5 as a live image. Things are generally working pretty well. We have been using LiveCD Tools 008 and 009 up till now. When we tried to upgrade to LiveCD tools 011 the images we created would no longer boot (in QEMU or via CD/DVD if burned to a disk). The error we see at boot is the one where it says that "/dev/root" is missing and that we should create the link and then exit the shell. This has normally been working fine. Is this a problem with a missing kernel module? Any ideas on how to fix this? Thanks, -Andy From katzj at redhat.com Thu Sep 20 14:48:44 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 20 Sep 2007 10:48:44 -0400 Subject: [Fedora-livecd-list] RFC- proposal for livecd filesystem layout changes In-Reply-To: <46F20B83.6080403@filteredperception.org> References: <46F20B83.6080403@filteredperception.org> Message-ID: <1190299724.4850.4.camel@localhost.localdomain> On Thu, 2007-09-20 at 00:56 -0500, Douglas McClendon wrote: > This is a (set of) proposal(s) that I don't feel too strongly about, but > if people agree, I wouldn't mind implementing. Honestly, I don't feel strongly one way or the other about any of this[1]. So I'll largely defer to whatever other people think Jeremy [1] With the exception that livecd-iso-to-stick really should keep working with both F7 and F8 live images regardless of any changes From katzj at redhat.com Thu Sep 20 14:54:15 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 20 Sep 2007 10:54:15 -0400 Subject: [Fedora-livecd-list] RFC- proposal for livecd filesystem layout changes In-Reply-To: <46F21267.1090101@filteredperception.org> References: <46F20B83.6080403@filteredperception.org> <46F21267.1090101@filteredperception.org> Message-ID: <1190300055.4850.8.camel@localhost.localdomain> 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-tools mitigates this. Yeah, I suspect we would need to do this. Which gets a little tricky with some of the config changes unless I can twist clumens's arm into putting out a pykickstart update as well :-/ > Also, one more addition to the scheme, would be prepending the fslabel > to the fstype.img syntax, e.g. for f7 it would become > > iso9660:/LiveOS/Fedora-7-Live-i386.squashfs.img > > This would potentially facilitate a nice directory structure for > LiveDVDs and LiveUSBs that could boot more than one LiveOS image. > > I don't think there are any issues with that syntax regarding > vfat/iso9660/syslinux filename limitations (?) Any files that we access from the boot loader have to stick to 8.3. Beyond that, shouldn't be a problem. It looks like Joliet restricts us to 64 characters, but as the label is limited to 32, we won't get to 64. Jeremy From katzj at redhat.com Thu Sep 20 15:02:07 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 20 Sep 2007 11:02:07 -0400 Subject: [Fedora-livecd-list] LiveCD Issues In-Reply-To: <23911628.1190295296083.JavaMail.root@eastrmwml14.mgt.cox.net> References: <23911628.1190295296083.JavaMail.root@eastrmwml14.mgt.cox.net> Message-ID: <1190300527.4850.16.camel@localhost.localdomain> On Thu, 2007-09-20 at 09:34 -0400, asmith11 at cox.net wrote: > 1) Installing to Live Image vs. Installing to System > > Is there a good way (or best practice) in my kickstart %post section > to determine whether I am installing to a live image vs. installing to > a system (or said differently whether the installation is happening > via the GUI installer vs. the livecd-creator? We have certain > operations we'd like to perform (format some large partitions, etc.) > that don't really make sense for the live image but we would like > installed on the real target system as part of a "real" > installation. Hrmm -- there's nothing at the moment. But I can definitely see it making some sense. And being able to differentiate for pungi as well. It would be easy enough to set an environment variable if that would help. I guess you could also key off of the existence of /root/anaconda-ks.cfg for it being an anaconda install, but that's definitely into heuristics territory > 2) Redhat Enterprise 5 Problem > > We've been able to successfully bundle RHEL5 as a live image. Things > are generally working pretty well. We have been using LiveCD Tools > 008 and 009 up till now. When we tried to upgrade to LiveCD tools 011 > the images we created would no longer boot (in QEMU or via CD/DVD if > burned to a disk). The error we see at boot is the one where it says > that "/dev/root" is missing and that we should create the link and > then exit the shell. This has normally been working fine. Is this a > problem with a missing kernel module? Any ideas on how to fix this? Yeah, if you look in livecd-creator, you'll see that we now write out things like "=ata" as the modules to use. Which won't work for RHEL5 as it doesn't have the file to do that mapping. At the same time, I really don't want to have to keep around the list of all of the pata/sata modules and have to keep updating it as the list changes over time :-/. Open to suggestions, though. Jeremy From asmith11 at cox.net Thu Sep 20 15:46:55 2007 From: asmith11 at cox.net (asmith11 at cox.net) Date: Thu, 20 Sep 2007 11:46:55 -0400 Subject: [Fedora-livecd-list] LiveCD Issues Message-ID: <25121790.1190303215473.JavaMail.root@eastrmwml14.mgt.cox.net> Jeremy, Thanks for the feedback. Couple of quick follow-up comments below... ---- Jeremy Katz wrote: > On Thu, 2007-09-20 at 09:34 -0400, asmith11 at cox.net wrote: > > 1) Installing to Live Image vs. Installing to System > > > > Is there a good way (or best practice) in my kickstart %post section > > to determine whether I am installing to a live image vs. installing to > > a system (or said differently whether the installation is happening > > via the GUI installer vs. the livecd-creator? We have certain > > operations we'd like to perform (format some large partitions, etc.) > > that don't really make sense for the live image but we would like > > installed on the real target system as part of a "real" > > installation. > > Hrmm -- there's nothing at the moment. But I can definitely see it > making some sense. And being able to differentiate for pungi as well. > It would be easy enough to set an environment variable if that would > help. I guess you could also key off of the existence > of /root/anaconda-ks.cfg for it being an anaconda install, but that's > definitely into heuristics territory This was basically the direction we were thinking we would end up heading. We're biased towards what we are calling the "real" installation because the live image is primarily a pretty installation vehicle for us. > > > 2) Redhat Enterprise 5 Problem > > > > We've been able to successfully bundle RHEL5 as a live image. Things > > are generally working pretty well. We have been using LiveCD Tools > > 008 and 009 up till now. When we tried to upgrade to LiveCD tools 011 > > the images we created would no longer boot (in QEMU or via CD/DVD if > > burned to a disk). The error we see at boot is the one where it says > > that "/dev/root" is missing and that we should create the link and > > then exit the shell. This has normally been working fine. Is this a > > problem with a missing kernel module? Any ideas on how to fix this? > > Yeah, if you look in livecd-creator, you'll see that we now write out > things like "=ata" as the modules to use. Which won't work for RHEL5 as > it doesn't have the file to do that mapping. At the same time, I really > don't want to have to keep around the list of all of the pata/sata > modules and have to keep updating it as the list changes over time :-/. > Open to suggestions, though. I took a look at the livecd-creator script modules section that you mentioned and I understand now why this is no longer working for RHEL5. I think we can just modify that section of livecd-creator to add the specific modules we'll need. It raises the question though, how should a livecd-creator user customize the set of modules that they need installed (in a case like this one). Obvious options would be: 1) livecd-creator command-line parameters (requires livecd-creator changes) 2) modify livecd-creator to taste on a case-by-case basis (yuck) 3) kickstart syntax (I don't know if this is really a valid option) Any thoughts? Thanks, -Andy > > Jeremy > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From katzj at redhat.com Thu Sep 20 19:41:33 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 20 Sep 2007 15:41:33 -0400 Subject: [Fedora-livecd-list] LiveCD Issues In-Reply-To: <25121790.1190303215473.JavaMail.root@eastrmwml14.mgt.cox.net> References: <25121790.1190303215473.JavaMail.root@eastrmwml14.mgt.cox.net> Message-ID: <1190317293.4850.30.camel@localhost.localdomain> On Thu, 2007-09-20 at 11:46 -0400, asmith11 at cox.net wrote: > ---- Jeremy Katz wrote: > > On Thu, 2007-09-20 at 09:34 -0400, asmith11 at cox.net wrote: > > > We've been able to successfully bundle RHEL5 as a live image. Things > > > are generally working pretty well. We have been using LiveCD Tools > > > 008 and 009 up till now. When we tried to upgrade to LiveCD tools 011 > > > the images we created would no longer boot (in QEMU or via CD/DVD if > > > burned to a disk). The error we see at boot is the one where it says > > > that "/dev/root" is missing and that we should create the link and > > > then exit the shell. This has normally been working fine. Is this a > > > problem with a missing kernel module? Any ideas on how to fix this? > > > > Yeah, if you look in livecd-creator, you'll see that we now write out > > things like "=ata" as the modules to use. Which won't work for RHEL5 as > > it doesn't have the file to do that mapping. At the same time, I really > > don't want to have to keep around the list of all of the pata/sata > > modules and have to keep updating it as the list changes over time :-/. > > Open to suggestions, though. > > I took a look at the livecd-creator script modules section that you > mentioned and I understand now why this is no longer working for > RHEL5. I think we can just modify that section of livecd-creator to > add the specific modules we'll need. Yeah, that definitely works as a short-term. > It raises the question though, how should a livecd-creator user > customize the set of modules that they need installed (in a case like > this one). Obvious options would be: Well, overall, that's one reason why things changed was so that we could have the information encoded more in the packages being installed rather than squirreled away in livecd-creator. > 1) livecd-creator command-line parameters (requires livecd-creator > changes) This is pretty bad from my point of view as it leads to a live CD which you need to know the magic command line option used if you want to recreate it. > 2) modify livecd-creator to taste on a case-by-case basis (yuck) It definitely works, but yeah, definitely yuck too :) > 3) kickstart syntax (I don't know if this is really a valid option) Could be doable, although feels like it's kind of unfortunate to have to do as we should in most cases "just do teh right thing". Then again, there is the device keyword and we could just overload the use of it. That's probably not that far from the intent with a real install, either, where device leads to modules being loaded. The fourth option is that you have a package to drop a file (either /etc/mayflower.conf or another file which is sourced by mayflower) to add modules. In fact, in any case, this is simple enough that I'll make it work even if it's not the "best" answer. Jeremy From dmc.fedora at filteredperception.org Thu Sep 20 20:07:13 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 20 Sep 2007 15:07:13 -0500 Subject: [Fedora-livecd-list] RFC- proposal for livecd filesystem layout changes In-Reply-To: <1190300055.4850.8.camel@localhost.localdomain> References: <46F20B83.6080403@filteredperception.org> <46F21267.1090101@filteredperception.org> <1190300055.4850.8.camel@localhost.localdomain> Message-ID: <46F2D2F1.9020707@filteredperception.org> 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-tools mitigates this. > > Yeah, I suspect we would need to do this. Which gets a little tricky > with some of the config changes unless I can twist clumens's arm into > putting out a pykickstart update as well :-/ 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? And install it by default, perhaps even in the minimal base spin config? -dmc From sundaram at fedoraproject.org Thu Sep 20 20:13:03 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 21 Sep 2007 01:43:03 +0530 Subject: [Fedora-livecd-list] RFC- proposal for livecd filesystem layout changes In-Reply-To: <46F2D2F1.9020707@filteredperception.org> References: <46F20B83.6080403@filteredperception.org> <46F21267.1090101@filteredperception.org> <1190300055.4850.8.camel@localhost.localdomain> <46F2D2F1.9020707@filteredperception.org> Message-ID: <46F2D44F.1020003@fedoraproject.org> Douglas McClendon wrote: > 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-tools mitigates this. >> >> Yeah, I suspect we would need to do this. Which gets a little tricky >> with some of the config changes unless I can twist clumens's arm into >> putting out a pykickstart update as well :-/ > > 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? > > And install it by default, perhaps even in the minimal base spin config? This sounds like a good idea especially if we provide a menu option to make this feature more visible to users and reviewers who don't read the release notes which is unfortunately quite a lot. Rahul From dmc.fedora at filteredperception.org Thu Sep 20 23:43:47 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 20 Sep 2007 18:43:47 -0500 Subject: [Fedora-livecd-list] RFC- proposal for livecd filesystem layout changes In-Reply-To: <46F2D44F.1020003@fedoraproject.org> References: <46F20B83.6080403@filteredperception.org> <46F21267.1090101@filteredperception.org> <1190300055.4850.8.camel@localhost.localdomain> <46F2D2F1.9020707@filteredperception.org> <46F2D44F.1020003@fedoraproject.org> Message-ID: <46F305B3.1060303@filteredperception.org> 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? >> >> And install it by default, perhaps even in the minimal base spin config? > > This sounds like a good idea especially if we provide a menu option to > make this feature more visible to users and reviewers who don't read the > release notes which is unfortunately quite a lot. I could throw together a ghetto zenity gui pretty quickly. The only user interaction is a) selecting iso - for the gui, this could be handled by zenity file-selection, or the default would be to use /dev/live if it exists (i.e. /dev/live is the accessible block device representing the currently booted livecd). b) bypassing checkisomd5 if it fails - this is easily enough a zenity question, or perhaps just make it a pure failure case for the gui c) livecd-iso-to-disk result text output, either success, or failure for some reason. Easy enough to dump to a zenity dialog. I'm curious, what kind of deadlines should I be thinking about for this and other livecd related things. I.e. the f8 devel freeze is Oct 4th, as of f8t3 release. But then there is an f8t3 devel freeze as of Sept 25th (along with translation freeze). What sort of development is considered acceptable between those two dates? Obviously I would like to get anything in by say... tonight, so that Jeremy has time to decide to accept it and commit it before tuesday, and then not try to get anything in after that. And would this theoretical gui livecd-iso-to-disk separate package fall outside the scope of even the oct-4th devel freeze, because it is a 'new' package? -dmc From dmc.fedora at filteredperception.org Thu Sep 20 23:45:30 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 20 Sep 2007 18:45:30 -0500 Subject: [Fedora-livecd-list] RFC- proposal for livecd filesystem layout changes In-Reply-To: <46F305B3.1060303@filteredperception.org> References: <46F20B83.6080403@filteredperception.org> <46F21267.1090101@filteredperception.org> <1190300055.4850.8.camel@localhost.localdomain> <46F2D2F1.9020707@filteredperception.org> <46F2D44F.1020003@fedoraproject.org> <46F305B3.1060303@filteredperception.org> Message-ID: <46F3061A.5090400@filteredperception.org> 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-blown livecd-creation? >>> >>> And install it by default, perhaps even in the minimal base spin config? >> >> This sounds like a good idea especially if we provide a menu option to >> make this feature more visible to users and reviewers who don't read >> the release notes which is unfortunately quite a lot. > > I could throw together a ghetto zenity gui pretty quickly. The only > user interaction is > > a) selecting iso > - for the gui, this could be handled by zenity file-selection, or the > default would be to use /dev/live if it exists (i.e. /dev/live is the > accessible block device representing the currently booted livecd). and d) for DUH... selecting the partition/device, which could be a selection amongst /dev/disk/by-id/ > b) bypassing checkisomd5 if it fails > - this is easily enough a zenity question, or perhaps just make it a > pure failure case for the gui > > c) livecd-iso-to-disk result text output, either success, or failure for > some reason. Easy enough to dump to a zenity dialog. > > I'm curious, what kind of deadlines should I be thinking about for this > and other livecd related things. > > I.e. the f8 devel freeze is Oct 4th, as of f8t3 release. But then there > is an f8t3 devel freeze as of Sept 25th (along with translation freeze). > > What sort of development is considered acceptable between those two dates? > > Obviously I would like to get anything in by say... tonight, so that > Jeremy has time to decide to accept it and commit it before tuesday, > and then not try to get anything in after that. > > And would this theoretical gui livecd-iso-to-disk separate package fall > outside the scope of even the oct-4th devel freeze, because it is a > 'new' package? > > -dmc > From tim.wood at datawranglers.com Fri Sep 21 00:10:10 2007 From: tim.wood at datawranglers.com (Tim Wood) Date: Thu, 20 Sep 2007 18:10:10 -0600 Subject: [Fedora-livecd-list] RFC- proposal for livecd filesystem layout changes In-Reply-To: <46F305B3.1060303@filteredperception.org> References: <46F20B83.6080403@filteredperception.org> <46F21267.1090101@filteredperception.org> <1190300055.4850.8.camel@localhost.localdomain> <46F2D2F1.9020707@filteredperception.org> <46F2D44F.1020003@fedoraproject.org> <46F305B3.1060303@filteredperception.org> Message-ID: <37F8659D-92A4-43E8-A032-83B23709A8A4@datawranglers.com> I just wrote a basic select a scsi or ata device bash script in zenity. I added /dev/live. Nothing fancy but it should save you a few minutes. Tim Wood ________________________________________ TITLE="Set Backup Drive" MESSAGE="Select a drive to use for backups" FLAGS="--list --radiolist --column Pick --column Device" devices=`cd /dev/;ls hd*;ls sd*; ls live` CHOICES="" PICK="True" for device in $devices; do CHOICES="$CHOICES $PICK $device" PICK="False" done COMMAND="zenity --title \"$TITLE\" --text \"$MESSAGE\" $FLAGS $CHOICES" echo $COMMAND DEVICE=$(zenity --title "$TITLE" --text "$MESSAGE" $FLAGS $CHOICES) ________________________________________ On Sep 20, 2007, at 5:43 PM, Douglas McClendon wrote: > I could throw together a ghetto zenity gui pretty quickly. The > only user interaction is > > a) selecting iso > - for the gui, this could be handled by zenity file-selection, or > the default would be to use /dev/live if it exists (i.e. /dev/live > is the accessible block device representing the currently booted > livecd). > > b) bypassing checkisomd5 if it fails > - this is easily enough a zenity question, or perhaps just make > it a pure failure case for the gui > > c) livecd-iso-to-disk result text output, either success, or > failure for some reason. Easy enough to dump to a zenity dialog. > > I'm curious, what kind of deadlines should I be thinking about for > this and other livecd related things. > > I.e. the f8 devel freeze is Oct 4th, as of f8t3 release. But then > there is an f8t3 devel freeze as of Sept 25th (along with > translation freeze). > > What sort of development is considered acceptable between those two > dates? > > Obviously I would like to get anything in by say... tonight, so > that Jeremy has time to decide to accept it and commit it before > tuesday, and then not try to get anything in after that. > > And would this theoretical gui livecd-iso-to-disk separate package > fall outside the scope of even the oct-4th devel freeze, because it > is a 'new' package? > > -dmc From katzj at redhat.com Fri Sep 21 01:06:29 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 20 Sep 2007 21:06:29 -0400 Subject: [Fedora-livecd-list] RFC- proposal for livecd filesystem layout changes In-Reply-To: <46F305B3.1060303@filteredperception.org> References: <46F20B83.6080403@filteredperception.org> <46F21267.1090101@filteredperception.org> <1190300055.4850.8.camel@localhost.localdomain> <46F2D2F1.9020707@filteredperception.org> <46F2D44F.1020003@fedoraproject.org> <46F305B3.1060303@filteredperception.org> Message-ID: <1190336789.4318.9.camel@localhost.localdomain> On Thu, 2007-09-20 at 18:43 -0500, 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-blown livecd-creation? > >> > >> And install it by default, perhaps even in the minimal base spin config? > > > > This sounds like a good idea especially if we provide a menu option to > > make this feature more visible to users and reviewers who don't read the > > release notes which is unfortunately quite a lot. > > I could throw together a ghetto zenity gui pretty quickly. The only > user interaction is [snip] > I'm curious, what kind of deadlines should I be thinking about for this > and other livecd related things. Technically speaking, features should mostly be done prior to the feature freeze (test2). How much of a feature this is could be arguable, though. > I.e. the f8 devel freeze is Oct 4th, as of f8t3 release. But then there > is an f8t3 devel freeze as of Sept 25th (along with translation freeze). > > What sort of development is considered acceptable between those two dates? Bugfixes only. The big difference is the severity of bugs fixed changes as of Oct 4th. > Obviously I would like to get anything in by say... tonight, so that > Jeremy has time to decide to accept it and commit it before tuesday, > and then not try to get anything in after that. > > And would this theoretical gui livecd-iso-to-disk separate package fall > outside the scope of even the oct-4th devel freeze, because it is a > 'new' package? If we don't install it by default, then it would be reasonable to put in. So given that livecd-tools isn't installed by default anywhere, in that respect, we could just put it in. But Rahul I think wants it installed by default. That said, in any case, I'm willing to put it on a branch for now Jeremy From dmc.fedora at filteredperception.org Fri Sep 21 10:19:36 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 21 Sep 2007 05:19:36 -0500 Subject: [Fedora-livecd-list] [PATCH 1/7] livecd filesystem layout cleanups -- remove /sysroot Message-ID: <46F39AB8.2040708@filteredperception.org> 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 of patches together, to at least scare people into voicing approval or opposition. I would be perfectly content to file these away, and possibly revisit them for F9. But, if people want them, I certainly wouldn't mind seeing them applied sooner. These have been tested on minimal spins under qemu. VERY IMPORTANTLY: much of the code changes have to do with legacy support in livecd-iso-to-disk and livecd-creator --base-on-iso, but I have not tested these AT ALL. If people voice no opposition, and some approval, then I will go to the trouble of testing those things. And in that case, this submission is also an avenue for feedback. Note, the --base-on-iso legacy support may be pointless, as if these were adopted for F8, then there is no reason to allow an f8 version of livecd-creator to run --base-on-iso against an F7 livecd. Now on to the patches. I'll elaborate in individual emails. This first patch, should probably be applied regardless of the rest. It simply removes the apparently pointless /sysroot directory from the iso9660 filesystem. Please let me know if I'm wrong and this is somehow needed by something. 6 more after this one... -dmc -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.1.remove_sysroot_from_iso.patch Type: text/x-patch Size: 1254 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Fri Sep 21 10:21:58 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 21 Sep 2007 05:21:58 -0500 Subject: [Fedora-livecd-list] [PATCH 2/7] move livecd fs image under /LiveOS, like liveusb already is Message-ID: <46F39B46.3020509@filteredperception.org> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.2.squashfs.img_to_LiveOS.patch Type: text/x-patch Size: 6327 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Fri Sep 21 10:25:30 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 21 Sep 2007 05:25:30 -0500 Subject: [Fedora-livecd-list] [PATCH 3/7] move embedded fs image under /LiveOS for consistency Message-ID: <46F39C1A.9050803@filteredperception.org> This patch moves the /os.img that is embedded in a squashfs to /LiveOS/os.img, to be consistent with non-embedded location. I find this aesthetically pleasing, and suspect that it may facilitate more elegant code in the future. And I see no downside. -dmc -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.3.squashed_image_to_LiveOS.patch Type: text/x-patch Size: 4921 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Fri Sep 21 10:29:30 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 21 Sep 2007 05:29:30 -0500 Subject: [Fedora-livecd-list] [PATCH 5/7] rename os.img to ext3fs.img for consistency Message-ID: <46F39D0A.9000803@filteredperception.org> This patch renames os.img in the embedded squashfs.img to ext3fs.img, to be consistent with the name choice of ext3fs.img in the --skip-compression case. -dmc -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.5.os_to_ext3fs.patch Type: text/x-patch Size: 4231 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Fri Sep 21 10:27:59 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 21 Sep 2007 05:27:59 -0500 Subject: [Fedora-livecd-list] [PATCH 4/7] move syslinux and isolinux directories under /boot Message-ID: <46F39CAF.1020209@filteredperception.org> 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 also move the /ppc dir to /boot/ppc on the ppc side. But I would recommend that as well if possible. -dmc -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.4.syslinux_to_boot.patch Type: text/x-patch Size: 5302 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Fri Sep 21 10:32:14 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 21 Sep 2007 05:32:14 -0500 Subject: [Fedora-livecd-list] [PATCH 6/7] rename ext3fs.img to ext3.img for consistency Message-ID: <46F39DAE.4000000@filteredperception.org> This patch renames the ext3fs.img file to ext3.img, to conform to a syntax of .img, along with the existing squashfs.img. This may be useful for future code simplification. I like it. -dmc -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.6.ext3fs_to_ext3.patch Type: text/x-patch Size: 6283 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Fri Sep 21 10:44:36 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 21 Sep 2007 05:44:36 -0500 Subject: [Fedora-livecd-list] [PATCH 7/7] prepend iso fslabel to fstype.img syntax Message-ID: <46F3A094.6080009@filteredperception.org> 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 being passed on the kernel-commandline, a uuid is passed instead. Thus as far as I could see (and maybe I'm just tired), at that point the cdlabel is lost to the liveusb. What I did was have livecd-creator write out the fslabel to /etc/LiveOS-release. And then I had mayflower read this when generating the initramfs init, so that it would know where to look for the file. I think /etc/LiveOS-release would also solve a problem recently brought up by Andy (asmith11), as to how to determine in the %post of whether or not you are in a livecd environment or not. Anyway, there may be better methods that just didn't occur to me, but this doesn't seem so bad to me. food for thought, like the rest of these patches... So, with all of these, the final cdrom filesystem layout, for the F7 livecd, would have looked like... /boot/isolinux/(stuff that used to be in /isolinux) /LiveOS/Fedora-7-Live-i386.squashfs.img /LiveOS/Fedora-7-Live-i386.osmin.img (note, no /sysroot) and inside the squashfs.img, is only /LiveOS/Fedora-7-Live-i386.ext3.img Maybe there should be another patch to rename the .osmin.img to .mininst.img or something... Again, I am not at all opposed to just shelving these for a few months, and seeing if people are more interested in them for F9. But I like them... -dmc -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.7.prepend_fslabel_to_osimage.patch Type: text/x-patch Size: 12144 bytes Desc: not available URL: From walters at redhat.com Fri Sep 21 15:12:33 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 21 Sep 2007 11:12:33 -0400 Subject: [Fedora-livecd-list] RFC- proposal for livecd filesystem layout changes In-Reply-To: <46F20B83.6080403@filteredperception.org> References: <46F20B83.6080403@filteredperception.org> Message-ID: On 9/20/07, Douglas McClendon 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 and more > intuitively understandable to less linux-guru users when they look at > the directory structure under windows (or anywhere) I'm not qualified to comment on whether filesystem path cleanups are useful for other reasons, but I think the Windows thing is not an interesting benefit. We don't (or shouldn't) require non-developers to interact with the directory structure, and developers will have to understand things anyways. From dmc.fedora at filteredperception.org Fri Sep 21 19:08:11 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 21 Sep 2007 14:08:11 -0500 Subject: [Fedora-livecd-list] RFC- proposal for livecd filesystem layout changes In-Reply-To: References: <46F20B83.6080403@filteredperception.org> Message-ID: <46F4169B.7040302@filteredperception.org> Colin Walters wrote: > On 9/20/07, Douglas McClendon 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 and more >> intuitively understandable to less linux-guru users when they look at >> the directory structure under windows (or anywhere) > > I'm not qualified to comment on whether filesystem path cleanups are > useful for other reasons, but I think the Windows thing is not an > interesting benefit. We don't (or shouldn't) require non-developers > to interact with the directory structure, and developers will have to > understand things anyways. This didn't have anything to do with _requiring_ non-developers to interact with the directory structure. It merely addresses the fact that they _might_ look at the directory structure by popping the livecd into the cdrom under windows. In that scenario, I advocate the following- 1) It should look aesthetically pleasing and intuitively understandable, and not like a bunch of technical gobbledygook. Naturally this should only be done if it is easy to do and has no downsides. I think the patches I submitted (after polishing and testing) fall into that category. 2) It should have a windows autorun that launches a copy of the release notes, or some other dedicated "how to use and what to expect from this fedora livecd". These release notes should live on the iso, such that they are accessible to the autorun, and also accessible to the user in an intuitive and non-threatening fashion. 3) If possible the livecd directory structure should have other beneficial things visible to a user looking at it under windows. I admit, we probably don't have the space on the livecd to match the ubuntu choice of offering the win32 installers for firefox, thunderbird and others. But if fedora starts shipping a LiveDVD, I think we should ship those, along with cygwin, qemu, and perhaps everything that is on opencd- http://www.theopencd.org/ Again, I don't mind shelving these opinions and revisiting them for F9, or F10, etc... But I absolutely _do_ think the directory structure matters and _will_ be viewed by non-developer users, whether this is intentional, needed, desirable, or not. And given that, I think it should look as non-threatening and intuitively understandable as reasonably possible. $0.02... -dmc From jsteer at bitscout.com Sat Sep 22 04:46:55 2007 From: jsteer at bitscout.com (Jon Steer) Date: Sat, 22 Sep 2007 00:46:55 -0400 Subject: [Fedora-livecd-list] Where to turn off filesystem writing spew.. Message-ID: <74e6f65d0709212146m6d4af114k738442f360b5415b@mail.gmail.com> 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 argument to mkisofs but that apparently wasn't it. Where can I turn this off? thanks, jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathansteffan at gmail.com Sat Sep 22 17:46:30 2007 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Sat, 22 Sep 2007 11:46:30 -0600 Subject: [Fedora-livecd-list] Where to turn off filesystem writing spew.. In-Reply-To: <74e6f65d0709212146m6d4af114k738442f360b5415b@mail.gmail.com> References: <74e6f65d0709212146m6d4af114k738442f360b5415b@mail.gmail.com> Message-ID: <46F554F6.3000005@gmail.com> 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 argument to > mkisofs but that apparently wasn't it. > > Where can I turn this off? That seems to be when it runs the squash (line 900-903). I don't, however, see a way to make mksquashfs be quite. You could add stdout=subprocess.PIPE, but then you need to deal with the stdout buffer or the call will hang. Jonathan Steffan daMaestro From dmc.fedora at filteredperception.org Sat Sep 22 21:48:15 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sat, 22 Sep 2007 16:48:15 -0500 Subject: [Fedora-livecd-list] Where to turn off filesystem writing spew.. In-Reply-To: <46F554F6.3000005@gmail.com> References: <74e6f65d0709212146m6d4af114k738442f360b5415b@mail.gmail.com> <46F554F6.3000005@gmail.com> Message-ID: <46F58D9F.9060407@filteredperception.org> 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 argument to >> mkisofs but that apparently wasn't it. >> >> Where can I turn this off? > That seems to be when it runs the squash (line 900-903). I don't, > however, see a way to make mksquashfs be quite. You could add > stdout=subprocess.PIPE, but then you need to deal with the stdout buffer > or the call will hang. -no-progress appears to be the option to mksquashfs that you are looking for. I too have been annoyed by its output in a logfile. I thought about throwing together a patch to finally implement some kind of --verbose/--debug/--quiet to livecd-creator. But I'm not exactly sure where the progress bar falls into that. Perhaps the correct way would be to somehow detect if the livecd-creator output is going to a terminal, and only do the progress bar in that situation. I know this is possible, as a bug I had in cleanupDeleted dealt with the fact that fsck (in the absense of a flag) behaved differently based on whether or not the output was redirected. -dmc From dmc.fedora at filteredperception.org Sun Sep 23 10:29:16 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 23 Sep 2007 05:29:16 -0500 Subject: [Fedora-livecd-list] [PATCH] squash osmin: saves 1.2MB of ram during LiveOS session (except install) Message-ID: <46F63FFC.3020102@filteredperception.org> 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 copying that 12kb image to ram, as opposed to an alternative of putting osmin in the same squashfs as the main system image. I chose to implement the seperate version, because it guarantees that the install will remain one long ~2G seekless cdrom read. This is seperate from the filesystem layout patchset I posted, but straightforward merging would need to be done if they are both applied. -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.squashedOsmin.patch Type: text/x-patch Size: 4999 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Sun Sep 23 10:30:01 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 23 Sep 2007 05:30:01 -0500 Subject: [Fedora-livecd-list] [PATCH 1/2] move loop modprobe before udevsettle, for simpler code Message-ID: <46F64029.5060609@filteredperception.org> 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 command is allowed to fail. I would personally feel comfortable committing this without the while-wait loop, because it seems like if udevsettle fails with a timeout of 30, it will never(tm) be because the loop devices have not been created. -dmc -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.1.earlyLoopModprobe.patch Type: text/x-patch Size: 773 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Sun Sep 23 10:31:00 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 23 Sep 2007 05:31:00 -0500 Subject: [Fedora-livecd-list] [PATCH 2/2] allow user specifiable number of loop devices Message-ID: <46F64064.2050701@filteredperception.org> 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 a normal system, in a LiveOS system, a loop device is used for the rootfs, and therefore the loop driver can never be removed and readded with a larger number of devices if needed. This patch adds an optional kernel commandline parameter num_loopdevs= which will cause that many loop devices to be created instead of the default of 16. This will be useful for people using the livecd who need lots of loop devices, but doesn't interfere with whatever reasons justified the lowering from 128 to 16. If you want to add this functionality without the prior patch which removed the while-wait, somthing like- maxloopdev="/dev/loop\$((\$num_loopdevs - 1))" while [ ! -b \$maxloopdev ] ; do sleep 1 done should do the trick -dmc -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.2.userNumLoop.patch Type: text/x-patch Size: 841 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Sun Sep 23 10:31:48 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 23 Sep 2007 05:31:48 -0500 Subject: [Fedora-livecd-list] [PATCH] disable mksquashfs progress bar for non-interactive sessions Message-ID: <46F64094.8050508@filteredperception.org> 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 livecd-creator, reasonably readable (e.g. with less). This may or may not solve the root issue that Jon Steer recently brought up. (maybe he wants it disabled even in terminal situation, in which case a --verbose/--debug/--quiet infrastructure is called for, which IMO would be a great addition as well). This specific case, might also be better as an upstream mksquashfs modification (Phillip, should I submit a patch?), but I think the global is handy, for instance if we want to provide our own progress bar. Comments welcome on generic style issues as always (is there something preferable to a global in this instance?) -dmc -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.interactive.patch Type: text/x-patch Size: 1292 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Sun Sep 23 10:34:25 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 23 Sep 2007 05:34:25 -0500 Subject: [Fedora-livecd-list] [PATCH] make ram overlay sparse file ridiculously large Message-ID: <46F64131.9080805@filteredperception.org> 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, coincides with the solution to exposing the user to how much ram overlay they have available. The solution would be as follows- 1) take this patch, making the sparse ram overlay ridiculously large, i.e. 1T 2) instead of putting the ram overlay sparse file in the root of the initramfs tmpfs, create a tmpfs dedicated to it. Perhaps /mnt/.LiveOS/overlayfs (which then gets mount --move(d) to /sysroot/mnt/.LiveOS/overlayfs) 3) and then to support clean shutdown, modify /etc/rc.d/init.d/functions and halt such that they don't try to unmount that filesystem at shutdown. Code that does this was in my persistence/overlay patch submitted here a while back. The result of this, is that "df -h /mnt/.LiveOS/overlayfs" will show you how much space is available there, and thus how much available for the read-write rootfs ram overlay. You can then also remount that tmpfs with a different size at runtime, or based on a kernel argument, to increase/decrease at will (as opposed to the tmpfs default of half of existing ram) NOTE: applying this patch will also suggest recompiling mkinitrd/nash with largefile support, to clear up the stat error on file-too-large which I believe is caused when the contents of the initramfs are deleted by nash/run-init/switchroot. (I think that is the fix). This problem of not being able for users to detect how much ram space they have available for copy-on-write-rootfs has come up a few times on this list in the past, so I strongly suggest the above or some other solution to the problem. -dmc -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.bigoverlay.patch Type: text/x-patch Size: 607 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Sun Sep 23 10:35:34 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 23 Sep 2007 05:35:34 -0500 Subject: [Fedora-livecd-list] RFC- proposal for livecd filesystem layout changes In-Reply-To: References: <46F20B83.6080403@filteredperception.org> Message-ID: <46F64176.6040404@filteredperception.org> Colin Walters wrote: > On 9/20/07, Douglas McClendon 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 and more >> intuitively understandable to less linux-guru users when they look at >> the directory structure under windows (or anywhere) > > I'm not qualified to comment on whether filesystem path cleanups are > useful for other reasons, but I think the Windows thing is not an > interesting benefit. We don't (or shouldn't) require non-developers > to interact with the directory structure, and developers will have to > understand things anyways. A couple more responses- First, not to your point but... I think that the same reasons I advocate these changes for windows users, apply moreso to developers. I think that the proposed filesystem layout will make more intuitive sense to developers. Second, I think I can provide an example use-case refuting your statement- What about the situation of a user wanting to spin a livecd with perhaps say... lots of creative commons media content. I.e. a bunch of .jpgs and .oggs on the iso. I think having a directory structure like- /music/(some .oggs) /images/(some .jpegs) /documentation/(some releasenotes and other html) /boot /LiveOS looks much better to the user than having /os.img and /osmin.gz and /isolinux littering the cdrom root filesystem. It is aesthetics. But I think they really do matter. -dmc From overholt at redhat.com Sun Sep 23 13:57:06 2007 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 23 Sep 2007 09:57:06 -0400 Subject: [Fedora-livecd-list] IOError: [Errno 13] Permission denied: '/var/tmp/...' Message-ID: <20070923135706.GB4786@redhat.com> 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 -c livecd-fedora-developer.ks -f Fedora-Developer-20070923 mke2fs 1.40.2 (12-Jul-2007) Filesystem label=Fedora-Developer OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 524288 inodes, 1048576 blocks 10485 blocks (1.00%) reserved for the super user First data block=0 Maximum filesystem blocks=1073741824 32 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736 Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 20 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. tune2fs 1.40.2 (12-Jul-2007) Setting maximal mount count to -1 Setting interval between checks to 0 seconds No Repositories Available to Set Up No Repositories Available to Set Up Retrieving http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/repodata/repomd.xml ...OK Retrieving http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/repodata/primary.sqlite.bz2 ...OK Traceback (most recent call last): File "../creator/livecd-creator", line 1480, in sys.exit(main()) File "../creator/livecd-creator", line 1453, in main target.install() File "../creator/livecd-creator", line 876, in install self.installPackages() File "../creator/livecd-creator", line 519, in installPackages self.ayum.selectPackage(pkg) File "../creator/livecd-creator", line 248, in selectPackage return self.install(pattern = pkg) File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 1830, in install parsePackages(self.pkgSack.returnPackages(),[kwargs['pattern']] , casematch=1) File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 517, in pkgSack = property(fget=lambda self: self._getSacks(), File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 377, in _getSacks self.repos.populateSack(which=repos) File "/usr/lib/python2.5/site-packages/yum/repos.py", line 239, in populateSack sack.populate(repo, mdtype, callback, cacheonly) File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 151, in populate db_fn = repo.retrieveMD(mydbtype) File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 839, in retrieveMD cache=self.http_caching == 'all') File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 607, in _getFile http_headers=headers, File "/usr/lib/python2.5/site-packages/urlgrabber/mirror.py", line 411, in urlgrab return self._mirror_try(func, url, kw) File "/usr/lib/python2.5/site-packages/urlgrabber/mirror.py", line 397, in _mirror_try return func_ref( *(fullurl,), **kwargs ) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 927, in urlgrab return self._retry(opts, retryfunc, url, filename) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 845, in _retry r = apply(func, (opts,) + args, {}) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 915, in retryfunc fo._do_grab() File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 1196, in _do_grab else: new_fo = open(self.filename, 'wb') IOError: [Errno 13] Permission denied: '/var/tmp/livecd-creator-G7ZrvX/install_root/var/cache/yum/development/primary.sqlite.bz2' Thanks, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tve at voneicken.com Sun Sep 23 17:57:10 2007 From: tve at voneicken.com (Thorsten von Eicken) Date: Sun, 23 Sep 2007 10:57:10 -0700 Subject: [Fedora-livecd-list] Re: booting from non-DMA IDE CF card In-Reply-To: <46DC3DAB.30705@voneicken.com> References: <46DC3DAB.30705@voneicken.com> Message-ID: <46F6A8F6.4060408@voneicken.com> Thorsten von Eicken wrote: > I am trying to boot off a CF card plugged into an IDE adapter and the > card doesn't support DMA. The problem is that with the new libata stuff, > the traditional "ide-nodma" kernel option doesn't do anything. How do I > turn DMA off so it boots properly. As it is, it tries MWDMA2 mode, fails > a few times, switches to MWDMA1 mode, but never goes down to PIO. > Apologies if this a FAQ, but couldn't find a solution anywhere. Replying to myself in case someone else has the same problem in the future. I ended up compiling the old ATA/IDE drivers into the kernel and omitting the new libata (PATA/SATA) drivers from the kernel. I also added ide=nodma to the kernel boot string. Thorsten From dmc.fedora at filteredperception.org Sun Sep 23 20:46:08 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 23 Sep 2007 15:46:08 -0500 Subject: [Fedora-livecd-list] IOError: [Errno 13] Permission denied: '/var/tmp/...' In-Reply-To: <20070923135706.GB4786@redhat.com> References: <20070923135706.GB4786@redhat.com> Message-ID: <46F6D090.9040100@filteredperception.org> 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 -c livecd-fedora-developer.ks -f Fedora-Developer-20070923 > mke2fs 1.40.2 (12-Jul-2007) ... > File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 1196, in _do_grab > else: new_fo = open(self.filename, 'wb') > IOError: [Errno 13] Permission denied: '/var/tmp/livecd-creator-G7ZrvX/install_root/var/cache/yum/development/primary.sqlite.bz2' My first thoughts on debugging this would be to comment out the 3 "target.teardown()" calls at the bottom of livecd-creator, and then rerun and do an ls -l on that permission denied file. Maybe there should be a very hidden debugging option to disable the teardown at exception? You will of course have to manually unmount a bunch of loopback mounted filesystems after doing that. -dmc From katzj at redhat.com Mon Sep 24 00:24:38 2007 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 23 Sep 2007 20:24:38 -0400 Subject: [Fedora-livecd-list] RFC- proposal for livecd filesystem layout changes In-Reply-To: <46F64176.6040404@filteredperception.org> References: <46F20B83.6080403@filteredperception.org> <46F64176.6040404@filteredperception.org> Message-ID: <1190593478.4603.28.camel@localhost.localdomain> On Sun, 2007-09-23 at 05:35 -0500, Douglas McClendon wrote: > Colin Walters wrote: > > On 9/20/07, Douglas McClendon 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 and more > >> intuitively understandable to less linux-guru users when they look at > >> the directory structure under windows (or anywhere) > > > > I'm not qualified to comment on whether filesystem path cleanups are > > useful for other reasons, but I think the Windows thing is not an > > interesting benefit. We don't (or shouldn't) require non-developers > > to interact with the directory structure, and developers will have to > > understand things anyways. > > A couple more responses- > > First, not to your point but... I think that the same reasons I > advocate these changes for windows users, apply moreso to developers. I > think that the proposed filesystem layout will make more intuitive sense > to developers. > > Second, I think I can provide an example use-case refuting your > statement- What about the situation of a user wanting to spin a livecd > with perhaps say... lots of creative commons media content. I.e. a > bunch of .jpgs and .oggs on the iso. I think having a directory > structure like- > > /music/(some .oggs) > /images/(some .jpegs) > /documentation/(some releasenotes and other html) > /boot > /LiveOS > > looks much better to the user than having /os.img and /osmin.gz and > /isolinux littering the cdrom root filesystem. > > It is aesthetics. But I think they really do matter. This is basically the crux of why I think it might be worth changing. And in fact have 99% convinced myself to go ahead and commit the patches later tonight or tomorrow. Jeremy From katzj at redhat.com Mon Sep 24 00:27:13 2007 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 23 Sep 2007 20:27:13 -0400 Subject: [Fedora-livecd-list] [PATCH 1/2] move loop modprobe before udevsettle, for simpler code In-Reply-To: <46F64029.5060609@filteredperception.org> References: <46F64029.5060609@filteredperception.org> Message-ID: <1190593633.4603.31.camel@localhost.localdomain> On Sun, 2007-09-23 at 05:30 -0500, Douglas McClendon wrote: > 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. Duh, this is obvious. Thanks for not beating over the head for missing it. Committed locally Jeremy From katzj at redhat.com Mon Sep 24 00:30:10 2007 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 23 Sep 2007 20:30:10 -0400 Subject: [Fedora-livecd-list] [PATCH 2/2] allow user specifiable number of loop devices In-Reply-To: <46F64064.2050701@filteredperception.org> References: <46F64064.2050701@filteredperception.org> Message-ID: <1190593810.4603.35.camel@localhost.localdomain> On Sun, 2007-09-23 at 05:31 -0500, Douglas McClendon wrote: > 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. There's some impact with udev startup. And Harald asked nicely :) > I had always guessed > that the reason David chose such a large number originally was because > of the fact that unlike in a normal system, in a LiveOS system, a loop > device is used for the rootfs, and therefore the loop driver can never > be removed and readded with a larger number of devices if needed. I thought it was just that he liked big numbers :-) > This patch adds an optional kernel commandline parameter > num_loopdevs= which will cause that many loop devices to be created > instead of the default of 16. This will be useful for people using the > livecd who need lots of loop devices, but doesn't interfere with > whatever reasons justified the lowering from 128 to 16. I'd rather go with using loop.max_loop as the option. My reason being that we want to get to where modprobe will look at things from /proc/cmdline and pass options in general with the same syntax as if the module were compiled into the kernel. I don't think that work will get done for F8, but this way, we're already using the syntax that we'll want for the future. Jeremy From katzj at redhat.com Mon Sep 24 00:31:51 2007 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 23 Sep 2007 20:31:51 -0400 Subject: [Fedora-livecd-list] [PATCH] disable mksquashfs progress bar for non-interactive sessions In-Reply-To: <46F64094.8050508@filteredperception.org> References: <46F64094.8050508@filteredperception.org> Message-ID: <1190593911.4603.38.camel@localhost.localdomain> On Sun, 2007-09-23 at 05:31 -0500, Douglas McClendon wrote: > 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 livecd-creator, reasonably readable (e.g. with less). I'm not sure how useful it really is as a global when we're using it for one thing. If we find more places that we want it, I might be convinced to make it more generally accessible, but until then, it just feels a little bit like polluting the namespace. Also, the more pythonic way to check is looking at sys.stdout.isatty() rather than os.isatty(Fdno) -- makes it a little bit more obvious to those who don't instinctively know "well duh, fd 1 is stdout" Jeremy From katzj at redhat.com Mon Sep 24 01:43:27 2007 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 23 Sep 2007 21:43:27 -0400 Subject: [Fedora-livecd-list] [PATCH] squash osmin: saves 1.2MB of ram during LiveOS session (except install) In-Reply-To: <46F63FFC.3020102@filteredperception.org> References: <46F63FFC.3020102@filteredperception.org> Message-ID: <1190598207.4603.59.camel@localhost.localdomain> On Sun, 2007-09-23 at 05:29 -0500, Douglas McClendon wrote: > 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 > copying that 12kb image to ram, as opposed to an alternative of putting > osmin in the same squashfs as the main system image. I chose to > implement the seperate version, because it guarantees that the install > will remain one long ~2G seekless cdrom read. Applied with a tiny rename to just be osmin.img instead of osmin.squashfs.img. The latter doesn't add a lot of value and could be problematic on msdos (not vfat) usb sticks Jeremy From katzj at redhat.com Mon Sep 24 01:49:25 2007 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 23 Sep 2007 21:49:25 -0400 Subject: [Fedora-livecd-list] [PATCH] disable mksquashfs progress bar for non-interactive sessions In-Reply-To: <1190593911.4603.38.camel@localhost.localdomain> References: <46F64094.8050508@filteredperception.org> <1190593911.4603.38.camel@localhost.localdomain> Message-ID: <1190598565.4603.62.camel@localhost.localdomain> On Sun, 2007-09-23 at 20:31 -0400, Jeremy Katz wrote: > On Sun, 2007-09-23 at 05:31 -0500, Douglas McClendon wrote: > > 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 livecd-creator, reasonably readable (e.g. with less). > > I'm not sure how useful it really is as a global when we're using it for > one thing. If we find more places that we want it, I might be convinced > to make it more generally accessible, but until then, it just feels a > little bit like polluting the namespace. > > Also, the more pythonic way to check is looking at sys.stdout.isatty() > rather than os.isatty(Fdno) -- makes it a little bit more obvious to > those who don't instinctively know "well duh, fd 1 is stdout" And done in my local tree[1] while moving mksquashfs into its own function. This adds the advantage of we don't need to copy around the hack of setting PWD in the environment as we have more than one place that we execute mksquashfs now. Jeremy [1] Not pushed to master as I'm about to head off to watch some TV before going to bed and thus want to make sure that the image I have going _finishes_ before pushing it From dmc.fedora at filteredperception.org Mon Sep 24 02:23:27 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 23 Sep 2007 21:23:27 -0500 Subject: [Fedora-livecd-list] non-vfat msdos usb sticks, persistence, misc... was Re: [PATCH] disable mksquashfs progress bar for non-interactive sessions In-Reply-To: <1190598565.4603.62.camel@localhost.localdomain> References: <46F64094.8050508@filteredperception.org> <1190593911.4603.38.camel@localhost.localdomain> <1190598565.4603.62.camel@localhost.localdomain> Message-ID: <46F71F9F.7040404@filteredperception.org> Jeremy Katz wrote: > On Sun, 2007-09-23 at 20:31 -0400, Jeremy Katz wrote: >> On Sun, 2007-09-23 at 05:31 -0500, Douglas McClendon wrote: >>> 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 livecd-creator, reasonably readable (e.g. with less). >> I'm not sure how useful it really is as a global when we're using it for >> one thing. If we find more places that we want it, I might be convinced >> to make it more generally accessible, but until then, it just feels a >> little bit like polluting the namespace. >> >> Also, the more pythonic way to check is looking at sys.stdout.isatty() >> rather than os.isatty(Fdno) -- makes it a little bit more obvious to >> those who don't instinctively know "well duh, fd 1 is stdout" yeah, that sounds better. As did the loop.max_loop choice. > And done in my local tree[1] while moving mksquashfs into its own > function. This adds the advantage of we don't need to copy around the > hack of setting PWD in the environment as we have more than one place > that we execute mksquashfs now. Note, I forgot to do an os.unlink of osmin from build_dir/data after its mksquashfs. So until you do that, an extra 10kb or so is wasted with an extra copy in the main squashfs. I won't try to offer a patch as I'm sure you can do it easily, and with the layout flux... I'd suggest... hmm... msdos(not vfat) sticks?... Is it really worth supporting msdos-nonvfat filesystems? Is any stick that isn't meant to be capable of holding an mp3 with a beyond 8.3 filename really worth supporting? Do sticks/cards often come preformatted that way? ( maybe they do... :( ) Clearly that would shoot down the last of my layout changes that adds the fslabel to the squashfs.img filename (unless you fell back to checking for the shorter version). I had been thinking given that naming scheme, that this new file should fit in similarly as fslabel.squashfs.mininst.img (or something). Finally, just a heads up, the remaining patches you might see soon, are the zenity-isotodisk, and a resend of the overlay/persistence. I think the latter might be worth considering applying before the devel freeze because a) it's such a useful feature, b) it could/would/should be turned off by default(for F8), c) it does actually work as long as you shutdown cleanly, and d) we do have plenty of time to fix bugs with it and make it more robust, or as a contingency, easily extricate it before F8. -dmc From dmc.fedora at filteredperception.org Mon Sep 24 03:53:55 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 23 Sep 2007 22:53:55 -0500 Subject: [Fedora-livecd-list] non-vfat msdos usb sticks (was related to squashed osmin naming) In-Reply-To: <46F71F9F.7040404@filteredperception.org> References: <46F64094.8050508@filteredperception.org> <1190593911.4603.38.camel@localhost.localdomain> <1190598565.4603.62.camel@localhost.localdomain> <46F71F9F.7040404@filteredperception.org> Message-ID: <46F734D3.5060601@filteredperception.org> Douglas McClendon wrote: > Is it really worth supporting msdos-nonvfat filesystems? Is any stick > that isn't meant to be capable of holding an mp3 with a beyond 8.3 > filename really worth supporting? Do sticks/cards often come > preformatted that way? ( maybe they do... :( ) I just tested what I thought was the case- you can have disk fdisk-ed as non-vfat msdos (6 - fat16), then mkfs.msdos it, then mount it as vfat, and all is well. Is there a case when that can't be relied on? I.e. perhaps when it isn't linux doing the mkfs.msdos? The case you mentioned was for osmin.squashfs.img->osmin.img. Assuming vfat can be relied upon(??), I can see that maybe having value before we move it under /LiveOS. But once under /LiveOS it seems reasonable to stick with the nice long intuitive/descriptive filenames. And thus in the rare case that that subdir is perused when mounted non-vfat, it's just OK that it clearly has stuff with long filenames that has been converted to the ugly dos 8.3 version. -dmc From alexm at asic.udl.cat Mon Sep 24 10:33:08 2007 From: alexm at asic.udl.cat (=?ISO-8859-1?Q?Alexandre_Magaz_Gra=E7a?=) Date: Mon, 24 Sep 2007 12:33:08 +0200 Subject: [Fedora-livecd-list] [PATCH 4/7] move syslinux and isolinux directories under /boot In-Reply-To: <46F39CAF.1020209@filteredperception.org> References: <46F39CAF.1020209@filteredperception.org> Message-ID: <46F79264.3030008@asic.udl.cat> 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. Aesthetics. > > Since I don't use ppc myself, I didn't attempt to also move the /ppc dir > to /boot/ppc on the ppc side. But I would recommend that as well if > possible. > > -dmc > Why not to put both the isolinux and ppc files directly into the /boot directory? I don't see the sense of having the /boot directory containig only a subdirectory. You already know the boot directory holds boot manager files, and configuration filenames tells you what boot manager it uses. Cheers, ?lex From dmc.fedora at filteredperception.org Mon Sep 24 11:02:17 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 24 Sep 2007 06:02:17 -0500 Subject: [Fedora-livecd-list] [PATCH 4/7] move syslinux and isolinux directories under /boot In-Reply-To: <46F79264.3030008@asic.udl.cat> References: <46F39CAF.1020209@filteredperception.org> <46F79264.3030008@asic.udl.cat> Message-ID: <46F79939.7030104@filteredperception.org> 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. Aesthetics. >> >> Since I don't use ppc myself, I didn't attempt to also move the /ppc >> dir to /boot/ppc on the ppc side. But I would recommend that as well >> if possible. >> >> -dmc >> > > Why not to put both the isolinux and ppc files directly into the /boot > directory? I don't see the sense of having the /boot directory containig > only a subdirectory. You already know the boot directory holds boot > manager files, and configuration filenames tells you what boot manager > it uses. To my understanding, with isolinux, the two and only two choices are /boot/isolinux and /isolinux. Though I have in the past put my kernel and initrd in /boot, with just the isolinux files under /boot/isolinux. Likewise, just to put all options on the table, a decent argument can be made for putting /LiveOS under /boot (or just the files therein). from /usr/share/doc/syslinux-*/syslinux.doc ++++ CONFIGURATION FILE ++++ All the configurable defaults in SYSLINUX can be changed by putting a file called "syslinux.cfg" in the root directory of the boot disk. This is a text file in either UNIX or DOS format, containing one or more of the following items (case is insensitive for keywords; upper case is used here to indicate that a word should be typed verbatim): Starting with version 3.35, the configuration file can also be in either the /boot/syslinux or /syslinux directories (searched in that order.) If that is the case, then all filenames are assumed to be relative to that same directory, unless preceded with a slash or backslash. ------------------------------- -dmc From alexm at asic.udl.cat Mon Sep 24 11:52:50 2007 From: alexm at asic.udl.cat (=?ISO-8859-1?Q?Alexandre_Magaz_Gra=E7a?=) Date: Mon, 24 Sep 2007 13:52:50 +0200 Subject: [Fedora-livecd-list] [PATCH 4/7] move syslinux and isolinux directories under /boot In-Reply-To: <46F79939.7030104@filteredperception.org> References: <46F39CAF.1020209@filteredperception.org> <46F79264.3030008@asic.udl.cat> <46F79939.7030104@filteredperception.org> Message-ID: <46F7A512.4010700@asic.udl.cat> En/na Douglas McClendon ha escrit: > 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. Aesthetics. >>> >>> Since I don't use ppc myself, I didn't attempt to also move the /ppc >>> dir to /boot/ppc on the ppc side. But I would recommend that as well >>> if possible. >>> >>> -dmc >>> >> >> Why not to put both the isolinux and ppc files directly into the /boot >> directory? I don't see the sense of having the /boot directory >> containig only a subdirectory. You already know the boot directory >> holds boot manager files, and configuration filenames tells you what >> boot manager it uses. > > To my understanding, with isolinux, the two and only two choices are > /boot/isolinux and /isolinux. Though I have in the past put my kernel > and initrd in /boot, with just the isolinux files under /boot/isolinux. > Likewise, just to put all options on the table, a decent argument can > be made for putting /LiveOS under /boot (or just the files therein). > > from /usr/share/doc/syslinux-*/syslinux.doc > > ++++ CONFIGURATION FILE ++++ > > All the configurable defaults in SYSLINUX can be changed by putting a > file called "syslinux.cfg" in the root directory of the boot disk. > > This is a text file in either UNIX or DOS format, containing one or > more of the following items (case is insensitive for keywords; upper > case is used here to indicate that a word should be typed verbatim): > > Starting with version 3.35, the configuration file can also be in > either the /boot/syslinux or /syslinux directories (searched in that > order.) If that is the case, then all filenames are assumed to be > relative to that same directory, unless preceded with a slash or > backslash. > Ok, then I think it's better to use /boot/syslinux. From rossini23 at gmail.com Mon Sep 24 13:46:59 2007 From: rossini23 at gmail.com (rossini ro) Date: Mon, 24 Sep 2007 21:46:59 +0800 Subject: [Fedora-livecd-list] Is there a chance to set homepage of firefox? Message-ID: <17771d90709240646l2bfa2e27v8f7fa8926f3f9152@mail.gmail.com> 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: From katzj at redhat.com Mon Sep 24 18:02:09 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 24 Sep 2007 14:02:09 -0400 Subject: [Fedora-livecd-list] non-vfat msdos usb sticks, persistence, misc... was Re: [PATCH] disable mksquashfs progress bar for non-interactive sessions In-Reply-To: <46F71F9F.7040404@filteredperception.org> References: <46F64094.8050508@filteredperception.org> <1190593911.4603.38.camel@localhost.localdomain> <1190598565.4603.62.camel@localhost.localdomain> <46F71F9F.7040404@filteredperception.org> Message-ID: <1190656929.7000.26.camel@localhost.localdomain> On Sun, 2007-09-23 at 21:23 -0500, Douglas McClendon wrote: > Note, I forgot to do an os.unlink of osmin from build_dir/data after its > mksquashfs. So until you do that, an extra 10kb or so is wasted with an > extra copy in the main squashfs. Done. > I won't try to offer a patch as I'm sure you can do it easily, and with > the layout flux... I'd suggest... hmm... msdos(not vfat) sticks?... > > Is it really worth supporting msdos-nonvfat filesystems? Is any stick > that isn't meant to be capable of holding an mp3 with a beyond 8.3 > filename really worth supporting? Do sticks/cards often come > preformatted that way? ( maybe they do... :( ) Trying to guarantee anything about how things come pre-formatted seems to be ... a path to losing, sadly. And really, when there's not a good reason _to_ use long file names, we might as well be conservative. > Clearly that would shoot down the last of my layout changes that adds > the fslabel to the squashfs.img filename (unless you fell back to > checking for the shorter version). I'm not sold on label in the filename, to be honest. Especially with then having to encode it on the filesystem to work with USB sticks given the UUID fun. Which is why I backed off on it a little before Fedora 7 when the idea came up. Jeremy From katzj at redhat.com Mon Sep 24 18:02:59 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 24 Sep 2007 14:02:59 -0400 Subject: [Fedora-livecd-list] [PATCH 4/7] move syslinux and isolinux directories under /boot In-Reply-To: <46F79264.3030008@asic.udl.cat> References: <46F39CAF.1020209@filteredperception.org> <46F79264.3030008@asic.udl.cat> Message-ID: <1190656979.7000.28.camel@localhost.localdomain> On Mon, 2007-09-24 at 12:33 +0200, 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. Aesthetics. > > > > Since I don't use ppc myself, I didn't attempt to also move the /ppc dir > > to /boot/ppc on the ppc side. But I would recommend that as well if > > possible. > > Why not to put both the isolinux and ppc files directly into the /boot > directory? I don't see the sense of having the /boot directory containig > only a subdirectory. You already know the boot directory holds boot > manager files, and configuration filenames tells you what boot manager > it uses. ppc stuff has to be under a ppc directory. Hooray for architecture booting constraints! Jeremy From dmc.fedora at filteredperception.org Mon Sep 24 20:51:41 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 24 Sep 2007 15:51:41 -0500 Subject: [Fedora-livecd-list] non-vfat msdos usb sticks, persistence, misc... was Re: [PATCH] disable mksquashfs progress bar for non-interactive sessions In-Reply-To: <1190656929.7000.26.camel@localhost.localdomain> References: <46F64094.8050508@filteredperception.org> <1190593911.4603.38.camel@localhost.localdomain> <1190598565.4603.62.camel@localhost.localdomain> <46F71F9F.7040404@filteredperception.org> <1190656929.7000.26.camel@localhost.localdomain> Message-ID: <46F8235D.3040902@filteredperception.org> Jeremy Katz wrote: > On Sun, 2007-09-23 at 21:23 -0500, Douglas McClendon wrote: >> Note, I forgot to do an os.unlink of osmin from build_dir/data after its >> mksquashfs. So until you do that, an extra 10kb or so is wasted with an >> extra copy in the main squashfs. > > Done. > >> I won't try to offer a patch as I'm sure you can do it easily, and with >> the layout flux... I'd suggest... hmm... msdos(not vfat) sticks?... >> >> Is it really worth supporting msdos-nonvfat filesystems? Is any stick >> that isn't meant to be capable of holding an mp3 with a beyond 8.3 >> filename really worth supporting? Do sticks/cards often come >> preformatted that way? ( maybe they do... :( ) > > Trying to guarantee anything about how things come pre-formatted seems > to be ... a path to losing, sadly. And really, when there's not a good > reason _to_ use long file names, we might as well be conservative. > >> Clearly that would shoot down the last of my layout changes that adds >> the fslabel to the squashfs.img filename (unless you fell back to >> checking for the shorter version). > > I'm not sold on label in the filename, to be honest. Especially with > then having to encode it on the filesystem to work with USB sticks given > the UUID fun. Which is why I backed off on it a little before Fedora 7 > when the idea came up. Yeah, complexity-wise it was more than all the other stuff combined, for a smaller immediate benefit. -dmc From dmc.fedora at filteredperception.org Mon Sep 24 23:39:48 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 24 Sep 2007 18:39:48 -0500 Subject: [Fedora-livecd-list] Is there a chance to set homepage of firefox? In-Reply-To: <17771d90709240646l2bfa2e27v8f7fa8926f3f9152@mail.gmail.com> References: <17771d90709240646l2bfa2e27v8f7fa8926f3f9152@mail.gmail.com> Message-ID: <46F84AC4.8040708@filteredperception.org> 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) /usr/lib/firefox-2.0.0.5/defaults/pref/all-redhat.js -dmc From katzj at redhat.com Tue Sep 25 16:51:22 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 25 Sep 2007 12:51:22 -0400 Subject: [Fedora-livecd-list] [PATCH 1/7] livecd filesystem layout cleanups -- remove /sysroot In-Reply-To: <46F39AB8.2040708@filteredperception.org> References: <46F39AB8.2040708@filteredperception.org> Message-ID: <1190739082.12936.4.camel@localhost.localdomain> On Fri, 2007-09-21 at 05:19 -0500, Douglas McClendon wrote: > Now on to the patches. I'll elaborate in individual emails. This first > patch, should probably be applied regardless of the rest. It simply > removes the apparently pointless /sysroot directory from the iso9660 > filesystem. Please let me know if I'm wrong and this is somehow needed > by something. I can't see any reason; applied Jeremy From katzj at redhat.com Tue Sep 25 16:51:33 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 25 Sep 2007 12:51:33 -0400 Subject: [Fedora-livecd-list] [PATCH 2/7] move livecd fs image under /LiveOS, like liveusb already is In-Reply-To: <46F39B46.3020509@filteredperception.org> References: <46F39B46.3020509@filteredperception.org> Message-ID: <1190739093.12936.6.camel@localhost.localdomain> On Fri, 2007-09-21 at 05:21 -0500, Douglas McClendon wrote: > 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/ Applied, thanks Jeremy From katzj at redhat.com Tue Sep 25 16:51:41 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 25 Sep 2007 12:51:41 -0400 Subject: [Fedora-livecd-list] [PATCH 3/7] move embedded fs image under /LiveOS for consistency In-Reply-To: <46F39C1A.9050803@filteredperception.org> References: <46F39C1A.9050803@filteredperception.org> Message-ID: <1190739101.12936.8.camel@localhost.localdomain> On Fri, 2007-09-21 at 05:25 -0500, Douglas McClendon wrote: > This patch moves the /os.img that is embedded in a squashfs to > /LiveOS/os.img, to be consistent with non-embedded location. Applied, thanks Jeremy From katzj at redhat.com Tue Sep 25 16:51:53 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 25 Sep 2007 12:51:53 -0400 Subject: [Fedora-livecd-list] [PATCH 5/7] rename os.img to ext3fs.img for consistency In-Reply-To: <46F39D0A.9000803@filteredperception.org> References: <46F39D0A.9000803@filteredperception.org> Message-ID: <1190739113.12936.10.camel@localhost.localdomain> On Fri, 2007-09-21 at 05:29 -0500, Douglas McClendon wrote: > This patch renames os.img in the embedded squashfs.img to ext3fs.img, to > be consistent with the name choice of ext3fs.img in the > --skip-compression case. Applied, thanks Jeremy From katzj at redhat.com Tue Sep 25 16:54:27 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 25 Sep 2007 12:54:27 -0400 Subject: [Fedora-livecd-list] [PATCH 4/7] move syslinux and isolinux directories under /boot In-Reply-To: <46F39CAF.1020209@filteredperception.org> References: <46F39CAF.1020209@filteredperception.org> Message-ID: <1190739267.12936.14.camel@localhost.localdomain> 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-linux-guru users. Aesthetics. So, after a little bit of thought, I decided not to apply this one. I'm not sure that sticking them under boot/ is really substantially better -- if we could hide them away under LiveOS/, it would be a different story, but as we can't, I'd rather just keep them at the top-level. Also, this keeps consistency with the install images Jeremy From katzj at redhat.com Tue Sep 25 16:55:42 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 25 Sep 2007 12:55:42 -0400 Subject: [Fedora-livecd-list] [PATCH 6/7] rename ext3fs.img to ext3.img for consistency In-Reply-To: <46F39DAE.4000000@filteredperception.org> References: <46F39DAE.4000000@filteredperception.org> Message-ID: <1190739342.12936.17.camel@localhost.localdomain> On Fri, 2007-09-21 at 05:32 -0500, Douglas McClendon wrote: > This patch renames the ext3fs.img file to ext3.img, to conform to a > syntax of .img, along with the existing squashfs.img. This may > be useful for future code simplification. I like it. I had applied this, but then reverted it. I think that the consistency of having them named foofs is better than caring about the module name. Especially as in general, we shouldn't have to know what the module/filesystem name is and just run mount. And I filed a bug to get libblkid fixed so that `mount squashfs.img /path/to/mountpoint` will work without having to pass -t squashfs Jeremy From katzj at redhat.com Tue Sep 25 17:01:46 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 25 Sep 2007 13:01:46 -0400 Subject: [Fedora-livecd-list] [PATCH 7/7] prepend iso fslabel to fstype.img syntax In-Reply-To: <46F3A094.6080009@filteredperception.org> References: <46F3A094.6080009@filteredperception.org> Message-ID: <1190739706.12936.22.camel@localhost.localdomain> On Fri, 2007-09-21 at 05:44 -0500, Douglas McClendon wrote: > This patch prepends the fslabel that the user gives to livecd-creator, > to the filesystem image names on the livecd and liveusb. So like we sort of concluded in the vfat/msdos discussion, I've held off on applying this for now. We can revisit it post-F8 if people want, though. Jeremy From cnegus at rucls.net Tue Sep 25 18:14:50 2007 From: cnegus at rucls.net (Chris Negus) Date: Tue, 25 Sep 2007 13:14:50 -0500 Subject: [Fedora-livecd-list] Fedora 8 live CDs In-Reply-To: <46F39AB8.2040708@filteredperception.org> References: <46F39AB8.2040708@filteredperception.org> Message-ID: <1190744090.2706.270.camel@einstein> I noticed a couple of new live CDs in the test area for Fedora 8. Does anyone know what these are: Fedora-7.91-FEL-Live-i386.iso and Fedora-7.91-developer-Live-i686.iso? Are there others that are expected to be in the official Fedora repository when Fedora 8 comes out? -- Chris Negus From sundaram at fedoraproject.org Tue Sep 25 18:12:53 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 25 Sep 2007 23:42:53 +0530 Subject: [Fedora-livecd-list] Fedora 8 live CDs In-Reply-To: <1190744090.2706.270.camel@einstein> References: <46F39AB8.2040708@filteredperception.org> <1190744090.2706.270.camel@einstein> Message-ID: <46F94FA5.4060600@fedoraproject.org> Chris Negus wrote: > I noticed a couple of new live CDs in the test area for Fedora 8. Does > anyone know what these are: Fedora-7.91-FEL-Live-i386.iso and > Fedora-7.91-developer-Live-i686.iso? Are there others that are expected > to be in the official Fedora repository when Fedora 8 comes out? Yes. See the test 2 release announcement and notes http://fedoraproject.org/wiki/F8Test2/ReleaseNotes We are also working on a games spin (Live DVD) which we hopefully get out in time for Fedora 8. http://fedoraproject.org/wiki/CustomSpins Rahul From tim.wood at datawranglers.com Tue Sep 25 22:02:19 2007 From: tim.wood at datawranglers.com (Tim Wood) Date: Tue, 25 Sep 2007 16:02:19 -0600 Subject: [Fedora-livecd-list] Spin with Revisor? In-Reply-To: <46F94FA5.4060600@fedoraproject.org> References: <46F39AB8.2040708@filteredperception.org> <1190744090.2706.270.camel@einstein> <46F94FA5.4060600@fedoraproject.org> Message-ID: I may be rehashing something old, but does the developer spin of (almost) 8 include Revisor? Tim On Sep 25, 2007, at 12:12 PM, Rahul Sundaram wrote: > Chris Negus wrote: >> I noticed a couple of new live CDs in the test area for Fedora 8. >> Does >> anyone know what these are: Fedora-7.91-FEL-Live-i386.iso and >> Fedora-7.91-developer-Live-i686.iso? Are there others that are >> expected >> to be in the official Fedora repository when Fedora 8 comes out? > > Yes. See the test 2 release announcement and notes > > http://fedoraproject.org/wiki/F8Test2/ReleaseNotes > > We are also working on a games spin (Live DVD) which we hopefully > get out in time for Fedora 8. > > http://fedoraproject.org/wiki/CustomSpins > > Rahul > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > From dmc.fedora at filteredperception.org Wed Sep 26 01:53:00 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 25 Sep 2007 20:53:00 -0500 Subject: [Fedora-livecd-list] [PATCH 4/7] move syslinux and isolinux directories under /boot In-Reply-To: <1190739267.12936.14.camel@localhost.localdomain> References: <46F39CAF.1020209@filteredperception.org> <1190739267.12936.14.camel@localhost.localdomain> Message-ID: <46F9BB7C.3050502@filteredperception.org> 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-linux-guru users. Aesthetics. > > So, after a little bit of thought, I decided not to apply this one. I'm > not sure that sticking them under boot/ is really substantially better > -- if we could hide them away under LiveOS/, it would be a different > story, but as we can't, I'd rather just keep them at the top-level. > Also, this keeps consistency with the install images Sure. And if /ppc can't be consistent either, all the more reason. Also, yes, +1 for the mount -t auto working on squashfs bug being filed. The main thing was getting straggler strangely named files out of /. I guess since iso and syslinux have linux in the name, they are at least relatively intuitive. And once we have perhaps /documentation or the like, perhaps a brief manifest/outline of the filesystem layout can be included somewhere... -dmc From dmc.fedora at filteredperception.org Wed Sep 26 01:54:56 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 25 Sep 2007 20:54:56 -0500 Subject: [Fedora-livecd-list] Spin with Revisor? In-Reply-To: References: <46F39AB8.2040708@filteredperception.org> <1190744090.2706.270.camel@einstein> <46F94FA5.4060600@fedoraproject.org> Message-ID: <46F9BBF0.8010009@filteredperception.org> Tim Wood wrote: > I may be rehashing something old, but does the developer spin of > (almost) 8 include Revisor? +1 From katzj at redhat.com Wed Sep 26 02:13:14 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 25 Sep 2007 22:13:14 -0400 Subject: [Fedora-livecd-list] [PATCH 4/7] move syslinux and isolinux directories under /boot In-Reply-To: <46F9BB7C.3050502@filteredperception.org> References: <46F39CAF.1020209@filteredperception.org> <1190739267.12936.14.camel@localhost.localdomain> <46F9BB7C.3050502@filteredperception.org> Message-ID: <1190772794.7929.9.camel@localhost.localdomain> On Tue, 2007-09-25 at 20:53 -0500, Douglas McClendon wrote: > The main thing was getting straggler strangely named files out of /. I > guess since iso and syslinux have linux in the name, they are at least > relatively intuitive. And once we have perhaps /documentation or the > like, perhaps a brief manifest/outline of the filesystem layout can be > included somewhere... The intent is that there's going to be a README available in the top-level of the CD (alongside the GPL) with the Fedora 8 release. Having a bit of information on the layout in there sounds entirely reasonable to me. I'm not finding where the source for said README is off-hand, though. It started on the wiki, but has moved to somewhere under /cvs/docs. just not sure where and my initial stab in the dark is failing miserably Jeremy From overholt at redhat.com Wed Sep 26 12:34:27 2007 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 26 Sep 2007 08:34:27 -0400 Subject: [Fedora-livecd-list] Spin with Revisor? In-Reply-To: <46F9BBF0.8010009@filteredperception.org> References: <46F39AB8.2040708@filteredperception.org> <1190744090.2706.270.camel@einstein> <46F94FA5.4060600@fedoraproject.org> <46F9BBF0.8010009@filteredperception.org> Message-ID: <20070926123426.GA6318@redhat.com> * Douglas McClendon [2007-09-25 22:29]: > Tim Wood wrote: >> I may be rehashing something old, but does the developer spin of (almost) >> 8 include Revisor? > > +1 Send Jeremy a patch :) (That will cut me out as the middle man) Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Wed Sep 26 12:47:32 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 26 Sep 2007 07:47:32 -0500 Subject: [Fedora-livecd-list] [PATCH] overlay/persistence patch, updated, still development quality Message-ID: <46FA54E4.1000907@filteredperception.org> 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, the following new things are relevant- - code has not been put in to mimick the running-from-git-directory feature that applies to mayflower. Thus the 3 files (findoverlay, and 2 .patch) files would need to be in /usr/lib/livecd-creator for it to work. - ntfs support removed. I tested with vfat (also noticing that a mount -t auto on a mkfs.msdos created filesystem results in vfat). - Only livecd-fedora-7-desktop.ks has the necessary gross code to patch /etc/rc.d/init.d/functions and halt. - it is off by default, so the basic way to test would be- git clone ... cd livecd patch -p1 < /tmp/downloaded_overlay.patch cd creator cp *.patch findoverlay /usr/lib/livecd-creator ./livecd-creator --config=../config/livecd-fedora-7-desktop.ks \ --fslabel=somelabel qemu-img create testoverlay.img 4G qemu -net none -m 384 -boot d -cdrom ./somelabel.iso \ -hdb ./testoverlay.img under qemu: fdisk /dev/sda, create a partition, give it a dos/vfat label (e.g. 6), mkfs.msdos /dev/sda1 mkdir /mnt/test mount /dev/sda1 /mnt/test mkdir /mnt/test/LiveOS dd if=/dev/zero of=/mnt/test/LiveOS/Persistence-somelabel- \ bs=1M count=256 # note trailing dash above, it matters. umount /mnt/test init 0 (or just ctrl-c qemu) (DONE WITH INIT) now invoke qemu again in the same way, but at isolinux boot, hit tab, and add "overlay=auto" to the kernel boot arguments. do some stuff shut down cleanly jump to (DONE WITH INIT) as often as desired... maybe things will persist if no bugs were encountered... Definitely much polishing and debugging yet to be done. But it does seem to work (at least until you forget to - or are unable to - cleanly shut down, at which point your persistence data may well become corrupted beyond repair) -dmc From dmc.fedora at filteredperception.org Wed Sep 26 12:50:55 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 26 Sep 2007 07:50:55 -0500 Subject: [Fedora-livecd-list] [PATCH] overlay/persistence patch, updated, still development quality In-Reply-To: <46FA54E4.1000907@filteredperception.org> References: <46FA54E4.1000907@filteredperception.org> Message-ID: <46FA55AF.3010404@filteredperception.org> Douglas McClendon wrote: > Here is another update to my devicemapper-snapshot based LiveOS > persistence implementation. Actually... _here_ it is. -dmc -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.v2overlay.patch Type: text/x-patch Size: 26140 bytes Desc: not available URL: From tim.wood at datawranglers.com Wed Sep 26 14:00:50 2007 From: tim.wood at datawranglers.com (Tim Wood) Date: Wed, 26 Sep 2007 08:00:50 -0600 Subject: [Fedora-livecd-list] Spin with Revisor? In-Reply-To: <20070926123426.GA6318@redhat.com> References: <46F39AB8.2040708@filteredperception.org> <1190744090.2706.270.camel@einstein> <46F94FA5.4060600@fedoraproject.org> <46F9BBF0.8010009@filteredperception.org> <20070926123426.GA6318@redhat.com> Message-ID: Darn... is the developer spin config/kickstart file in /etc/ revisor/... ? Tim On Sep 26, 2007, at 6:34 AM, Andrew Overholt wrote: > * Douglas McClendon [2007-09-25 > 22:29]: >> Tim Wood wrote: >>> I may be rehashing something old, but does the developer spin of >>> (almost) >>> 8 include Revisor? >> >> +1 > > Send Jeremy a patch :) (That will cut me out as the middle man) > > Andrew From overholt at redhat.com Wed Sep 26 14:05:50 2007 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 26 Sep 2007 10:05:50 -0400 Subject: [Fedora-livecd-list] Spin with Revisor? In-Reply-To: References: <46F39AB8.2040708@filteredperception.org> <1190744090.2706.270.camel@einstein> <46F94FA5.4060600@fedoraproject.org> <46F9BBF0.8010009@filteredperception.org> <20070926123426.GA6318@redhat.com> Message-ID: <20070926140549.GB8959@redhat.com> * Tim Wood [2007-09-26 10:02]: > Darn... is the developer spin config/kickstart file in /etc/revisor/... ? I don't know. It's in livecd-tools git. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tim.wood at datawranglers.com Wed Sep 26 14:31:02 2007 From: tim.wood at datawranglers.com (Tim Wood) Date: Wed, 26 Sep 2007 08:31:02 -0600 Subject: [Fedora-livecd-list] Spin with Revisor? In-Reply-To: <20070926140549.GB8959@redhat.com> References: <46F39AB8.2040708@filteredperception.org> <1190744090.2706.270.camel@einstein> <46F94FA5.4060600@fedoraproject.org> <46F9BBF0.8010009@filteredperception.org> <20070926123426.GA6318@redhat.com> <20070926140549.GB8959@redhat.com> Message-ID: Sorry... that should have been a rhetorical question. I've got a sneaking suspicion that I won't have time to hack on something like this until 8 gets released.... On Sep 26, 2007, at 8:05 AM, Andrew Overholt wrote: > * Tim Wood [2007-09-26 10:02]: >> Darn... is the developer spin config/kickstart file in /etc/ >> revisor/... ? > > I don't know. It's in livecd-tools git. > > Andrew From mdickson at redhat.com Wed Sep 26 21:46:49 2007 From: mdickson at redhat.com (Mike Dickson) Date: Wed, 26 Sep 2007 14:46:49 -0700 Subject: [Fedora-livecd-list] LIveCD/USB + Persistance Message-ID: <1190843209.4092.17.camel@teachjava.redhat.com> I am interested getting a USB stick up and running w/ the F8T2 LIve install plus adding persistence. Who is working on this and how can I install it? Done so far: I have F8 Developer T2 Live running on a Patriot 4 gig USB stick. It works great but it would be really cool if I could open up eclipse and edit my Java project and save it to the same stick. Thanks, MikeD JBoss SA -- Seattle -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmc.fedora at filteredperception.org Thu Sep 27 01:34:15 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 26 Sep 2007 20:34:15 -0500 Subject: [Fedora-livecd-list] LIveCD/USB + Persistance In-Reply-To: <1190843209.4092.17.camel@teachjava.redhat.com> References: <1190843209.4092.17.camel@teachjava.redhat.com> Message-ID: <46FB0897.5030804@filteredperception.org> Mike Dickson wrote: > I am interested getting a USB stick up and running w/ the F8T2 LIve > install plus adding persistence. Who is working on this and how can I > install it? To save you some trouble (is there a 'native' way to search the archives of this list, other than googling?)- Here is the simple persistence implementation from asdas at redhat.com, which due to not living on a loopback file on a filesystem, is I believe not susceptible to some of the non-shutdown-cleanly-corruption problems that my implementation has. https://www.redhat.com/archives/fedora-livecd-list/2007-August/msg00182.html It would need to be updated to take into consideration my recently applied de-hardcoding of loop devices patch, but that shouldn't be too hard. As yet, I haven't really heard much feedback regarding people using either that implementation, or the persistence-data-as-a-file implementation that I've been posting. Note, I'll update that one fairly soon, to use udev rules instead of the /var/tmp/ state file that it currently uses. -dmc From alexm at asic.udl.cat Thu Sep 27 14:28:22 2007 From: alexm at asic.udl.cat (=?ISO-8859-1?Q?Alexandre_Magaz_Gra=E7a?=) Date: Thu, 27 Sep 2007 16:28:22 +0200 Subject: [Fedora-livecd-list] traceback when installing openssh-server Message-ID: <46FBBE06.4070108@asic.udl.cat> 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 sys.exit(main()) File "/usr/bin/livecd-creator", line 1483, in main target.unmount() File "/usr/bin/livecd-creator", line 503, in unmount self.ayum.close() File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 92, in close self._repos.close() File "/usr/lib/python2.5/site-packages/yum/repos.py", line 76, in close repo.close() File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 257, in close self.sack.close() File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 233, in close del self.pkgobjlist AttributeError: pkgobjlist I noticed that it only happened when the base group is installed. After some tests, I discovered it was caused by the openssh-server package (ks attached). It worked when I tested in another machine, but failed againg after a system update which included yum (from 3.2.1-1.fc7 to 3.2.5-1.fc7). Could someone give some hint about how to find out what is making it fail? Thanks, ?lex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test.ks URL: From dmc.fedora at filteredperception.org Fri Sep 28 06:04:46 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 28 Sep 2007 01:04:46 -0500 Subject: [Fedora-livecd-list] udev selinux problem? "udevd_event selinux_setfilecon failed" Message-ID: <46FC997E.4030602@filteredperception.org> 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 harmless) that look vaguely like the following- udevd_event selinux_setfilecon failed permission denied /dev/usbdev.... I googled for selinux_setfilecon and found basically nothing. Do these keywords ring a bell to anyone? the /dev/usbdev... means that I get the same error half a dozen times (seems relative to how many usb devices are plugged in) with various non-intuitive incarnations of that filename. -dmc From walters at redhat.com Fri Sep 28 12:11:27 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 28 Sep 2007 08:11:27 -0400 Subject: [Fedora-livecd-list] udev selinux problem? "udevd_event selinux_setfilecon failed" In-Reply-To: <46FC997E.4030602@filteredperception.org> References: <46FC997E.4030602@filteredperception.org> Message-ID: On 9/28/07, Douglas McClendon wrote: > > > udevd_event selinux_setfilecon failed permission denied /dev/usbdev.... Is it possible to get audit events from this early boot? Maybe audit to the network? (Though with a quick look at http://people.redhat.com/sgrubb/audit/ I don't see that) -------------- next part -------------- An HTML attachment was scrubbed... URL: From katzj at redhat.com Fri Sep 28 12:55:53 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 28 Sep 2007 08:55:53 -0400 Subject: [Fedora-livecd-list] udev selinux problem? "udevd_event selinux_setfilecon failed" In-Reply-To: <46FC997E.4030602@filteredperception.org> References: <46FC997E.4030602@filteredperception.org> Message-ID: <1190984153.11341.4.camel@localhost.localdomain> On Fri, 2007-09-28 at 01:04 -0500, Douglas McClendon wrote: > 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 harmless) that look > vaguely like the following- > > udevd_event selinux_setfilecon failed permission denied /dev/usbdev.... > > I googled for selinux_setfilecon and found basically nothing. > > Do these keywords ring a bell to anyone? It looks like (from the messages) that udev is trying to set a file context based upon its config but that it's not being allowed to do so. Probably because it's running as a type that isn't allowed to set those contexts on files. So I'd take a look the context of udevd with ps -Z and see if it's a context that's allowed to set file contexts of the appropriate type Jeremy From chitlesh at fedoraproject.org Sun Sep 30 10:20:14 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 30 Sep 2007 12:20:14 +0200 Subject: [Fedora-livecd-list] selinux alerts and livecd doesn't boot Message-ID: <13dbfe4f0709300320q2adc90c0n7537f19c7c3152b0@mail.gmail.com> Hello there, i did a clean installation of the FEL F8T2 livecd. then did the updates then yum install livecd-tools (012) I created a livecd like i used to do. however during the installation of the packages for the livecd, there are lots of selinux denial notification popped on the system tray. it's nice to see the selinux notifier being integrated into the KDE desktop. however, non of my 7 livecds I recreated was bootable. during the build i can see restorecon /proc/1xxxx : permission denied. I'm wondering if the livecd creation procedures have been changed again that im unaware of or it's a bug. see attachments. chitlesh -- http://clunixchit.blogspot.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: selinux_alert.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-fedora-electronic-lab.ks Type: application/octet-stream Size: 4432 bytes Desc: not available URL: From chitlesh at fedoraproject.org Sun Sep 30 10:57:09 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 30 Sep 2007 12:57:09 +0200 Subject: [Fedora-livecd-list] Re: selinux alerts and livecd doesn't boot In-Reply-To: <13dbfe4f0709300320q2adc90c0n7537f19c7c3152b0@mail.gmail.com> References: <13dbfe4f0709300320q2adc90c0n7537f19c7c3152b0@mail.gmail.com> Message-ID: <13dbfe4f0709300357q74b2172fpb8787cd0507dd55f@mail.gmail.com> On 9/30/07, Chitlesh GOORAH wrote: > Hello there, > > i did a clean installation of the FEL F8T2 livecd. > then did the updates > then yum install livecd-tools (012) > > I created a livecd like i used to do. > however during the installation of the packages for the livecd, there > are lots of selinux denial notification popped on the system tray. > > it's nice to see the selinux notifier being integrated into the KDE desktop. > > however, non of my 7 livecds I recreated was bootable. > during the build i can see restorecon /proc/1xxxx : permission denied. > > I'm wondering if the livecd creation procedures have been changed > again that im unaware of or it's a bug. On a F7 box with all the updates, it doesn't even build : /sbin/restorecon reset /root/.tcshrc context root:object_r:user_home_t:s0->root:object_r:sysadm_home_t:s0 /sbin/restorecon reset /lib/udev/devices context system_u:object_r:lib_t:s0->system_u:object_r:device_t:s0 /sbin/restorecon reset /lib/dbus-1/dbus-daemon-launch-helper context system_u:object_r:lib_t:s0->system_u:object_r:bin_t:s0 Read error on pipe. Building an initramfs at /boot/livecd-initramfs.img for kernel 2.6.23-0.214.rc8.git2.fc8 Done; initramfs is 4.5M. Traceback (most recent call last): File "/usr/bin/livecd-creator", line 1480, in sys.exit(main()) File "/usr/bin/livecd-creator", line 1460, in main target.unmount() File "/usr/bin/livecd-creator", line 484, in unmount self.ayum.close() File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 92, in close self._repos.close() File "/usr/lib/python2.5/site-packages/yum/repos.py", line 76, in close repo.close() File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 257, in close self.sack.close() File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 233, in close del self.pkgobjlist AttributeError: pkgobjlist -- http://clunixchit.blogspot.com