Anaconda-devel March 2006

anaconda-devel@lists.stg.fedoraproject.org

35 participants
33 discussions

upd-instroot
by Aggarwal, VikasX 31 Mar '06

31 Mar '06

Hi Please provide hints to resolve this - I have added "sbin/my_utility" in upd-instroot but still its not available when booted from the install-disk1. I am building custom FC5-test3 with anaconda 10.92.14. Though my_utility.rpm is there in i386_disk3 tree, created by splittree.py. I need to run my_utility after booting from the install-disk1 and before kicking the installation. Please help as I could not find any documentation so far to describe the procedure. -vikas

1 0

7 proposals - was Re: [Fedora-livecd-list] Kadischi - Anaconda
by Jane Dogalt 31 Mar '06

31 Mar '06

I tried to post this on fedora-livecd-list. It seems relevent here as well, though please note, I just now subscribed to this list. So I don't know how much of this might have been discussed/debated already. --- "J. Hartline" <jasperhartline(a)adelphia.net> wrote: > Hi. > A few seem to be interested in getting Kadischi-like stuff fused with > Anaconda. This sounds like me and one of my recent posts :) From what you wrote, I don't think you understood what I meant, but then, thats why you asked for clarity. So here is an attempt to outline what I meant, which actually covers a few different proposals which don't need to all be taken together. *** proposal 1 *** *** integrating the current functionality of kadischi directly into anaconda a) new commandline option --output-livecd=/path/to/destination.iso b) optionally, --livecd-config=/path/to/livecdkickstart.config (b) is optional because the tokens/config/info contained there could also be put directly into the normal kickstart or additional anaconda gui installation steps One way to implement this, would be to have anaconda create it's own temporary rootpath, and temporary kadischi build directories that the user needn't ever know exist, other than anaconda complaining about lack of disk space. Only the absolute minimum of (kadischi like) post install scripts would be run by anaconda. Anything else could be user specified/provided by the livecd kickstart options. the hard drive partitioning phase of anaconda would be skipped in this scenario, just as it currently is in kadischis --rootpath invocation *** proposal 2 *** *** usage of kadischi, or anaconda+kadischi(proposal1), during a normal anaconda install. The output of this, would be perhaps /root/anaconda-livecd.iso in a newly installed system. One which perhaps would ideally be identical to what would be produced by invoking kadischi with the /root/anaconda-ks.cfg which is currently left by anaconda during a normal install. The user interface to this, for the first beta/development version of this, could depend on booting the fedora install cd/dvd with the flag livecdoption (i.e. isolinux boot: "linux livecdoption", as opposed to say "linux mediacheck") If the user enabled this functionality in that way, they would be provided with an additional anaconda gui step/screen, which had a checkbox for "go ahead and create livecd image", as well as a selection for the output filename, where default was /root/anaconda-livecd.iso (or whatever). Additionally, the user would then see the same additional livecd configuration steps listed in proposal 1, or would specify them in kickstart. Implementation-wise, anaconda would go through and do the normal install, and then, just before rebooting, would use tmp space on the newly installed system to assemble the livecd iso. This functionality would involve hdd partitioning, as it is a traditional fedora install onto harddisk (merely with livecd.iso bonus) *** proposal 3 *** *** allow proposal 2 to work, with the normal system installation as an option This was probably where I started to create confusion. prop2 requires that anaconda use quite a bit of additional disk space on the installation system for the assembly, and output of the livecd image. It is also using the actual installed system as the image base to produce that livecd image. One possibility, is that if sufficient free space exists on the system (say, on a vfat C:\ filesystem), then the whole process for creating the /root/anaconda-livecd.iso could be carried in temporary space on C:\, and the output left in C:\anaconda-livecd.iso. In this scenario, fedora is not really installed onto the target system. And as par the description, no hdd partitioning need ever be done. The only thing with the hdd that might need to be done is asking the users permission to use space on their C:\ partition (or their debian /usr partition, or temporarily using unpartitioned space, but leaving it that way, ...) *** proposal 4 *** *** allow prop2 and/or prop3 to work, and to even burn a copy of the new iso before ever rebooting If the user has a cd/dvd burner available that is unused by the installer, then the output iso could be burned immediately after it is created. Additionally and optionally, steps could be taken to free up the burner if it was used to boot the install cd/dvd. I.e. cache the iso (or needed parts of it) to ram or disk, so it can be remounted from there, and freeing the drive. *** proposal 5 *** *** add a --stateless option to anaconda, to produce output(installations) which make no assumptions about system hardware, and instead depend on runtime autoconfiguration of hardware. Currently I've noticed by default that kadischi output enables firstboot. I'm guessing that this is what chitlesh's cd uses for hardware configuration. I.e. let the user boot the livecd, and then babysit the hardware configuration every time. As opposed to knoppix and other livecds, which attempt to autoconfigure hardware on every boot, and have stuff 'just work'. One way to think of this proposal, is to view it as creating fedora installations that are "physically portable". I.e. the two big examples are a target media of a livecd, or a target media of a removable drive (usb thumbdrive, ipod, etc...). Then you take this physically portable media, and boot any system with it, and it autoconfigures hardware at runtime. Basically the goal of this is to put your workstation on your ipod(or livecd+ipod, or livecd+thumbdrive), and take it around with you, turning any system in front of you into a "thick client". On implementation detail, is that hardware configurations could be cached. I.e. no need to probe everything if you can identify the system (say with an lspci, or looking at the eth mac addr, or both), and have already done the HW config in the past, and saved that info (naturally wouldn't work on livecd only media). This is very much like the microsoft hardware profiles, if of course, microsoft included all the drivers for all the hardware and automatically installed and configured them every boot, and never needed to be rebooted to get drivers to work. (haha) Another implementation detail, is that this may require tweaking individual packages, and not only anaconda. I currently have a bug outstanding with anaconda --rootpath causing my system to reconfigure it's network and timezone. It may be that some individual rpm's postinstall script is tweaking the system during install. I would suggest that all rpms obey a convention that if they see a file /stateless, that they install under the above assumptions. Actually this is confusing and should be 2 things. If they see /rootpath, they should assume that they are not in a native install, and perhaps are not even running on a system of the same release. (i.e. this might be an installation of a fc7 system running on a fc5, or even debian system, therefore they shouldn't try to do anything to the hardware). Then, seperate from the rpm being aware if it is a rootpath install, the rpm should be aware if it is a stateless install, and if so, should set itself up so that if any hardware configuration needs to be done, it should be done during every boot. Note: this is a quite different (but not entirely) usage of the term 'stateless', from the official stateless project of fedora. It's extending the concept from the user and system data, into the hardware configuration data realm. Of course, note I haven't followed that project closely, so I could be wrong about that. *** proposal 6 *** *** give livecd systems ability to install(or perhaps just cache) themselves to harddrive I haven't looked at mandriva one, but they say they do this. What I have done in the past, is to have linuxrc (early early boot), dump the iso from the cdrom drive onto temp space on the harddrive (say C:\dontmindme\foo.iso), and then remount from there. This frees up the cd drive for the user, and drastically speeds boot. If you additionally dump some loadlin stuff in there (or even grub), then the livecd is now "installed/cached" on the harddrive, and the user can boot it again without the actual cdrom. If you are careful, you could even "install/cache" it to a newly created ext3 fs on unpartitioned space, and have what appears to be (and in fact actually is) a normal installed fedora system. This is what I would guess mandriva one is doing. *** proposal 7 *** *** use unionfs This is completely seperate from all the above, and has many wonderous benefits in countless ways. -jdog __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Custom FC5
by Alexandre CONRAD 31 Mar '06

31 Mar '06

Hello all, I've been browsing the list archives and I can see there are some posts about customizing the FC5 distro. Until now, I've been able to customize FC4's DVD by merging official RPM updates and be able to install FC4 on servers without internet (no yum update). ARCH="i386" BUILD="i386-build/" PKGORDER_LST="/tmp/pkgorder.lst" /usr/lib/anaconda-runtime/genhdlist --productpath Fedora ${BUILD} /usr/lib/anaconda-runtime/pkgorder ${BUILD} ${ARCH} Fedora > ${PKGORDER_LST} /usr/lib/anaconda-runtime/buildinstall --comp gulerod --pkgorder ${PKGORDER_LST} --version 4 --product "Fedora Core 4" --prodpath Fedora ${BUILD} genhdlist --withnumbers --productpath Fedora --fileorder ${PKGORDER_LST} ${BUILD} It seems that the process has changed for FC5 and "createrepo" should be used. Apparently no more genhdlist is needed. But as FC5 just came out, googling around doesn't show up any step-by-step customizing Fedora Core 5 HOWTOs. If anyone had any success making a custom FC5 ISO file, please share your experience and scripts. Regards, -- Alexandre CONRAD - TLV Research & Development tel : +33 1 30 80 55 05 fax : +33 1 30 80 55 06 6, rue de la plaine 78860 - SAINT NOM LA BRETECHE FRANCE

2 2

user utility: booted from install disc1
by Aggarwal, VikasX 30 Mar '06

30 Mar '06

Hi How can I make my user utility available during the install time, when I just booted from the install disc1. I am building a custom ISO for FC5 and it has a utility which is required during install time. I have added a line into upd-instroot in "KEEPFILE", and copied the RPM of this util to the $TREE/Fedora/RPMS. Do I have to do something special in util.spec file? Thanks for helping. -vikas

1 0

again: customize FC5
by G.-B. Hauck 30 Mar '06

30 Mar '06

Hi all, Since FC1 i'm making my own distro - but in FC5 i can't get it run ;-(. Yes, i'm using createrepo - but i saw that in pkgorder only my re- or new-build RPMs have the right "relativepath" (i386/Fedora) - all others don't - setting a base-path with "-u" in createrepo did not change anything. I changed the "relativepath" line in pkgorder and build the RPM-Name by "name-version-rel.arch.rpm" - then i got an install-directory but after pxe-boot, language selection, selection of NFS-Server and path - anaconda can't start in graphical mode, it can't find vesamodes ... I think, i do not use createrepo the right way and/or don't understand yum and/or ... - updating createrepo to 0.4.4 did not help ;-| What does the "--comp" parameter of buildinstall means ? Does someone have a working script like: pushd $FCBASE/$arch/$productpath/RPMS createrepo -o ../../ -g ../base/comps.xml ./ popd $PKGORDER "$FCBASE/$arch" $arch $productpath | tee $FCBASE/pkgfile.txt $BUILDINSTALL --comp Test --pkgorder $FCBASE/pkgfile.txt \ --discs $(makelist $BINDISCS ",") \ --version $distver --prodpath $productpath --product "$productname" \ --release "$release" $FCBASE/$arch splittree.py --arch=$arch --total-discs=$TOTALDISCS \ --bin-discs=$BINDISCS --src-discs=$SRCDISCS \ --release-string="$release" \ --pkgorderfile=$FCBASE/pkgfile.txt \ --distdir="$FCBASE/$arch" --srcdir="$FCBASE/SRPMS" \ --productpath=$productpath Thanks for every reply Georg

3 3

pkgorder trouble
by Christian Theil Have 30 Mar '06

30 Mar '06

Hi I'm having trouble with pkgorder. Im trying to build a custom distro based on fc5. When I run pkgorder it throws the following exception: Traceback (most recent call last): File "/usr/lib/anaconda-runtime/pkgorder", line 158, in ? ds.setup(fn=config, excludes=options.excludeList, root = testpath) File "/usr/lib/anaconda-runtime/pkgorder", line 57, in setup self.doGroupSetup() File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 374, in doGroupSetup yum.Errors.GroupsError: No Groups Available in any repository Can anybody tell me why? What do I need to do to fix it? An other question: I'm confused about getfullcomps.py and genhdlist is missing. Is there an other way to generate comps.xml? Regards, Christian Theil Have

2 1

.discinfo
by Christian Theil Have 30 Mar '06

30 Mar '06

Hi I'm trying to build a distro based on Fedora Core 5. I haven't found the perfect source of information on how to do this, but have gathered different information from the web. Most of it seems pretty outdated though. If anybody can point me to a good source of information, please post.. My current question is about the .discinfo file: Several places, I've seen that they copy the .discinfo file to the ISO. Can anyone tell me what the purpose and format of this file (do I need to edit it and how?). Thanks, Christian Theil Have.

3 2

Installed Kernel
by William Rizzo 28 Mar '06

28 Mar '06

Hi all, I need to change the default installed kernel. My idea is to prepare a new kernel (from src.rpm), apply the patches needed and prepare an RPM. My question.... How can i know wich parts of the kernel are built as Module and wich not in the default kernel? i want to keep operativity of the default kernel... Is there a command or a way-to-know it? Thanks in advance, William

2 1

Running anaconda twice
by James Dixson 16 Mar '06

16 Mar '06

I am building a network appliance based on linux. I want this appliance to have three bootable partitions, a recovery partition and two runtime partitions (designated 0 and 1). To simply manufacturing as well as to facilitate functional testing in virtual hardware, I want to build a bootable ISO that I can use to either initialize new hardware or to initialize virtual hardware with all three partitions. I have decided to use kickstart/anaconda to automate the install process. I have succeeded so far in constructing a netstg2.img that uses a "shim" anaconda to invoke the "real" anaconda twice in succession, but with different ks.cfg files, and then invoke partimage to duplicate image0 to create image1. My new netstg2.img works perfectly, but success with stage2.img and ISO/CD installs (as opposed to network-installs) is eluding me. My shim anaconda is included below (the original 10.2.1.5-2 anaconda has been copied to /usr/bin/anaconda.orig). My problem is the following... When running under netstg2.img the 'reset_mounts' function correctly umounts the ks.cfg defined partitions, and removes all of the anaconda-created device nodes allowing anaconda to be run a second time with a different ks.cfg. However when running under stage2.img, the 'reset_mounts' functions fails to umount the "/mnt/sysimage" partition with a "Device Busy" error. Furthermore switching to the alternative tty and issuing 'umount /mnt/sysimage' also results in a Device Busy error. I am sure the problem is a subtle different in the way stage2 operates from netstg2, but I at a loss as to what it could be. -- James -------------------------------------------- #!/usr/bin/python import os import sys # If this is a syslogd request, handle it if sys.argv[1] == '--syslogd': os.execv('/usr/bin/anaconda.orig', ('syslogd',sys.argv[1],sys.argv[2],sys.argv[3])) method = 'cdrom' def _invoke(cmdpath, args): pid = os.fork() if not pid: os.execv(cmdpath, args) os.waitpid(pid, 0) def do_anaconda(imageName, args): nargs = args[:] # .. other stuff to change arg list to load a dynamically generated ks.cfg _invoke('/usr/bin/anaconda.orig',['anaconda',]+list(nargs)) def reset_mounts(zapdevices=True): # if CD install create CDROM mount point if method == "cdrom": os.mkdir("/mnt/cdrom") # Unmount sysimage mounts ('maint','data','image0','image1' are all partitions created in ks.cfg) sysMounts = ('dev','selinux','sys','proc','boot','maint','data','image0','image1') for m in sysMounts: _invoke('/usr/bin/umount',('umount','/mnt/sysimage/%s'%m)) _invoke('/usr/bin/umount',('umount','/mnt/sysimage')) # /dev/hdc7 is provisioned as the swap partition in ks.cfg _invoke('/usr/bin/swapoff',('swapoff','/dev/hdc7')) # Drop device nodes deviceGlobs = ('/dev/hdc*','/dev/md*','dev/sda*','dev/initctl','/dev/mapper','/dev/log ','/dev/hdc*') if zapdevices: map(lambda x: _invoke('/usr/bin/rm',('rm','-rf',x)), deviceGlobs) if method == 'cdrom': _invoke('/usr/bin/mount',('mount','/tmp/cdrom','/mnt/source')) os.unlink('/tmp/cdrom') try: args = sys.argv[1:] # Run anaconda on maint do_anaconda('maint',args) # Run anaconda on image0 reset_mounts() do_anaconda('image0',args) # .. other stuff to canonicalize maint and image0, update grub # Capture image0 and duplicate to image1 reset_mounts(zapdevices=False) # .. other stuff to use partimage to copy image0 to image1 and canonicalize image1 except: print "%s %s\n%s" % (sys.exc_info()[0],sys.exc_info()[1],repr(sys.exc_info()[2])) # Done print "Press any key to reboot" sys.stdin.readline() sys.exit(0) ----------------------------------------------

1 0

how to customize centos4.2 distribution
by Rakesh L 14 Mar '06

14 Mar '06

Hi, I am using CentOS4.2 and I want to customize the distribution to include some additional packages to it. I had donbe the same earlier for RedHat 9. But the same steps does not hold ggod for CentOS also. When I execute genhdlist without even making any changes, it is creating hdlist files with smaller size than the actual. It starts installation but after saying 'Reading RPM information' it give error saying killing installion and so on. So please anybody help me. bye

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel March 2006