From ltx at charter.net Sun Feb 3 01:03:14 2008 From: ltx at charter.net (ltx) Date: Sat, 02 Feb 2008 20:03:14 -0500 Subject: [Fedora-livecd-list] live fedora 8 cd - login: no shell: Permission denied Message-ID: <47A512D2.4050106@charter.net> Hi, I'm trying to build a basic Fedora 8 livecd to use as a vehicle to flash a card I am working on. The flash utility works from linux running from the hard drive so that is not a concern at the moment. My problem - I can't log in! The iso builds fine with command; livecd-creator --config=./livecd-fedora-minimal.ks --fslabel=Fedora8 When I boot from it, or use qemu to test, I can't log into root or another id that I create in the kiskstart file. I followed the instructions at http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo which are great, but they even point out that the livecd-fedora-minimal.ks kickstart file found in /usr/share/livecd-tools will not let you log in. (unless you go to all full desktop environment - which I don't need/want) I noticed that the minimal kickstart file disabled the root id, so I removed that and scoured the net and found that kickstart command rootpw allows you to set the root password. That gave me some progress. Now when I try to log in to root I get these messages; Last login: time date... Welcome to my world (this is what I put in /etc/motd) login: no shell: Permission denied. So, several questions: 1 - What is wrong with my kickstart file (below) that prevents me from logging in? 2 - Is there any collections of kickstart files available (other than those that come with the livecd-tools packages? 3 - Where can I find the kickstart file options documented? Oh, my build environment is Fedora 8 (x86_64) with all the latest updates. I point to the x86 mirrors so I can use the CD on older machines. I'd appreciate any help you can offer. Thanks. Jerry lang en_US.UTF-8 keyboard us timezone US/Eastern #auth --useshadow --enablemd5 selinux --disabled firewall --disabled firstboot --disable #root password rootpw emulex part / --size 1024 repo --name=released --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=i386 repo --name=updates --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f8&arch=i386 %packages @core bash kernel passwd policycoreutils chkconfig authconfig rootfiles %post # FIXME: it'd be better to get this installed from a package cat > /etc/rc.d/init.d/fedora-live << EOF #!/bin/bash # # live: Init script for live image # # chkconfig: 345 00 99 # description: Init script for live image. . /etc/init.d/functions if ! strstr "\`cat /proc/cmdline\`" liveimg || [ "\$1" != "start" ] || [ -e /.liveimg-configured ] ; then exit 0 fi exists() { which \$1 >/dev/null 2>&1 || return \$* } touch /.liveimg-configured # mount live image if [ -b /dev/live ]; then mkdir -p /mnt/live mount -o ro /dev/live /mnt/live fi # add a user useradd -c "Jerry" jerry echo 'password' | passwd --stdin jerry # read some variables out of /proc/cmdline for o in \`cat /proc/cmdline\` ; do case \$o in ks=*) ks="\${o#ks=}" ;; xdriver=*) xdriver="--set-driver=\${o#xdriver=}" ;; esac done # Stopgap fix for RH #217966; should be fixed in HAL instead touch /media/.hal-mtab EOF chmod 755 /etc/rc.d/init.d/fedora-live #/sbin/restorecon /etc/rc.d/init.d/fedora-live /sbin/chkconfig --add fedora-live echo "Welcome to my world" > /etc/motd %end From tim.wood at datawranglers.com Sun Feb 3 02:45:56 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Sat, 02 Feb 2008 19:45:56 -0700 Subject: [Fedora-livecd-list] live fedora 8 cd - login: no shell: Permission denied In-Reply-To: <47A512D2.4050106@charter.net> References: <47A512D2.4050106@charter.net> Message-ID: <47A52AE4.2060009@datawranglers.com> One 'feature' of the minimal is that login is disabled. The kde desktop is a good starter. Tim Wood ltx wrote: > > > Hi, > > I'm trying to build a basic Fedora 8 livecd to use as > a vehicle to flash a card I am working on. The flash > utility works from linux running from the hard drive > so that is not a concern at the moment. > > My problem - I can't log in! The iso builds fine with > command; > > livecd-creator --config=./livecd-fedora-minimal.ks --fslabel=Fedora8 > > When I boot from it, or use qemu to test, I can't log into root > or another id that I create in the kiskstart file. I followed > the instructions at > http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo > which are great, but they even point out that the > livecd-fedora-minimal.ks > kickstart file found in /usr/share/livecd-tools will not let you log in. > (unless you go to all full desktop environment - which I don't need/want) > > I noticed that the minimal kickstart file disabled the root id, > so I removed that and scoured the net and found that kickstart command > rootpw allows you to set the root password. That gave me some > progress. Now when I try to log in to root I get these messages; > > Last login: time date... > Welcome to my world (this is what I put in /etc/motd) > login: no shell: Permission denied. > > So, several questions: > > 1 - What is wrong with my kickstart file (below) that prevents > me from logging in? > > 2 - Is there any collections of kickstart files available (other than > those that come with the livecd-tools packages? > > 3 - Where can I find the kickstart file options documented? > > Oh, my build environment is Fedora 8 (x86_64) with all the latest > updates. I point to the x86 mirrors so I can use the CD on older > machines. > > I'd appreciate any help you can offer. > > Thanks. > Jerry > > > lang en_US.UTF-8 > keyboard us > timezone US/Eastern > #auth --useshadow --enablemd5 > selinux --disabled > firewall --disabled > firstboot --disable > #root password > rootpw emulex > part / --size 1024 > > repo --name=released > --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=i386 > > repo --name=updates > --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f8&arch=i386 > > > %packages > @core > bash > kernel > passwd > policycoreutils > chkconfig > authconfig > rootfiles > > %post > # FIXME: it'd be better to get this installed from a package > cat > /etc/rc.d/init.d/fedora-live << EOF > #!/bin/bash > # > # live: Init script for live image > # > # chkconfig: 345 00 99 > # description: Init script for live image. > > . /etc/init.d/functions > > if ! strstr "\`cat /proc/cmdline\`" liveimg || [ "\$1" != "start" ] || > [ -e /.liveimg-configured ] ; then > exit 0 > fi > > exists() { > which \$1 >/dev/null 2>&1 || return > \$* > } > > touch /.liveimg-configured > > # mount live image > if [ -b /dev/live ]; then > mkdir -p /mnt/live > mount -o ro /dev/live /mnt/live > fi > > # add a user > useradd -c "Jerry" jerry > echo 'password' | passwd --stdin jerry > > # read some variables out of /proc/cmdline > for o in \`cat /proc/cmdline\` ; do > case \$o in > ks=*) > ks="\${o#ks=}" > ;; > xdriver=*) > xdriver="--set-driver=\${o#xdriver=}" > ;; > esac > done > > # Stopgap fix for RH #217966; should be fixed in HAL instead > touch /media/.hal-mtab > EOF > > chmod 755 /etc/rc.d/init.d/fedora-live > #/sbin/restorecon /etc/rc.d/init.d/fedora-live > /sbin/chkconfig --add fedora-live > > echo "Welcome to my world" > /etc/motd > > %end > > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > -- _________________________________ Tim Wood, CLP, RHCT 719.338.7484 (tel) The Data Wranglers Web, Database & more since since 1994 www.datawranglers.com From ltx at charter.net Sun Feb 3 03:01:01 2008 From: ltx at charter.net (ltx) Date: Sat, 02 Feb 2008 22:01:01 -0500 Subject: [Fedora-livecd-list] live fedora 8 cd - login: no shell: Permission denied In-Reply-To: <47A52AE4.2060009@datawranglers.com> References: <47A512D2.4050106@charter.net> <47A52AE4.2060009@datawranglers.com> Message-ID: <47A52E6D.6030102@charter.net> Hi Tim, Thanks for the quick reply. I was hoping to avoid all the graphics since this is more for utility work and will be booted often. Even if I went to the KDE desktop kickstart file what would the root password be? Thanks. Jerry Tim Wood wrote: > One 'feature' of the minimal is that login is disabled. The kde desktop > is a good starter. > > Tim Wood > > > ltx wrote: >> >> >> Hi, >> >> I'm trying to build a basic Fedora 8 livecd to use as >> a vehicle to flash a card I am working on. The flash >> utility works from linux running from the hard drive >> so that is not a concern at the moment. >> >> My problem - I can't log in! The iso builds fine with >> command; >> >> livecd-creator --config=./livecd-fedora-minimal.ks --fslabel=Fedora8 >> >> When I boot from it, or use qemu to test, I can't log into root >> or another id that I create in the kiskstart file. I followed >> the instructions at >> http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo >> which are great, but they even point out that the >> livecd-fedora-minimal.ks >> kickstart file found in /usr/share/livecd-tools will not let you log in. >> (unless you go to all full desktop environment - which I don't need/want) >> >> I noticed that the minimal kickstart file disabled the root id, >> so I removed that and scoured the net and found that kickstart command >> rootpw allows you to set the root password. That gave me some >> progress. Now when I try to log in to root I get these messages; >> >> Last login: time date... >> Welcome to my world (this is what I put in /etc/motd) >> login: no shell: Permission denied. >> >> So, several questions: >> >> 1 - What is wrong with my kickstart file (below) that prevents >> me from logging in? >> >> 2 - Is there any collections of kickstart files available (other than >> those that come with the livecd-tools packages? >> >> 3 - Where can I find the kickstart file options documented? >> >> Oh, my build environment is Fedora 8 (x86_64) with all the latest >> updates. I point to the x86 mirrors so I can use the CD on older >> machines. >> >> I'd appreciate any help you can offer. >> >> Thanks. >> Jerry >> >> >> lang en_US.UTF-8 >> keyboard us >> timezone US/Eastern >> #auth --useshadow --enablemd5 >> selinux --disabled >> firewall --disabled >> firstboot --disable >> #root password >> rootpw emulex >> part / --size 1024 >> >> repo --name=released >> --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=i386 >> >> repo --name=updates >> --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f8&arch=i386 >> >> >> %packages >> @core >> bash >> kernel >> passwd >> policycoreutils >> chkconfig >> authconfig >> rootfiles >> >> %post >> # FIXME: it'd be better to get this installed from a package >> cat > /etc/rc.d/init.d/fedora-live << EOF >> #!/bin/bash >> # >> # live: Init script for live image >> # >> # chkconfig: 345 00 99 >> # description: Init script for live image. >> >> . /etc/init.d/functions >> >> if ! strstr "\`cat /proc/cmdline\`" liveimg || [ "\$1" != "start" ] || >> [ -e /.liveimg-configured ] ; then >> exit 0 >> fi >> >> exists() { >> which \$1 >/dev/null 2>&1 || return >> \$* >> } >> >> touch /.liveimg-configured >> >> # mount live image >> if [ -b /dev/live ]; then >> mkdir -p /mnt/live >> mount -o ro /dev/live /mnt/live >> fi >> >> # add a user >> useradd -c "Jerry" jerry >> echo 'password' | passwd --stdin jerry >> >> # read some variables out of /proc/cmdline >> for o in \`cat /proc/cmdline\` ; do >> case \$o in >> ks=*) >> ks="\${o#ks=}" >> ;; >> xdriver=*) >> xdriver="--set-driver=\${o#xdriver=}" >> ;; >> esac >> done >> >> # Stopgap fix for RH #217966; should be fixed in HAL instead >> touch /media/.hal-mtab >> EOF >> >> chmod 755 /etc/rc.d/init.d/fedora-live >> #/sbin/restorecon /etc/rc.d/init.d/fedora-live >> /sbin/chkconfig --add fedora-live >> >> echo "Welcome to my world" > /etc/motd >> >> %end >> >> >> -- >> Fedora-livecd-list mailing list >> Fedora-livecd-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-livecd-list >> > > From ltx at charter.net Sun Feb 3 03:31:32 2008 From: ltx at charter.net (ltx) Date: Sat, 02 Feb 2008 22:31:32 -0500 Subject: [Fedora-livecd-list] live fedora 8 cd - login: no shell: Permission denied In-Reply-To: <47A5317C.90508@datawranglers.com> References: <47A512D2.4050106@charter.net> <47A52AE4.2060009@datawranglers.com> <47A52E6D.6030102@charter.net> <47A5317C.90508@datawranglers.com> Message-ID: <47A53594.4040004@charter.net> Yeah, I can't seem to find any docs that mention what the password is. I did put the rootpw line in and it does appear that the log in works since I get the 'Last Login' message and I get the message from /etc/motd, but then it complains that there is 'no shell: Permission denied' Jerry Tim Wood wrote: > Good question that I don't have the answer to. Since I always forget, I > started overiding it by adding this to the kickstart: > > # Set root password > rootpw iamroot > > If it's not a space issue, modify /etc/inittab during post and change > the runlevel from 5 to 3. If /etc/inittab doesn't make sense to you, > post again and I'll copy and paste the particular line. > > Tim > > > > ltx wrote: >> >> Hi Tim, >> >> Thanks for the quick reply. I was hoping to avoid all the >> graphics since this is more for utility work and will be >> booted often. >> >> Even if I went to the KDE desktop kickstart file what would >> the root password be? >> >> Thanks. >> Jerry >> >> Tim Wood wrote: >>> One 'feature' of the minimal is that login is disabled. The kde >>> desktop is a good starter. >>> >>> Tim Wood >>> >>> >>> ltx wrote: >>>> >>>> >>>> Hi, >>>> >>>> I'm trying to build a basic Fedora 8 livecd to use as >>>> a vehicle to flash a card I am working on. The flash >>>> utility works from linux running from the hard drive >>>> so that is not a concern at the moment. >>>> >>>> My problem - I can't log in! The iso builds fine with >>>> command; >>>> >>>> livecd-creator --config=./livecd-fedora-minimal.ks --fslabel=Fedora8 >>>> >>>> When I boot from it, or use qemu to test, I can't log into root >>>> or another id that I create in the kiskstart file. I followed >>>> the instructions at >>>> http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo >>>> which are great, but they even point out that the >>>> livecd-fedora-minimal.ks >>>> kickstart file found in /usr/share/livecd-tools will not let you log >>>> in. >>>> (unless you go to all full desktop environment - which I don't >>>> need/want) >>>> >>>> I noticed that the minimal kickstart file disabled the root id, >>>> so I removed that and scoured the net and found that kickstart command >>>> rootpw allows you to set the root password. That gave me some >>>> progress. Now when I try to log in to root I get these messages; >>>> >>>> Last login: time date... >>>> Welcome to my world (this is what I put in /etc/motd) >>>> login: no shell: Permission denied. >>>> >>>> So, several questions: >>>> >>>> 1 - What is wrong with my kickstart file (below) that prevents >>>> me from logging in? >>>> >>>> 2 - Is there any collections of kickstart files available (other than >>>> those that come with the livecd-tools packages? >>>> >>>> 3 - Where can I find the kickstart file options documented? >>>> >>>> Oh, my build environment is Fedora 8 (x86_64) with all the latest >>>> updates. I point to the x86 mirrors so I can use the CD on older >>>> machines. >>>> >>>> I'd appreciate any help you can offer. >>>> >>>> Thanks. >>>> Jerry >>>> >>>> >>>> lang en_US.UTF-8 >>>> keyboard us >>>> timezone US/Eastern >>>> #auth --useshadow --enablemd5 >>>> selinux --disabled >>>> firewall --disabled >>>> firstboot --disable >>>> #root password >>>> rootpw emulex >>>> part / --size 1024 >>>> >>>> repo --name=released >>>> --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=i386 >>>> >>>> repo --name=updates >>>> --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f8&arch=i386 >>>> >>>> >>>> %packages >>>> @core >>>> bash >>>> kernel >>>> passwd >>>> policycoreutils >>>> chkconfig >>>> authconfig >>>> rootfiles >>>> >>>> %post >>>> # FIXME: it'd be better to get this installed from a package >>>> cat > /etc/rc.d/init.d/fedora-live << EOF >>>> #!/bin/bash >>>> # >>>> # live: Init script for live image >>>> # >>>> # chkconfig: 345 00 99 >>>> # description: Init script for live image. >>>> >>>> . /etc/init.d/functions >>>> >>>> if ! strstr "\`cat /proc/cmdline\`" liveimg || [ "\$1" != "start" ] >>>> || [ -e /.liveimg-configured ] ; then >>>> exit 0 >>>> fi >>>> >>>> exists() { >>>> which \$1 >/dev/null 2>&1 || return >>>> \$* >>>> } >>>> >>>> touch /.liveimg-configured >>>> >>>> # mount live image >>>> if [ -b /dev/live ]; then >>>> mkdir -p /mnt/live >>>> mount -o ro /dev/live /mnt/live >>>> fi >>>> >>>> # add a user >>>> useradd -c "Jerry" jerry >>>> echo 'password' | passwd --stdin jerry >>>> >>>> # read some variables out of /proc/cmdline >>>> for o in \`cat /proc/cmdline\` ; do >>>> case \$o in >>>> ks=*) >>>> ks="\${o#ks=}" >>>> ;; >>>> xdriver=*) >>>> xdriver="--set-driver=\${o#xdriver=}" >>>> ;; >>>> esac >>>> done >>>> >>>> # Stopgap fix for RH #217966; should be fixed in HAL instead >>>> touch /media/.hal-mtab >>>> EOF >>>> >>>> chmod 755 /etc/rc.d/init.d/fedora-live >>>> #/sbin/restorecon /etc/rc.d/init.d/fedora-live >>>> /sbin/chkconfig --add fedora-live >>>> >>>> echo "Welcome to my world" > /etc/motd >>>> >>>> %end >>>> >>>> >>>> -- >>>> Fedora-livecd-list mailing list >>>> Fedora-livecd-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-livecd-list >>>> >>> >>> >> > > From tim.wood at datawranglers.com Sun Feb 3 04:06:48 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Sat, 02 Feb 2008 21:06:48 -0700 Subject: [Fedora-livecd-list] live fedora 8 cd - login: no shell: Permission denied In-Reply-To: <47A53594.4040004@charter.net> References: <47A512D2.4050106@charter.net> <47A52AE4.2060009@datawranglers.com> <47A52E6D.6030102@charter.net> <47A5317C.90508@datawranglers.com> <47A53594.4040004@charter.net> Message-ID: <47A53DD8.5030207@datawranglers.com> Hmmm... this is just guessing, but that usually comes from having something like /dev/null next to root in /etc/password. You could have your %post -nochroot section copy /etc/password from your dev system like this: cp /etc/password $INSTALL_ROOT/etc/password Tim ltx wrote: > > Yeah, I can't seem to find any docs that mention what the > password is. > > I did put the rootpw line in and it does appear that the > log in works since I get the 'Last Login' message and > I get the message from /etc/motd, but then it complains > that there is 'no shell: Permission denied' > > Jerry > > Tim Wood wrote: >> Good question that I don't have the answer to. Since I always >> forget, I started overiding it by adding this to the kickstart: >> >> # Set root password >> rootpw iamroot >> >> If it's not a space issue, modify /etc/inittab during post and change >> the runlevel from 5 to 3. If /etc/inittab doesn't make sense to you, >> post again and I'll copy and paste the particular line. >> >> Tim >> >> >> >> ltx wrote: >>> >>> Hi Tim, >>> >>> Thanks for the quick reply. I was hoping to avoid all the >>> graphics since this is more for utility work and will be >>> booted often. >>> >>> Even if I went to the KDE desktop kickstart file what would >>> the root password be? >>> >>> Thanks. >>> Jerry >>> >>> Tim Wood wrote: >>>> One 'feature' of the minimal is that login is disabled. The kde >>>> desktop is a good starter. >>>> >>>> Tim Wood >>>> >>>> >>>> ltx wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I'm trying to build a basic Fedora 8 livecd to use as >>>>> a vehicle to flash a card I am working on. The flash >>>>> utility works from linux running from the hard drive >>>>> so that is not a concern at the moment. >>>>> >>>>> My problem - I can't log in! The iso builds fine with >>>>> command; >>>>> >>>>> livecd-creator --config=./livecd-fedora-minimal.ks --fslabel=Fedora8 >>>>> >>>>> When I boot from it, or use qemu to test, I can't log into root >>>>> or another id that I create in the kiskstart file. I followed >>>>> the instructions at >>>>> http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo >>>>> which are great, but they even point out that the >>>>> livecd-fedora-minimal.ks >>>>> kickstart file found in /usr/share/livecd-tools will not let you >>>>> log in. >>>>> (unless you go to all full desktop environment - which I don't >>>>> need/want) >>>>> >>>>> I noticed that the minimal kickstart file disabled the root id, >>>>> so I removed that and scoured the net and found that kickstart >>>>> command >>>>> rootpw allows you to set the root password. That gave me some >>>>> progress. Now when I try to log in to root I get these messages; >>>>> >>>>> Last login: time date... >>>>> Welcome to my world (this is what I put in /etc/motd) >>>>> login: no shell: Permission denied. >>>>> >>>>> So, several questions: >>>>> >>>>> 1 - What is wrong with my kickstart file (below) that prevents >>>>> me from logging in? >>>>> >>>>> 2 - Is there any collections of kickstart files available (other than >>>>> those that come with the livecd-tools packages? >>>>> >>>>> 3 - Where can I find the kickstart file options documented? >>>>> >>>>> Oh, my build environment is Fedora 8 (x86_64) with all the latest >>>>> updates. I point to the x86 mirrors so I can use the CD on older >>>>> machines. >>>>> >>>>> I'd appreciate any help you can offer. >>>>> >>>>> Thanks. >>>>> Jerry >>>>> >>>>> >>>>> lang en_US.UTF-8 >>>>> keyboard us >>>>> timezone US/Eastern >>>>> #auth --useshadow --enablemd5 >>>>> selinux --disabled >>>>> firewall --disabled >>>>> firstboot --disable >>>>> #root password >>>>> rootpw emulex >>>>> part / --size 1024 >>>>> >>>>> repo --name=released >>>>> --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=i386 >>>>> >>>>> repo --name=updates >>>>> --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f8&arch=i386 >>>>> >>>>> >>>>> %packages >>>>> @core >>>>> bash >>>>> kernel >>>>> passwd >>>>> policycoreutils >>>>> chkconfig >>>>> authconfig >>>>> rootfiles >>>>> >>>>> %post >>>>> # FIXME: it'd be better to get this installed from a package >>>>> cat > /etc/rc.d/init.d/fedora-live << EOF >>>>> #!/bin/bash >>>>> # >>>>> # live: Init script for live image >>>>> # >>>>> # chkconfig: 345 00 99 >>>>> # description: Init script for live image. >>>>> >>>>> . /etc/init.d/functions >>>>> >>>>> if ! strstr "\`cat /proc/cmdline\`" liveimg || [ "\$1" != "start" >>>>> ] || [ -e /.liveimg-configured ] ; then >>>>> exit 0 >>>>> fi >>>>> >>>>> exists() { >>>>> which \$1 >/dev/null 2>&1 || return >>>>> \$* >>>>> } >>>>> >>>>> touch /.liveimg-configured >>>>> >>>>> # mount live image >>>>> if [ -b /dev/live ]; then >>>>> mkdir -p /mnt/live >>>>> mount -o ro /dev/live /mnt/live >>>>> fi >>>>> >>>>> # add a user >>>>> useradd -c "Jerry" jerry >>>>> echo 'password' | passwd --stdin jerry >>>>> >>>>> # read some variables out of /proc/cmdline >>>>> for o in \`cat /proc/cmdline\` ; do >>>>> case \$o in >>>>> ks=*) >>>>> ks="\${o#ks=}" >>>>> ;; >>>>> xdriver=*) >>>>> xdriver="--set-driver=\${o#xdriver=}" >>>>> ;; >>>>> esac >>>>> done >>>>> >>>>> # Stopgap fix for RH #217966; should be fixed in HAL instead >>>>> touch /media/.hal-mtab >>>>> EOF >>>>> >>>>> chmod 755 /etc/rc.d/init.d/fedora-live >>>>> #/sbin/restorecon /etc/rc.d/init.d/fedora-live >>>>> /sbin/chkconfig --add fedora-live >>>>> >>>>> echo "Welcome to my world" > /etc/motd >>>>> >>>>> %end >>>>> >>>>> >>>>> -- >>>>> 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 > -- _________________________________ Tim Wood, CLP, RHCT 719.338.7484 (tel) The Data Wranglers Web, Database & more since since 1994 www.datawranglers.com From tim.wood at datawranglers.com Sun Feb 3 04:10:55 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Sat, 02 Feb 2008 21:10:55 -0700 Subject: [Fedora-livecd-list] live fedora 8 cd - login: no shell: Permission denied In-Reply-To: <47A53594.4040004@charter.net> References: <47A512D2.4050106@charter.net> <47A52AE4.2060009@datawranglers.com> <47A52E6D.6030102@charter.net> <47A5317C.90508@datawranglers.com> <47A53594.4040004@charter.net> Message-ID: <47A53ECF.8090408@datawranglers.com> FWIW... be very careful when doing what I just suggested. And, just in case, do the following (just in case). Open a terminal window. su (to root). make a backup of /etc/password somewhere else. Leave that window open. Open a new terminal window and build your LiveCD. Then, if the kickstart causes your system (rather than the livecd's) /etc/password to be overwritten, you'll still have a root window open and you _should_ be able to copy back the backup. At a worst case scenario, you can boot off of a livecd and restore the backup of /etc/password. Tim Wood ltx wrote: > > Yeah, I can't seem to find any docs that mention what the > password is. > > I did put the rootpw line in and it does appear that the > log in works since I get the 'Last Login' message and > I get the message from /etc/motd, but then it complains > that there is 'no shell: Permission denied' > > Jerry > > Tim Wood wrote: >> Good question that I don't have the answer to. Since I always >> forget, I started overiding it by adding this to the kickstart: >> >> # Set root password >> rootpw iamroot >> >> If it's not a space issue, modify /etc/inittab during post and change >> the runlevel from 5 to 3. If /etc/inittab doesn't make sense to you, >> post again and I'll copy and paste the particular line. >> >> Tim >> >> >> >> ltx wrote: >>> >>> Hi Tim, >>> >>> Thanks for the quick reply. I was hoping to avoid all the >>> graphics since this is more for utility work and will be >>> booted often. >>> >>> Even if I went to the KDE desktop kickstart file what would >>> the root password be? >>> >>> Thanks. >>> Jerry >>> >>> Tim Wood wrote: >>>> One 'feature' of the minimal is that login is disabled. The kde >>>> desktop is a good starter. >>>> >>>> Tim Wood >>>> >>>> >>>> ltx wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I'm trying to build a basic Fedora 8 livecd to use as >>>>> a vehicle to flash a card I am working on. The flash >>>>> utility works from linux running from the hard drive >>>>> so that is not a concern at the moment. >>>>> >>>>> My problem - I can't log in! The iso builds fine with >>>>> command; >>>>> >>>>> livecd-creator --config=./livecd-fedora-minimal.ks --fslabel=Fedora8 >>>>> >>>>> When I boot from it, or use qemu to test, I can't log into root >>>>> or another id that I create in the kiskstart file. I followed >>>>> the instructions at >>>>> http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo >>>>> which are great, but they even point out that the >>>>> livecd-fedora-minimal.ks >>>>> kickstart file found in /usr/share/livecd-tools will not let you >>>>> log in. >>>>> (unless you go to all full desktop environment - which I don't >>>>> need/want) >>>>> >>>>> I noticed that the minimal kickstart file disabled the root id, >>>>> so I removed that and scoured the net and found that kickstart >>>>> command >>>>> rootpw allows you to set the root password. That gave me some >>>>> progress. Now when I try to log in to root I get these messages; >>>>> >>>>> Last login: time date... >>>>> Welcome to my world (this is what I put in /etc/motd) >>>>> login: no shell: Permission denied. >>>>> >>>>> So, several questions: >>>>> >>>>> 1 - What is wrong with my kickstart file (below) that prevents >>>>> me from logging in? >>>>> >>>>> 2 - Is there any collections of kickstart files available (other than >>>>> those that come with the livecd-tools packages? >>>>> >>>>> 3 - Where can I find the kickstart file options documented? >>>>> >>>>> Oh, my build environment is Fedora 8 (x86_64) with all the latest >>>>> updates. I point to the x86 mirrors so I can use the CD on older >>>>> machines. >>>>> >>>>> I'd appreciate any help you can offer. >>>>> >>>>> Thanks. >>>>> Jerry >>>>> >>>>> >>>>> lang en_US.UTF-8 >>>>> keyboard us >>>>> timezone US/Eastern >>>>> #auth --useshadow --enablemd5 >>>>> selinux --disabled >>>>> firewall --disabled >>>>> firstboot --disable >>>>> #root password >>>>> rootpw emulex >>>>> part / --size 1024 >>>>> >>>>> repo --name=released >>>>> --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=i386 >>>>> >>>>> repo --name=updates >>>>> --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f8&arch=i386 >>>>> >>>>> >>>>> %packages >>>>> @core >>>>> bash >>>>> kernel >>>>> passwd >>>>> policycoreutils >>>>> chkconfig >>>>> authconfig >>>>> rootfiles >>>>> >>>>> %post >>>>> # FIXME: it'd be better to get this installed from a package >>>>> cat > /etc/rc.d/init.d/fedora-live << EOF >>>>> #!/bin/bash >>>>> # >>>>> # live: Init script for live image >>>>> # >>>>> # chkconfig: 345 00 99 >>>>> # description: Init script for live image. >>>>> >>>>> . /etc/init.d/functions >>>>> >>>>> if ! strstr "\`cat /proc/cmdline\`" liveimg || [ "\$1" != "start" >>>>> ] || [ -e /.liveimg-configured ] ; then >>>>> exit 0 >>>>> fi >>>>> >>>>> exists() { >>>>> which \$1 >/dev/null 2>&1 || return >>>>> \$* >>>>> } >>>>> >>>>> touch /.liveimg-configured >>>>> >>>>> # mount live image >>>>> if [ -b /dev/live ]; then >>>>> mkdir -p /mnt/live >>>>> mount -o ro /dev/live /mnt/live >>>>> fi >>>>> >>>>> # add a user >>>>> useradd -c "Jerry" jerry >>>>> echo 'password' | passwd --stdin jerry >>>>> >>>>> # read some variables out of /proc/cmdline >>>>> for o in \`cat /proc/cmdline\` ; do >>>>> case \$o in >>>>> ks=*) >>>>> ks="\${o#ks=}" >>>>> ;; >>>>> xdriver=*) >>>>> xdriver="--set-driver=\${o#xdriver=}" >>>>> ;; >>>>> esac >>>>> done >>>>> >>>>> # Stopgap fix for RH #217966; should be fixed in HAL instead >>>>> touch /media/.hal-mtab >>>>> EOF >>>>> >>>>> chmod 755 /etc/rc.d/init.d/fedora-live >>>>> #/sbin/restorecon /etc/rc.d/init.d/fedora-live >>>>> /sbin/chkconfig --add fedora-live >>>>> >>>>> echo "Welcome to my world" > /etc/motd >>>>> >>>>> %end >>>>> >>>>> >>>>> -- >>>>> 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 > -- _________________________________ Tim Wood, CLP, RHCT 719.338.7484 (tel) The Data Wranglers Web, Database & more since since 1994 www.datawranglers.com From ltx at charter.net Sun Feb 3 04:18:21 2008 From: ltx at charter.net (Jerry) Date: Sat, 02 Feb 2008 23:18:21 -0500 Subject: [Fedora-livecd-list] live fedora 8 cd - login: no shell: Permission denied In-Reply-To: <47A53ECF.8090408@datawranglers.com> References: <47A512D2.4050106@charter.net> <47A52AE4.2060009@datawranglers.com> <47A52E6D.6030102@charter.net> <47A5317C.90508@datawranglers.com> <47A53594.4040004@charter.net> <47A53ECF.8090408@datawranglers.com> Message-ID: <47A5408D.70305@charter.net> Thanks. I'll give it a try tomorrow. I've had enough for today :-) Thanks for your help. Jerry Tim Wood wrote: > FWIW... be very careful when doing what I just suggested. And, just in > case, do the following (just in case). Open a terminal window. su (to > root). make a backup of /etc/password somewhere else. Leave that > window open. Open a new terminal window and build your LiveCD. Then, > if the kickstart causes your system (rather than the livecd's) > /etc/password to be overwritten, you'll still have a root window open > and you _should_ be able to copy back the backup. At a worst case > scenario, you can boot off of a livecd and restore the backup of > /etc/password. > > Tim Wood > > > ltx wrote: >> >> Yeah, I can't seem to find any docs that mention what the >> password is. >> >> I did put the rootpw line in and it does appear that the >> log in works since I get the 'Last Login' message and >> I get the message from /etc/motd, but then it complains >> that there is 'no shell: Permission denied' >> >> Jerry >> >> Tim Wood wrote: >>> Good question that I don't have the answer to. Since I always >>> forget, I started overiding it by adding this to the kickstart: >>> >>> # Set root password >>> rootpw iamroot >>> >>> If it's not a space issue, modify /etc/inittab during post and change >>> the runlevel from 5 to 3. If /etc/inittab doesn't make sense to you, >>> post again and I'll copy and paste the particular line. >>> >>> Tim >>> >>> >>> >>> ltx wrote: >>>> >>>> Hi Tim, >>>> >>>> Thanks for the quick reply. I was hoping to avoid all the >>>> graphics since this is more for utility work and will be >>>> booted often. >>>> >>>> Even if I went to the KDE desktop kickstart file what would >>>> the root password be? >>>> >>>> Thanks. >>>> Jerry >>>> >>>> Tim Wood wrote: >>>>> One 'feature' of the minimal is that login is disabled. The kde >>>>> desktop is a good starter. >>>>> >>>>> Tim Wood >>>>> >>>>> >>>>> ltx wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I'm trying to build a basic Fedora 8 livecd to use as >>>>>> a vehicle to flash a card I am working on. The flash >>>>>> utility works from linux running from the hard drive >>>>>> so that is not a concern at the moment. >>>>>> >>>>>> My problem - I can't log in! The iso builds fine with >>>>>> command; >>>>>> >>>>>> livecd-creator --config=./livecd-fedora-minimal.ks --fslabel=Fedora8 >>>>>> >>>>>> When I boot from it, or use qemu to test, I can't log into root >>>>>> or another id that I create in the kiskstart file. I followed >>>>>> the instructions at >>>>>> http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo >>>>>> which are great, but they even point out that the >>>>>> livecd-fedora-minimal.ks >>>>>> kickstart file found in /usr/share/livecd-tools will not let you >>>>>> log in. >>>>>> (unless you go to all full desktop environment - which I don't >>>>>> need/want) >>>>>> >>>>>> I noticed that the minimal kickstart file disabled the root id, >>>>>> so I removed that and scoured the net and found that kickstart >>>>>> command >>>>>> rootpw allows you to set the root password. That gave me some >>>>>> progress. Now when I try to log in to root I get these messages; >>>>>> >>>>>> Last login: time date... >>>>>> Welcome to my world (this is what I put in /etc/motd) >>>>>> login: no shell: Permission denied. >>>>>> >>>>>> So, several questions: >>>>>> >>>>>> 1 - What is wrong with my kickstart file (below) that prevents >>>>>> me from logging in? >>>>>> >>>>>> 2 - Is there any collections of kickstart files available (other than >>>>>> those that come with the livecd-tools packages? >>>>>> >>>>>> 3 - Where can I find the kickstart file options documented? >>>>>> >>>>>> Oh, my build environment is Fedora 8 (x86_64) with all the latest >>>>>> updates. I point to the x86 mirrors so I can use the CD on older >>>>>> machines. >>>>>> >>>>>> I'd appreciate any help you can offer. >>>>>> >>>>>> Thanks. >>>>>> Jerry >>>>>> >>>>>> >>>>>> lang en_US.UTF-8 >>>>>> keyboard us >>>>>> timezone US/Eastern >>>>>> #auth --useshadow --enablemd5 >>>>>> selinux --disabled >>>>>> firewall --disabled >>>>>> firstboot --disable >>>>>> #root password >>>>>> rootpw emulex >>>>>> part / --size 1024 >>>>>> >>>>>> repo --name=released >>>>>> --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=i386 >>>>>> >>>>>> repo --name=updates >>>>>> --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f8&arch=i386 >>>>>> >>>>>> >>>>>> %packages >>>>>> @core >>>>>> bash >>>>>> kernel >>>>>> passwd >>>>>> policycoreutils >>>>>> chkconfig >>>>>> authconfig >>>>>> rootfiles >>>>>> >>>>>> %post >>>>>> # FIXME: it'd be better to get this installed from a package >>>>>> cat > /etc/rc.d/init.d/fedora-live << EOF >>>>>> #!/bin/bash >>>>>> # >>>>>> # live: Init script for live image >>>>>> # >>>>>> # chkconfig: 345 00 99 >>>>>> # description: Init script for live image. >>>>>> >>>>>> . /etc/init.d/functions >>>>>> >>>>>> if ! strstr "\`cat /proc/cmdline\`" liveimg || [ "\$1" != "start" >>>>>> ] || [ -e /.liveimg-configured ] ; then >>>>>> exit 0 >>>>>> fi >>>>>> >>>>>> exists() { >>>>>> which \$1 >/dev/null 2>&1 || return >>>>>> \$* >>>>>> } >>>>>> >>>>>> touch /.liveimg-configured >>>>>> >>>>>> # mount live image >>>>>> if [ -b /dev/live ]; then >>>>>> mkdir -p /mnt/live >>>>>> mount -o ro /dev/live /mnt/live >>>>>> fi >>>>>> >>>>>> # add a user >>>>>> useradd -c "Jerry" jerry >>>>>> echo 'password' | passwd --stdin jerry >>>>>> >>>>>> # read some variables out of /proc/cmdline >>>>>> for o in \`cat /proc/cmdline\` ; do >>>>>> case \$o in >>>>>> ks=*) >>>>>> ks="\${o#ks=}" >>>>>> ;; >>>>>> xdriver=*) >>>>>> xdriver="--set-driver=\${o#xdriver=}" >>>>>> ;; >>>>>> esac >>>>>> done >>>>>> >>>>>> # Stopgap fix for RH #217966; should be fixed in HAL instead >>>>>> touch /media/.hal-mtab >>>>>> EOF >>>>>> >>>>>> chmod 755 /etc/rc.d/init.d/fedora-live >>>>>> #/sbin/restorecon /etc/rc.d/init.d/fedora-live >>>>>> /sbin/chkconfig --add fedora-live >>>>>> >>>>>> echo "Welcome to my world" > /etc/motd >>>>>> >>>>>> %end >>>>>> >>>>>> >>>>>> -- >>>>>> 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 fedoraproject.org Mon Feb 4 16:39:59 2008 From: katzj at fedoraproject.org (Jeremy Katz) Date: Mon, 4 Feb 2008 09:39:59 -0700 Subject: [Fedora-livecd-list] 2 commits - config/livecd-fedora-8-base-desktop.ks config/livecd-fedora-desktop.ks Message-ID: <200802041639.m14Gdxms005411@hosted1.fedoraproject.org> config/livecd-fedora-8-base-desktop.ks | 1 + config/livecd-fedora-desktop.ks | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) New commits: commit ade8a8c33a6e3051ec9bf48d0bacdd1475a2aed5 Author: Jeremy Katz Date: Mon Feb 4 11:28:59 2008 -0500 ensure liveos dir exists (#431287) diff --git a/config/livecd-fedora-8-base-desktop.ks b/config/livecd-fedora-8-base-desktop.ks index 199093f..2cf42b5 100644 --- a/config/livecd-fedora-8-base-desktop.ks +++ b/config/livecd-fedora-8-base-desktop.ks @@ -172,6 +172,7 @@ cp $INSTALL_ROOT/usr/share/doc/HTML/readme-live-image/en_US/readme-live-image-en # only works on x86, x86_64 if [ "$(uname -i)" = "i386" -o "$(uname -i)" = "x86_64" ]; then + if [ ! -d $LIVE_ROOT/LiveOS ]; then mkdir -p $LIVE_ROOT/LiveOS ; fi cp /usr/bin/livecd-iso-to-disk $LIVE_ROOT/LiveOS fi %end commit 37900892e214169fffcb61da25800fe26e4aa507 Author: Jeremy Katz Date: Thu Jan 31 10:08:43 2008 -0500 Fix up package name diff --git a/config/livecd-fedora-desktop.ks b/config/livecd-fedora-desktop.ks index 444d655..2738126 100644 --- a/config/livecd-fedora-desktop.ks +++ b/config/livecd-fedora-desktop.ks @@ -125,7 +125,7 @@ gnome-blog # more fun with space saving -scim-lang-chinese scim-chewing -scim-chinese-pinyin +scim-pinyin # save some space -gnome-user-docs From asheesh at creativecommons.org Mon Feb 4 18:47:22 2008 From: asheesh at creativecommons.org (Asheesh Laroia) Date: Mon, 4 Feb 2008 10:47:22 -0800 (PST) Subject: [Fedora-livecd-list] Adding data to the generated ISO image Message-ID: I have a directory that I'd like to be available on the generated Live CD ISO and accessible to people who put the CD into their machines, even without running the actual Fedora live image. Does livecd-creator offer an option to stick data into the ISO toward the end of the process? (I did take a look and didn't find such an option.) If not, what would be a good way to make this happen? Thanks! -- Asheesh. -- Life is a whim of several billion cells to be you for a while. From jkeating at redhat.com Mon Feb 4 13:51:01 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Feb 2008 08:51:01 -0500 Subject: [Fedora-livecd-list] Adding data to the generated ISO image In-Reply-To: References: Message-ID: <20080204085101.584819ed@redhat.com> On Mon, 4 Feb 2008 10:47:22 -0800 (PST) Asheesh Laroia wrote: > Does livecd-creator offer an option to stick data into the ISO toward > the end of the process? (I did take a look and didn't find such an > option.) If not, what would be a good way to make this happen? Use %post in your kickstart script do accomplish this. -- 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 asheesh at creativecommons.org Mon Feb 4 19:01:20 2008 From: asheesh at creativecommons.org (Asheesh Laroia) Date: Mon, 4 Feb 2008 11:01:20 -0800 (PST) Subject: [Fedora-livecd-list] Adding data to the generated ISO image In-Reply-To: <20080204085101.584819ed@redhat.com> References: <20080204085101.584819ed@redhat.com> Message-ID: On Mon, 4 Feb 2008, Jesse Keating wrote: > On Mon, 4 Feb 2008 10:47:22 -0800 (PST) Asheesh Laroia > wrote: > >> Does livecd-creator offer an option to stick data into the ISO toward >> the end of the process? (I did take a look and didn't find such an >> option.) If not, what would be a good way to make this happen? > > Use %post in your kickstart script do accomplish this. But won't that get put in the squashfs? If not, then I don't understand something - maybe you can explain. If so, then that's not what I want - I want the data to be available outside the squashfs to e.g. Windows users that load the CD/DVD. In the case that I can't add files to the ISO (outside the squashfs) from the .ks, looking at the way package() is implemented, would you accept a patch that adds a command-line argument that turns package from: def package(self): self.createSquashFS() self.createIso() self.implantIsoMD5() into def package(self): self.createSquashFS() self.addFilesToIso() self.createIso() self.implantIsoMD5() where addFilesToIso() looks at a command-line argument and merges a directory's contents with the build_dir before the mkisofs is run in createIso()? That way, you could add files to the ISO outside the squashfs the way I'm saying I want. (But if this is possible in the .ks, then please enlighten me.) -- Asheesh. -- <|Rain|> #define struct union /* great space saver */ From katzj at redhat.com Mon Feb 4 19:03:00 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Feb 2008 14:03:00 -0500 Subject: [Fedora-livecd-list] Adding data to the generated ISO image In-Reply-To: References: <20080204085101.584819ed@redhat.com> Message-ID: <1202151780.26123.12.camel@aglarond.local> On Mon, 2008-02-04 at 11:01 -0800, Asheesh Laroia wrote: > On Mon, 4 Feb 2008, Jesse Keating wrote: > > On Mon, 4 Feb 2008 10:47:22 -0800 (PST) Asheesh Laroia > > wrote: > > > >> Does livecd-creator offer an option to stick data into the ISO toward > >> the end of the process? (I did take a look and didn't find such an > >> option.) If not, what would be a good way to make this happen? > > > > Use %post in your kickstart script do accomplish this. > > But won't that get put in the squashfs? Not if you use --nochroot. See the F8 configs for an example Jeremy From rjones at redhat.com Mon Feb 4 19:05:24 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 04 Feb 2008 19:05:24 +0000 Subject: [Fedora-livecd-list] Virt-p2v live CD, comments and packaging Message-ID: <47A761F4.10204@redhat.com> Virt-p2v is a physical-to-virtual migration tool, for turning physical computers into virtual machines running under some virtualization environment like Xen. The tool is packaged as a live CD, based on a Fedora 8 distribution, and using livecd-creator to build the ISO. Main page: http://et.redhat.com/~rjones/virt-p2v/ Source repo: http://hg.et.redhat.com/virt/applications/virt-p2v--devel I'm posting here to see if anyone has any comments about the way I did this live CD. The kickstart script uses a rather complex %post section, which adds a few files to the filesystem, instead of building RPMs or modifying existing RPMs. I've also investigated how to attach stuff to the end of the ISO image, and the way I've come up with allows me to update an ISO with a new script quite easily, and much more quickly than waiting for livecd-creator to rerun. This great (a) for rapid development and (b) to send new updates to users without forcing them to download another 170 MB ISO. I'd like to package this for Fedora. Obviously I don't want to package the binary live CD, but instead package the kickstart file and some tools to allow people to easily build custom live CDs. If anyone has any ideas or examples of this I'd be interested to hear. Thanks, Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From asheesh at creativecommons.org Mon Feb 4 19:11:09 2008 From: asheesh at creativecommons.org (Asheesh Laroia) Date: Mon, 4 Feb 2008 11:11:09 -0800 (PST) Subject: [Fedora-livecd-list] Adding data to the generated ISO image In-Reply-To: <1202151780.26123.12.camel@aglarond.local> References: <20080204085101.584819ed@redhat.com> <1202151780.26123.12.camel@aglarond.local> Message-ID: On Mon, 4 Feb 2008, Jeremy Katz wrote: > Not if you use --nochroot. See the F8 configs for an example Wow, that's elegant. Thanks. (-: -- Asheesh. -- anyone seen my 80 column card? From katzj at redhat.com Mon Feb 4 21:14:17 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Feb 2008 16:14:17 -0500 Subject: [Fedora-livecd-list] Re: Review? LiveUSB persistence In-Reply-To: <47A247A1.1040702@filteredperception.org> References: <47A247A1.1040702@filteredperception.org> Message-ID: <1202159657.26123.37.camel@aglarond.local> Moving to the more appropriate list, original is at https://www.redhat.com/archives/fedora-devel-list/2008-January/msg03188.html for those not on fedora-devel On Thu, 2008-01-31 at 16:11 -0600, Douglas McClendon wrote: > I keep hearing these crazy rumors that RedHat actually wants to subject > actual users to my LiveUSB persistence feature next/this month. Lots of people want lots of different things. I've definitely left this sitting hanging too long and I apologize. I just didn't have time to poke over the holidays and my January was a bitty nutty. But I should be back to just my normal mail lag now ;-) > I for one think the feature is really cool, useful, and know of no > showstopping or even known bugs. But I also would not subject actual > users to it, without having had more people review it and sign off on > it. Anyway, to absolve myself of any responsibility, I once again > request code review and feedback- Overall, I think that it looks good. I think the big thing to work out is how best to integrate the initscripts changes. Especially as we're in parallel switching things over to upstart for F9. Just to make sure that I'm clear about what's there so that when we try to bribe Bill, we can do so effectively... * The unmount loops in /etc/init.d/functions are modified so that we don't unmount the underlying fs of the overlay * We don't want to sync the hwclock on shutdown of a live image * Do an overlay teardown on halt to replace the rw snapshot with a ro version The latter feels like we're going to want a generic hook to be able to run, perhaps from back in the initramfs. The middle feels largely unrelated to persistence in general, but just a "needs fixing" which will fit in nicely with other hwclock changes that are underway in rawhide. And the first I'm less clear on I guess. Outside of those changes, everything looks pretty straight-forward and reasonable. We'll want a little more error checking in livecd-iso-to-disk and it might also be nice to have another tool that lets you create your usb stick to use with the actual cd form (I did this by hand and it was pretty nice that I could easily get it working!). As for the findoverlay bits, for right now, leaving them as a separate script is fine. In the longer term, we're hopefully going to kill mayflower and be able to use more "normal" initrds[1], at which point pulling it in more directly would be nice. As far as reliability... shutting down cleanly, I can't cause a problem. I pulled the usb stick from a box and got some garbage in a file I had written. I want to do some more playing here, but I also wanted to get this mail out today. Worst case, if we say "you need to shut down cleanly", then so be it. It might be nice if we flag clean vs not shutdown so that we can force a fsck in unclean cases. But no clue if that's even feasible; I'll take a look, though. Jeremy [1] One mkinitrd to rule them all... :) From katzj at redhat.com Mon Feb 4 22:21:53 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Feb 2008 17:21:53 -0500 Subject: [Fedora-livecd-list] Virt-p2v live CD, comments and packaging In-Reply-To: <47A761F4.10204@redhat.com> References: <47A761F4.10204@redhat.com> Message-ID: <1202163713.26123.43.camel@aglarond.local> On Mon, 2008-02-04 at 19:05 +0000, Richard W.M. Jones wrote: > I'm posting here to see if anyone has any comments about the way I did > this live CD. The kickstart script uses a rather complex %post section, > which adds a few files to the filesystem, instead of building RPMs or > modifying existing RPMs. >From a maintainability point of view, you're going to be happier in the long run if you actually package up things into RPMs as opposed to just concatenating piles of scripts. I've already gotten pretty frustrated with just the initscript we're using in the desktop case on a few occasions. > I've also investigated how to attach stuff to the end of the ISO image, > and the way I've come up with allows me to update an ISO with a new > script quite easily, and much more quickly than waiting for > livecd-creator to rerun. This great (a) for rapid development and (b) > to send new updates to users without forcing them to download another > 170 MB ISO. Ewwww :) Jeremy From dmc.fedora at filteredperception.org Mon Feb 4 23:34:54 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 04 Feb 2008 17:34:54 -0600 Subject: [Fedora-livecd-list] Re: Review? LiveUSB persistence In-Reply-To: <1202159657.26123.37.camel@aglarond.local> References: <47A247A1.1040702@filteredperception.org> <1202159657.26123.37.camel@aglarond.local> Message-ID: <47A7A11E.5030008@filteredperception.org> Jeremy Katz wrote: > Moving to the more appropriate list, original is at > https://www.redhat.com/archives/fedora-devel-list/2008-January/msg03188.html for those not on fedora-devel > > On Thu, 2008-01-31 at 16:11 -0600, Douglas McClendon wrote: >> I keep hearing these crazy rumors that RedHat actually wants to subject >> actual users to my LiveUSB persistence feature next/this month. > > Lots of people want lots of different things. I've definitely left this > sitting hanging too long and I apologize. I just didn't have time to > poke over the holidays and my January was a bitty nutty. But I should > be back to just my normal mail lag now ;-) > >> I for one think the feature is really cool, useful, and know of no >> showstopping or even known bugs. But I also would not subject actual >> users to it, without having had more people review it and sign off on >> it. Anyway, to absolve myself of any responsibility, I once again >> request code review and feedback- > > Overall, I think that it looks good. I think the big thing to work out > is how best to integrate the initscripts changes. Especially as we're > in parallel switching things over to upstart for F9. Just to make sure > that I'm clear about what's there so that when we try to bribe Bill, we > can do so effectively... > * The unmount loops in /etc/init.d/functions are modified so that we > don't unmount the underlying fs of the overlay Correct. And the method currently in use is adding any subcomponents of the rootfs to /dev/.fstab.live.special. I chose that location just because it is available from both the initramfs and then later during shutdown. > * We don't want to sync the hwclock on shutdown of a live image > * Do an overlay teardown on halt to replace the rw snapshot with a ro > version Yup, basically the old phase of 'remount rootfs readonly' just gets quite a bit more complicated, but still essentially just that. > The latter feels like we're going to want a generic hook to be able to > run, perhaps from back in the initramfs. The middle feels largely > unrelated to persistence in general, but just a "needs fixing" which > will fit in nicely with other hwclock changes that are underway in > rawhide. And the first I'm less clear on I guess. > > Outside of those changes, everything looks pretty straight-forward and > reasonable. We'll want a little more error checking in > livecd-iso-to-disk and it might also be nice to have another tool that > lets you create your usb stick to use with the actual cd form (I did > this by hand and it was pretty nice that I could easily get it > working!). As for the findoverlay bits, for right now, leaving them as > a separate script is fine. In the longer term, we're hopefully going to > kill mayflower and be able to use more "normal" initrds[1], at which > point pulling it in more directly would be nice. I have no preference where the code lives. The main thing I would highlight is how originally I wrote findoverlay, with the mindset that the overlay file/layer could be located anywhere. But then, to focus on getting something really usable, I honed in on the assumption of the overlay file living together with the LiveOS on a LiveUSB. As a result the findoverlay script definitely does not look like entirely grade A code right now. But I have no objection to it getting merged in any form, and perhaps later having cleanup/refactoring passes, perhaps with even later passes that add back the functionality I originally had in mind. > As far as reliability... shutting down cleanly, I can't cause a problem. > I pulled the usb stick from a box and got some garbage in a file I had > written. I want to do some more playing here, but I also wanted to get > this mail out today. Worst case, if we say "you need to shut down > cleanly", then so be it. It might be nice if we flag clean vs not > shutdown so that we can force a fsck in unclean cases. But no clue if > that's even feasible; I'll take a look, though. My vague understanding right now would that it would be treated just like a normal rootfs. I.e. the same things happening if it is flagged as dirty, as if a normal system. But... I guess then there is the issue of fscking the host filesystem, e.g. vfat(ext3?) of the LiveUSB. Ugh. One immediate enhancement I thought of, is that perhaps the interface for initialization can be taken out of livecd-iso-to-disk, and put into the initramfs. I.e. a new kernel cmdline parameter of "initoverlay=256MB" would just invoke the dd if=/dev/zero... during that boot. Maybe even a default value that just uses half the free space on the LiveUSB. Thus perhaps livecd-iso-to-disk just by default adds another couple menu entries to syslinux, one for 'boot with persistence' and one for 'initialize persistence'. Or perhaps the former automatically initializes if none is found, and the latter, or some post-boot system command could 'reinitialize persistence'... -dmc From asheesh at creativecommons.org Mon Feb 4 23:49:44 2008 From: asheesh at creativecommons.org (Asheesh Laroia) Date: Mon, 4 Feb 2008 15:49:44 -0800 (PST) Subject: [Fedora-livecd-list] Making content available on both sides of the live CD Message-ID: I was talking earlier about putting content on the ISO to be read by e.g. Windows users. If I want to make that content available in the live Fedora system also, what's the best way to do that? What I'm after is a directory on the live Fedora desktop that doesn't waste space but shows the same content as the There were a couple of "obvious" ways I could think of, which I'll refer to by one would achieve them: * mount --bind /media/cdrom/my_directory /home/liveuser/Desktop/my_directory * ln -s /media/cdrom/my_directory /home/liveuser/Desktop/my_directory Both these can only expose the content read-only, which is acceptable but less than amazing. * have a unionfs/aufs mount that exposes the ISO's content and lets users write using "copy-up" semantics The downside of unionfs is that it adds complications. Given these choices, I'd go for the symlink. Is that what you guys would do? Is there something I'm missing? One used to be able to make "hybrid CDs" (c.f. http://en.wikipedia.org/wiki/Hybrid_CD ) that shared data between the HFS filesystems and ISO9660 filesystems on them, but I imagine that's not possible for the ISO9660 filesystem at the base of the LiveCD-Creator disc and the squashfs inside it - right? Thanks for the quick and sharp replies! -- Asheesh. -- A witty saying proves nothing. -- Voltaire From tim.wood at datawranglers.com Tue Feb 5 00:37:41 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Mon, 04 Feb 2008 17:37:41 -0700 Subject: [Fedora-livecd-list] Re: Virt-p2v live CD, comments and packaging In-Reply-To: <1202163713.26123.43.camel@aglarond.local> References: <47A761F4.10204@redhat.com> <1202163713.26123.43.camel@aglarond.local> Message-ID: <47A7AFD5.2090303@datawranglers.com> As a not-quite-counter argument, I've found that if each change is small (e.g. three sed commands to tweak a config), a longer kickstart can make a lot of sense. Beyond short stuff, I will agree completely with Jeremy. RPMs are not too hard to pull off if you have a little patience on the first one. Guru labs has a nice tutorial you can google (the examples are google-able, too ... they just arn't in the same place) On embedding stuff in the kickstart, one suggestion. Use some sort of really really obvious delimiter and extra white space between each chunk (see the example below). I've got a kickstart that tweaks a bunch of odds & ends in %post and this approached has saved my sanity and made maintenance and improvement much easier. Tim Wood ############################## # # tweak the config for foo [some lines] ############################## # # copy the files for bar [some lines] Jeremy Katz wrote: > On Mon, 2008-02-04 at 19:05 +0000, Richard W.M. Jones wrote: > >> I'm posting here to see if anyone has any comments about the way I did >> this live CD. The kickstart script uses a rather complex %post section, >> which adds a few files to the filesystem, instead of building RPMs or >> modifying existing RPMs. >> > > >From a maintainability point of view, you're going to be happier in the > long run if you actually package up things into RPMs as opposed to just > concatenating piles of scripts. I've already gotten pretty frustrated > with just the initscript we're using in the desktop case on a few > occasions. > > >> I've also investigated how to attach stuff to the end of the ISO image, >> and the way I've come up with allows me to update an ISO with a new >> script quite easily, and much more quickly than waiting for >> livecd-creator to rerun. This great (a) for rapid development and (b) >> to send new updates to users without forcing them to download another >> 170 MB ISO. >> > > Ewwww :) > > Jeremy > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > -- _________________________________ Tim Wood, CLP, RHCT 719.338.7484 (tel) The Data Wranglers Web, Database & more since since 1994 www.datawranglers.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.wood at datawranglers.com Tue Feb 5 00:41:39 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Mon, 04 Feb 2008 17:41:39 -0700 Subject: [Fedora-livecd-list] Making content available on both sides of the live CD In-Reply-To: References: Message-ID: <47A7B0C3.9050306@datawranglers.com> I think you're looking for something like this. If bob had a file called 'my_file.html' in his home directory, he'd do this to copy it to the root of the cd: %post --nochroot cp /home/bob/my_file.html $LIVE_ROOT/ fwiw, we had a more thorough discussion of this about a week ago on the list. Tim Asheesh Laroia wrote: > I was talking earlier about putting content on the ISO to be read by > e.g. Windows users. If I want to make that content available in the > live Fedora system also, what's the best way to do that? > > What I'm after is a directory on the live Fedora desktop that doesn't > waste space but shows the same content as the > > There were a couple of "obvious" ways I could think of, which I'll > refer to by one would achieve them: > > * mount --bind /media/cdrom/my_directory > /home/liveuser/Desktop/my_directory > > * ln -s /media/cdrom/my_directory /home/liveuser/Desktop/my_directory > > Both these can only expose the content read-only, which is acceptable > but less than amazing. > > * have a unionfs/aufs mount that exposes the ISO's content and lets > users write using "copy-up" semantics > > The downside of unionfs is that it adds complications. > > Given these choices, I'd go for the symlink. Is that what you guys > would do? Is there something I'm missing? > > One used to be able to make "hybrid CDs" (c.f. > http://en.wikipedia.org/wiki/Hybrid_CD ) that shared data between the > HFS filesystems and ISO9660 filesystems on them, but I imagine that's > not possible for the ISO9660 filesystem at the base of the > LiveCD-Creator disc and the squashfs inside it - right? > > Thanks for the quick and sharp replies! > > -- Asheesh. > -- _________________________________ Tim Wood, CLP, RHCT 719.338.7484 (tel) The Data Wranglers Web, Database & more since since 1994 www.datawranglers.com From asheesh at creativecommons.org Tue Feb 5 00:47:59 2008 From: asheesh at creativecommons.org (Asheesh Laroia) Date: Mon, 4 Feb 2008 16:47:59 -0800 (PST) Subject: [Fedora-livecd-list] Making content available on both sides of the live CD In-Reply-To: <47A7B0C3.9050306@datawranglers.com> References: <47A7B0C3.9050306@datawranglers.com> Message-ID: On Mon, 4 Feb 2008, Tim Wood wrote: > I think you're looking for something like this. If bob had a file > called 'my_file.html' in his home directory, he'd do this to copy it to > the root of the cd: > > %post --nochroot > cp /home/bob/my_file.html $LIVE_ROOT/ Right - but if we're talking about gigabytes of photos and music, then that's less than ideal space-wise. Hence my bringing up Hybrid CDs. > fwiw, we had a more thorough discussion of this about a week ago on the list. Taking a look at https://www.redhat.com/archives/fedora-livecd-list/2008-February/thread.html and https://www.redhat.com/archives/fedora-livecd-list/2008-January/thread.html doesn't find anything obviously relevant to me - sorry if I'm just missing something. -- Asheesh. -- Hurewitz's Memory Principle: The chance of forgetting something is directly proportional to... to... uh..... From tim.wood at datawranglers.com Tue Feb 5 00:51:18 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Mon, 04 Feb 2008 17:51:18 -0700 Subject: [Fedora-livecd-list] Making content available on both sides of the live CD In-Reply-To: References: <47A7B0C3.9050306@datawranglers.com> Message-ID: <47A7B306.2030709@datawranglers.com> That's what I get for replying to emails when my brain is fried ;-) Tim Asheesh Laroia wrote: > On Mon, 4 Feb 2008, Tim Wood wrote: > >> I think you're looking for something like this. If bob had a file >> called 'my_file.html' in his home directory, he'd do this to copy it >> to the root of the cd: >> >> %post --nochroot >> cp /home/bob/my_file.html $LIVE_ROOT/ > > Right - but if we're talking about gigabytes of photos and music, then > that's less than ideal space-wise. Hence my bringing up Hybrid CDs. > >> fwiw, we had a more thorough discussion of this about a week ago on >> the list. > > Taking a look at > https://www.redhat.com/archives/fedora-livecd-list/2008-February/thread.html > and > https://www.redhat.com/archives/fedora-livecd-list/2008-January/thread.html > doesn't find anything obviously relevant to me - sorry if I'm just > missing something. > > -- Asheesh. > -- _________________________________ Tim Wood, CLP, RHCT 719.338.7484 (tel) The Data Wranglers Web, Database & more since since 1994 www.datawranglers.com From dmc.fedora at filteredperception.org Tue Feb 5 00:51:51 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 04 Feb 2008 18:51:51 -0600 Subject: [Fedora-livecd-list] Re: Review? LiveUSB persistence In-Reply-To: <1202159657.26123.37.camel@aglarond.local> References: <47A247A1.1040702@filteredperception.org> <1202159657.26123.37.camel@aglarond.local> Message-ID: <47A7B327.3090801@filteredperception.org> Jeremy Katz wrote: > > Outside of those changes, everything looks pretty straight-forward and > reasonable. We'll want a little more error checking in > livecd-iso-to-disk and it might also be nice to have another tool that > lets you create your usb stick to use with the actual cd form (I did > this by hand and it was pretty nice that I could easily get it > working!). I didn't really slow down and read this bit at first- So you actually used the livecd+usb form? I probably tried that once when I first wrote the code, but haven't even considered it since then. I guess you must have by hand added something like overlay=UUID=bla to the kernel cmdline. Of course the original incarnation of the patch supported the syntax overlay=auto which would scan all drives. But that code scares my responsibility-averse nature, and I was happy to remove it when focusing on the liveusb case. And also there was a bunch of related bash junk for dealing with finding multiple overlays. -dmc -dmc From dmc.fedora at filteredperception.org Tue Feb 5 00:58:29 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 04 Feb 2008 18:58:29 -0600 Subject: [Fedora-livecd-list] Making content available on both sides of the live CD In-Reply-To: References: <47A7B0C3.9050306@datawranglers.com> Message-ID: <47A7B4B5.8090509@filteredperception.org> Asheesh Laroia wrote: > On Mon, 4 Feb 2008, Tim Wood wrote: > >> I think you're looking for something like this. If bob had a file >> called 'my_file.html' in his home directory, he'd do this to copy it >> to the root of the cd: >> >> %post --nochroot >> cp /home/bob/my_file.html $LIVE_ROOT/ > > Right - but if we're talking about gigabytes of photos and music, then > that's less than ideal space-wise. Hence my bringing up Hybrid CDs. So it sounds like you really want your gigabytes to be on the HFS side of the *DVD* right? That certainly isn't supported at the moment, though I suppose could be made to work. (I have no idea what a hybrid looks like (automounting and such) to the system currently). >> fwiw, we had a more thorough discussion of this about a week ago on >> the list. > > Taking a look at > https://www.redhat.com/archives/fedora-livecd-list/2008-February/thread.html > and > https://www.redhat.com/archives/fedora-livecd-list/2008-January/thread.html > doesn't find anything obviously relevant to me - sorry if I'm just > missing something. > This may be the relevent post, but doesn't add too much- https://www.redhat.com/archives/fedora-livecd-list/2008-January/msg00080.html -dmc From asheesh at creativecommons.org Tue Feb 5 01:09:41 2008 From: asheesh at creativecommons.org (Asheesh Laroia) Date: Mon, 4 Feb 2008 17:09:41 -0800 (PST) Subject: [Fedora-livecd-list] Making content available on both sides of the live CD In-Reply-To: <47A7B4B5.8090509@filteredperception.org> References: <47A7B0C3.9050306@datawranglers.com> <47A7B4B5.8090509@filteredperception.org> Message-ID: On Mon, 4 Feb 2008, Douglas McClendon wrote: > Asheesh Laroia wrote: >> On Mon, 4 Feb 2008, Tim Wood wrote: >> >>> I think you're looking for something like this. If bob had a file called >>> 'my_file.html' in his home directory, he'd do this to copy it to the root >>> of the cd: >>> >>> %post --nochroot >>> cp /home/bob/my_file.html $LIVE_ROOT/ >> >> Right - but if we're talking about gigabytes of photos and music, then >> that's less than ideal space-wise. Hence my bringing up Hybrid CDs. > > So it sounds like you really want your gigabytes to be on the HFS side of the > *DVD* right? That certainly isn't supported at the moment, though I suppose > could be made to work. (I have no idea what a hybrid looks like > (automounting and such) to the system currently). Er, let me be clear - sorry! I don't actually want a Hybrid disc. I want the data to be available in the live Linux system, as well as Windows and OS X. Windows and OS X can read ISO9660 just fine, so there's no need for HFS. > This may be the relevent post, but doesn't add too much- > > https://www.redhat.com/archives/fedora-livecd-list/2008-January/msg00080.html Thanks - that is relevant, and now I feel silly for having asked the same question in a separate thread earlier today. (-: To ask a question that I think *hasn't* been asked: Let's say I want to store big files in the ISO and symlink them to the user's $HOME. What's the appropriate way to, as part of the bootup process, mount the DVD? I noticed that, upon booting the live system, "mount /dev/cdrom" simply told me that it /dev/cdrom wasn't in the fstab. The /dev/cdrom symlink was set properly, so I could just add /dev/cdrom to the fstab myself or issue a mount command from an init script. But is that really the right way to automatically mount the disc from which the live system is booting? -- Asheesh. -- Will the third world war keep "Bosom Buddies" off the air? From dmc.fedora at filteredperception.org Tue Feb 5 01:27:56 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 04 Feb 2008 19:27:56 -0600 Subject: [Fedora-livecd-list] Making content available on both sides of the live CD In-Reply-To: References: <47A7B0C3.9050306@datawranglers.com> <47A7B4B5.8090509@filteredperception.org> Message-ID: <47A7BB9C.8040308@filteredperception.org> Asheesh Laroia wrote: > On Mon, 4 Feb 2008, Douglas McClendon wrote: > >> Asheesh Laroia wrote: >>> On Mon, 4 Feb 2008, Tim Wood wrote: >>> >>>> I think you're looking for something like this. If bob had a file >>>> called 'my_file.html' in his home directory, he'd do this to copy it >>>> to the root of the cd: >>>> >>>> %post --nochroot >>>> cp /home/bob/my_file.html $LIVE_ROOT/ >>> >>> Right - but if we're talking about gigabytes of photos and music, >>> then that's less than ideal space-wise. Hence my bringing up Hybrid >>> CDs. >> >> So it sounds like you really want your gigabytes to be on the HFS side >> of the *DVD* right? That certainly isn't supported at the moment, >> though I suppose could be made to work. (I have no idea what a hybrid >> looks like (automounting and such) to the system currently). > > Er, let me be clear - sorry! > > I don't actually want a Hybrid disc. I want the data to be available in > the live Linux system, as well as Windows and OS X. Windows and OS X > can read ISO9660 just fine, so there's no need for HFS. > >> This may be the relevent post, but doesn't add too much- >> >> https://www.redhat.com/archives/fedora-livecd-list/2008-January/msg00080.html >> > > Thanks - that is relevant, and now I feel silly for having asked the > same question in a separate thread earlier today. (-: Don't worry, you are just bringing more attention to the need of better documentation. > To ask a question that I think *hasn't* been asked: > > Let's say I want to store big files in the ISO and symlink them to the > user's $HOME. What's the appropriate way to, as part of the bootup > process, mount the DVD? I noticed that, upon booting the live system, > "mount /dev/cdrom" simply told me that it /dev/cdrom wasn't in the > fstab. The /dev/cdrom symlink was set properly, so I could just add > /dev/cdrom to the fstab myself or issue a mount command from an init > script. But is that really the right way to automatically mount the > disc from which the live system is booting? I think the answer you are looking for is /mnt/live. It will be mounted, and refers to the cdrom iso9660, or the fs that hosts the LiveOS on a LiveUSB. -dmc From katzj at redhat.com Tue Feb 5 01:37:48 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Feb 2008 20:37:48 -0500 Subject: [Fedora-livecd-list] Making content available on both sides of the live CD In-Reply-To: <47A7BB9C.8040308@filteredperception.org> References: <47A7B0C3.9050306@datawranglers.com> <47A7B4B5.8090509@filteredperception.org> <47A7BB9C.8040308@filteredperception.org> Message-ID: <1202175468.26123.47.camel@aglarond.local> On Mon, 2008-02-04 at 19:27 -0600, Douglas McClendon wrote: > Asheesh Laroia wrote: > > To ask a question that I think *hasn't* been asked: > > > > Let's say I want to store big files in the ISO and symlink them to the > > user's $HOME. What's the appropriate way to, as part of the bootup > > process, mount the DVD? I noticed that, upon booting the live system, > > "mount /dev/cdrom" simply told me that it /dev/cdrom wasn't in the > > fstab. The /dev/cdrom symlink was set properly, so I could just add > > /dev/cdrom to the fstab myself or issue a mount command from an init > > script. But is that really the right way to automatically mount the > > disc from which the live system is booting? > > I think the answer you are looking for is /mnt/live. > > It will be mounted, and refers to the cdrom iso9660, or the fs that > hosts the LiveOS on a LiveUSB. Correct. /mnt/live is definitely what you want. Bind mounting or a symlink from the user's desktop is probably the best thing to do. It's something I've been looking at adding for the main live images, just dependent on having the content to include that way. Jeremy From asheesh at creativecommons.org Tue Feb 5 01:39:50 2008 From: asheesh at creativecommons.org (Asheesh Laroia) Date: Mon, 4 Feb 2008 17:39:50 -0800 (PST) Subject: [Fedora-livecd-list] Making content available on both sides of the live CD In-Reply-To: <47A7BB9C.8040308@filteredperception.org> References: <47A7B0C3.9050306@datawranglers.com> <47A7B4B5.8090509@filteredperception.org> <47A7BB9C.8040308@filteredperception.org> Message-ID: On Mon, 4 Feb 2008, Douglas McClendon wrote: >> To ask a question that I think *hasn't* been asked: >> >> Let's say I want to store big files in the ISO and symlink them to the >> user's $HOME. What's the appropriate way to, as part of the bootup >> process, mount the DVD? I noticed that, upon booting the live system, >> "mount /dev/cdrom" simply told me that it /dev/cdrom wasn't in the >> fstab. The /dev/cdrom symlink was set properly, so I could just add >> /dev/cdrom to the fstab myself or issue a mount command from an init >> script. But is that really the right way to automatically mount the >> disc from which the live system is booting? > > I think the answer you are looking for is /mnt/live. > > It will be mounted, and refers to the cdrom iso9660, or the fs that > hosts the LiveOS on a LiveUSB. Hmm - my live DVD I built doesn't have the CD system mounted at /mnt/live. Let me download an official Fedora 8 live disc and check that.... -- Asheesh. -- No lifeguard on duty. From asheesh at creativecommons.org Tue Feb 5 01:45:46 2008 From: asheesh at creativecommons.org (Asheesh Laroia) Date: Mon, 4 Feb 2008 17:45:46 -0800 (PST) Subject: [Fedora-livecd-list] Making content available on both sides of the live CD In-Reply-To: References: <47A7B0C3.9050306@datawranglers.com> <47A7B4B5.8090509@filteredperception.org> <47A7BB9C.8040308@filteredperception.org> Message-ID: On Mon, 4 Feb 2008, Asheesh Laroia wrote: > Hmm - my live DVD I built doesn't have the CD system mounted at > /mnt/live. Let me download an official Fedora 8 live disc and check > that.... Problem found - we don't include the Fedora /etc/rc.d/init.d/fedora-live in our disc. Fixing now. (-: -- Asheesh. -- Go away, I'm all right. -- H. G. Wells' last words. From katzj at redhat.com Tue Feb 5 01:54:44 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Feb 2008 20:54:44 -0500 Subject: [Fedora-livecd-list] Re: Review? LiveUSB persistence In-Reply-To: <47A7A11E.5030008@filteredperception.org> References: <47A247A1.1040702@filteredperception.org> <1202159657.26123.37.camel@aglarond.local> <47A7A11E.5030008@filteredperception.org> Message-ID: <1202176484.26123.55.camel@aglarond.local> On Mon, 2008-02-04 at 17:34 -0600, Douglas McClendon wrote: > Jeremy Katz wrote: > > Moving to the more appropriate list, original is at > > https://www.redhat.com/archives/fedora-devel-list/2008-January/msg03188.html for those not on fedora-devel > > > > On Thu, 2008-01-31 at 16:11 -0600, Douglas McClendon wrote: > >> I keep hearing these crazy rumors that RedHat actually wants to subject > >> actual users to my LiveUSB persistence feature next/this month. > > > > Lots of people want lots of different things. I've definitely left this > > sitting hanging too long and I apologize. I just didn't have time to > > poke over the holidays and my January was a bitty nutty. But I should > > be back to just my normal mail lag now ;-) > > > >> I for one think the feature is really cool, useful, and know of no > >> showstopping or even known bugs. But I also would not subject actual > >> users to it, without having had more people review it and sign off on > >> it. Anyway, to absolve myself of any responsibility, I once again > >> request code review and feedback- > > > > Overall, I think that it looks good. I think the big thing to work out > > is how best to integrate the initscripts changes. Especially as we're > > in parallel switching things over to upstart for F9. Just to make sure > > that I'm clear about what's there so that when we try to bribe Bill, we > > can do so effectively... > > * The unmount loops in /etc/init.d/functions are modified so that we > > don't unmount the underlying fs of the overlay > > Correct. And the method currently in use is adding any subcomponents of > the rootfs to /dev/.fstab.live.special. I chose that location just > because it is available from both the initramfs and then later during > shutdown. *nod* > > * We don't want to sync the hwclock on shutdown of a live image > > * Do an overlay teardown on halt to replace the rw snapshot with a ro > > version > > Yup, basically the old phase of 'remount rootfs readonly' just gets > quite a bit more complicated, but still essentially just that. Right. I really am leaning towards thinking that the teardown of the rw mount to be ro probably needs to be from initramfs land as that allows it to not require changes anywhere else when adding a new rootfs scheme. I'll have to see what we can cobble together to make that work (it has the added bonus of we'd be able to eject the cd on reboot from a livecd) > > The latter feels like we're going to want a generic hook to be able to > > run, perhaps from back in the initramfs. The middle feels largely > > unrelated to persistence in general, but just a "needs fixing" which > > will fit in nicely with other hwclock changes that are underway in > > rawhide. And the first I'm less clear on I guess. > > > > Outside of those changes, everything looks pretty straight-forward and > > reasonable. We'll want a little more error checking in > > livecd-iso-to-disk and it might also be nice to have another tool that > > lets you create your usb stick to use with the actual cd form (I did > > this by hand and it was pretty nice that I could easily get it > > working!). As for the findoverlay bits, for right now, leaving them as > > a separate script is fine. In the longer term, we're hopefully going to > > kill mayflower and be able to use more "normal" initrds[1], at which > > point pulling it in more directly would be nice. > > I have no preference where the code lives. The main thing I would > highlight is how originally I wrote findoverlay, with the mindset that > the overlay file/layer could be located anywhere. But then, to focus on > getting something really usable, I honed in on the assumption of the > overlay file living together with the LiveOS on a LiveUSB. As a result > the findoverlay script definitely does not look like entirely grade A > code right now. But I have no objection to it getting merged in any > form, and perhaps later having cleanup/refactoring passes, perhaps with > even later passes that add back the functionality I originally had in mind. *nod* I think it's the best way so that we get things in sooner rather than later. You've had it basically working for quite a while and we should just bite the bullet and say "good enough" rather than waiting for "perfect" > > As far as reliability... shutting down cleanly, I can't cause a problem. > > I pulled the usb stick from a box and got some garbage in a file I had > > written. I want to do some more playing here, but I also wanted to get > > this mail out today. Worst case, if we say "you need to shut down > > cleanly", then so be it. It might be nice if we flag clean vs not > > shutdown so that we can force a fsck in unclean cases. But no clue if > > that's even feasible; I'll take a look, though. > > My vague understanding right now would that it would be treated just > like a normal rootfs. I.e. the same things happening if it is flagged > as dirty, as if a normal system. But... I guess then there is the > issue of fscking the host filesystem, e.g. vfat(ext3?) of the LiveUSB. Ugh. Right. It's ... less than pretty. But could easily be a second pass once we get things merged in. > One immediate enhancement I thought of, is that perhaps the interface > for initialization can be taken out of livecd-iso-to-disk, and put into > the initramfs. I.e. a new kernel cmdline parameter of "initoverlay=256MB" > would just invoke the dd if=/dev/zero... during that boot. Maybe even a > default value that just uses half the free space on the LiveUSB. This would definitely make things simpler for Luke who's working on a Win32 version of livecd-iso-to-disk ;-) I'm not really sure where I stand on this one, I could probably be moved in either direction > Thus perhaps livecd-iso-to-disk just by default adds another couple menu > entries to syslinux, one for 'boot with persistence' and one for > 'initialize persistence'. Or perhaps the former automatically > initializes if none is found, and the latter, or some post-boot system > command could 'reinitialize persistence'... The problem with adding entries is that conceivably, you could have multiple kernels included and editing the syslinux.cfg at that point gets tricky. But I can think of a few ways to handle that, including having the persistence option in CD form and letting people choose (with a timeout) a location for their persistent bits. I'm not going to get hung up on figuring that out today, though. I kind of like the fact that to easily use it, you use livecd-iso-to-disk and it sets things up for you. Since if you're going to have persistence, then a USB stick is a pretty good idea. And by using USB instead, you end up getting better performance Jeremy From katzj at redhat.com Tue Feb 5 01:55:59 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Feb 2008 20:55:59 -0500 Subject: [Fedora-livecd-list] Re: Review? LiveUSB persistence In-Reply-To: <47A7B327.3090801@filteredperception.org> References: <47A247A1.1040702@filteredperception.org> <1202159657.26123.37.camel@aglarond.local> <47A7B327.3090801@filteredperception.org> Message-ID: <1202176559.26123.58.camel@aglarond.local> On Mon, 2008-02-04 at 18:51 -0600, Douglas McClendon wrote: > Jeremy Katz wrote: > > Outside of those changes, everything looks pretty straight-forward and > > reasonable. We'll want a little more error checking in > > livecd-iso-to-disk and it might also be nice to have another tool that > > lets you create your usb stick to use with the actual cd form (I did > > this by hand and it was pretty nice that I could easily get it > > working!). > > I didn't really slow down and read this bit at first- So you actually > used the livecd+usb form? I probably tried that once when I first wrote > the code, but haven't even considered it since then. I guess you must > have by hand added something like overlay=UUID=bla to the kernel > cmdline. Of course the original incarnation of the patch supported the > syntax overlay=auto which would scan all drives. But that code scares > my responsibility-averse nature, and I was happy to remove it when > focusing on the liveusb case. And also there was a bunch of related > bash junk for dealing with finding multiple overlays. Yep, I remember the auto bits as well. While at the time, I think I was pushing you towards it, I think I'm now with you on the being conservative. It was pretty easy to set up to use an external drive, though. I had a partition with a dos filesystem, created the LiveOS/Fedora-8-Live-i686- file and booted with overlay=LABEL=foo (which was the label of my filesystem). Jeremy From katzj at redhat.com Tue Feb 5 02:00:27 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Feb 2008 21:00:27 -0500 Subject: [Fedora-livecd-list] Making content available on both sides of the live CD In-Reply-To: References: <47A7B0C3.9050306@datawranglers.com> <47A7B4B5.8090509@filteredperception.org> <47A7BB9C.8040308@filteredperception.org> Message-ID: <1202176827.26123.61.camel@aglarond.local> On Mon, 2008-02-04 at 17:45 -0800, Asheesh Laroia wrote: > On Mon, 4 Feb 2008, Asheesh Laroia wrote: > > Hmm - my live DVD I built doesn't have the CD system mounted at > > /mnt/live. Let me download an official Fedora 8 live disc and check > > that.... > > Problem found - we don't include the Fedora /etc/rc.d/init.d/fedora-live > in our disc. Fixing now. (-: Yep, that'd do it. Note to self: need to work on getting the main parts of that integrated into regular initscripts rather than hanging out off by themselves Jeremy From asheesh at creativecommons.org Tue Feb 5 02:10:26 2008 From: asheesh at creativecommons.org (Asheesh Laroia) Date: Mon, 4 Feb 2008 18:10:26 -0800 (PST) Subject: [Fedora-livecd-list] Making content available on both sides of the live CD In-Reply-To: <1202176827.26123.61.camel@aglarond.local> References: <47A7B0C3.9050306@datawranglers.com> <47A7B4B5.8090509@filteredperception.org> <47A7BB9C.8040308@filteredperception.org> <1202176827.26123.61.camel@aglarond.local> Message-ID: On Mon, 4 Feb 2008, Jeremy Katz wrote: > On Mon, 2008-02-04 at 17:45 -0800, Asheesh Laroia wrote: >> On Mon, 4 Feb 2008, Asheesh Laroia wrote: >>> Hmm - my live DVD I built doesn't have the CD system mounted at >>> /mnt/live. Let me download an official Fedora 8 live disc and check >>> that.... >> >> Problem found - we don't include the Fedora /etc/rc.d/init.d/fedora-live >> in our disc. Fixing now. (-: > > Yep, that'd do it. Note to self: need to work on getting the main parts > of that integrated into regular initscripts rather than hanging out off > by themselves Turns out we had forked it into a separate file (which we put in our customization RPM...) and commented out the mounting of /mnt/live. (Fixed in our RPM!) Anyway, off-topic question: Do people have a suggestion for how to auto-generate the thumbnails for Nautilus before the live CD runs. That way, Nautilus will have pre-generated thumbnails for the images and movies. That will look nice, plus avoid a TERRIBLE I/O storm caused by Nautilus opening these folders and saying, "Oh, I'll make thumbnails now." I'd like to script this process, like: $ wget http://example.com/lotsa-images.zip $ unzip lotsa-images.zip $ magically_create_thumbnails and put the resulting directory into the ISO. -- Asheesh. -- Shedenhelm's Law: All trails have more uphill sections than they have downhill sections. From katzj at redhat.com Tue Feb 5 02:37:56 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Feb 2008 21:37:56 -0500 Subject: [Fedora-livecd-list] Making content available on both sides of the live CD In-Reply-To: References: <47A7B0C3.9050306@datawranglers.com> <47A7B4B5.8090509@filteredperception.org> <47A7BB9C.8040308@filteredperception.org> <1202176827.26123.61.camel@aglarond.local> Message-ID: <1202179076.26123.68.camel@aglarond.local> On Mon, 2008-02-04 at 18:10 -0800, Asheesh Laroia wrote: > Anyway, off-topic question: Do people have a suggestion for how to > auto-generate the thumbnails for Nautilus before the live CD runs. That > way, Nautilus will have pre-generated thumbnails for the images and > movies. That will look nice, plus avoid a TERRIBLE I/O storm caused by > Nautilus opening these folders and saying, "Oh, I'll make thumbnails now." I looked at this at one point and had something working. You want to resize to an image that's < 128x128 and stick the thumbnail under ~/.thumbnails/normal. For a file that's (eg, for the fedora user) ~/Photos/me.png, the thumbnail would be ~/.thumbnails/normal/$(echo "file:///home/fedora/Photos/me.png" | md5sum) If you come up with a nice script to do this, I'd be glad to include it in livecd-tools as an example for others :-) Jeremy From asheesh at creativecommons.org Tue Feb 5 02:46:00 2008 From: asheesh at creativecommons.org (Asheesh Laroia) Date: Mon, 4 Feb 2008 18:46:00 -0800 (PST) Subject: [Fedora-livecd-list] Making content available on both sides of the live CD In-Reply-To: <1202179076.26123.68.camel@aglarond.local> References: <47A7B0C3.9050306@datawranglers.com> <47A7B4B5.8090509@filteredperception.org> <47A7BB9C.8040308@filteredperception.org> <1202176827.26123.61.camel@aglarond.local> <1202179076.26123.68.camel@aglarond.local> Message-ID: On Mon, 4 Feb 2008, Jeremy Katz wrote: > On Mon, 2008-02-04 at 18:10 -0800, Asheesh Laroia wrote: >> Anyway, off-topic question: Do people have a suggestion for how to >> auto-generate the thumbnails for Nautilus before the live CD runs. That >> way, Nautilus will have pre-generated thumbnails for the images and >> movies. That will look nice, plus avoid a TERRIBLE I/O storm caused by >> Nautilus opening these folders and saying, "Oh, I'll make thumbnails now." > > I looked at this at one point and had something working. You want to > resize to an image that's < 128x128 and stick the thumbnail under > ~/.thumbnails/normal. For a file that's (eg, for the fedora user) > ~/Photos/me.png, the thumbnail would be > ~/.thumbnails/normal/$(echo "file:///home/fedora/Photos/me.png" | md5sum) echo -n, I presume. Hilariously the spec is a 403 but it's available in the Wayback Machine. > If you come up with a nice script to do this, I'd be glad to include it > in livecd-tools as an example for others :-) I'm disappointed to say I may make such a contribution. (-; -- Asheesh. -- What sin has not been committed in the name of efficiency? From dmc.fedora at filteredperception.org Tue Feb 5 05:42:02 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 04 Feb 2008 23:42:02 -0600 Subject: [Fedora-livecd-list] Re: Review? LiveUSB persistence In-Reply-To: <1202176559.26123.58.camel@aglarond.local> References: <47A247A1.1040702@filteredperception.org> <1202159657.26123.37.camel@aglarond.local> <47A7B327.3090801@filteredperception.org> <1202176559.26123.58.camel@aglarond.local> Message-ID: <47A7F72A.5070209@filteredperception.org> Jeremy Katz wrote: > On Mon, 2008-02-04 at 18:51 -0600, Douglas McClendon wrote: >> Jeremy Katz wrote: >>> Outside of those changes, everything looks pretty straight-forward and >>> reasonable. We'll want a little more error checking in >>> livecd-iso-to-disk and it might also be nice to have another tool that >>> lets you create your usb stick to use with the actual cd form (I did >>> this by hand and it was pretty nice that I could easily get it >>> working!). >> I didn't really slow down and read this bit at first- So you actually >> used the livecd+usb form? I probably tried that once when I first wrote >> the code, but haven't even considered it since then. I guess you must >> have by hand added something like overlay=UUID=bla to the kernel >> cmdline. Of course the original incarnation of the patch supported the >> syntax overlay=auto which would scan all drives. But that code scares >> my responsibility-averse nature, and I was happy to remove it when >> focusing on the liveusb case. And also there was a bunch of related >> bash junk for dealing with finding multiple overlays. > > Yep, I remember the auto bits as well. While at the time, I think I was > pushing you towards it, I think I'm now with you on the being > conservative. It was pretty easy to set up to use an external drive, > though. I had a partition with a dos filesystem, created the > LiveOS/Fedora-8-Live-i686- file and booted with overlay=LABEL=foo (which > was the label of my filesystem). So now that you're threatening to merge the code... reviewing it myself I see that- One obvious error is that in the halt teardown code, I assume the overlay device is /dev/live. This is only true for the LiveUSB case, and my seemingly pointless use of a variable to store /dev/live, shows that I was somewhat aware of the issue. The right answer might be the need to add another udev rule to the initramfs so that the overlayfs device can be known at halt time. I would say that because I think there might be no guaranteed way to determine the FS holding the file associated with a loop device (because losetup -a output may be truncated, and I don't know of another way?????) Other than that, I don't actually see anything too ugly. Probably the selinux permissifying in the teardown should be tested to see if it is really needed. It's possible I just messed up my labels in some prior version. Or, it's possible that the right answer is to change the selinux policy to allow whatever it was disallowing. As far as your statements about doing teardown from initramfs... One thing I had wanted to do was to make the initramfs mount visible later on. This was to be able to watch the size of the overlay sparse file. My way around the need for that was to create a new tmpfs just for it. But what you see in the code ('nobwa') is that currently there is a devicemapper bug I'm hitting if I try to do that. (I have a reproducibly indeterminite example I need to make the effort of attaching to the bug report). But digressing a bit... To see the initramfs, I think you might have to change nash so that it goes back to using pivotroot instead of mount --move. And then presumably hook into halt so that at the end, it fires off something from the initramfs again. Or I guess, you could copy your initramfs stuff to a new tmpfs, and not need the pivotroot thing. But the pivotroot thing seems more natural. But I have no idea why that got changed to a movemount (just to hide the mountpoint, or some other issue?) -dmc From dmc.fedora at filteredperception.org Tue Feb 5 08:41:25 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 05 Feb 2008 02:41:25 -0600 Subject: [Fedora-livecd-list] Woohoo! 31% boot speedup (*so far*), and 4.5MB free... Message-ID: <47A82135.1050403@filteredperception.org> Disclaimer: take these claims with the proverbial grain of salt, as I can on occasion be a bit over-optimistic or over-committal... Second Disclaimer: read the first disclaimer again. BUT THAT SAID... The Bad News: my "SuperDeviceMapperCaching" technique does not (yet[1]) appear to actually significantly improve LiveCD boot speed. The Good News: Some of the things that I did which were prerequisites of SDMC, appear to have the potential to speed up LiveCD boot by at least 31%, and even shrink the LiveCD by 4.5MB. The Better News: those prerequisite things are actually far less invasive (non-invasive really) than SDMC. Review: The SDMC idea was to use a virtualized boot of a LiveCD to determine which files were accessed during boot, then remaster the root filesystem so that those files would be grouped together, so that they could be read into a portion of the rootfs that would temporarily live in ram, via a devicemapper linear combination of the 'cached/preloaded' portion, and the normal rest of the rootfs on CDROM. The Reality: For expediency, I opted to gather the list of files via a simple find atime command after a virtual boot settled. I then sorted the files (and perhaps more importantly, directories and symlinks) by size, and then populated a filesystem, starting with the smallest boot-accessed file, and working my way up to the largest boot accessed file, and then just doing the rest. The realization: At some point I realized that this was actually gathering the files at inner part of the cdrom, which is read half as fast as the outter part. The sick future: I will get those files pushed to the outter edge... no matter what sick devicemapper magic it takes ;) The already optimistic numbers, that I really hope I'm not misinterpreting or overhyping- I timed a fedora-8 livecd boot on my laptop. I got about 2:30s to gdm, 3:30s to gnome desktop fully rendered, and 3:50s to firefox launched and fully rendered. I then (slight lie, did this last), timed a build of my very fedora-like livecd, built with my VirOS tools, but for all practical purposes, in no way radically different than the fedora livecd. What I got was 2:06s to the first post rhgb cursor (I'm using gdm autologin, so this is either a gdm mouse arrow, or the gnome mouse arrow). Then 3:19s to gnome fully rendered, and 3:23s to firefox fully rendered. (firefox was autostarted and fighting with gnome a bit). Then, I tried my SDMC livecd, but without SDMC, just the file reordering- and got 1:48s to first gdm mouse arrow, 2:29s to gnome fully rendered, and 2:34s to firefox fully rendered. I think I was able to get my SDMC mechanism to shave 2-5 seconds off of that, but not really a terribly significant difference. Another interesting fact, is that the reordered filesystem was 4.5MB smaller than unordered. This is no doubt because when I sort those files by size, a lot of very similar files end up spatially closer together, and are thus better compressed by squashfs. Thus, what I tenatively see, beyond the 4.5M of free space, is a 31% speedup (203s/154s) So, going forward, I plan to [1]A) do some sick stuff to get those early files on the outter rim of the cdrom, which I think may get further significant gains by itself, and perhaps even push my SDMC method into the significantly profitable area (though I don't much care at this point). B) perform all of this semi-manually on the official F8-livecd, and see how much I can really improve 'the real deal'. C) do boot file access data gathering on a pair of dissimilar physical hosts, and use the file diffs to determine classes of files (hw drivers mostly) which should get added to the list. Probably /lib/modules and a few other obvious directories should just get thrown into the list. D) I don't really care enough at this point to do a full systemtap or similar boot profile. atime seems sufficient for now (though I wonder, do I miss a lot of files that get touched when root is still mounted readonly?) E) do all of this for ubuntu, where I think my SDMC techniques, combined with their native squashfs usage, will yield as much, or perhaps even more benefit. -dmc/jdog Disclaimer: I really hope this all doesn't turn out to be fruitless... but I'm doing a pretty good job convincing myself that it all makes sense... (I'm just disappointed that I failed to really eliminate 95% of all seeks during boot... I still think that might be possible... but I need to go write a little C program to visualize the population of a sparse file... or instrument some filesystems.... Nah... I'm pretty sure I've got lower hanging fruit within my grasp...) P.S.- When I say I 'did' all of this, I of course mean completely scripted from a single VirOS commandline that just takes nearly half a day to run :) From Kenneth.Holter at nav.no Tue Feb 5 09:50:59 2008 From: Kenneth.Holter at nav.no (Holter, Kenneth) Date: Tue, 5 Feb 2008 10:50:59 +0100 Subject: [Fedora-livecd-list] RPMs for RHEL 4 Message-ID: Hi. I need to make a Live CD for disaster recovery purposes, and found this link on the web: http://www.informit.com/articles/article.aspx?p=1157197 ... and thought I'd give it a try. I'm running Red Hat Enterprise Linux 4, and can't seem to find any RPMs for my distro. Does such exist? If yes: where can I find them? Regards, Kenneth Holter -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjones at redhat.com Tue Feb 5 10:22:34 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 05 Feb 2008 10:22:34 +0000 Subject: [Fedora-livecd-list] Virt-p2v live CD, comments and packaging In-Reply-To: <1202163713.26123.43.camel@aglarond.local> References: <47A761F4.10204@redhat.com> <1202163713.26123.43.camel@aglarond.local> Message-ID: <47A838EA.2070108@redhat.com> Jeremy Katz wrote: > On Mon, 2008-02-04 at 19:05 +0000, Richard W.M. Jones wrote: >> I'm posting here to see if anyone has any comments about the way I did >> this live CD. The kickstart script uses a rather complex %post section, >> which adds a few files to the filesystem, instead of building RPMs or >> modifying existing RPMs. > >>From a maintainability point of view, you're going to be happier in the > long run if you actually package up things into RPMs as opposed to just > concatenating piles of scripts. I've already gotten pretty frustrated > with just the initscript we're using in the desktop case on a few > occasions. So there are two genuine issues with using RPMs: (1) I need to replace existing files -- in particular I need a new /etc/inittab. AIUI to do this with RPMs would involve building a custom 'initscripts' RPM and maintaining it, but let me know if I've got that wrong. (2) I'd like users to be able to download the source tarball and do: ./configure make to build an ISO. However the intermediate step -- building RPMs -- requires a full RPM build root inside the user's home directory, so they'd need to set that up and create the ~/.rpmmacros file, and specify where it is to ./configure. Again, that's AIUI, please correct me if I'm wrong. >> I've also investigated how to attach stuff to the end of the ISO image, >> and the way I've come up with allows me to update an ISO with a new >> script quite easily, and much more quickly than waiting for >> livecd-creator to rerun. This great (a) for rapid development and (b) >> to send new updates to users without forcing them to download another >> 170 MB ISO. > > Ewwww :) OK funny, but there's a genuine reason for doing this. P2V is extremely difficult to test; I'd like to compare it to debugging software in outer space. In all cases where someone has reported a bug to me I've had no access to the hardware, and no way to build comparable hardware at home (often it's because they're using some oddball SCSI controller or RAID array). I'm relying on a third party to give me as many details as possible. I then run the program through on paper to see if there are any scenarios which would give rise to the same bug. I then make a small change to the script, and send them another ISO to test. The problem is that it takes an hour and a half to upload a 170MB ISO, and another 15 minutes for the third party to download it. The only change may be a couple of lines in a 1,000 line script which I could send to them by email in seconds. ISO attachments allow much more interactive testing. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rjones at redhat.com Tue Feb 5 12:07:47 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 05 Feb 2008 12:07:47 +0000 Subject: [Fedora-livecd-list] %post and errors Message-ID: <47A85193.4030106@redhat.com> Shouldn't %post (and hence livecd-creator) exit if a shell command fails? At the moment the %post script prints an error message, but continues, resulting in a bad ISO. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From katzj at redhat.com Tue Feb 5 13:13:52 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 05 Feb 2008 08:13:52 -0500 Subject: [Fedora-livecd-list] %post and errors In-Reply-To: <47A85193.4030106@redhat.com> References: <47A85193.4030106@redhat.com> Message-ID: <1202217232.26123.74.camel@aglarond.local> On Tue, 2008-02-05 at 12:07 +0000, Richard W.M. Jones wrote: > Shouldn't %post (and hence livecd-creator) exit if a shell command fails? > > At the moment the %post script prints an error message, but continues, > resulting in a bad ISO. The behavior is the same as that of anaconda in this case. I could conceivably see a %post --exitonfail or maybe even an option of --fatalscripts to livecd-creator Jeremy From apevec at redhat.com Tue Feb 5 13:54:06 2008 From: apevec at redhat.com (Alan Pevec) Date: Tue, 05 Feb 2008 14:54:06 +0100 Subject: [Fedora-livecd-list] Re: Review? LiveUSB persistence In-Reply-To: <47A7F72A.5070209@filteredperception.org> References: <47A247A1.1040702@filteredperception.org> <1202159657.26123.37.camel@aglarond.local> <47A7B327.3090801@filteredperception.org> <1202176559.26123.58.camel@aglarond.local> <47A7F72A.5070209@filteredperception.org> Message-ID: <47A86A7E.6030609@redhat.com> Douglas McClendon wrote: > attaching to the bug report). But digressing a bit... To see the > initramfs, I think you might have to change nash so that it goes back to > using pivotroot instead of mount --move. And then presumably hook into > halt so that at the end, it fires off something from the initramfs > again. Or I guess, you could copy your initramfs stuff to a new tmpfs, > and not need the pivotroot thing. But the pivotroot thing seems more > natural. But I have no idea why that got changed to a movemount (just > to hide the mountpoint, or some other issue?) http://lxr.linux.no/linux/fs/namespace.c#L1642 you can't pivot_root initramfs=rootfs From tim.wood at datawranglers.com Tue Feb 5 14:39:39 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Tue, 05 Feb 2008 07:39:39 -0700 Subject: [Fedora-livecd-list] %post and errors In-Reply-To: <1202217232.26123.74.camel@aglarond.local> References: <47A85193.4030106@redhat.com> <1202217232.26123.74.camel@aglarond.local> Message-ID: <47A8752B.5030509@datawranglers.com> Agreed. Jeremy Katz wrote: > On Tue, 2008-02-05 at 12:07 +0000, Richard W.M. Jones wrote: > >> Shouldn't %post (and hence livecd-creator) exit if a shell command fails? >> >> At the moment the %post script prints an error message, but continues, >> resulting in a bad ISO. >> > > The behavior is the same as that of anaconda in this case. I could > conceivably see a %post --exitonfail or maybe even an option of > --fatalscripts to livecd-creator > > Jeremy > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > -- _________________________________ Tim Wood, CLP, RHCT 719.338.7484 (tel) The Data Wranglers Web, Database & more since since 1994 www.datawranglers.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From katzj at redhat.com Tue Feb 5 15:59:09 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 05 Feb 2008 10:59:09 -0500 Subject: [Fedora-livecd-list] Virt-p2v live CD, comments and packaging In-Reply-To: <47A838EA.2070108@redhat.com> References: <47A761F4.10204@redhat.com> <1202163713.26123.43.camel@aglarond.local> <47A838EA.2070108@redhat.com> Message-ID: <1202227149.26123.82.camel@aglarond.local> On Tue, 2008-02-05 at 10:22 +0000, Richard W.M. Jones wrote: > Jeremy Katz wrote: > > On Mon, 2008-02-04 at 19:05 +0000, Richard W.M. Jones wrote: > >> I'm posting here to see if anyone has any comments about the way I did > >> this live CD. The kickstart script uses a rather complex %post section, > >> which adds a few files to the filesystem, instead of building RPMs or > >> modifying existing RPMs. > > > >>From a maintainability point of view, you're going to be happier in the > > long run if you actually package up things into RPMs as opposed to just > > concatenating piles of scripts. I've already gotten pretty frustrated > > with just the initscript we're using in the desktop case on a few > > occasions. > > So there are two genuine issues with using RPMs: > > (1) I need to replace existing files -- in particular I need a new > /etc/inittab. AIUI to do this with RPMs would involve building a custom > 'initscripts' RPM and maintaining it, but let me know if I've got that > wrong. An entirely new inittab seems... overkill. Is an initscript to run your functionality not good enough? > (2) I'd like users to be able to download the source tarball and do: > ./configure > make > to build an ISO. However the intermediate step -- building RPMs -- > requires a full RPM build root inside the user's home directory, so > they'd need to set that up and create the ~/.rpmmacros file, and specify > where it is to ./configure. Again, that's AIUI, please correct me if > I'm wrong. --define _builddir, etc on the rpmbuild command line works. And you can then put it under a mktemp'd directory. > >> I've also investigated how to attach stuff to the end of the ISO image, > >> and the way I've come up with allows me to update an ISO with a new > >> script quite easily, and much more quickly than waiting for > >> livecd-creator to rerun. This great (a) for rapid development and (b) > >> to send new updates to users without forcing them to download another > >> 170 MB ISO. > > > > Ewwww :) > > OK funny, but there's a genuine reason for doing this. Sure, but it's going to be pretty fragile and I know I'd rather have something more dependable. Why not just use something like xdelta between isos? A little more time-consuming to create, but I suspect that time difference is already made up with the time you spent writing the ocaml script :-) Jeremy From katzj at redhat.com Tue Feb 5 16:04:25 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 05 Feb 2008 11:04:25 -0500 Subject: [Fedora-livecd-list] Re: Review? LiveUSB persistence In-Reply-To: <47A7F72A.5070209@filteredperception.org> References: <47A247A1.1040702@filteredperception.org> <1202159657.26123.37.camel@aglarond.local> <47A7B327.3090801@filteredperception.org> <1202176559.26123.58.camel@aglarond.local> <47A7F72A.5070209@filteredperception.org> Message-ID: <1202227465.26123.88.camel@aglarond.local> On Mon, 2008-02-04 at 23:42 -0600, Douglas McClendon wrote: > Jeremy Katz wrote: > > On Mon, 2008-02-04 at 18:51 -0600, Douglas McClendon wrote: > >> Jeremy Katz wrote: > >>> Outside of those changes, everything looks pretty straight-forward and > >>> reasonable. We'll want a little more error checking in > >>> livecd-iso-to-disk and it might also be nice to have another tool that > >>> lets you create your usb stick to use with the actual cd form (I did > >>> this by hand and it was pretty nice that I could easily get it > >>> working!). > >> I didn't really slow down and read this bit at first- So you actually > >> used the livecd+usb form? I probably tried that once when I first wrote > >> the code, but haven't even considered it since then. I guess you must > >> have by hand added something like overlay=UUID=bla to the kernel > >> cmdline. Of course the original incarnation of the patch supported the > >> syntax overlay=auto which would scan all drives. But that code scares > >> my responsibility-averse nature, and I was happy to remove it when > >> focusing on the liveusb case. And also there was a bunch of related > >> bash junk for dealing with finding multiple overlays. > > > > Yep, I remember the auto bits as well. While at the time, I think I was > > pushing you towards it, I think I'm now with you on the being > > conservative. It was pretty easy to set up to use an external drive, > > though. I had a partition with a dos filesystem, created the > > LiveOS/Fedora-8-Live-i686- file and booted with overlay=LABEL=foo (which > > was the label of my filesystem). > > So now that you're threatening to merge the code... reviewing it myself > I see that- My plan is working ;-) Just kidding... > One obvious error is that in the halt teardown code, I assume the > overlay device is /dev/live. This is only true for the LiveUSB case, > and my seemingly pointless use of a variable to store /dev/live, shows > that I was somewhat aware of the issue. The right answer might be the > need to add another udev rule to the initramfs so that the overlayfs > device can be known at halt time. I would say that because I think > there might be no guaranteed way to determine the FS holding the file > associated with a loop device (because losetup -a output may be > truncated, and I don't know of another way?????) Yeah, if we can't go back into the initramfs (which, yes, may not be possible given our use of mount --move), then we'll have to come up with some better trickery for the halt side. I need to corner notting this afternoon and see what thoughts he has on it as initscripts/init is all his territory and he's in the middle of reworking some of it for upstart anyway > As far as your statements about doing teardown from initramfs... One > thing I had wanted to do was to make the initramfs mount visible later > on. This was to be able to watch the size of the overlay sparse file. > My way around the need for that was to create a new tmpfs just for it. > But what you see in the code ('nobwa') is that currently there is a > devicemapper bug I'm hitting if I try to do that. (I have a > reproducibly indeterminite example I need to make the effort of > attaching to the bug report). But digressing a bit... To see the > initramfs, I think you might have to change nash so that it goes back to > using pivotroot instead of mount --move. And then presumably hook into > halt so that at the end, it fires off something from the initramfs > again. Or I guess, you could copy your initramfs stuff to a new tmpfs, > and not need the pivotroot thing. But the pivotroot thing seems more > natural. But I have no idea why that got changed to a movemount (just > to hide the mountpoint, or some other issue?) You can't (successfully) do a pivotroot from an initramfs iirc. Jeremy From katzj at redhat.com Tue Feb 5 16:04:53 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 05 Feb 2008 11:04:53 -0500 Subject: [Fedora-livecd-list] RPMs for RHEL 4 In-Reply-To: References: Message-ID: <1202227493.26123.89.camel@aglarond.local> On Tue, 2008-02-05 at 10:50 +0100, Holter, Kenneth wrote: > I need to make a Live CD for disaster recovery purposes, and found > this link on the web: > > http://www.informit.com/articles/article.aspx?p=1157197 > > ? and thought I'd give it a try. > > I'm running Red Hat Enterprise Linux 4, and can't seem to find any > RPMs for my distro. Does such exist? If yes: where can I find them? livecd-tools doesn't exist for RHEL4 and requires quite a bit more infrastructure than existed at that time. Sorry Jeremy From rjones at redhat.com Tue Feb 5 16:51:02 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 05 Feb 2008 16:51:02 +0000 Subject: [Fedora-livecd-list] Virt-p2v live CD, comments and packaging In-Reply-To: <1202227149.26123.82.camel@aglarond.local> References: <47A761F4.10204@redhat.com> <1202163713.26123.43.camel@aglarond.local> <47A838EA.2070108@redhat.com> <1202227149.26123.82.camel@aglarond.local> Message-ID: <47A893F6.9010502@redhat.com> Jeremy Katz wrote: > An entirely new inittab seems... overkill. Is an initscript to run your > functionality not good enough? No, I used to do it like that, and it was problematic. This was many months ago so I'm a bit vague on the exact details but it would have been something to do with either getting stdin/stdout to the tty or having /sbin/init unexpectedly put up a prompt during or after my initscript running. The current method (modifying inittab) works well anyway. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From bvarney at gmail.com Tue Feb 5 16:52:13 2008 From: bvarney at gmail.com (Brian Varney) Date: Tue, 5 Feb 2008 09:52:13 -0700 Subject: [Fedora-livecd-list] liveinst failing on images made with livecd-creator In-Reply-To: <19dc81ae0801021348sadbc92al8fbd6f758946ce77@mail.gmail.com> References: <19dc81ae0801021216w3742b4a5sa9182de4fbb3cbe9@mail.gmail.com> <1199305985.6402.22.camel@erebor.boston.redhat.com> <19dc81ae0801021348sadbc92al8fbd6f758946ce77@mail.gmail.com> Message-ID: <19dc81ae0802050852p58c8df75p94f6bc568b284d33@mail.gmail.com> I'm still having the same problem. I haven't been able to get liveinst to work on any livecd that I create. It never finished the "performing post-installation filesystem changes" step. Eventually, I'll break out of this and find out what actually got put on the hard drive. Everything got copied to the "/" partition just fine. The "/boot" partition only contains a grub directory with "splash.xpm.gz" file in it. The kernel and initrd are not in there. The LiveCd uses an ext3 filesystem and I'm choosing an ext3 filesystem in the liveinst. I've watched top and ps, and the last thing I see is ext2resize run. It appears that the problem is something anaconda does after this? Is there a way to get some debug information out of anaconda? On Jan 2, 2008 2:48 PM, Brian Varney wrote: > > > On Jan 2, 2008 1:33 PM, Jeremy Katz wrote: > > > On Wed, 2008-01-02 at 13:16 -0700, Brian Varney wrote: > > > I'm having problems getting the liveinst to work with images that I > > > create with livecd-creator. > > [snip] > > > liveinst works great until the very end when it says "performing > > > post-installation filesystem changes". This step never finishes. It > > > stays on this step forever and I've waited days. When I try to boot > > > to the installed image, I get a grub prompt but no menu options. > > > > Are you using non-ext3 filesystem images either for installing to or > > from? > > > No. Everything is ext3. From liveinst, I choose "Remove all partitions > on selected drives and create default layout", which creates an LVM with an > ext3 filesystem. > > > > > > > Jeremy > > > > -- > > Fedora-livecd-list mailing list > > Fedora-livecd-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ltx at charter.net Tue Feb 5 23:04:10 2008 From: ltx at charter.net (ltx at charter.net) Date: Tue, 5 Feb 2008 15:04:10 -0800 Subject: SELinux required? was - Re: [Fedora-livecd-list] live fedora 8 cd - login: no shell: Permission denied In-Reply-To: <47A5408D.70305@charter.net> Message-ID: <20080205180410.1K084.83360.root@fepweb08> Ok, I think I've found a solution, but I don't quite understand it. It has to do with whether the livecd build system has selinux enabled. If it is not enabled on the host then and "selinux --disabled" is set in the kickstart file, then I can't log in at all with the iso built with the kickstart file below. If the build system has selinux set to Permissive or Enforcing then the file below creates an iso that I can log in to without any problem. So, is there a way to not require that the build system have selinux enabled? Thanks. Jerry lang en_US.UTF-8 keyboard us timezone US/Eastern auth --useshadow --enablemd5 selinux --disabled firewall --disabled firstboot --disable #root password rootpw myroot part / --size 1024 repo --name=released --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=i386 repo --name=updates --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f8&arch=i386 %packages @core bash kernel passwd policycoreutils chkconfig authconfig rootfiles %post # FIXME: it'd be better to get this installed from a package cat > /etc/rc.d/init.d/fedora-live << EOF #!/bin/bash # # live: Init script for live image # # chkconfig: 345 00 99 # description: Init script for live image. . /etc/init.d/functions # add fedora user with no passwd useradd -c "Jerry" fedora echo 'password' | passwd --stdin fedora # Stopgap fix for RH #217966; should be fixed in HAL instead touch /media/.hal-mtab EOF chmod 755 /etc/rc.d/init.d/fedora-live /sbin/restorecon /etc/rc.d/init.d/fedora-live /sbin/chkconfig --add fedora-live echo "Welcome to my world" > /etc/motd %end ---- Jerry wrote: > > Thanks. I'll give it a try tomorrow. I've had enough for > today :-) > > Thanks for your help. > > Jerry > > > Tim Wood wrote: > > FWIW... be very careful when doing what I just suggested. And, just in > > case, do the following (just in case). Open a terminal window. su (to > > root). make a backup of /etc/password somewhere else. Leave that > > window open. Open a new terminal window and build your LiveCD. Then, > > if the kickstart causes your system (rather than the livecd's) > > /etc/password to be overwritten, you'll still have a root window open > > and you _should_ be able to copy back the backup. At a worst case > > scenario, you can boot off of a livecd and restore the backup of > > /etc/password. > > > > Tim Wood > > > > > > ltx wrote: > >> > >> Yeah, I can't seem to find any docs that mention what the > >> password is. > >> > >> I did put the rootpw line in and it does appear that the > >> log in works since I get the 'Last Login' message and > >> I get the message from /etc/motd, but then it complains > >> that there is 'no shell: Permission denied' > >> > >> Jerry > >> > >> Tim Wood wrote: > >>> Good question that I don't have the answer to. Since I always > >>> forget, I started overiding it by adding this to the kickstart: > >>> > >>> # Set root password > >>> rootpw iamroot > >>> > >>> If it's not a space issue, modify /etc/inittab during post and change > >>> the runlevel from 5 to 3. If /etc/inittab doesn't make sense to you, > >>> post again and I'll copy and paste the particular line. > >>> > >>> Tim > >>> > >>> > >>> > >>> ltx wrote: > >>>> > >>>> Hi Tim, > >>>> > >>>> Thanks for the quick reply. I was hoping to avoid all the > >>>> graphics since this is more for utility work and will be > >>>> booted often. > >>>> > >>>> Even if I went to the KDE desktop kickstart file what would > >>>> the root password be? > >>>> > >>>> Thanks. > >>>> Jerry > >>>> > >>>> Tim Wood wrote: > >>>>> One 'feature' of the minimal is that login is disabled. The kde > >>>>> desktop is a good starter. > >>>>> > >>>>> Tim Wood > >>>>> > >>>>> > >>>>> ltx wrote: > >>>>>> > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I'm trying to build a basic Fedora 8 livecd to use as > >>>>>> a vehicle to flash a card I am working on. The flash > >>>>>> utility works from linux running from the hard drive > >>>>>> so that is not a concern at the moment. > >>>>>> > >>>>>> My problem - I can't log in! The iso builds fine with > >>>>>> command; > >>>>>> > >>>>>> livecd-creator --config=./livecd-fedora-minimal.ks --fslabel=Fedora8 > >>>>>> > >>>>>> When I boot from it, or use qemu to test, I can't log into root > >>>>>> or another id that I create in the kiskstart file. I followed > >>>>>> the instructions at > >>>>>> http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo > >>>>>> which are great, but they even point out that the > >>>>>> livecd-fedora-minimal.ks > >>>>>> kickstart file found in /usr/share/livecd-tools will not let you > >>>>>> log in. > >>>>>> (unless you go to all full desktop environment - which I don't > >>>>>> need/want) > >>>>>> > >>>>>> I noticed that the minimal kickstart file disabled the root id, > >>>>>> so I removed that and scoured the net and found that kickstart > >>>>>> command > >>>>>> rootpw allows you to set the root password. That gave me some > >>>>>> progress. Now when I try to log in to root I get these messages; > >>>>>> > >>>>>> Last login: time date... > >>>>>> Welcome to my world (this is what I put in /etc/motd) > >>>>>> login: no shell: Permission denied. > >>>>>> > >>>>>> So, several questions: > >>>>>> > >>>>>> 1 - What is wrong with my kickstart file (below) that prevents > >>>>>> me from logging in? > >>>>>> > >>>>>> 2 - Is there any collections of kickstart files available (other than > >>>>>> those that come with the livecd-tools packages? > >>>>>> > >>>>>> 3 - Where can I find the kickstart file options documented? > >>>>>> > >>>>>> Oh, my build environment is Fedora 8 (x86_64) with all the latest > >>>>>> updates. I point to the x86 mirrors so I can use the CD on older > >>>>>> machines. > >>>>>> > >>>>>> I'd appreciate any help you can offer. > >>>>>> > >>>>>> Thanks. > >>>>>> Jerry > >>>>>> > >>>>>> > >>>>>> lang en_US.UTF-8 > >>>>>> keyboard us > >>>>>> timezone US/Eastern > >>>>>> #auth --useshadow --enablemd5 > >>>>>> selinux --disabled > >>>>>> firewall --disabled > >>>>>> firstboot --disable > >>>>>> #root password > >>>>>> rootpw emulex > >>>>>> part / --size 1024 > >>>>>> > >>>>>> repo --name=released > >>>>>> --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=i386 > >>>>>> > >>>>>> repo --name=updates > >>>>>> --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f8&arch=i386 > >>>>>> > >>>>>> > >>>>>> %packages > >>>>>> @core > >>>>>> bash > >>>>>> kernel > >>>>>> passwd > >>>>>> policycoreutils > >>>>>> chkconfig > >>>>>> authconfig > >>>>>> rootfiles > >>>>>> > >>>>>> %post > >>>>>> # FIXME: it'd be better to get this installed from a package > >>>>>> cat > /etc/rc.d/init.d/fedora-live << EOF > >>>>>> #!/bin/bash > >>>>>> # > >>>>>> # live: Init script for live image > >>>>>> # > >>>>>> # chkconfig: 345 00 99 > >>>>>> # description: Init script for live image. > >>>>>> > >>>>>> . /etc/init.d/functions > >>>>>> > >>>>>> if ! strstr "\`cat /proc/cmdline\`" liveimg || [ "\$1" != "start" > >>>>>> ] || [ -e /.liveimg-configured ] ; then > >>>>>> exit 0 > >>>>>> fi > >>>>>> > >>>>>> exists() { > >>>>>> which \$1 >/dev/null 2>&1 || return > >>>>>> \$* > >>>>>> } > >>>>>> > >>>>>> touch /.liveimg-configured > >>>>>> > >>>>>> # mount live image > >>>>>> if [ -b /dev/live ]; then > >>>>>> mkdir -p /mnt/live > >>>>>> mount -o ro /dev/live /mnt/live > >>>>>> fi > >>>>>> > >>>>>> # add a user > >>>>>> useradd -c "Jerry" jerry > >>>>>> echo 'password' | passwd --stdin jerry > >>>>>> > >>>>>> # read some variables out of /proc/cmdline > >>>>>> for o in \`cat /proc/cmdline\` ; do > >>>>>> case \$o in > >>>>>> ks=*) > >>>>>> ks="\${o#ks=}" > >>>>>> ;; > >>>>>> xdriver=*) > >>>>>> xdriver="--set-driver=\${o#xdriver=}" > >>>>>> ;; > >>>>>> esac > >>>>>> done > >>>>>> > >>>>>> # Stopgap fix for RH #217966; should be fixed in HAL instead > >>>>>> touch /media/.hal-mtab > >>>>>> EOF > >>>>>> > >>>>>> chmod 755 /etc/rc.d/init.d/fedora-live > >>>>>> #/sbin/restorecon /etc/rc.d/init.d/fedora-live > >>>>>> /sbin/chkconfig --add fedora-live > >>>>>> > >>>>>> echo "Welcome to my world" > /etc/motd > >>>>>> > >>>>>> %end > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> 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 > >> > > > > > > -- > 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 Feb 6 04:16:08 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 05 Feb 2008 22:16:08 -0600 Subject: [Fedora-livecd-list] Woohoo! 31% boot speedup (*so far*), and 4.5MB free... In-Reply-To: <47A82135.1050403@filteredperception.org> References: <47A82135.1050403@filteredperception.org> Message-ID: <47A93488.4080506@filteredperception.org> Douglas McClendon wrote: ... > Thus, what I tenatively see, beyond the 4.5M of free space, is a 31% > speedup (203s/154s) > > So, going forward, I plan to > > [1]A) do some sick stuff to get those early files on the outter rim of > the cdrom, which I think may get further significant gains by itself, > and perhaps even push my SDMC method into the significantly profitable > area (though I don't much care at this point). And here I was thinking of doing my own kludge, but yet AGAIN, Device Mapper Is Just So Cool - (dm-reverse) http://sources.redhat.com/cgi-bin/cvsweb.cgi/device-mapper/contrib/?cvsroot=dm -dmc From katzj at fedoraproject.org Thu Feb 7 06:03:26 2008 From: katzj at fedoraproject.org (Jeremy Katz) Date: Wed, 6 Feb 2008 23:03:26 -0700 Subject: [Fedora-livecd-list] 2 commits - imgcreate/creator.py imgcreate/kickstart.py tools/mayflower Message-ID: <200802070603.m1763QOm022972@hosted1.fedoraproject.org> imgcreate/creator.py | 4 ++-- imgcreate/kickstart.py | 6 ++++++ tools/mayflower | 2 +- 3 files changed, 9 insertions(+), 3 deletions(-) New commits: commit ce1a7bb55abb8ae9c04351555bb28edc9e6c6285 Author: Jeremy Katz Date: Thu Feb 7 01:02:32 2008 -0500 Don't explicitly specify the filesystem type to mount so that ext2 can get mounted as well diff --git a/tools/mayflower b/tools/mayflower index f77b2be..2e46098 100755 --- a/tools/mayflower +++ b/tools/mayflower @@ -609,7 +609,7 @@ do_live_from_base_loop() { rm -f /dev/root ln -s /dev/mapper/live-rw /dev/root - mount -n -t ext3 /dev/mapper/live-rw /sysroot + mount -n /dev/mapper/live-rw /sysroot # here you can modify the rw ext3 fs for testing if you don't want to # respin the entire rootfs (which takes ages). Example # commit 4f761b21c6ab98a2421d7706c12860c55c26fa69 Author: Jeremy Katz Date: Thu Feb 7 01:02:09 2008 -0500 Actually follow the specified filesystem from the ks.cfg diff --git a/imgcreate/creator.py b/imgcreate/creator.py index b1766b6..40dcead 100644 --- a/imgcreate/creator.py +++ b/imgcreate/creator.py @@ -206,7 +206,7 @@ class ImageCreator(object): A sensible default implementation is provided. """ - s = "/dev/root / ext3 defaults,noatime 0 0\n" + s = "/dev/root / %s defaults,noatime 0 0\n" %(self._fstype) s += "devpts /dev/pts devpts gid=5,mode=620 0 0\n" s += "tmpfs /dev/shm tmpfs defaults 0 0\n" s += "proc /proc proc defaults 0 0\n" @@ -697,7 +697,7 @@ class LoopImageCreator(ImageCreator): self.__minsize_KB = 0 self.__blocksize = 4096 - self.__fstype = "ext3" + self.__fstype = kickstart.get_image_fstype(self.ks, "ext3") self.__instloop = None self.__imgdir = None diff --git a/imgcreate/kickstart.py b/imgcreate/kickstart.py index 4c6f48f..a7e0723 100644 --- a/imgcreate/kickstart.py +++ b/imgcreate/kickstart.py @@ -396,6 +396,12 @@ def get_image_size(ks, default = None): return int(p.size) * 1024L * 1024L return default +def get_image_fstype(ks, default = None): + for p in ks.handler.partition.partitions: + if p.mountpoint == "/" and p.fstype: + return p.fstype + return default + def get_modules(ks): devices = [] if isinstance(ks.handler.device, kscommands.device.FC3_Device): From dmc.fedora at filteredperception.org Sun Feb 10 22:42:39 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 10 Feb 2008 16:42:39 -0600 Subject: [Fedora-livecd-list] Woohoo! 31% boot speedup (*so far*), and 4.5MB free... In-Reply-To: <47A93488.4080506@filteredperception.org> References: <47A82135.1050403@filteredperception.org> <47A93488.4080506@filteredperception.org> Message-ID: <47AF7DDF.1030205@filteredperception.org> Just a status report on this, since 31% is such an outlandish claim... I'm currently investigating why it is that my find atime command on my livecd typically shows about 20k/80k files accessed during a normal boot, versus 3k/80k on the f8 livecd. If anyone would like to venture speculation or facts as to which of those numbers is more realistic... Looking at the diffs, I know that 3k is missing some stuff, like, /etc/xdg/menus (the directory entry) not showing up, even though files under the directory show up. And I did extract the initramfs from the f8 livecd, change it's /etc/fstab, initramfs /init, and /sysroot/etc/fstab to all have atime,diratime instead of noatime and/or relatime. And I echod 0 to /proc/sys/fs/default_relatime as soon as proc was mounted. ( find / -xdev -atime -7 -exec ls -ld '{}' ';' > boot.afiles.list.txt ) Anyway, I still think I can get significant improvement, but there are a lot of experiments and trials to run. In general, I'm also going to try ordering the filesystem with all directory entries together, and symlinks together, to see how that helps compression. Likewise all text files, and all these things alpha and size sorted. I'm particularly interested if anyone has speculation as to why clustering the directory entries and symlinks might be some bad cornercase for ext3 filesystem performance. And unfortunately I can't get the dm-reverse kernel module to compile easily (don't think anyone's actually used it in years). But I may go back to my own kludge, somewhat similar to the perl extent reversing example in the dm docs. I'll let you all know how it goes... Maybe nowhere, maybe it'll speed up boot 50% and make space for another 10MB of compressed stuff... -dmc Douglas McClendon wrote: > Douglas McClendon wrote: > ... >> Thus, what I tenatively see, beyond the 4.5M of free space, is a 31% >> speedup (203s/154s) >> >> So, going forward, I plan to >> >> [1]A) do some sick stuff to get those early files on the outter rim of >> the cdrom, which I think may get further significant gains by itself, >> and perhaps even push my SDMC method into the significantly profitable >> area (though I don't much care at this point). > > And here I was thinking of doing my own kludge, but yet AGAIN, Device > Mapper Is Just So Cool - (dm-reverse) > > http://sources.redhat.com/cgi-bin/cvsweb.cgi/device-mapper/contrib/?cvsroot=dm > > > -dmc > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From rjones at redhat.com Mon Feb 11 16:22:21 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 11 Feb 2008 16:22:21 +0000 Subject: [Fedora-livecd-list] [PATCH] Add support for pxeboot Message-ID: <47B0763D.9010702@redhat.com> The attached patch adds support for turning a liveCD ISO image into a network-bootable PXE image. Myself and Chris Lalancette looked into this in some detail and came up with two different ways to do this. This is the simpler of the two methods and results in the least invasive changes to livecd-creator -- just a single line patch to mayflower and a 100-or-so-line extra script called 'livecd-iso-to-pxeboot' which works analogously to 'livecd-iso-to-disk'. The way it works is to bundle the complete ISO image inside the initrd. The kernel and (bloated) initrd are downloaded using PXE in the normal way, and the init script finds and loopback-mounts the ISO image and booting continues as normal. One possible con of this approach is whether or not it's a good idea to download a very large (min 200 MB) initrd image over TFTP. There are two reasons we can think of why you *wouldn't* want to do this: (1) "traditional" TFTP is limited to 32 MB max file size, although all modern TFTP implementations supersede that with a 4 GB limit (RFC 2348). (2) TFTP uses its own transport layer which might not be able to back-off as nicely as TCP on busy networks. However in my testing there was no problem at all using TFTP on large files over an ethernet LAN. The other approach which we looked at and partially implemented was to modify the normal initrd/init so that it could do a separate request to download the ISO. It could possibly do this over another protocol such as HTTP (although in Chris's tests he just used a separate TFTP connection). The implementation of this is considerably more complicated: (a) The initrd has to carry around dhclient, network scripts, and all the network programs like '/sbin/ip'. (b) The initrd has to be able to find the TFTP server again, which basically involves making another DHCP query. In Chris's original implementation he also added specific DHCP options to carry the TFTP server information since it wasn't clear how to get this out of stock dhclient. (c) After booting, because of (b), the network is already set up, which is not how a live CD expects it to be. Therefore the live CD itself would need to be changed if it does any network configuration. All in all, I would say that the attached patch is a simpler and better approach. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-pxeboot.patch Type: text/x-patch Size: 5683 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From katzj at redhat.com Mon Feb 11 17:54:01 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 11 Feb 2008 12:54:01 -0500 Subject: [Fedora-livecd-list] [PATCH] Add support for pxeboot In-Reply-To: <47B0763D.9010702@redhat.com> References: <47B0763D.9010702@redhat.com> Message-ID: <1202752441.23702.41.camel@aglarond.local> On Mon, 2008-02-11 at 16:22 +0000, Richard W.M. Jones wrote: > The way it works is to bundle the complete ISO image inside the initrd. > The kernel and (bloated) initrd are downloaded using PXE in the normal > way, and the init script finds and loopback-mounts the ISO image and > booting continues as normal. Hmmm, while sort of painful for the reasons you mention, the trivial amount of change required is somewhat attractive in the short-term. And I guess that in reality, it's always something that someone might for some crazy reason want to do. One thing you can do to make your script easier is just stick the iso in another cpio.gz file and append it to the main initrd (which is an initramfs). The kernel should then do the right thing with multiple initramfs's. Alternately, if you're expecting that people are using pxelinux (which it seems you are), you don't even have to do the append. Just make the cpio.gz of the iso image and use syntax like append initrd=initrd0.img,isocpio.gz in the pxelinux.cfg. > The other approach which we looked at and partially implemented was to > modify the normal initrd/init so that it could do a separate request to > download the ISO. It could possibly do this over another protocol such > as HTTP (although in Chris's tests he just used a separate TFTP > connection). The implementation of this is considerably more complicated: Longer-term, I suspect this is something which is more interesting to support but I also think that it needs to wait until we really have the live initramfs process integrated with mkinitrd (which already has all of the network bring-up bits). Redoing all of that is on the todo list, but probably not for this time around. Jeremy From katzj at fedoraproject.org Mon Feb 11 19:29:43 2008 From: katzj at fedoraproject.org (Jeremy Katz) Date: Mon, 11 Feb 2008 12:29:43 -0700 Subject: [Fedora-livecd-list] imgcreate/yuminst.py Message-ID: <200802111929.m1BJTh3P003534@hosted1.fedoraproject.org> imgcreate/yuminst.py | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) New commits: commit ce58f625e8215cface69ddc7f12cfbded0e3c66f Author: Jeremy Katz Date: Mon Feb 11 14:16:37 2008 -0500 Ensure removing packages (-foo) really removes them -foo works as long as the package is a regular package, but it intentionally doesn't remove them from being pulled in for deps. We don't, though, want them to be pulled in as a result of the conditional requirements. So go through and remove them from the conditionals dict. Yes, this is ugly but conditionals are generally ugly diff --git a/imgcreate/yuminst.py b/imgcreate/yuminst.py index d15ed2f..14f4806 100644 --- a/imgcreate/yuminst.py +++ b/imgcreate/yuminst.py @@ -100,7 +100,15 @@ class LiveCDYum(yum.YumBase): txmbrs.append(p) if len(txmbrs) > 0: - map(lambda x: self.tsInfo.remove(x.pkgtup), txmbrs) + for x in txmbrs: + self.tsInfo.remove(x.pkgtup) + # we also need to remove from the conditionals + # dict so that things don't get pulled back in as a result + # of them. yes, this is ugly. conditionals should die. + for req, pkgs in self.tsInfo.conditionals: + if x in pkgs: + pkgs.remove(x) + self.tsInfo.conditionals[req] = pkgs else: print >> sys.stderr, "No such package %s to remove" %(pkg,) From katzj at fedoraproject.org Mon Feb 11 19:33:43 2008 From: katzj at fedoraproject.org (Jeremy Katz) Date: Mon, 11 Feb 2008 12:33:43 -0700 Subject: [Fedora-livecd-list] config/livecd-fedora-desktop.ks Message-ID: <200802111933.m1BJXhOQ012459@hosted1.fedoraproject.org> config/livecd-fedora-desktop.ks | 1 + 1 file changed, 1 insertion(+) New commits: commit 8a5fe014f981a1d94e3cedda613c6d1176ca35c9 Author: Jeremy Katz Date: Mon Feb 11 14:32:43 2008 -0500 Don't install hunspell dicts to save space diff --git a/config/livecd-fedora-desktop.ks b/config/livecd-fedora-desktop.ks index 2738126..8726462 100644 --- a/config/livecd-fedora-desktop.ks +++ b/config/livecd-fedora-desktop.ks @@ -117,6 +117,7 @@ gnome-blog # dictionaries are big -aspell-* +-hunspell-* -man-pages-* -scim-tables-* -wqy-bitmap-fonts From orion at cora.nwra.com Mon Feb 11 21:19:35 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 11 Feb 2008 14:19:35 -0700 Subject: [Fedora-livecd-list] [PATCH] Add support for pxeboot In-Reply-To: <47B0763D.9010702@redhat.com> References: <47B0763D.9010702@redhat.com> Message-ID: <47B0BBE7.9070005@cora.nwra.com> Richard W.M. Jones wrote: > The attached patch adds support for turning a liveCD ISO image into a > network-bootable PXE image. > Thanks for the work. However, for this to be of any real use we're going to need some way to integrate this into an existing PXE boot and /tftpboot configuration. What I would like to be able to do is specify the tftp root directory, the subdirectory to put the kernel and initrd images, and a name for the boot file. In my case I would do something like: /tftpboot/ks/live/devel/minimal/{vmlinuz0,initrd0.img} /tftpboot/ks/pxelinux.cfg/live.devel-minimal : DEFAULT pxeboot TIMEOUT 20 PROMPT 0 LABEL pxeboot KERNEL /live/devel/minimal/vmlinuz0 APPEND initrd=/live/devel/minimal/initrd0.img root=/livecd-fedora-minimal-200802111321.iso rootfstype=iso9660 rootflags=loop ONERROR LOCALBOOT 0 And also have it not try to create pxeboot.0 and pxelinux.cfg. So, something like: livecd-iso-to-pxeboot --tftproot=/tftpboot/ks --imagedir=live/devel/minimal --bootfile=live.devel-minimal livecd-fedora-minimal-200802111321.iso to create the above. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From clalance at redhat.com Mon Feb 11 21:29:11 2008 From: clalance at redhat.com (Chris Lalancette) Date: Mon, 11 Feb 2008 16:29:11 -0500 Subject: [Fedora-livecd-list] [PATCH] Add support for pxeboot In-Reply-To: <47B0BBE7.9070005@cora.nwra.com> References: <47B0763D.9010702@redhat.com> <47B0BBE7.9070005@cora.nwra.com> Message-ID: <47B0BE27.2030503@redhat.com> Orion Poplawski wrote: > And also have it not try to create pxeboot.0 and pxelinux.cfg. > > So, something like: > > livecd-iso-to-pxeboot --tftproot=/tftpboot/ks > --imagedir=live/devel/minimal --bootfile=live.devel-minimal > livecd-fedora-minimal-200802111321.iso > > to create the above. My original idea was to create a local tftpboot directory, and populate it with the stuff that we knew we needed for ourselves; then people are free to integrate it however they want into their existing infrastructure, or just to use it verbatim. I'm afraid with your suggestion that there are going to be too many caveats for too many different infrastructure setups, and you'll just end up with a maze of options. Chris Lalancette From katzj at redhat.com Mon Feb 11 23:53:04 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 11 Feb 2008 18:53:04 -0500 Subject: [Fedora-livecd-list] [PATCH] Add support for pxeboot In-Reply-To: <47B0BE27.2030503@redhat.com> References: <47B0763D.9010702@redhat.com> <47B0BBE7.9070005@cora.nwra.com> <47B0BE27.2030503@redhat.com> Message-ID: <1202773984.23702.53.camel@aglarond.local> On Mon, 2008-02-11 at 16:29 -0500, Chris Lalancette wrote: > Orion Poplawski wrote: > > And also have it not try to create pxeboot.0 and pxelinux.cfg. > > > > So, something like: > > > > livecd-iso-to-pxeboot --tftproot=/tftpboot/ks > > --imagedir=live/devel/minimal --bootfile=live.devel-minimal > > livecd-fedora-minimal-200802111321.iso > > > > to create the above. > > My original idea was to create a local tftpboot directory, and populate it with > the stuff that we knew we needed for ourselves; then people are free to > integrate it however they want into their existing infrastructure, or just to > use it verbatim. I'm afraid with your suggestion that there are going to be too > many caveats for too many different infrastructure setups, and you'll just end > up with a maze of options. Yeah, I think that just outputting something simple that can be copied around is going to be less error-prone. Jeremy From katzj at fedoraproject.org Tue Feb 12 03:53:03 2008 From: katzj at fedoraproject.org (Jeremy Katz) Date: Mon, 11 Feb 2008 20:53:03 -0700 Subject: [Fedora-livecd-list] imgcreate/creator.py Message-ID: <200802120353.m1C3r3cx032281@hosted1.fedoraproject.org> imgcreate/creator.py | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) New commits: commit 2b80ea0024969591d4ef044b68cb31c045d3d2f9 Author: Warren Togami Date: Mon Feb 11 17:59:35 2008 -0500 Fix typos diff --git a/imgcreate/creator.py b/imgcreate/creator.py index 40dcead..c2ed770 100644 --- a/imgcreate/creator.py +++ b/imgcreate/creator.py @@ -122,7 +122,7 @@ class ImageCreator(object): mounting creating and loopback mounting a filesystem image to _instroot. - There is no default implmentation. + There is no default implementation. base_on -- this is the value passed to mount() and can be interpreted as the subclass wishes; it might e.g. be the location of @@ -138,7 +138,7 @@ class ImageCreator(object): in _mount_instroot(). For example, if a filesystem image was mounted onto _instroot, it should be unmounted here. - There is no default implmentation. + There is no default implementation. """ pass @@ -153,7 +153,7 @@ class ImageCreator(object): packages have been installed and the kickstart configuration has been applied, but before the %post scripts have been executed. - There is no default implmentation. + There is no default implementation. """ pass @@ -238,7 +238,7 @@ class ImageCreator(object): A dict should be returned mapping the available kernel types to a list of the available versions for those kernels. - The default implementation uses rpm to iterates over everything + The default implementation uses rpm to iterate over everything providing 'kernel', finds /boot/vmlinuz-* and returns the version obtained from the vmlinuz filename. (This can differ from the kernel RPM's n-v-r in the case of e.g. xen) From clalance at redhat.com Tue Feb 12 04:03:33 2008 From: clalance at redhat.com (Chris Lalancette) Date: Mon, 11 Feb 2008 23:03:33 -0500 Subject: [Fedora-livecd-list] Re: [PATCH] Add support for pxeboot In-Reply-To: <47B0763D.9010702@redhat.com> References: <47B0763D.9010702@redhat.com> Message-ID: <47B11A95.3000400@redhat.com> Richard W.M. Jones wrote: > > (a) The initrd has to carry around dhclient, network scripts, and all > the network programs like '/sbin/ip'. > > (b) The initrd has to be able to find the TFTP server again, which > basically involves making another DHCP query. In Chris's original > implementation he also added specific DHCP options to carry the TFTP > server information since it wasn't clear how to get this out of stock > dhclient. > > (c) After booting, because of (b), the network is already set up, which > is not how a live CD expects it to be. Therefore the live CD itself > would need to be changed if it does any network configuration. This turns out not to be a problem in practice; the network init scripts are just fine re-doing all the configuration that the initrd did, it just takes some time. In particular, another downfall with this method that Richard did not mention is that by the time you've actually booted, you've DHCP'ed 3 times on the same interface; once to find your PXE server and TFTP the kernel/initrd, once in the initrd to fetch your root filesystem, and finally a third time to bring the interface up for real. Each of these takes time, slowing down the boot process. In Richard's version, this is reduced to two DHCP's; the first one to fetch everything via PXE, and the second in the network init scripts. Chris Lalancette From cmadams at hiwaay.net Tue Feb 12 04:17:34 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 11 Feb 2008 22:17:34 -0600 Subject: [Fedora-livecd-list] Re: [PATCH] Add support for pxeboot In-Reply-To: <47B0763D.9010702@redhat.com> References: <47B0763D.9010702@redhat.com> Message-ID: <20080212041734.GB1000216@hiwaay.net> Once upon a time, Richard W.M. Jones said: > The other approach which we looked at and partially implemented was to > modify the normal initrd/init so that it could do a separate request to > download the ISO. Did you look at mounting the ISO over NFS? I would expect that a lot of the cases where PXE is available NFS (or some type of network FS) is available. That's the path I was planning to chase. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From rjones at redhat.com Tue Feb 12 09:34:42 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 12 Feb 2008 09:34:42 +0000 Subject: [Fedora-livecd-list] Re: [PATCH] Add support for pxeboot In-Reply-To: <20080212041734.GB1000216@hiwaay.net> References: <47B0763D.9010702@redhat.com> <20080212041734.GB1000216@hiwaay.net> Message-ID: <47B16832.1000604@redhat.com> Chris Adams wrote: > Once upon a time, Richard W.M. Jones said: >> The other approach which we looked at and partially implemented was to >> modify the normal initrd/init so that it could do a separate request to >> download the ISO. > > Did you look at mounting the ISO over NFS? I would expect that a lot of > the cases where PXE is available NFS (or some type of network FS) is > available. That's the path I was planning to chase. Again, that's possible but also much more complex. The administrator now has to set up an NFS server as well as DHCP, TFTP and PXE. This is designed to be a solution with minimal impact on livecd-creator, and mostly effortless for existing pxeboot administrators. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rjones at redhat.com Tue Feb 12 09:50:32 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 12 Feb 2008 09:50:32 +0000 Subject: [Fedora-livecd-list] [PATCH version 2] Add support for pxeboot Message-ID: <47B16BE8.5090501@redhat.com> Second version of the patch. I have modified it as requested by Jeremy Katz, so that instead of rebuilding the initrd.img, it appends a cpio archive containing the ISO file to the end of the initrd.img. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-pxeboot-2.patch Type: text/x-patch Size: 5539 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rjones at redhat.com Tue Feb 12 09:58:41 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 12 Feb 2008 09:58:41 +0000 Subject: [Fedora-livecd-list] Re: [PATCH] Add support for pxeboot In-Reply-To: <47B11A95.3000400@redhat.com> References: <47B0763D.9010702@redhat.com> <47B11A95.3000400@redhat.com> Message-ID: <47B16DD1.6080903@redhat.com> Chris Lalancette wrote: > This turns out not to be a problem in practice; the network init scripts > are just fine re-doing all the configuration that the initrd did, it > just takes some time. There is a problem: I tried this using a static IP address network configuration in the live CD. The network configuration worked, but then the network broke a few minutes later when the original dhclient woke up and screwed around with the eth0 configuration. This caused my P2V transfer to halt some way through. Of course it's possible to fix even this, but I still maintain that the live CD can be confused by a different network configuration existing at boot than it's expecting (ie. when it's expecting none at all). Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From katzj at fedoraproject.org Tue Feb 12 13:48:50 2008 From: katzj at fedoraproject.org (Jeremy Katz) Date: Tue, 12 Feb 2008 06:48:50 -0700 Subject: [Fedora-livecd-list] 3 commits - config/livecd-fedora-base-desktop.ks imgcreate/yuminst.py Message-ID: <200802121348.m1CDmoo2007395@hosted1.fedoraproject.org> config/livecd-fedora-base-desktop.ks | 3 --- imgcreate/yuminst.py | 3 ++- 2 files changed, 2 insertions(+), 4 deletions(-) New commits: commit 843df455573d95e615f2c573662e82f8cfca401f Author: Jeremy Katz Date: Tue Feb 12 08:46:39 2008 -0500 Ensure that HOME is set to / Some package %post scripts end up using the value of $HOME; let's make sure we don't leak things into the environment that way diff --git a/imgcreate/yuminst.py b/imgcreate/yuminst.py index 55003e2..c42e77e 100644 --- a/imgcreate/yuminst.py +++ b/imgcreate/yuminst.py @@ -147,6 +147,7 @@ class LiveCDYum(yum.YumBase): return repo def runInstall(self): + os.environ["HOME"] = "/" try: (res, resmsg) = self.buildTransaction() except yum.Errors.RepoError, e: commit 0dff0597eae747a10d6f58c7eb98d1ac9ab2201d Author: Jeremy Katz Date: Mon Feb 11 22:33:03 2008 -0500 Remove gparted from the desktop spins gparted now depends on vim-common and thus has a sizable footprint for the live images. Additionally, as anaconda provides support for resizing filesystems, the need for gparted is reduced. diff --git a/config/livecd-fedora-base-desktop.ks b/config/livecd-fedora-base-desktop.ks index 4fe7299..092d621 100644 --- a/config/livecd-fedora-base-desktop.ks +++ b/config/livecd-fedora-base-desktop.ks @@ -55,9 +55,6 @@ memtest86+ -xsane-gimp -sane-backends -# lots of people want to have this -gparted - # livecd bits to set up the livecd and be able to install anaconda isomd5sum commit 6094ff202f8b4bb6eda75473e1c442d4f9a0805c Author: Jeremy Katz Date: Mon Feb 11 22:17:45 2008 -0500 Merge fix I lost moving things between machines diff --git a/imgcreate/yuminst.py b/imgcreate/yuminst.py index 14f4806..55003e2 100644 --- a/imgcreate/yuminst.py +++ b/imgcreate/yuminst.py @@ -105,7 +105,7 @@ class LiveCDYum(yum.YumBase): # we also need to remove from the conditionals # dict so that things don't get pulled back in as a result # of them. yes, this is ugly. conditionals should die. - for req, pkgs in self.tsInfo.conditionals: + for req, pkgs in self.tsInfo.conditionals.iteritems(): if x in pkgs: pkgs.remove(x) self.tsInfo.conditionals[req] = pkgs From katzj at fedoraproject.org Tue Feb 12 18:32:55 2008 From: katzj at fedoraproject.org (Jeremy Katz) Date: Tue, 12 Feb 2008 11:32:55 -0700 Subject: [Fedora-livecd-list] 2 commits - imgcreate/yuminst.py livecd-tools.spec Makefile Message-ID: <200802121832.m1CIWtAE008835@hosted1.fedoraproject.org> Makefile | 2 +- imgcreate/yuminst.py | 2 +- livecd-tools.spec | 11 ++++++++++- 3 files changed, 12 insertions(+), 3 deletions(-) New commits: commit 2130d64d02f1593d73594f0b2f48fe1fc0686ad8 Author: Jeremy Katz Date: Tue Feb 12 13:30:58 2008 -0500 Bump version diff --git a/Makefile b/Makefile index 393d6db..b04cba4 100644 --- a/Makefile +++ b/Makefile @@ -1,5 +1,5 @@ -VERSION = 013 +VERSION = 014 INSTALL = /usr/bin/install -c INSTALL_PROGRAM = ${INSTALL} diff --git a/livecd-tools.spec b/livecd-tools.spec index 8201cc8..7aa5b40 100644 --- a/livecd-tools.spec +++ b/livecd-tools.spec @@ -4,7 +4,7 @@ Summary: Tools for building live CD's Name: livecd-tools -Version: 013 +Version: 014 Release: 1%{?dist} License: GPLv2 Group: System Environment/Base @@ -63,6 +63,15 @@ rm -rf $RPM_BUILD_ROOT %{python_sitelib}/imgcreate/*.pyc %changelog +* Tue Feb 12 2008 Jeremy Katz - 014-1 +- Rework to provide a python API for use by other tools (thanks to + markmc for a lot of the legwork here) +- Fix creation of images with ext2 filesystems and no SELinux +- Don't require a yum-cache directory inside of the cachedir (#430066) +- Many config updates for rawhide +- Allow running live images from MMC/SD (#430444) +- Don't let a non-standard TMPDIR break things (Jim Meyering) + * Mon Oct 29 2007 Jeremy Katz - 013-1 - Lots of config updates - Support 'device foo' to say what modules go in the initramfs commit 9dfce5f149205bdbc1b1761dd637b23772f6e5dd Author: Jeremy Katz Date: Tue Feb 12 13:26:59 2008 -0500 Fix bad import diff --git a/imgcreate/yuminst.py b/imgcreate/yuminst.py index c42e77e..4c9ae40 100644 --- a/imgcreate/yuminst.py +++ b/imgcreate/yuminst.py @@ -23,7 +23,7 @@ import yum import rpmUtils import pykickstart.parser -from yuminst import * +from imgcreate.errors import * class TextProgress(object): def start(self, filename, url, *args, **kwargs): From katzj at fedoraproject.org Tue Feb 12 18:32:58 2008 From: katzj at fedoraproject.org (Jeremy Katz) Date: Tue, 12 Feb 2008 11:32:58 -0700 Subject: [Fedora-livecd-list] Changes to 'refs/tags/livecd-tools-012' Message-ID: <200802121832.m1CIWwKa008908@hosted1.fedoraproject.org> Tag 'livecd-tools-012' created by Jeremy Katz at 2007-09-25 21:38 -0700 livecd-tools-012 Changes since livecd-tools-011-71: --- 0 files changed --- From katzj at fedoraproject.org Tue Feb 12 18:33:16 2008 From: katzj at fedoraproject.org (Jeremy Katz) Date: Tue, 12 Feb 2008 11:33:16 -0700 Subject: [Fedora-livecd-list] Changes to 'refs/tags/livecd-tools-014' Message-ID: <200802121833.m1CIXGCY009113@hosted1.fedoraproject.org> Changes since livecd-tools-012-177: --- 0 files changed --- From katzj at redhat.com Tue Feb 12 18:55:04 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 12 Feb 2008 13:55:04 -0500 Subject: [Fedora-livecd-list] livecd-tools build pushed Message-ID: <1202842504.2729.15.camel@aglarond.local> I've pushed a build of current git of livecd-tools into rawhide so that it can start to get some more testing beyond those of us who are using git. While I don't know of anything big and looming as far as changes to the API, I reserve the right to change it until we're a lot closer to finished with Fedora 9. Now that it's pushed out, though, there are three more things that I want to get into the tree feature-wise for Fedora 9 (and thus, over the next couple of weeks) and otherwise, just focus on finding and fixing up any latent bugs 1) Get Rich's patch from yesterday/today in. I mostly just didn't want to rock the boat since I was pretty comfortable with things as they were but should just be a matter of me doing the commit 2) Get dmc's bits for persistence in 3) Get some of Luke's work for allowing livecd-iso-to-disk to also be useful on Windows (and have a GUI) into the main livecd repo. This is perhaps a little more controversial, but I really don't see the value of maintaining this elsewhere and having two of these scripts. Other opinions welcome, though. Jeremy From katzj at fedoraproject.org Tue Feb 12 21:27:51 2008 From: katzj at fedoraproject.org (Jeremy Katz) Date: Tue, 12 Feb 2008 14:27:51 -0700 Subject: [Fedora-livecd-list] livecd-tools.spec Makefile tools/livecd-iso-to-pxeboot.sh tools/mayflower Message-ID: <200802122127.m1CLRpvg021896@hosted1.fedoraproject.org> Makefile | 1 livecd-tools.spec | 1 tools/livecd-iso-to-pxeboot.sh | 129 +++++++++++++++++++++++++++++++++++++++++ tools/mayflower | 3 4 files changed, 133 insertions(+), 1 deletion(-) New commits: commit e0f0269d3a8f8f310e7c5fdfb8af45892f419c13 Author: Richard W.M. Jones Date: Tue Feb 12 09:50:32 2008 +0000 Add support for pxeboot Myself and Chris Lalancette looked into this in some detail and came up with two different ways to do this. This is the simpler of the two methods and results in the least invasive changes to livecd-creator -- just a single line patch to mayflower and a 100-or-so-line extra script called 'livecd-iso-to-pxeboot' which works analogously to 'livecd-iso-to-disk'. The way it works is to bundle the complete ISO image inside the initrd. The kernel and (bloated) initrd are downloaded using PXE in the normal way, and the init script finds and loopback-mounts the ISO image and booting continues as normal. diff --git a/Makefile b/Makefile index b04cba4..050fe88 100644 --- a/Makefile +++ b/Makefile @@ -19,6 +19,7 @@ install: $(INSTALL_PROGRAM) -D tools/livecd-creator $(DESTDIR)/usr/bin/livecd-creator $(INSTALL_PROGRAM) -D tools/image-creator $(DESTDIR)/usr/bin/image-creator $(INSTALL_PROGRAM) -D tools/livecd-iso-to-disk.sh $(DESTDIR)/usr/bin/livecd-iso-to-disk + $(INSTALL_PROGRAM) -D tools/livecd-iso-to-pxeboot.sh $(DESTDIR)/usr/bin/livecd-iso-to-pxeboot $(INSTALL_PROGRAM) -D tools/mayflower $(DESTDIR)/usr/lib/livecd-creator/mayflower $(INSTALL_DATA) -D AUTHORS $(DESTDIR)/usr/share/doc/livecd-tools-$(VERSION)/AUTHORS $(INSTALL_DATA) -D COPYING $(DESTDIR)/usr/share/doc/livecd-tools-$(VERSION)/COPYING diff --git a/livecd-tools.spec b/livecd-tools.spec index 7aa5b40..a789460 100644 --- a/livecd-tools.spec +++ b/livecd-tools.spec @@ -52,6 +52,7 @@ rm -rf $RPM_BUILD_ROOT %doc AUTHORS COPYING README HACKING %{_bindir}/livecd-creator %{_bindir}/livecd-iso-to-disk +%{_bindir}/livecd-iso-to-pxeboot %dir /usr/lib/livecd-creator /usr/lib/livecd-creator/mayflower %dir %{_datadir}/livecd-tools diff --git a/tools/livecd-iso-to-pxeboot.sh b/tools/livecd-iso-to-pxeboot.sh new file mode 100755 index 0000000..b1ccf5f --- /dev/null +++ b/tools/livecd-iso-to-pxeboot.sh @@ -0,0 +1,129 @@ +#!/bin/bash +# Convert a live CD iso so that it can be booted over the network +# using PXELINUX. +# Copyright 2008 Red Hat, Inc. +# Written by Richard W.M. Jones +# Based on a script by Jeremy Katz +# Based on original work by Chris Lalancette +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU Library General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + +export PATH=/sbin:/usr/sbin:$PATH + +usage() { + echo "Usage: livecd-iso-to-pxeboot " + exit 1 +} + +cleanup() { + [ -d "$CDMNT" ] && umount $CDMNT && rmdir $CDMNT +} + +exitclean() { + echo "Cleaning up to exit..." + cleanup + exit 1 +} + +if [ $(id -u) != 0 ]; then + echo "You need to be root to run this script." + exit 1 +fi + +# Check pxelinux.0 exists. +if [ ! -f /usr/lib/syslinux/pxelinux.0 ]; then + echo "Warning: /usr/lib/syslinux/pxelinux.0 not found." + echo "Make sure syslinux or pxelinux is installed on this system." +fi + +while [ $# -gt 1 ]; do + case "$1" in + *) usage ;; + esac + shift +done + +ISO="$1" + +if [ -z "$ISO" -o ! -e "$ISO" ]; then + usage +fi + +if [ -d tftpboot ]; then + echo "Subdirectory tftpboot exists already. I won't overwrite it." + echo "Delete the subdirectory before running." + exit 1 +fi + +mkdir tftpboot + +# Mount the ISO. +# FIXME: would be better if we had better mountpoints +CDMNT=$(mktemp -d /media/cdtmp.XXXXXX) +mount -o loop "$ISO" $CDMNT || exitclean + +trap exitclean SIGINT SIGTERM + +# Does it look like an ISO? +if [ ! -d $CDMNT/isolinux -o ! -f $CDMNT/isolinux/initrd0.img ]; then + echo "The ISO image doesn't look like a LiveCD ISO image to me." + exitclean +fi + +# Create a cpio archive of just the ISO and append it to the +# initrd image. The Linux kernel will do the right thing, +# aggregating both cpio archives (initrd + ISO) into a single +# filesystem. +ISOBASENAME=`basename "$ISO"` +ISODIRNAME=`dirname "$ISO"` +( cd "$ISODIRNAME" && echo "$ISOBASENAME" | cpio -H newc --quiet -o ) | + gzip -9 | + cat $CDMNT/isolinux/initrd0.img - > tftpboot/initrd0.img + +# Kernel image. +cp $CDMNT/isolinux/vmlinuz0 tftpboot/vmlinuz0 + +# pxelinux bootloader. +if [ -f /usr/lib/syslinux/pxelinux.0 ]; then + cp /usr/lib/syslinux/pxelinux.0 tftpboot +else + echo "Warning: You need to add pxelinux.0 to tftpboot/ subdirectory" +fi + +# pxelinux configuration. +mkdir tftpboot/pxelinux.cfg +cat > tftpboot/pxelinux.cfg/default < References: <1202842504.2729.15.camel@aglarond.local> Message-ID: <47B32899.3090607@cora.nwra.com> Jeremy Katz wrote: > I've pushed a build of current git of livecd-tools into rawhide so that > it can start to get some more testing beyond those of us who are using > git. While I don't know of anything big and looming as far as changes > to the API, I reserve the right to change it until we're a lot closer to > finished with Fedora 9. I'm trying to use it on F-8 but getting: Error creating Live CD : Failed to find package 'gv' : No package(s) available to install Is there any reason to expect that it wouldn't work with the yum in F-8? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jiesun66 at yahoo.com Wed Feb 13 21:28:18 2008 From: jiesun66 at yahoo.com (jie sun) Date: Wed, 13 Feb 2008 13:28:18 -0800 (PST) Subject: [Fedora-livecd-list] livecd-tools build failed In-Reply-To: <47B32899.3090607@cora.nwra.com> Message-ID: <680506.69353.qm@web31610.mail.mud.yahoo.com> Hi, I am trying to use livecd-creator to build a fc7 live cd but it always failed with the following message: Installing: hal ##################### [191/194] Installing: grub ##################### [192/194] Installing: kudzu ##################### [193/194] Installing: redhat-artwork ##################### [194/194] Building an initramfs at /boot/livecd-initramfs.img for kernel 2.6.21-1.3194.fc7 FATAL: Module ide_cd not found. FATAL: Module usbhid not found. Done; initramfs is 4.2M. Error creating Live CD : syslinux not installed : /var/tmp/livecd-creator-lHNeK2/install_root/usr/lib/syslinux/isolinux.bin not found Does anyone has any idea? I tried using livecd-tools-009-3.fc7.noarch.rpm livecd-tools-009-1.fc7.noarch.rpm livecd-tools-008-1.fc7.noarch.rpm livecd-tools-007-1.fc7.noarch.rpm All the same error. Even the following sample command failed. livecd-creator --config=/usr/share/livecd-tools/livecd-fedora-minimal.ks But when I try livecd-creator with my own ks file on FC8, it success. Looks like livecd-tools in fc7 is not working. Regards, Jie Sun --------------------------------- Never miss a thing. Make Yahoo your homepage. -------------- next part -------------- An HTML attachment was scrubbed... URL: From katzj at redhat.com Wed Feb 13 23:14:27 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 13 Feb 2008 18:14:27 -0500 Subject: [Fedora-livecd-list] livecd-tools build pushed In-Reply-To: <47B32899.3090607@cora.nwra.com> References: <1202842504.2729.15.camel@aglarond.local> <47B32899.3090607@cora.nwra.com> Message-ID: <1202944467.31536.39.camel@aglarond.local> On Wed, 2008-02-13 at 10:27 -0700, Orion Poplawski wrote: > Jeremy Katz wrote: > > I've pushed a build of current git of livecd-tools into rawhide so that > > it can start to get some more testing beyond those of us who are using > > git. While I don't know of anything big and looming as far as changes > > to the API, I reserve the right to change it until we're a lot closer to > > finished with Fedora 9. > > I'm trying to use it on F-8 but getting: > > Error creating Live CD : Failed to find package 'gv' : No package(s) > available to install > > Is there any reason to expect that it wouldn't work with the yum in F-8? Nothing I know of, but I also haven't had a chance to try it out on F8. Are you running on an Fedora 8 host or building a Fedora 8 image? That looks like a config just specifying a package which isn't there and so it (correctly) failing Jeremy From ianc2112 at yahoo.co.uk Wed Feb 13 23:32:06 2008 From: ianc2112 at yahoo.co.uk (ian) Date: Wed, 13 Feb 2008 23:32:06 +0000 (GMT) Subject: [Fedora-livecd-list] livecd-tools build failed In-Reply-To: <680506.69353.qm@web31610.mail.mud.yahoo.com> Message-ID: <839472.43997.qm@web27212.mail.ukl.yahoo.com> use program called record now, worked for me. --------------------------------- Sent from Yahoo! - a smarter inbox. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiesun66 at yahoo.com Thu Feb 14 14:41:40 2008 From: jiesun66 at yahoo.com (jie sun) Date: Thu, 14 Feb 2008 06:41:40 -0800 (PST) Subject: [Fedora-livecd-list] livecd-tools build pushed In-Reply-To: <1202944467.31536.39.camel@aglarond.local> Message-ID: <28336.96627.qm@web31605.mail.mud.yahoo.com> Hi Jeremy, I got the same error message while using livecd-creator to create a live cd on fc7. I wonder if this issue has been fixed in fc7? llivecd-creator works fine in fc8. Regards, Jie ======================================================== On Mon, 2007-05-21 at 09:27 +0200, Lars Bj??rndal wrote: > Running livecd-creator, I get the following error message: > > Building an initramfs at /boot/livecd-initramfs.img for kernel > 2.6.21-1.3163.fc7 > FATAL: Module ide_cd not found. > FATAL: Module usbhid not found. > Done; initramfs is 4,3M. > > Should I use an older kernel while building the livecd? No, the messages are misleading... I thought I had killed them off, but apparently not. Patches accepted or I'll get there eventually :-) Jeremy Jeremy Katz wrote: On Wed, 2008-02-13 at 10:27 -0700, Orion Poplawski wrote: > Jeremy Katz wrote: > > I've pushed a build of current git of livecd-tools into rawhide so that > > it can start to get some more testing beyond those of us who are using > > git. While I don't know of anything big and looming as far as changes > > to the API, I reserve the right to change it until we're a lot closer to > > finished with Fedora 9. > > I'm trying to use it on F-8 but getting: > > Error creating Live CD : Failed to find package 'gv' : No package(s) > available to install > > Is there any reason to expect that it wouldn't work with the yum in F-8? Nothing I know of, but I also haven't had a chance to try it out on F8. Are you running on an Fedora 8 host or building a Fedora 8 image? That looks like a config just specifying a package which isn't there and so it (correctly) failing Jeremy -- Fedora-livecd-list mailing list Fedora-livecd-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtogami at redhat.com Fri Feb 15 15:02:52 2008 From: wtogami at redhat.com (Warren Togami) Date: Fri, 15 Feb 2008 10:02:52 -0500 Subject: [Fedora-livecd-list] class ChrootCreator for Review Message-ID: <47B5A99C.7090704@redhat.com> Hi folks, I am attaching changes that implements class ChrootCreator, allowing you to install into a target chroot. chroot-creator is the frontend script that uses this new class. ChrootCreator is similar to existing uses of ImageCreator except the installed chroot is not destroyed after it is done. Any comments to improve this? Warren Togami wtogami at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: creator.py.patch Type: text/x-patch Size: 2524 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chroot-creator.patch Type: text/x-patch Size: 2556 bytes Desc: not available URL: From gary at mlbassoc.com Fri Feb 15 15:12:29 2008 From: gary at mlbassoc.com (Gary Thomas) Date: Fri, 15 Feb 2008 08:12:29 -0700 Subject: [Fedora-livecd-list] livecd-iso-to-disk Message-ID: <47B5ABDD.90601@mlbassoc.com> The documentation on 'livecd-iso-to-disk' is pretty thin. My main [first?] question is once I create such a USB-stick image, how do I boot it? Do I have to have a machine with a BIOS that understands such? Thanks for any help/pointers -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From hpillay at redhat.com Fri Feb 15 15:23:13 2008 From: hpillay at redhat.com (Harish Pillay 9v1hp) Date: Fri, 15 Feb 2008 23:23:13 +0800 Subject: [Fedora-livecd-list] livecd-iso-to-disk In-Reply-To: <47B5ABDD.90601@mlbassoc.com> References: <47B5ABDD.90601@mlbassoc.com> Message-ID: <47B5AE61.3010409@redhat.com> Gary - > The documentation on 'livecd-iso-to-disk' is pretty thin. > My main [first?] question is once I create such a USB-stick > image, how do I boot it? Do I have to have a machine with > a BIOS that understands such? In a word, yes. Typically, you could set up the BIOS to attempt to boot from the USB first, then the CDROM, then the harddisk. HTH. -- Harish Pillay hpillay at redhat.com gpg id: 746809E3 fingerprint: F7F5 5CCD 25B9 FC25 303E 3DA2 0F80 27DB 7468 09E3 From dmc.fedora at filteredperception.org Fri Feb 15 17:40:59 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 15 Feb 2008 11:40:59 -0600 Subject: [Fedora-livecd-list] livecd-iso-to-disk In-Reply-To: <47B5AE61.3010409@redhat.com> References: <47B5ABDD.90601@mlbassoc.com> <47B5AE61.3010409@redhat.com> Message-ID: <47B5CEAB.1060809@filteredperception.org> Harish Pillay 9v1hp wrote: > Gary - > >> The documentation on 'livecd-iso-to-disk' is pretty thin. >> My main [first?] question is once I create such a USB-stick >> image, how do I boot it? Do I have to have a machine with >> a BIOS that understands such? > > In a word, yes. Typically, you could set up the BIOS to > attempt to boot from the USB first, then the CDROM, then > the harddisk. It can also be more complicated than that. For starters, some bioses have an entry (usb-zip?) which will boot from a usb-flash drive if it is formatted in a specific way (see syslinux documentation I think for details). Also, the bios on one of my systems has a lot of options, and I think one of them actually works, but I need to (re)figure out- USB-HDD/USB-FDD/USB-RMD/USB-ARMsomething.... I agree it would be nice to have a good doc that mentions these things. I'll certainly drop some notes when I re-figure out the above choice (usb-hdd didn't seem to work, but I'm pretty sure one of the others did) -dmc From gmureddu at prodigy.net.mx Fri Feb 15 18:37:57 2008 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Fri, 15 Feb 2008 12:37:57 -0600 Subject: [Fedora-livecd-list] Creating i386 LiveCD on x86_64 Fedora Message-ID: <47B5DC05.7030609@prodigy.net.mx> Hello, I'm terribly sorry if this has already been asked, and thus answered. I'm trying to generate an i686 LiveCD image on an x86_64 Fedora, how can I force the packages to be fetched and "installed" be those for i686, or do I need to be running an i686 Fedora? Thanks in advance. From jkeating at redhat.com Fri Feb 15 18:52:56 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 15 Feb 2008 13:52:56 -0500 Subject: [Fedora-livecd-list] Creating i386 LiveCD on x86_64 Fedora In-Reply-To: <47B5DC05.7030609@prodigy.net.mx> References: <47B5DC05.7030609@prodigy.net.mx> Message-ID: <20080215135256.41b6a2e8@redhat.com> On Fri, 15 Feb 2008 12:37:57 -0600 Gian Paolo Mureddu wrote: > Hello, I'm terribly sorry if this has already been asked, and thus > answered. I'm trying to generate an i686 LiveCD image on an x86_64 > Fedora, how can I force the packages to be fetched and "installed" be > those for i686, or do I need to be running an i686 Fedora? call 'setarch i686 livecd-creator ...' -- 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 gmureddu at prodigy.net.mx Fri Feb 15 20:49:50 2008 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Fri, 15 Feb 2008 14:49:50 -0600 Subject: [Fedora-livecd-list] Creating i386 LiveCD on x86_64 Fedora In-Reply-To: <20080215135256.41b6a2e8@redhat.com> References: <47B5DC05.7030609@prodigy.net.mx> <20080215135256.41b6a2e8@redhat.com> Message-ID: <47B5FAEE.4040205@prodigy.net.mx> Jesse Keating escribi?: > On Fri, 15 Feb 2008 12:37:57 -0600 > Gian Paolo Mureddu wrote: > > >> Hello, I'm terribly sorry if this has already been asked, and thus >> answered. I'm trying to generate an i686 LiveCD image on an x86_64 >> Fedora, how can I force the packages to be fetched and "installed" be >> those for i686, or do I need to be running an i686 Fedora? >> > > call 'setarch i686 livecd-creator ...' > > Thank you very much. I had generated other images in a 32-bit install, and when I tried to replicate that in my main system (x86_64) I got an x86_64 image, where I was expecting an i386. Thanks again. From rjones at redhat.com Sat Feb 16 17:39:49 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 16 Feb 2008 17:39:49 +0000 Subject: [Fedora-livecd-list] Creating i386 LiveCD on x86_64 Fedora In-Reply-To: <20080215135256.41b6a2e8@redhat.com> References: <47B5DC05.7030609@prodigy.net.mx> <20080215135256.41b6a2e8@redhat.com> Message-ID: <47B71FE5.6000904@redhat.com> Jesse Keating wrote: > On Fri, 15 Feb 2008 12:37:57 -0600 > Gian Paolo Mureddu wrote: > >> Hello, I'm terribly sorry if this has already been asked, and thus >> answered. I'm trying to generate an i686 LiveCD image on an x86_64 >> Fedora, how can I force the packages to be fetched and "installed" be >> those for i686, or do I need to be running an i686 Fedora? > > call 'setarch i686 livecd-creator ...' That's interesting because I've been generating what are apparently 32 bit images on my x86-64 system just by selecting the i386 repo in the kickstart script: repo --name=released --baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Everything/i386/os/ That seems to work fine and indeed the ISOs I've made have been booting fine on a 32 bit machine. Am I doing something wrong? Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From jkeating at redhat.com Sat Feb 16 20:57:54 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 16 Feb 2008 15:57:54 -0500 Subject: [Fedora-livecd-list] Creating i386 LiveCD on x86_64 Fedora In-Reply-To: <47B71FE5.6000904@redhat.com> References: <47B5DC05.7030609@prodigy.net.mx> <20080215135256.41b6a2e8@redhat.com> <47B71FE5.6000904@redhat.com> Message-ID: <20080216155754.2f9e7149@redhat.com> On Sat, 16 Feb 2008 17:39:49 +0000 "Richard W.M. Jones" wrote: > Am I doing something wrong? I don't believe so. The default repo has an alias for basearch so that you don't have to change it to compose for a different arch. Thus setarch. -- 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 berrange at redhat.com Sun Feb 17 02:14:43 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sun, 17 Feb 2008 02:14:43 +0000 Subject: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool Message-ID: <20080217021443.GH24669@redhat.com> This patch adds support for another installation variant. The livecd-creator produces ISO images which boot using syslinux. The image-creator creates a single file containing a filesystem in which the OS is installated. This patch adds a new disk-creator, which creates a single file containing a partitioned disk with potentially many filesystems in which the OS is installed. Furthermore it installs grub in the boot sector, so this image is immediately bootable in a virtual machine. The idea is that this serves as a tool for creating pre-installed appliances suitable for distribution to end users, with no further installation steps required, beyond potentially an appliance specific firstboot script. I've used this tool to create an instance of the oVirt web management appliance from its kickstart recipe. Currently developers building the appliance have to boot a VM using the F8 boot.iso and run the kickstart script in the VM and so on. While this works, involves many steps with potential for failure. This new tool reduces the problem to simply disk-creator --name ovirt-wui-demo.dsk ovirt-wui-appliance.ks A short while later you end up with 'ovirt-wui-demo.dks' which you can boot straight up in KVM / Xen / etc. With the background information out of the way, here's some info about the changes in this patch... Most of the change here involves re-factoring the imgcreate/fs.py module. The SparseExtLoopbackMount, SparseLoopbackMount, LoopbackMount classes all have the built-in limitation that the image being produced corresponds to a single filesystem / loop mount. With the disk creator, the image being produced can be partitioned into multiple chunks, with many filesystems. Furthermore, not all of them require loopback mounts, as the partitions themselves are already visible via /dev/mapper/ So this patch separates the roles. There are now classes which deal with accessing / creating disks: Disk - generic base for disks RawDisk - a disk backed by a block device LoopbackDisk - a disk backed by a file SparseLoopbackDisk - a disk backed by a sparse file The 'create' method must make the disk visible as a block device - eg by calling losetup. For RawDisk, this is obviously a no-op. The 'cleanup' method must undo the 'create' operation. There are then classes which deal with mounting things: Mount - generic base for mounts DiskMount - able to mount a Disk object ExtDiskMount - able to format/resize ext3 filesystems when mounting The livecd-creator/image-creator tools are updated to take account of these API changes. Next, up we have a new class 'PartitionedMount'. This takes a Disk object and adds one or more partitions to it. It then creates further Disk and Mount object instances for each partition. So, mounting a 'PartitionedMount' object will in fact mount all its partitions (formatting the filesystems or swap space as needed). Currently only ext3/swap is supported for partition types. We use parted to create partitions. This works well enough, but parted will spew lots of scary looking warnings about being unable to tell the kernel to reload its partition table. This is because loop devices don't support partition tables. In this scenario though its not a problem because we then use the kpartx tool to add entries to /dev/mapper for each partition. When mounting partitions, PartitionedMount, figures out the correct order based on the mount points, so it ensures the / is mounted before /boot. The imgcreator/disk.py class contains the DiskImageCreator class which is a subclass of ImageCreator. This uses the PartitionedMount object to do an installation of the kickstart. It is fairly simple at the moment, only being able to cope with 'part' entries in the kickstart which are either ext3 or swap, and which have an explicit size given - ie --grow is not supported. For testing I've been using part /boot --fstype ext3 --size=100 --ondisk=sda part swap --fstype swap --size=500 --ondisk=sda part /var/lib/pgsql --fstype ext3 --size=300 --ondisk=sda part / --fstype ext3 --size=3000 --ondisk=sda part /home --fstype ext3 --size=500 --ondisk=sda part /var --fstype ext3 --size=1000 --ondisk=sda Which ensures it correctly deals with adding extended and logical partitions. It doesn't currently care about --ondisk only outputting a single disk image, but I intend to extend the CLI to allow creation of installs which spawn multiple output disks. Aside from partitioning, DiskImageCreator will setup an fstab file containing entries for all the filesystems and swap space. It will add the grub device map file, and create a grub.cfg based off the installed kernel. It is able to cope with a layout where grub config is on /, or a separate /boot partition. We can't use grub-install since it doesn't understand loopdevices, so to do the MBR install we invoke grub manually. If the disk image happens to be the same size or smaller than one of your USB flash drives, you can also dd the entire image straight to the driver with no modifications required. It should 'just boot' in any machine able to boot off USB Future enhancements for this: - Autosize partitions when --grow is used - Support LVM volumes - Allow splitting across multiple disks (sda, sdb, etc) - Deal with disk filesytem labels - Deal with non-ext3 filesystems - Install to pre-existing block device / LVM vol instead of file - When staging final image, use qemu-img to generate qcow2, vmdk or raw files at user's choice. qcow2 would give huge size savings - Output XML file for use with 'virt-image' tool, so that the entire build and deploy process consists of nothing more than: # disk-creator ovirt-wui-appliance.ks # virt-image ovirt-wui-appliance.xml The last two options are probably my most immediate TODO items because this will result in an excellant virtual appliance creation tool for Fedora derived distros. Perhaps it should be called appliance-creator instead of disk-creator ? Final note - the patch contains a tonne of 'print' statements for debugging. Debugging this stuff can be 'fun' when things go wrong, so I think it may be useful if we make use of the python logging module throughout the livecd tools. If folks agree, I'll switch the 'print' to logging.debug(), otherwise I'll just remove them entirely before reposting this patch The attached patch changes: API | 4 Makefile | 3 imgcreate/__init__.py | 3 imgcreate/creator.py | 17 + imgcreate/disk.py | 20 +- imgcreate/fs.py | 425 ++++++++++++++++++++++++++++++++++++++----------- imgcreate/kickstart.py | 3 imgcreate/live.py | 6 livecd-tools.spec | 1 9 files changed, 376 insertions(+), 106 deletions(-) I'm also attaching the kickstart file I'm using as a demonstration... Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -------------- next part -------------- diff --git a/API b/API index 9783c74..ef9c1aa 100644 --- a/API +++ b/API @@ -76,3 +76,7 @@ switching from the LiveImageCreator to another ImageCreator object. build live images which use dm-snapshot, etc. This is what is used by livecd-creator. +* DiskImageCreator: This generates disk images containing multiple + partitions in a loopback file. It installs grub in the MBR and + can be directly booted in any virtual machine + diff --git a/Makefile b/Makefile index 050fe88..d3d4ab7 100644 --- a/Makefile +++ b/Makefile @@ -18,6 +18,7 @@ all: install: $(INSTALL_PROGRAM) -D tools/livecd-creator $(DESTDIR)/usr/bin/livecd-creator $(INSTALL_PROGRAM) -D tools/image-creator $(DESTDIR)/usr/bin/image-creator + $(INSTALL_PROGRAM) -D tools/disk-creator $(DESTDIR)/usr/bin/disk-creator $(INSTALL_PROGRAM) -D tools/livecd-iso-to-disk.sh $(DESTDIR)/usr/bin/livecd-iso-to-disk $(INSTALL_PROGRAM) -D tools/livecd-iso-to-pxeboot.sh $(DESTDIR)/usr/bin/livecd-iso-to-pxeboot $(INSTALL_PROGRAM) -D tools/mayflower $(DESTDIR)/usr/lib/livecd-creator/mayflower @@ -34,6 +35,8 @@ install: uninstall: rm -f $(DESTDIR)/usr/bin/livecd-creator rm -rf $(DESTDIR)/usr/lib/livecd-creator + rm -rf $(DESTDIR)/usr/bin/disk-creator + rm -rf $(DESTDIR)/usr/bin/image-creator rm -rf $(DESTDIR)/usr/share/doc/livecd-tools-$(VERSION) rm -rf $(DESTDIR)/usr/share/livecd-tools diff --git a/imgcreate/__init__.py b/imgcreate/__init__.py index e535014..44f3ec5 100644 --- a/imgcreate/__init__.py +++ b/imgcreate/__init__.py @@ -21,6 +21,7 @@ from imgcreate.creator import * from imgcreate.yuminst import * from imgcreate.kickstart import * from imgcreate.fs import * +from imgcreate.disk import * """A set of classes for building Fedora system images. @@ -28,6 +29,7 @@ The following image creators are available: - ImageCreator - installs to a directory - LoopImageCreator - installs to an ext3 image - LiveImageCreator - installs to a bootable ISO + - DiskImageCreator - installs to a partitioned disk image Also exported are: - CreatorError - all exceptions throw are of this type @@ -60,6 +62,7 @@ __all__ = ( 'ImageCreator', 'LiveImageCreator', 'LoopImageCreator', + 'DiskImageCreator', 'FSLABEL_MAXLEN', 'read_kickstart', 'construct_name' diff --git a/imgcreate/creator.py b/imgcreate/creator.py index c2ed770..fb3b309 100644 --- a/imgcreate/creator.py +++ b/imgcreate/creator.py @@ -207,7 +207,11 @@ class ImageCreator(object): """ s = "/dev/root / %s defaults,noatime 0 0\n" %(self._fstype) - s += "devpts /dev/pts devpts gid=5,mode=620 0 0\n" + s += self._get_fstab_special() + return s + + def _get_fstab_special(self): + s = "devpts /dev/pts devpts gid=5,mode=620 0 0\n" s += "tmpfs /dev/shm tmpfs defaults 0 0\n" s += "proc /proc proc defaults 0 0\n" s += "sysfs /sys sysfs defaults 0 0\n" @@ -816,12 +820,11 @@ class LoopImageCreator(ImageCreator): if not base_on is None: shutil.copyfile(base_on, self._image) - self.__instloop = SparseExtLoopbackMount(self._image, - self._instroot, - self.__image_size, - self.__fstype, - self.__blocksize, - self.fslabel) + self.__instloop = ExtDiskMount(SparseLoopbackDisk(self._image, self.__image_size), + self._instroot, + self.__fstype, + self.__blocksize, + self.fslabel) try: self.__instloop.mount() diff --git a/imgcreate/disk.py b/imgcreate/disk.py index a0dd6e9..991db01 100644 --- a/imgcreate/disk.py +++ b/imgcreate/disk.py @@ -144,11 +144,12 @@ class DiskImageCreator(ImageCreator): def _create_grub_config(self): (bootdevnum, rootdevnum, rootdev, prefix) = self._get_grub_boot_config() + # XXX don't hardcode default - see livecd code grub = "" grub += "default=0\n" grub += "timeout=5\n" - grub += "splashimage=(hd0,%-d)%s/grub/splash.xpm.gz\n" % (rootdevnum, prefix) - grub += "hiddenemnu\n" + grub += "splashimage=(hd0,%d)%s/grub/splash.xpm.gz\n" % (bootdevnum, prefix) + grub += "hiddenmenu\n" versions = [] kernels = self._get_kernel_versions() @@ -158,11 +159,11 @@ class DiskImageCreator(ImageCreator): for v in versions: grub += "title Fedora (%s)\n" % v - grub += " root (hd0,%-d)\n" % bootdevnum + grub += " root (hd0,%d)\n" % bootdevnum grub += " kernel %s/vmlinuz-%s ro root=%s\n" % (prefix, v, rootdev) grub += " initrd %s/initrd-%s.img\n" % (prefix, v) - cfg = open(self._instroot + "/boot/grub/grub.cfg", "w") + cfg = open(self._instroot + "/boot/grub/grub.conf", "w") cfg.write(grub) cfg.close() @@ -185,11 +186,16 @@ class DiskImageCreator(ImageCreator): def _install_grub(self): (bootdevnum, rootdevnum, rootdev, prefix) = self._get_grub_boot_config() + # Ensure all data is flushed to disk before doing grub install + subprocess.call(["sync"]) + + stage2 = self._instroot + "/boot/grub/stage2" + setup = "" setup += "device (hd0) %s\n" % (self.__instloop.disk.device) - setup += "root (hd0,%d)\n" % rootdevnum - setup += "configfile (hd0,%d)%s/grub/grub.cfg" % (bootdevnum, prefix) - setup += "setup --prefix=%s/grub (hd0) (hd0,%d)\n" % (prefix, bootdevnum) + setup += "root (hd0,%d)\n" % bootdevnum + setup += "setup --stage2=%s --prefix=%s/grub (hd0)\n" % (stage2, prefix) + setup += "quit\n" grub = subprocess.Popen(["grub", "--batch", "--no-floppy"], stdin=subprocess.PIPE) diff --git a/imgcreate/fs.py b/imgcreate/fs.py index 9ca3a3e..b76f38b 100644 --- a/imgcreate/fs.py +++ b/imgcreate/fs.py @@ -86,42 +86,51 @@ class BindChrootMount: subprocess.call(["/bin/umount", self.dest]) self.mounted = False -class LoopbackMount: - def __init__(self, lofile, mountdir, fstype = None): - self.lofile = lofile - self.mountdir = mountdir - self.fstype = fstype +class Disk: + def __init__(self, size, device = None): + self._device = device + self._size = size - self.mounted = False - self.losetup = False - self.rmdir = False - self.loopdev = None + def create(self): + pass def cleanup(self): - self.unmount() - self.lounsetup() + pass - def unmount(self): - if self.mounted: - rc = subprocess.call(["/bin/umount", self.mountdir]) - if rc == 0: - self.mounted = False + def get_device(self): + return self._device + def set_device(self, path): + self._device = path + device = property(get_device, set_device) + + def get_size(self): + return self._size + size = property(get_size) - if self.rmdir and not self.mounted: - try: - os.rmdir(self.mountdir) - except OSError, e: - pass - self.rmdir = False - def lounsetup(self): - if self.losetup: - rc = subprocess.call(["/sbin/losetup", "-d", self.loopdev]) - self.losetup = False - self.loopdev = None +class RawDisk(Disk): + def __init__(self, size, device): + Disk.__init__(self, size, device) + + def fixed(self): + return True + + def exists(self): + return True + +class LoopbackDisk(Disk): + def __init__(self, lofile, size): + Disk.__init__(self, size) + self.lofile = lofile - def loopsetup(self): - if self.losetup: + def fixed(self): + return False + + def exists(self): + return os.path.exists(self.lofile) + + def create(self): + if self.device is not None: return losetupProc = subprocess.Popen(["/sbin/losetup", "-f"], @@ -132,40 +141,27 @@ class LoopbackMount: raise MountError("Failed to allocate loop device for '%s'" % self.lofile) - self.loopdev = losetupOutput.split()[0] + device = losetupOutput.split()[0] - rc = subprocess.call(["/sbin/losetup", self.loopdev, self.lofile]) + print "Losetup add %s %s" % (device, self.lofile) + rc = subprocess.call(["/sbin/losetup", device, self.lofile]) if rc != 0: raise MountError("Failed to allocate loop device for '%s'" % self.lofile) + self.device = device - self.losetup = True - - def mount(self): - if self.mounted: + def cleanup(self): + if self.device is None: return + print "Losetup remove %s" % self.device + rc = subprocess.call(["/sbin/losetup", "-d", self.device]) + self.device = None - self.loopsetup() - if not os.path.isdir(self.mountdir): - os.makedirs(self.mountdir) - self.rmdir = True - - args = [ "/bin/mount", self.loopdev, self.mountdir ] - if self.fstype: - args.extend(["-t", self.fstype]) - rc = subprocess.call(args) - if rc != 0: - raise MountError("Failed to mount '%s' to '%s'" % - (self.loopdev, self.mountdir)) - - self.mounted = True - -class SparseLoopbackMount(LoopbackMount): - def __init__(self, lofile, mountdir, size, fstype = None): - LoopbackMount.__init__(self, lofile, mountdir, fstype) - self.size = size +class SparseLoopbackDisk(LoopbackDisk): + def __init__(self, lofile, size): + LoopbackDisk.__init__(self, lofile, size) def expand(self, create = False, size = None): flags = os.O_WRONLY @@ -191,10 +187,81 @@ class SparseLoopbackMount(LoopbackMount): def create(self): self.expand(create = True) + LoopbackDisk.create(self) + +class Mount: + def __init__(self, mountdir): + self.mountdir = mountdir + + def cleanup(self): + self.unmount() + + def mount(self): + pass + + def unmount(self): + pass + +class DiskMount(Mount): + def __init__(self, disk, mountdir, fstype = None, rmmountdir = True): + Mount.__init__(self, mountdir) + + self.disk = disk + self.fstype = fstype + self.rmmountdir = rmmountdir + + self.mounted = False + self.rmdir = False + + def cleanup(self): + Mount.cleanup(self) + self.disk.cleanup() + + def unmount(self): + if self.mounted: + rc = subprocess.call(["/bin/umount", self.mountdir]) + if rc == 0: + self.mounted = False + + if self.rmdir and not self.mounted: + try: + os.rmdir(self.mountdir) + except OSError, e: + pass + self.rmdir = False + + + def __create(self): + print "Disk create %s" % str(self) + self.disk.create() + + + def mount(self): + if self.mounted: + return + + print "Disk mount" + if not os.path.isdir(self.mountdir): + os.makedirs(self.mountdir) + self.rmdir = self.rmmountdir + + self.__create() + + print "Do mount %s " % self.disk.device + args = [ "/bin/mount", self.disk.device, self.mountdir ] + if self.fstype: + args.extend(["-t", self.fstype]) + + rc = subprocess.call(args) + if rc != 0: + raise MountError("Failed to mount '%s' to '%s'" % + (self.disk.device, self.mountdir)) + + self.mounted = True -class SparseExtLoopbackMount(SparseLoopbackMount): - def __init__(self, lofile, mountdir, size, fstype, blocksize, fslabel): - SparseLoopbackMount.__init__(self, lofile, mountdir, size, fstype) +class ExtDiskMount(DiskMount): + def __init__(self, disk, mountdir, fstype, blocksize, fslabel, rmmountdir=True): + DiskMount.__init__(self, disk, mountdir, fstype, rmmountdir) self.blocksize = blocksize self.fslabel = fslabel @@ -202,19 +269,15 @@ class SparseExtLoopbackMount(SparseLoopbackMount): rc = subprocess.call(["/sbin/mkfs." + self.fstype, "-F", "-L", self.fslabel, "-m", "1", "-b", str(self.blocksize), - self.lofile, - str(self.size / self.blocksize)]) + self.disk.device]) + # str(self.disk.size / self.blocksize)]) if rc != 0: raise MountError("Error creating %s filesystem" % (self.fstype,)) subprocess.call(["/sbin/tune2fs", "-c0", "-i0", "-Odir_index", - "-ouser_xattr,acl", self.lofile]) - - def create(self): - SparseLoopbackMount.create(self) - self.__format_filesystem() + "-ouser_xattr,acl", self.disk.device]) - def resize(self, size = None): - current_size = os.stat(self.lofile)[stat.ST_SIZE] + def __resize_filesystem(self, size = None): + current_size = os.stat(self.disk.lofile)[stat.ST_SIZE] if size is None: size = self.size @@ -227,21 +290,31 @@ class SparseExtLoopbackMount(SparseLoopbackMount): self.__fsck() - resize2fs(self.lofile, size) - - if size < current_size: - self.truncate(size) + resize2fs(self.disk.lofile, size) return size - def mount(self): - if not os.path.isfile(self.lofile): - self.create() + def __create(self): + print "Wibble" + resize = False + if not self.disk.fixed() and self.disk.exists(): + resize = True + + #DiskMount.__create(self) + self.disk.create() + + if resize: + print "Fs resie" + self.__resize_filesystem() else: - self.resize() - return SparseLoopbackMount.mount(self) + print "FS format" + self.__format_filesystem() + + def mount(self): + self.__create() + DiskMount.mount(self) def __fsck(self): - subprocess.call(["/sbin/e2fsck", "-f", "-y", self.lofile]) + subprocess.call(["/sbin/e2fsck", "-f", "-y", self.disk.lofile]) def __get_size_from_filesystem(self): def parse_field(output, field): @@ -253,7 +326,7 @@ class SparseExtLoopbackMount(SparseLoopbackMount): dev_null = os.open("/dev/null", os.O_WRONLY) try: - out = subprocess.Popen(['/sbin/dumpe2fs', '-h', self.lofile], + out = subprocess.Popen(['/sbin/dumpe2fs', '-h', self.disk.lofile], stdout = subprocess.PIPE, stderr = dev_null).communicate()[0] finally: @@ -273,7 +346,7 @@ class SparseExtLoopbackMount(SparseLoopbackMount): while top != (bot + 1): t = bot + ((top - bot) / 2) - if not resize2fs(self.lofile, t): + if not resize2fs(self.disk.lofile, t): top = t else: bot = t @@ -281,12 +354,187 @@ class SparseExtLoopbackMount(SparseLoopbackMount): def resparse(self, size = None): self.cleanup() - minsize = self.__resize_to_minimal() + self.disk.truncate(minsize) + return minsize + +class PartitionedMount(Mount): + def __init__(self, disk, mountdir): + Mount.__init__(self, mountdir) + self.disk = disk + self.partitions = [] + self.mapped = False + self.mountOrder = [] + self.unmountOrder = [] + + def add_partition(self, size, mountpoint, fstype = None): + self.partitions.append({'size': size, 'mountpoint': mountpoint, 'fstype': fstype, 'device': None, 'mount': None, 'num': None}) + + def __format_disk(self): + print "Formatting" + rc = subprocess.call(["/sbin/parted", "-s", self.disk.device, "mklabel", "msdos"]) + if rc != 0: + raise MountError("Error writing partition table on %s" % self.disk.device) + + print "Adding parts" + extSize = 0 + num = 1 + for p in self.partitions: + if num > 3: + extSize += p['size'] + num += 1 + + # XXX we should probably work in cylinder units to keep fdisk happier.. + start = 0 + num = 1 + for p in self.partitions: + if num == 4: + print "Added extened part at %d of size %d" %(start, extSize) + rc = subprocess.call(["/sbin/parted", "-s", self.disk.device, "mkpart", "extended", "%dM" % start, "%dM" % (start+extSize)]) + num += 1 + + type = "primary" + if num > 3: + type = "logical" + print "Add %s part at %d of size %d" % (type, start, p['size']) + rc = subprocess.call(["/sbin/parted", "-s", self.disk.device, "mkpart", type, "%dM" % start, "%dM" % (start+p['size'])]) + if rc != 0 and 1 == 0: # XXX disabled because parted always fails to reload part table with loop devices + raise MountError("Error creating partition on %s" % self.disk.device) + start = start + p['size'] + p['num'] = num + num += 1 + + def __map_partitions(self): + if self.mapped: + return + + kpartx = subprocess.Popen(["/sbin/kpartx", "-l", self.disk.device], + stdout=subprocess.PIPE) + + kpartxOutput = kpartx.communicate()[0].split("\n") + # Strip trailing blank + kpartxOutput = kpartxOutput[0:len(kpartxOutput)-1] + print "Run %s" % str(kpartxOutput) + if kpartx.returncode: + raise MountError("Failed to query partition mapping for '%s'" % + self.disk.device) + + if len(kpartxOutput) != len(self.partitions): + raise MountError("Unexpected number of partitions from kpartx: %d != %d", + len(kpartxOutput), len(self.partitions)) + + for i in range(len(kpartxOutput)): + print " Got %s" % (kpartxOutput[i]) + line = kpartxOutput[i] + dev = line.split()[0] + mapperdev = "/dev/mapper/" + dev + loopdev = self.disk.device + dev[-1] + print "Dev %s: %s -> %s" % (dev, loopdev, mapperdev) + self.partitions[i]['device'] = loopdev + + # grub's install wants partitions to be named + # to match their parent device + partition num + # kpartx doesn't work like this, so we add compat + # symlinks to point to /dev/mapper + os.symlink(mapperdev, loopdev) + + print "Mapping" + rc = subprocess.call(["/sbin/kpartx", "-a", self.disk.device]) + if rc != 0: + raise MountError("Failed to map partitions for '%s'" % + self.disk.device) + self.mapped = True + + + def __unmap_partitions(self): + if not self.mapped: + return + + print "Removing compat symlinks" + for p in self.partitions: + if p['device'] != None: + os.unlink(p['device']) + p['device'] = None + + print "Unmapping" + rc = subprocess.call(["/sbin/kpartx", "-d", self.disk.device]) + if rc != 0: + raise MountError("Failed to unmap partitions for '%s'" % + self.disk.device) + + self.mapped = False + + + def __calculate_mountorder(self): + for p in self.partitions: + self.mountOrder.append(p['mountpoint']) + self.unmountOrder.append(p['mountpoint']) + + self.mountOrder.sort() + self.unmountOrder.sort() + self.unmountOrder.reverse() + print str(self.mountOrder) - self.truncate(minsize) + def cleanup(self): + import time + time.sleep(20) + Mount.cleanup(self) + self.__unmap_partitions() + self.disk.cleanup() + + def unmount(self): + for mp in self.unmountOrder: + if mp == 'swap': + continue + p = None + for p1 in self.partitions: + if p1['mountpoint'] == mp: + p = p1 + break + + if p['mount'] != None: + print "Clenaup %s " % p['mountpoint'] + try: + p['mount'].cleanup() + except: + pass + p['mount'] = None + + def mount(self): + self.disk.create() + + self.__format_disk() + self.__map_partitions() + self.__calculate_mountorder() + + for mp in self.mountOrder: + p = None + for p1 in self.partitions: + if p1['mountpoint'] == mp: + p = p1 + break + + if mp == 'swap': + subprocess.call(["/sbin/mkswap", p['device']]) + continue + + print "Submount %s " % p['mountpoint'] + rmmountdir = False + if p['mountpoint'] == "/": + rmmountdir = True + pdisk = ExtDiskMount(RawDisk(p['size'] * 1024 * 1024, p['device']), + self.mountdir + p['mountpoint'], + p['fstype'], + 4096, + p['mountpoint'], + rmmountdir) + pdisk.mount() + p['mount'] = pdisk + + def resparse(self, size = None): + # Can't re-sparse a disk image - too hard + pass - return self.resize(size) class DeviceMapperSnapshot(object): def __init__(self, imgloop, cowloop): @@ -306,8 +554,8 @@ class DeviceMapperSnapshot(object): if self.__created: return - self.imgloop.loopsetup() - self.cowloop.loopsetup() + self.imgloop.create() + self.cowloop.create() self.__name = "imgcreate-%d-%d" % (os.getpid(), random.randint(0, 2**16)) @@ -315,8 +563,8 @@ class DeviceMapperSnapshot(object): size = os.stat(self.imgloop.lofile)[stat.ST_SIZE] table = "0 %d snapshot %s %s p 8" % (size / 512, - self.imgloop.loopdev, - self.cowloop.loopdev) + self.imgloop.device, + self.cowloop.device) args = ["/sbin/dmsetup", "create", self.__name, "--table", table] if subprocess.call(args) != 0: @@ -382,15 +630,14 @@ class DeviceMapperSnapshot(object): # 8) Create a squashfs of the COW # def create_image_minimizer(path, image, minimal_size): - imgloop = LoopbackMount(image, "None") + imgloop = LoopbackDisk(image, None) # Passing bogus size - doesn't matter - cowloop = SparseLoopbackMount(os.path.join(os.path.dirname(path), "osmin"), - None, 64L * 1024L * 1024L) + cowloop = SparseLoopbackDisk(os.path.join(os.path.dirname(path), "osmin"), + 64L * 1024L * 1024L) snapshot = DeviceMapperSnapshot(imgloop, cowloop) try: - cowloop.create() snapshot.create() resize2fs(snapshot.path, minimal_size) diff --git a/imgcreate/kickstart.py b/imgcreate/kickstart.py index a7e0723..a92f877 100644 --- a/imgcreate/kickstart.py +++ b/imgcreate/kickstart.py @@ -468,6 +468,9 @@ def get_groups(ks, required = []): def get_excluded(ks, required = []): return ks.handler.packages.excludedList + required +def get_partitions(ks, required = []): + return ks.handler.partition.partitions + def ignore_missing(ks): return ks.handler.packages.handleMissing == ksconstants.KS_MISSING_IGNORE diff --git a/imgcreate/live.py b/imgcreate/live.py index bbb17ef..dc2aea9 100644 --- a/imgcreate/live.py +++ b/imgcreate/live.py @@ -130,7 +130,7 @@ class LiveImageCreatorBase(LoopImageCreator): # def __base_on_iso(self, base_on): """helper function to extract ext3 file system from a live CD ISO""" - isoloop = LoopbackMount(base_on, self._mkdtemp()) + isoloop = Mount(LoopbackDisk(base_on), self._mkdtemp()) try: isoloop.mount() @@ -144,10 +144,10 @@ class LiveImageCreatorBase(LoopImageCreator): else: squashimg = isoloop.mountdir + "/LiveOS/squashfs.img" - squashloop = LoopbackMount(squashimg, self._mkdtemp(), "squashfs") + squashloop = Mount(LoopbackDisk(squashimg), self._mkdtemp(), "squashfs") try: - if not os.path.exists(squashloop.lofile): + if not squashloop.disk.exists(): raise CreatorError("'%s' is not a valid live CD ISO : " "squashfs.img doesn't exist" % base_on) diff --git a/livecd-tools.spec b/livecd-tools.spec index a789460..d9118ba 100644 --- a/livecd-tools.spec +++ b/livecd-tools.spec @@ -58,6 +58,7 @@ rm -rf $RPM_BUILD_ROOT %dir %{_datadir}/livecd-tools %{_datadir}/livecd-tools/* %{_bindir}/image-creator +%{_bindir}/disk-creator %dir %{python_sitelib}/imgcreate %{python_sitelib}/imgcreate/*.py %{python_sitelib}/imgcreate/*.pyo -------------- next part -------------- # Kickstart file automatically generated by anaconda. install url --url http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Fedora/x86_64/os/ lang en_US.UTF-8 keyboard us network --device eth0 --bootproto dhcp rootpw --iscrypted $1$HNOucon/$m69RprODwQn4XjzVUi9TU0 firewall --disabled authconfig --enableshadow --enablemd5 selinux --disabled services --disabled=iptables,yum-updatesd,libvirtd,bluetooth,cups,gpm,pcscd --enabled=ntpd,dhcpd,xinetd,httpd,postgresql,ovirt-wui timezone --utc America/New_York text bootloader --location=mbr --driveorder=sda # The following is the partition information you requested # Note that any partitions you deleted are not expressed # here so unless you clear all partitions first, this is # not guaranteed to work zerombr clearpart --all --drives=sda part /boot --fstype ext3 --size=100 --ondisk=sda part swap --fstype swap --size=500 --grow --ondisk=sda part /var/lib/pgsql --fstype ext3 --size=300 --ondisk=sda part / --fstype ext3 --size=3000 --grow --ondisk=sda part /home --fstype ext3 --size=500 --grow --ondisk=sda part /var --fstype ext3 --size=1000 --ondisk=sda #part pv.2 --size=3000 --grow --ondisk=sda #volgroup VolGroup00 --pesize=32768 pv.2 #logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=512 #logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow repo --name=f8 --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=$basearch repo --name=f8-updates --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f8&arch=$basearch # Not using rawhide currently #repo --name=rawhide --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=$basearch repo --name=freeipa --baseurl=http://freeipa.com/downloads/devel/rpms/F7/$basearch/ repo --name=ovirt --baseurl=http://ovirt.et.redhat.com/repos/ovirt/$basearch/ %packages @admin-tools @editors @system-tools @text-internet @core @base @hardware-support @web-server @sql-server @development-libs @legacy-fonts @development-tools radeontool fuse pax imake dhcp tftp-server tftp dhclient ipa-server ipa-admintools xinetd libvirt cyrus-sasl-gssapi iscsi-initiator-utils collectd ruby-libvirt ruby-postgres ovirt-wui firefox xorg-x11-xauth virt-viewer -libgcj -glib-java -valgrind -boost-devel -frysk -bittorrent -fetchmail -slrn -cadaver -mutt %post cat > /root/create_default_principals.py << \EOF #!/usr/bin/python import krbV import os, string, re import socket import shutil def kadmin_local(command): ret = os.system("/usr/kerberos/sbin/kadmin.local -q '" + command + "'") if ret != 0: raise default_realm = krbV.Context().default_realm # here, generate the libvirt/ principle for this machine, necessary # for taskomatic and host-browser this_libvirt_princ = 'libvirt/' + socket.gethostname() + '@' + default_realm kadmin_local('addprinc -randkey +requires_preauth ' + this_libvirt_princ) kadmin_local('ktadd -k /usr/share/ovirt-wui/ovirt.keytab ' + this_libvirt_princ) # We need to replace the KrbAuthRealms in the ovirt-wui http configuration # file to be the correct Realm (i.e. default_realm) ovirtconfname = '/etc/httpd/conf.d/ovirt-wui.conf' ipaconfname = '/etc/httpd/conf.d/ipa.conf' # make sure we skip this on subsequent runs of this script if string.find(file(ipaconfname, 'rb').read(), '') < 0: ipaconf = open(ipaconfname, 'r') ipatext = ipaconf.readlines() ipaconf.close() ipaconf2 = open(ipaconfname, 'w') print >>ipaconf2, "Listen 8089" print >>ipaconf2, "NameVirtualHost *:8089" print >>ipaconf2, "" for line in ipatext: newline = re.sub(r'(.*RewriteCond %{HTTP_HOST}.*)', r'#\1', line) newline = re.sub(r'(.*RewriteRule \^/\(.*\).*)', r'#\1', newline) newline = re.sub(r'(.*RewriteCond %{SERVER_PORT}.*)', r'#\1', newline) newline = re.sub(r'(.*RewriteCond %{REQUEST_URI}.*)', r'#\1', newline) ipaconf2.write(newline) print >>ipaconf2, "" ipaconf2.close() if string.find(file(ovirtconfname, 'rb').read(), '') < 0: ovirtconf = open(ovirtconfname, 'r') ovirttext = ovirtconf.readlines() ovirtconf.close() ovirtconf2 = open(ovirtconfname, 'w') print >>ovirtconf2, "NameVirtualHost *:80" print >>ovirtconf2, "" for line in ovirttext: newline = re.sub(r'(.*)KrbAuthRealms.*', r'\1KrbAuthRealms ' + default_realm, line) newline = re.sub(r'(.*)Krb5KeyTab.*', r'\1Krb5KeyTab /etc/httpd/conf/ipa.keytab', newline) ovirtconf2.write(newline) print >>ovirtconf2, "" ovirtconf2.close() EOF chmod +x /root/create_default_principals.py cat > /root/add_host_principal.py << \EOF #!/usr/bin/python import krbV import os import socket import shutil import sys def kadmin_local(command): ret = os.system("/usr/kerberos/sbin/kadmin.local -q '" + command + "'") if ret != 0: raise def get_ip(hostname): return socket.gethostbyname(hostname) if len(sys.argv) != 2: print "Usage: add_host_principal.py " sys.exit(1) default_realm = krbV.Context().default_realm ipaddr = get_ip(sys.argv[1]) libvirt_princ = 'libvirt/' + sys.argv[1] + '@' + default_realm outname = '/usr/share/ipa/html/' + ipaddr + '-libvirt.tab' # here, generate the libvirt/ principle for this machine, necessary # for taskomatic and host-browser kadmin_local('addprinc -randkey +requires_preauth ' + libvirt_princ) kadmin_local('ktadd -k ' + outname + ' ' + libvirt_princ) # make sure it is readable by apache os.chmod(outname, 0644) EOF chmod +x /root/add_host_principal.py cat > /usr/share/ovirt-wui/psql.cmds << \EOF CREATE USER ovirt WITH PASSWORD 'v23zj59an'; CREATE DATABASE ovirt; GRANT ALL PRIVILEGES ON DATABASE ovirt to ovirt; CREATE DATABASE ovirt_test; GRANT ALL PRIVILEGES ON DATABASE ovirt_test to ovirt; EOF chmod a+r /usr/share/ovirt-wui/psql.cmds cat > /etc/init.d/ovirt-app-first-run << \EOF #!/bin/bash # # ovirt-app-first-run First run configuration for Ovirt WUI appliance # # chkconfig: 3 99 01 # description: ovirt appliance first run configuration # # Source functions library . /etc/init.d/functions start() { service postgresql initdb echo "local all all trust" > /var/lib/pgsql/data/pg_hba.conf echo "host all all 127.0.0.1 255.255.255.0 trust" >> /var/lib/pgsql/data/pg_hba.conf service postgresql start su - postgres -c "/usr/bin/psql -f /usr/share/ovirt-wui/psql.cmds" cd /usr/share/ovirt-wui ; rake db:migrate /usr/bin/ovirt_grant_admin_privileges.sh admin } case "$1" in start) start ;; *) echo "Usage: ovirt {start}" exit 2 esac chkconfig ovirt-app-first-run off EOF chmod +x /etc/init.d/ovirt-app-first-run chkconfig ovirt-app-first-run on sed -i -e 's/\(.*\)disable\(.*\)= yes/\1disable\2= no/' /etc/xinetd.d/tftp # set up the yum repos cat > /etc/yum.repos.d/freeipa.repo << \EOF [freeipa] name=FreeIPA Development baseurl=http://freeipa.com/downloads/devel/rpms/F7/x86_64/ enabled=1 gpgcheck=0 EOF cat > /etc/yum.repos.d/ovirt.repo << \EOF [ovirt] name=Ovirt baseurl=http://ovirt.et.redhat.com/repos/ovirt/x86_64 enabled=1 gpgcheck=0 EOF # pretty login screen.. echo -e "" > /etc/issue echo -e " 888 888 \\033[0;32md8b\\033[0;39m 888 " >> /etc/issue echo -e " 888 888 \\033[0;32mY8P\\033[0;39m 888 " >> /etc/issue echo -e " 888 888 888 " >> /etc/issue echo -e " .d88b. Y88b d88P 888 888d888 888888 " >> /etc/issue echo -e " d88''88b Y88b d88P 888 888P' 888 " >> /etc/issue echo -e " 888 888 Y88o88P 888 888 888 " >> /etc/issue echo -e " Y88..88P Y888P 888 888 Y88b. " >> /etc/issue echo -e " 'Y88P' Y8P 888 888 'Y888 " >> /etc/issue echo -e "" >> /etc/issue echo -e " Admin node \\\\n " >> /etc/issue echo -e "" >> /etc/issue echo -e " Virtualization just got the \\033[0;32mGreen Light\\033[0;39m" >> /etc/issue echo -e "" >> /etc/issue cp /etc/issue /etc/issue.net echo "0.fedora.pool.ntp.org" >> /etc/ntp/step-tickers # remove the mod_auth_kerb, and make sure we get the one from freeipa rpm -e --nodeps mod_auth_kerb yum -y --disablerepo=* --enablerepo=freeipa install mod_auth_kerb # with the new libvirt (0.4.0), make sure we we setup gssapi in the mech_list sed -i -e 's/mech_list: digest-md5/#mech_list: digest-md5/' /etc/sasl2/libvirt.conf sed -i -e 's/#mech_list: gssapi/mech_list: gssapi/' /etc/sasl2/libvirt.conf # for firefox, we need to add the following to ~/.mozilla/firefox/zzzzz/prefs.js #echo 'user_pref("network.negotiate-auth.delegation-uris", ".redhat.com");' >> ~/.mozilla/firefox/zzzz/prefs.js #echo 'user_pref("network.negotiate-auth.trusted-uris", ".redhat.com");' >> ~/.mozilla/firefox/zzzz/prefs.js %end From dmc.fedora at filteredperception.org Sun Feb 17 05:18:58 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sat, 16 Feb 2008 23:18:58 -0600 Subject: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool In-Reply-To: <20080217021443.GH24669@redhat.com> References: <20080217021443.GH24669@redhat.com> Message-ID: <47B7C3C2.3090202@filteredperception.org> Daniel P. Berrange wrote: > This patch adds support for another installation variant. The livecd-creator > produces ISO images which boot using syslinux. The image-creator creates a > single file containing a filesystem in which the OS is installated. This patch > adds a new disk-creator, which creates a single file containing a partitioned > disk with potentially many filesystems in which the OS is installed. Furthermore > it installs grub in the boot sector, so this image is immediately bootable in > a virtual machine. FWIW, I advocate, (and my VirOS projects already uses), a system where such a virtual appliance is a mandatory phase of livecd creation. I don't expect any buy-in to convert livecd-creator to this, but this seems an appropriate time to advocate the design choice- Basically, I see it as useful to look at the process as distro_config --(phase1process)--> virtual_appliance_disk_image --(phase2process)--> livecd_image Where an alternate phase2process plugin could be for example - network push deploy to physical host. Or, instantiate to virtual host. Basically it seems like since what livecd-creator uses internally, is already _so close_ to an appliance image like this new disk-creator creates already, why not just go ahead and do it (also, theoretically for QA turnaround time, testing new stuff as virtappliance_diskimage is much quicker than waiting for full livecd mksquashfs processing) Another reason why I like that pipeline breakdown, is because the sorts of things that go on in phase2process can even be largely distribution agnostic. Combined with alternate phase1process plugins that support other distributions, and you get quite a flexible provisioning tool. $0.02... -dmc From dmc.fedora at filteredperception.org Sun Feb 17 05:29:24 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sat, 16 Feb 2008 23:29:24 -0600 Subject: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool In-Reply-To: <47B7C3C2.3090202@filteredperception.org> References: <20080217021443.GH24669@redhat.com> <47B7C3C2.3090202@filteredperception.org> Message-ID: <47B7C634.5070209@filteredperception.org> Douglas McClendon wrote: > Daniel P. Berrange wrote: >> This patch adds support for another installation variant. The >> livecd-creator >> produces ISO images which boot using syslinux. The image-creator >> creates a >> single file containing a filesystem in which the OS is installated. >> This patch >> adds a new disk-creator, which creates a single file containing a >> partitioned >> disk with potentially many filesystems in which the OS is installed. >> Furthermore >> it installs grub in the boot sector, so this image is immediately >> bootable in >> a virtual machine. > > FWIW, I advocate, (and my VirOS projects already uses), a system where > such a virtual appliance is a mandatory phase of livecd creation. I > don't expect any buy-in to convert livecd-creator to this, but this > seems an appropriate time to advocate the design choice- > > Basically, I see it as useful to look at the process as > > distro_config > > --(phase1process)--> > > virtual_appliance_disk_image > > --(phase2process)--> > > livecd_image Also, one other advantage of this pipeline, is that having the virt_appliance_disk_image, allows you to add interesting extra steps to the pipeline that involve virtually booting the appliance. The two that come to mind are a) virt booting to precook auto-logged-in-user home directory contents such that they needn't be created during livecd boot and live in ram (instead living in the squashfs). b) virt booting to determine optimal ways to perform the livecd creation processing. (i.e. determining boot file access order, and then sorting the filesystem... I still need to prove that that is worth it, but I think it is) -dmc From berrange at redhat.com Sun Feb 17 14:27:09 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sun, 17 Feb 2008 14:27:09 +0000 Subject: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool In-Reply-To: <47B7C3C2.3090202@filteredperception.org> References: <20080217021443.GH24669@redhat.com> <47B7C3C2.3090202@filteredperception.org> Message-ID: <20080217142709.GA28254@redhat.com> On Sat, Feb 16, 2008 at 11:18:58PM -0600, Douglas McClendon wrote: > Daniel P. Berrange wrote: > >This patch adds support for another installation variant. The > >livecd-creator > >produces ISO images which boot using syslinux. The image-creator creates a > >single file containing a filesystem in which the OS is installated. This > >patch > >adds a new disk-creator, which creates a single file containing a > >partitioned > >disk with potentially many filesystems in which the OS is installed. > >Furthermore > >it installs grub in the boot sector, so this image is immediately bootable > >in > >a virtual machine. > > FWIW, I advocate, (and my VirOS projects already uses), a system where > such a virtual appliance is a mandatory phase of livecd creation. I > don't expect any buy-in to convert livecd-creator to this, but this > seems an appropriate time to advocate the design choice- > > Basically, I see it as useful to look at the process as > > distro_config > > --(phase1process)--> > > virtual_appliance_disk_image > > --(phase2process)--> > > livecd_image > > Where an alternate phase2process plugin could be for example - network > push deploy to physical host. Or, instantiate to virtual host. The seperation between different processes is more or less what we already have in the live cd code, though not as a pipeline, instead via class inheritance. The livecd library base has the generic logic for processing the kickstarting & doing the installation. The livecd/image/ disk creators simply subclass it to add specific code for either ISOs, flat images, or partitioned disks, along with the particular type of bootloader needed (syslinux vs grub). > Basically it seems like since what livecd-creator uses internally, is > already _so close_ to an appliance image like this new disk-creator > creates already, why not just go ahead and do it (also, theoretically > for QA turnaround time, testing new stuff as virtappliance_diskimage is > much quicker than waiting for full livecd mksquashfs processing) There is no significant time difference between any of the tools. If you add the secret undocumented --skip-compression and --skip-minimize flags to livecd-creator, it'll be just as fast as the disk creator. > Another reason why I like that pipeline breakdown, is because the sorts > of things that go on in phase2process can even be largely distribution > agnostic. Combined with alternate phase1process plugins that support > other distributions, and you get quite a flexible provisioning tool. A significant part of the phase 2 procss is dealing with the bootloader and initrd setup which is far from distro-agnostic. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From dmc.fedora at filteredperception.org Sun Feb 17 19:55:03 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 17 Feb 2008 13:55:03 -0600 Subject: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool In-Reply-To: <20080217142709.GA28254@redhat.com> References: <20080217021443.GH24669@redhat.com> <47B7C3C2.3090202@filteredperception.org> <20080217142709.GA28254@redhat.com> Message-ID: <47B89117.3090805@filteredperception.org> Daniel P. Berrange wrote: > On Sat, Feb 16, 2008 at 11:18:58PM -0600, Douglas McClendon wrote: >> Another reason why I like that pipeline breakdown, is because the sorts >> of things that go on in phase2process can even be largely distribution >> agnostic. Combined with alternate phase1process plugins that support >> other distributions, and you get quite a flexible provisioning tool. > > A significant part of the phase 2 procss is dealing with the bootloader > and initrd setup which is far from distro-agnostic. Well, livecd was just one of the multiple phase2process options I listed. (others were push to a server, and instantiate as a virt host). And even in the livecd case, I admit, there are significant differences, but it is actually quite an educational problem to refactor the distro specific differences and the things that are general to most distros. For instance, I wrote my own initramfs init for fedora based on what I saw as the best features of both the existing livecd-tools version, and the very mature and flexible architecture that ubuntu's casper uses. The next addition I plan to make to it is to support unionfs copy-on-write for fedora, and then to support ubuntu/debian as bases. I do not anticipate that this will actually be a terribly hard thing to do (for me, given my experience in the area). For reference, my initramfs init is browsable here- http://filteredperception.org/smiley/projects/viros/viros-0.5/tools/ZyX-Live-OS/live.init.html But yes, definitely non trivial, but something I plan to have fun doing... -dmc From berrange at redhat.com Sun Feb 17 21:26:04 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sun, 17 Feb 2008 21:26:04 +0000 Subject: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool In-Reply-To: <20080217021443.GH24669@redhat.com> References: <20080217021443.GH24669@redhat.com> Message-ID: <20080217212604.GA10935@redhat.com> On Sun, Feb 17, 2008 at 02:14:43AM +0000, Daniel P. Berrange wrote: > Future enhancements for this: > > - Allow splitting across multiple disks (sda, sdb, etc) > > - When staging final image, use qemu-img to generate qcow2, vmdk > or raw files at user's choice. qcow2 would give huge size savings > > - Output XML file for use with 'virt-image' tool, so that the entire > build and deploy process consists of nothing more than: > > # disk-creator ovirt-wui-appliance.ks > # virt-image ovirt-wui-appliance.xml This new version of the patch implements all three of the above features. As an example, creating an appliance with 2 disks (sda & sdb), outputting in qcow2 format: disk-creator --format qcow2 \ --name ovirt-wui \ --disk ovirt-wui-os --size 5000 \ --disk ovirt-wui-data --size 1000 \ ovirt-wui-appliance.ks You'll end up with ovirt-wui-os.qcow2, ovirt-wui-data.qcow2 and ovirt-wui.xml This can be deployed as a VM with virt-image --connect qemu:///system ovirt-wui.xml Well, due to a bug in virt-image, it'll refuse to create a VM with qcow2 disks, but I've fixed that upstream. For now just leave out the --format arg to create in raw file. I'm definitely now of opinion we should actually name it appliance-creator instead of disk-creator, but not changed it in this patch yet. The attached patch touches: API | 4 Makefile | 3 imgcreate/__init__.py | 3 imgcreate/creator.py | 17 + imgcreate/disk.py | 146 ++++++++++---- imgcreate/fs.py | 480 +++++++++++++++++++++++++++++++++++++++---------- imgcreate/kickstart.py | 3 imgcreate/live.py | 6 livecd-tools.spec | 1 tools/disk-creator | 49 ++++- 10 files changed, 569 insertions(+), 143 deletions(-) Also attaching the new kickstart file I'm using for multi-disks. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -------------- next part -------------- diff --git a/API b/API index 9783c74..ef9c1aa 100644 --- a/API +++ b/API @@ -76,3 +76,7 @@ switching from the LiveImageCreator to another ImageCreator object. build live images which use dm-snapshot, etc. This is what is used by livecd-creator. +* DiskImageCreator: This generates disk images containing multiple + partitions in a loopback file. It installs grub in the MBR and + can be directly booted in any virtual machine + diff --git a/Makefile b/Makefile index 050fe88..d3d4ab7 100644 --- a/Makefile +++ b/Makefile @@ -18,6 +18,7 @@ all: install: $(INSTALL_PROGRAM) -D tools/livecd-creator $(DESTDIR)/usr/bin/livecd-creator $(INSTALL_PROGRAM) -D tools/image-creator $(DESTDIR)/usr/bin/image-creator + $(INSTALL_PROGRAM) -D tools/disk-creator $(DESTDIR)/usr/bin/disk-creator $(INSTALL_PROGRAM) -D tools/livecd-iso-to-disk.sh $(DESTDIR)/usr/bin/livecd-iso-to-disk $(INSTALL_PROGRAM) -D tools/livecd-iso-to-pxeboot.sh $(DESTDIR)/usr/bin/livecd-iso-to-pxeboot $(INSTALL_PROGRAM) -D tools/mayflower $(DESTDIR)/usr/lib/livecd-creator/mayflower @@ -34,6 +35,8 @@ install: uninstall: rm -f $(DESTDIR)/usr/bin/livecd-creator rm -rf $(DESTDIR)/usr/lib/livecd-creator + rm -rf $(DESTDIR)/usr/bin/disk-creator + rm -rf $(DESTDIR)/usr/bin/image-creator rm -rf $(DESTDIR)/usr/share/doc/livecd-tools-$(VERSION) rm -rf $(DESTDIR)/usr/share/livecd-tools diff --git a/imgcreate/__init__.py b/imgcreate/__init__.py index e535014..44f3ec5 100644 --- a/imgcreate/__init__.py +++ b/imgcreate/__init__.py @@ -21,6 +21,7 @@ from imgcreate.creator import * from imgcreate.yuminst import * from imgcreate.kickstart import * from imgcreate.fs import * +from imgcreate.disk import * """A set of classes for building Fedora system images. @@ -28,6 +29,7 @@ The following image creators are available: - ImageCreator - installs to a directory - LoopImageCreator - installs to an ext3 image - LiveImageCreator - installs to a bootable ISO + - DiskImageCreator - installs to a partitioned disk image Also exported are: - CreatorError - all exceptions throw are of this type @@ -60,6 +62,7 @@ __all__ = ( 'ImageCreator', 'LiveImageCreator', 'LoopImageCreator', + 'DiskImageCreator', 'FSLABEL_MAXLEN', 'read_kickstart', 'construct_name' diff --git a/imgcreate/creator.py b/imgcreate/creator.py index c2ed770..fb3b309 100644 --- a/imgcreate/creator.py +++ b/imgcreate/creator.py @@ -207,7 +207,11 @@ class ImageCreator(object): """ s = "/dev/root / %s defaults,noatime 0 0\n" %(self._fstype) - s += "devpts /dev/pts devpts gid=5,mode=620 0 0\n" + s += self._get_fstab_special() + return s + + def _get_fstab_special(self): + s = "devpts /dev/pts devpts gid=5,mode=620 0 0\n" s += "tmpfs /dev/shm tmpfs defaults 0 0\n" s += "proc /proc proc defaults 0 0\n" s += "sysfs /sys sysfs defaults 0 0\n" @@ -816,12 +820,11 @@ class LoopImageCreator(ImageCreator): if not base_on is None: shutil.copyfile(base_on, self._image) - self.__instloop = SparseExtLoopbackMount(self._image, - self._instroot, - self.__image_size, - self.__fstype, - self.__blocksize, - self.fslabel) + self.__instloop = ExtDiskMount(SparseLoopbackDisk(self._image, self.__image_size), + self._instroot, + self.__fstype, + self.__blocksize, + self.fslabel) try: self.__instloop.mount() diff --git a/imgcreate/disk.py b/imgcreate/disk.py index a0dd6e9..6027b75 100644 --- a/imgcreate/disk.py +++ b/imgcreate/disk.py @@ -37,7 +37,7 @@ class DiskImageCreator(ImageCreator): """ - def __init__(self, ks, name): + def __init__(self, ks, name, disks, format="raw"): """Initialize a DiskImageCreator instance. This method takes the same arguments as ImageCreator.__init__() @@ -47,32 +47,20 @@ class DiskImageCreator(ImageCreator): self.__instloop = None self.__imgdir = None - - # XXX configure me :-) - self.__disk_size = 8192L * 1024 * 1024 - - def __get_disk(self): - if self.__imgdir is None: - raise CreatorError("_disk is not valid before calling mount()") - return self.__imgdir + "/disk.dsk" - _disk = property(__get_disk) - """The location of the disk file. - - This is the path to the filesystem disk. Subclasses may use this path - in order to package the disk in _stage_final_disk(). - - Note, this directory does not exist before DiskCreator.mount() is called. - - Note also, this is a read-only attribute. - - """ + self.__disks = disks + self.__format = format def _get_fstab(self): s = "" - # XXX > 1 disk, don't assume sda - for p in self.__instloop.partitions: + for mp in self.__instloop.mountOrder: + p = None + for p1 in self.__instloop.partitions: + if p1['mountpoint'] == mp: + p = p1 + break + s += "%(device)s %(mountpoint)s %(fstype)s defaults,noatime 0 0\n" % { - 'device': "/dev/sda%-d" % p['num'], + 'device': "/dev/%s%-d" % (p['disk'], p['num']), 'mountpoint': p['mountpoint'], 'fstype': p['fstype'] } @@ -86,18 +74,35 @@ class DiskImageCreator(ImageCreator): self.__imgdir = self._mkdtemp() parts = kickstart.get_partitions(self.ks) + + devnames = [] + for p in parts: + dev = p.disk + if not dev in devnames: + devnames.append(dev) + devnames.sort() - self.__instloop = PartitionedMount(SparseLoopbackDisk(self._disk, self.__disk_size), + disks = [] + + if len(devnames) != len(self.__disks): + raise CreatorError("Not enough disks for declared partitions") + + for i in range(len(self.__disks)): + disk = SparseLoopbackDisk("%s/disk%d.raw" % (self.__imgdir, i), + self.__disks[i]['size']) + self.__disks[i]['disk'] = disk + disks.append(disk) + + self.__instloop = PartitionedMount(disks, devnames, self._instroot) for p in parts: - self.__instloop.add_partition(int(p.size), p.mountpoint, p.fstype) + self.__instloop.add_partition(int(p.size), p.disk, p.mountpoint, p.fstype) try: self.__instloop.mount() except MountError, e: - raise CreatorError("Failed mount '%s' : %s" % - (self._disk, e)) + raise CreatorError("Failed mount disks : %s" % e) def _get_required_packages(self): return ["grub"] @@ -110,6 +115,8 @@ class DiskImageCreator(ImageCreator): if not dev in devs: devs.append(dev) + devs.sort() + n = 0 devmap = "" for dev in devs: @@ -124,7 +131,6 @@ class DiskImageCreator(ImageCreator): bootdevnum = None rootdevnum = None rootdev = None - # XXX > 1 disk, don't assume sda for p in self.__instloop.partitions: if p['mountpoint'] == "/boot": bootdevnum = p['num'] - 1 @@ -133,7 +139,7 @@ class DiskImageCreator(ImageCreator): if p['mountpoint'] == "/": rootdevnum = p['num'] - 1 - rootdev = "/dev/sda%-d" % p['num'] + rootdev = "/dev/%s%-d" % (p['disk'], p['num']) prefix = "" if bootdevnum == rootdevnum: @@ -144,11 +150,15 @@ class DiskImageCreator(ImageCreator): def _create_grub_config(self): (bootdevnum, rootdevnum, rootdev, prefix) = self._get_grub_boot_config() + # NB we're assuming that grub config is on the first physical disk + # ie /boot must be on sda, or if there's no /boot, then / must be sda + + # XXX don't hardcode default kernel - see livecd code grub = "" grub += "default=0\n" grub += "timeout=5\n" - grub += "splashimage=(hd0,%-d)%s/grub/splash.xpm.gz\n" % (rootdevnum, prefix) - grub += "hiddenemnu\n" + grub += "splashimage=(hd0,%d)%s/grub/splash.xpm.gz\n" % (bootdevnum, prefix) + grub += "hiddenmenu\n" versions = [] kernels = self._get_kernel_versions() @@ -158,11 +168,11 @@ class DiskImageCreator(ImageCreator): for v in versions: grub += "title Fedora (%s)\n" % v - grub += " root (hd0,%-d)\n" % bootdevnum + grub += " root (hd0,%d)\n" % bootdevnum grub += " kernel %s/vmlinuz-%s ro root=%s\n" % (prefix, v, rootdev) grub += " initrd %s/initrd-%s.img\n" % (prefix, v) - cfg = open(self._instroot + "/boot/grub/grub.cfg", "w") + cfg = open(self._instroot + "/boot/grub/grub.conf", "w") cfg.write(grub) cfg.close() @@ -185,11 +195,18 @@ class DiskImageCreator(ImageCreator): def _install_grub(self): (bootdevnum, rootdevnum, rootdev, prefix) = self._get_grub_boot_config() + # Ensure all data is flushed to disk before doing grub install + subprocess.call(["sync"]) + + stage2 = self._instroot + "/boot/grub/stage2" + setup = "" - setup += "device (hd0) %s\n" % (self.__instloop.disk.device) - setup += "root (hd0,%d)\n" % rootdevnum - setup += "configfile (hd0,%d)%s/grub/grub.cfg" % (bootdevnum, prefix) - setup += "setup --prefix=%s/grub (hd0) (hd0,%d)\n" % (prefix, bootdevnum) + for i in range(len(self.__disks)): + loopdev = self.__disks[i]['disk'].device + setup += "device (hd%d) %s\n" % (i, loopdev) + setup += "root (hd0,%d)\n" % bootdevnum + setup += "setup --stage2=%s --prefix=%s/grub (hd0)\n" % (stage2, prefix) + setup += "quit\n" grub = subprocess.Popen(["grub", "--batch", "--no-floppy"], stdin=subprocess.PIPE) @@ -211,7 +228,58 @@ class DiskImageCreator(ImageCreator): def _resparse(self, size = None): return self.__instloop.resparse(size) + + def _write_image_xml(self): + xml = "\n" + xml += " %s\n" % self.name + xml += " \n" + # XXX don't hardcode - determine based on the kernel we installed for grub + # baremetal vs xen + xml += " \n" + xml += " \n" + xml += " %s\n" % os.uname()[4] + xml += " \n" + xml += " \n" + xml += " \n" + xml += " \n" + for i in range(len(self.__disks)): + xml += " \n" % (self.__disks[i]['name'], self.__format, chr(ord('a')+i)) + xml += " \n" + xml += " \n" + xml += " 1\n" + xml += " %d\n" %(256 * 1024) + xml += " \n" + xml += " \n" + xml += " \n" + xml += " \n" + xml += " \n" + for i in range(len(self.__disks)): + # XXX don't hardcode raw + xml += " \n" % (self.__disks[i]['name'], self.__format, self.__format) + xml += " \n" + xml += "\n" + + print "Writing %s/%s.xml" % (self._outdir, self.name) + cfg = open("%s/%s.xml" % (self._outdir, self.name), "w") + cfg.write(xml) + cfg.close() + + def _stage_final_image(self): self._resparse() - print "Copying image to %s " % (self._outdir + "/" + self.name + ".dsk",) - shutil.move(self._disk, self._outdir + "/" + self.name + ".dsk") + + print "Writing image XML" + self._write_image_xml() + print "Moving disks to final location" + for i in range(len(self.__disks)): + dst = "%s/%s.%s" % (self._outdir, self.__disks[i]['name'], self.__format) + if self.__format == "raw": + print "Moving tmp %s image to %s " % (self.__disks[i]['disk'].lofile, dst) + shutil.move(self.__disks[i]['disk'].lofile, dst) + else: + rc = subprocess.call(["qemu-img", "convert", + "-f", "raw", self.__disks[i]['disk'].lofile, + "-O", self.__format, dst]) + if rc != 0: + raise CreatorError("Unable to convert disk to %s" % (self.__format)) + print "All done" diff --git a/imgcreate/fs.py b/imgcreate/fs.py index 9ca3a3e..8d73102 100644 --- a/imgcreate/fs.py +++ b/imgcreate/fs.py @@ -86,42 +86,51 @@ class BindChrootMount: subprocess.call(["/bin/umount", self.dest]) self.mounted = False -class LoopbackMount: - def __init__(self, lofile, mountdir, fstype = None): - self.lofile = lofile - self.mountdir = mountdir - self.fstype = fstype +class Disk: + def __init__(self, size, device = None): + self._device = device + self._size = size - self.mounted = False - self.losetup = False - self.rmdir = False - self.loopdev = None + def create(self): + pass def cleanup(self): - self.unmount() - self.lounsetup() + pass - def unmount(self): - if self.mounted: - rc = subprocess.call(["/bin/umount", self.mountdir]) - if rc == 0: - self.mounted = False + def get_device(self): + return self._device + def set_device(self, path): + self._device = path + device = property(get_device, set_device) - if self.rmdir and not self.mounted: - try: - os.rmdir(self.mountdir) - except OSError, e: - pass - self.rmdir = False + def get_size(self): + return self._size + size = property(get_size) + + +class RawDisk(Disk): + def __init__(self, size, device): + Disk.__init__(self, size, device) + + def fixed(self): + return True - def lounsetup(self): - if self.losetup: - rc = subprocess.call(["/sbin/losetup", "-d", self.loopdev]) - self.losetup = False - self.loopdev = None + def exists(self): + return True - def loopsetup(self): - if self.losetup: +class LoopbackDisk(Disk): + def __init__(self, lofile, size): + Disk.__init__(self, size) + self.lofile = lofile + + def fixed(self): + return False + + def exists(self): + return os.path.exists(self.lofile) + + def create(self): + if self.device is not None: return losetupProc = subprocess.Popen(["/sbin/losetup", "-f"], @@ -132,40 +141,27 @@ class LoopbackMount: raise MountError("Failed to allocate loop device for '%s'" % self.lofile) - self.loopdev = losetupOutput.split()[0] + device = losetupOutput.split()[0] - rc = subprocess.call(["/sbin/losetup", self.loopdev, self.lofile]) + print "Losetup add %s %s" % (device, self.lofile) + rc = subprocess.call(["/sbin/losetup", device, self.lofile]) if rc != 0: raise MountError("Failed to allocate loop device for '%s'" % self.lofile) + self.device = device - self.losetup = True - - def mount(self): - if self.mounted: + def cleanup(self): + if self.device is None: return + print "Losetup remove %s" % self.device + rc = subprocess.call(["/sbin/losetup", "-d", self.device]) + self.device = None - self.loopsetup() - - if not os.path.isdir(self.mountdir): - os.makedirs(self.mountdir) - self.rmdir = True - - args = [ "/bin/mount", self.loopdev, self.mountdir ] - if self.fstype: - args.extend(["-t", self.fstype]) - - rc = subprocess.call(args) - if rc != 0: - raise MountError("Failed to mount '%s' to '%s'" % - (self.loopdev, self.mountdir)) - self.mounted = True -class SparseLoopbackMount(LoopbackMount): - def __init__(self, lofile, mountdir, size, fstype = None): - LoopbackMount.__init__(self, lofile, mountdir, fstype) - self.size = size +class SparseLoopbackDisk(LoopbackDisk): + def __init__(self, lofile, size): + LoopbackDisk.__init__(self, lofile, size) def expand(self, create = False, size = None): flags = os.O_WRONLY @@ -191,10 +187,81 @@ class SparseLoopbackMount(LoopbackMount): def create(self): self.expand(create = True) + LoopbackDisk.create(self) -class SparseExtLoopbackMount(SparseLoopbackMount): - def __init__(self, lofile, mountdir, size, fstype, blocksize, fslabel): - SparseLoopbackMount.__init__(self, lofile, mountdir, size, fstype) +class Mount: + def __init__(self, mountdir): + self.mountdir = mountdir + + def cleanup(self): + self.unmount() + + def mount(self): + pass + + def unmount(self): + pass + +class DiskMount(Mount): + def __init__(self, disk, mountdir, fstype = None, rmmountdir = True): + Mount.__init__(self, mountdir) + + self.disk = disk + self.fstype = fstype + self.rmmountdir = rmmountdir + + self.mounted = False + self.rmdir = False + + def cleanup(self): + Mount.cleanup(self) + self.disk.cleanup() + + def unmount(self): + if self.mounted: + rc = subprocess.call(["/bin/umount", self.mountdir]) + if rc == 0: + self.mounted = False + + if self.rmdir and not self.mounted: + try: + os.rmdir(self.mountdir) + except OSError, e: + pass + self.rmdir = False + + + def __create(self): + print "Disk create %s" % str(self) + self.disk.create() + + + def mount(self): + if self.mounted: + return + + print "Disk mount" + if not os.path.isdir(self.mountdir): + os.makedirs(self.mountdir) + self.rmdir = self.rmmountdir + + self.__create() + + print "Do mount %s " % self.disk.device + args = [ "/bin/mount", self.disk.device, self.mountdir ] + if self.fstype: + args.extend(["-t", self.fstype]) + + rc = subprocess.call(args) + if rc != 0: + raise MountError("Failed to mount '%s' to '%s'" % + (self.disk.device, self.mountdir)) + + self.mounted = True + +class ExtDiskMount(DiskMount): + def __init__(self, disk, mountdir, fstype, blocksize, fslabel, rmmountdir=True): + DiskMount.__init__(self, disk, mountdir, fstype, rmmountdir) self.blocksize = blocksize self.fslabel = fslabel @@ -202,19 +269,15 @@ class SparseExtLoopbackMount(SparseLoopbackMount): rc = subprocess.call(["/sbin/mkfs." + self.fstype, "-F", "-L", self.fslabel, "-m", "1", "-b", str(self.blocksize), - self.lofile, - str(self.size / self.blocksize)]) + self.disk.device]) + # str(self.disk.size / self.blocksize)]) if rc != 0: raise MountError("Error creating %s filesystem" % (self.fstype,)) subprocess.call(["/sbin/tune2fs", "-c0", "-i0", "-Odir_index", - "-ouser_xattr,acl", self.lofile]) - - def create(self): - SparseLoopbackMount.create(self) - self.__format_filesystem() + "-ouser_xattr,acl", self.disk.device]) - def resize(self, size = None): - current_size = os.stat(self.lofile)[stat.ST_SIZE] + def __resize_filesystem(self, size = None): + current_size = os.stat(self.disk.lofile)[stat.ST_SIZE] if size is None: size = self.size @@ -227,21 +290,30 @@ class SparseExtLoopbackMount(SparseLoopbackMount): self.__fsck() - resize2fs(self.lofile, size) - - if size < current_size: - self.truncate(size) + resize2fs(self.disk.lofile, size) return size - def mount(self): - if not os.path.isfile(self.lofile): - self.create() + def __create(self): + resize = False + if not self.disk.fixed() and self.disk.exists(): + resize = True + + #DiskMount.__create(self) + self.disk.create() + + if resize: + print "Fs resie" + self.__resize_filesystem() else: - self.resize() - return SparseLoopbackMount.mount(self) + print "FS format" + self.__format_filesystem() + + def mount(self): + self.__create() + DiskMount.mount(self) def __fsck(self): - subprocess.call(["/sbin/e2fsck", "-f", "-y", self.lofile]) + subprocess.call(["/sbin/e2fsck", "-f", "-y", self.disk.lofile]) def __get_size_from_filesystem(self): def parse_field(output, field): @@ -253,7 +325,7 @@ class SparseExtLoopbackMount(SparseLoopbackMount): dev_null = os.open("/dev/null", os.O_WRONLY) try: - out = subprocess.Popen(['/sbin/dumpe2fs', '-h', self.lofile], + out = subprocess.Popen(['/sbin/dumpe2fs', '-h', self.disk.lofile], stdout = subprocess.PIPE, stderr = dev_null).communicate()[0] finally: @@ -273,7 +345,7 @@ class SparseExtLoopbackMount(SparseLoopbackMount): while top != (bot + 1): t = bot + ((top - bot) / 2) - if not resize2fs(self.lofile, t): + if not resize2fs(self.disk.lofile, t): top = t else: bot = t @@ -281,12 +353,243 @@ class SparseExtLoopbackMount(SparseLoopbackMount): def resparse(self, size = None): self.cleanup() - minsize = self.__resize_to_minimal() + self.disk.truncate(minsize) + return minsize + +class PartitionedMount(Mount): + def __init__(self, disks, devnames, mountdir): + Mount.__init__(self, mountdir) + self.disks = {} + for i in range(len(disks)): + d = disks[i] + devname = devnames[i] + print "Assigned disk %s" % devname + self.disks[devname] = { 'disk': d, # Disk object + 'mapped': False, # True if kpartx mapping exists + 'numpart': 0, # Number of allocate partitions + 'partitions': [], # indexes to self.partitions + 'extended': 0, # Size of extended partition + 'offset': 0 } # Offset of next partition + self.partitions = [] + self.mapped = False + self.mountOrder = [] + self.unmountOrder = [] + + def add_partition(self, size, disk, mountpoint, fstype = None): + self.partitions.append({'size': size, + 'mountpoint': mountpoint, # Mount relative to chroot + 'fstype': fstype, + 'disk': disk, # physical disk name holding partition + 'device': None, # kpartx device node for partition + 'mount': None, # Mount object + 'num': None}) # Partition number + + def __format_disks(self): + print "Assigning disks" + for dev in self.disks.keys(): + d = self.disks[dev] + print "Initializing partition table for %s" % (d['disk'].device) + rc = subprocess.call(["/sbin/parted", "-s", d['disk'].device, "mklabel", "msdos"]) + if rc != 0: + raise MountError("Error writing partition table on %s" % d.device) + + print "Assigning partitions" + for n in range(len(self.partitions)): + p = self.partitions[n] + + if not self.disks.has_key(p['disk']): + raise MountError("No disk %s for partition %s" % (p['disk'], p['mountpoint'])) + + d = self.disks[p['disk']] + d['numpart'] += 1 + if d['numpart'] > 3: + # Increase allocation of extended partition to hold this partition + d['extended'] += p['size'] + p['type'] = 'logical' + p['num'] = d['numpart'] + 1 + else: + p['type'] = 'primary' + p['num'] = d['numpart'] + + p['start'] = d['offset'] + d['offset'] += p['size'] + d['partitions'].append(n) + print "Assigned %s to %s%d at %d at size %d" % (p['mountpoint'], p['disk'], p['num'], p['start'], p['size']) + + # XXX we should probably work in cylinder units to keep fdisk happier.. + start = 0 + print "Creating partitions" + for p in self.partitions: + d = self.disks[p['disk']] + if p['num'] == 5: + print "Added extended part at %d of size %d" % (p['start'], d['extended']) + rc = subprocess.call(["/sbin/parted", "-s", d['disk'].device, "mkpart", "extended", + "%dM" % p['start'], "%dM" % (p['start'] + d['extended'])]) + + print "Add %s part at %d of size %d" % (p['type'], p['start'], p['size']) + rc = subprocess.call(["/sbin/parted", "-s", d['disk'].device, "mkpart", + p['type'], "%dM" % p['start'], "%dM" % (p['start']+p['size'])]) + + # XXX disabled return code check because parted always fails to + # reload part table with loop devices. Annoying because we can't + # distinguish this failure from real partition failures :-( + if rc != 0 and 1 == 0: + raise MountError("Error creating partition on %s" % d['disk'].device) + + def __map_partitions(self): + for dev in self.disks.keys(): + d = self.disks[dev] + if d['mapped']: + continue + + kpartx = subprocess.Popen(["/sbin/kpartx", "-l", d['disk'].device], + stdout=subprocess.PIPE) + + kpartxOutput = kpartx.communicate()[0].split("\n") + # Strip trailing blank + kpartxOutput = kpartxOutput[0:len(kpartxOutput)-1] + print "Partx planned mapping %s" % str(kpartxOutput) + if kpartx.returncode: + raise MountError("Failed to query partition mapping for '%s'" % + d.device) + + # Quick sanity check that the number of partitions matches + # our expectation. If it doesn't, someone broke the code + # further up + if len(kpartxOutput) != d['numpart']: + raise MountError("Unexpected number of partitions from kpartx: %d != %d" % + (len(kpartxOutput), d['numpart'])) + + for i in range(len(kpartxOutput)): + print " Got %s" % (kpartxOutput[i]) + line = kpartxOutput[i] + newdev = line.split()[0] + mapperdev = "/dev/mapper/" + newdev + loopdev = d['disk'].device + newdev[-1] + + print "Dev %s: %s -> %s" % (newdev, loopdev, mapperdev) + pnum = d['partitions'][i] + self.partitions[pnum]['device'] = loopdev + + # grub's install wants partitions to be named + # to match their parent device + partition num + # kpartx doesn't work like this, so we add compat + # symlinks to point to /dev/mapper + os.symlink(mapperdev, loopdev) + + print "Adding partx mapping for %s" % d['disk'].device + rc = subprocess.call(["/sbin/kpartx", "-a", d['disk'].device]) + if rc != 0: + raise MountError("Failed to map partitions for '%s'" % + d['disk'].device) + d['mapped'] = True + + + def __unmap_partitions(self): + for dev in self.disks.keys(): + d = self.disks[dev] + if not d['mapped']: + continue + + print "Removing compat symlinks" + for pnum in d['partitions']: + if self.partitions[pnum]['device'] != None: + os.unlink(self.partitions[pnum]['device']) + self.partitions[pnum]['device'] = None + + print "Unmapping" + rc = subprocess.call(["/sbin/kpartx", "-d", d['disk'].device]) + if rc != 0: + raise MountError("Failed to unmap partitions for '%s'" % + d['disk'].device) + + d['mapped'] = False + + + def __calculate_mountorder(self): + for p in self.partitions: + self.mountOrder.append(p['mountpoint']) + self.unmountOrder.append(p['mountpoint']) + + self.mountOrder.sort() + self.unmountOrder.sort() + self.unmountOrder.reverse() + print str(self.mountOrder) - self.truncate(minsize) + def cleanup(self): + print "Doing cleanup" + import time + #time.sleep(20) + Mount.cleanup(self) + print "Unmap parts" + self.__unmap_partitions() + print "Cleanup disks" + for dev in self.disks.keys(): + d = self.disks[dev] + try: + print "Cleanup disk %s -> %s" % (d['disk'].lofile, d['disk'].device) + d['disk'].cleanup() + except: + pass + + def unmount(self): + print "Do unmount" + for mp in self.unmountOrder: + if mp == 'swap': + continue + p = None + for p1 in self.partitions: + if p1['mountpoint'] == mp: + p = p1 + break + + if p['mount'] != None: + print "Clenaup %s " % p['mountpoint'] + try: + p['mount'].cleanup() + except: + pass + p['mount'] = None + print "Done unmount" + + def mount(self): + for dev in self.disks.keys(): + d = self.disks[dev] + d['disk'].create() + + self.__format_disks() + self.__map_partitions() + self.__calculate_mountorder() + + for mp in self.mountOrder: + p = None + for p1 in self.partitions: + if p1['mountpoint'] == mp: + p = p1 + break + + if mp == 'swap': + subprocess.call(["/sbin/mkswap", p['device']]) + continue + + print "Submount %s " % p['mountpoint'] + rmmountdir = False + if p['mountpoint'] == "/": + rmmountdir = True + pdisk = ExtDiskMount(RawDisk(p['size'] * 1024 * 1024, p['device']), + self.mountdir + p['mountpoint'], + p['fstype'], + 4096, + p['mountpoint'], + rmmountdir) + pdisk.mount() + p['mount'] = pdisk + + def resparse(self, size = None): + # Can't re-sparse a disk image - too hard + pass - return self.resize(size) class DeviceMapperSnapshot(object): def __init__(self, imgloop, cowloop): @@ -306,8 +609,8 @@ class DeviceMapperSnapshot(object): if self.__created: return - self.imgloop.loopsetup() - self.cowloop.loopsetup() + self.imgloop.create() + self.cowloop.create() self.__name = "imgcreate-%d-%d" % (os.getpid(), random.randint(0, 2**16)) @@ -315,8 +618,8 @@ class DeviceMapperSnapshot(object): size = os.stat(self.imgloop.lofile)[stat.ST_SIZE] table = "0 %d snapshot %s %s p 8" % (size / 512, - self.imgloop.loopdev, - self.cowloop.loopdev) + self.imgloop.device, + self.cowloop.device) args = ["/sbin/dmsetup", "create", self.__name, "--table", table] if subprocess.call(args) != 0: @@ -382,15 +685,14 @@ class DeviceMapperSnapshot(object): # 8) Create a squashfs of the COW # def create_image_minimizer(path, image, minimal_size): - imgloop = LoopbackMount(image, "None") + imgloop = LoopbackDisk(image, None) # Passing bogus size - doesn't matter - cowloop = SparseLoopbackMount(os.path.join(os.path.dirname(path), "osmin"), - None, 64L * 1024L * 1024L) + cowloop = SparseLoopbackDisk(os.path.join(os.path.dirname(path), "osmin"), + 64L * 1024L * 1024L) snapshot = DeviceMapperSnapshot(imgloop, cowloop) try: - cowloop.create() snapshot.create() resize2fs(snapshot.path, minimal_size) diff --git a/imgcreate/kickstart.py b/imgcreate/kickstart.py index a7e0723..a92f877 100644 --- a/imgcreate/kickstart.py +++ b/imgcreate/kickstart.py @@ -468,6 +468,9 @@ def get_groups(ks, required = []): def get_excluded(ks, required = []): return ks.handler.packages.excludedList + required +def get_partitions(ks, required = []): + return ks.handler.partition.partitions + def ignore_missing(ks): return ks.handler.packages.handleMissing == ksconstants.KS_MISSING_IGNORE diff --git a/imgcreate/live.py b/imgcreate/live.py index bbb17ef..dc2aea9 100644 --- a/imgcreate/live.py +++ b/imgcreate/live.py @@ -130,7 +130,7 @@ class LiveImageCreatorBase(LoopImageCreator): # def __base_on_iso(self, base_on): """helper function to extract ext3 file system from a live CD ISO""" - isoloop = LoopbackMount(base_on, self._mkdtemp()) + isoloop = Mount(LoopbackDisk(base_on), self._mkdtemp()) try: isoloop.mount() @@ -144,10 +144,10 @@ class LiveImageCreatorBase(LoopImageCreator): else: squashimg = isoloop.mountdir + "/LiveOS/squashfs.img" - squashloop = LoopbackMount(squashimg, self._mkdtemp(), "squashfs") + squashloop = Mount(LoopbackDisk(squashimg), self._mkdtemp(), "squashfs") try: - if not os.path.exists(squashloop.lofile): + if not squashloop.disk.exists(): raise CreatorError("'%s' is not a valid live CD ISO : " "squashfs.img doesn't exist" % base_on) diff --git a/livecd-tools.spec b/livecd-tools.spec index a789460..d9118ba 100644 --- a/livecd-tools.spec +++ b/livecd-tools.spec @@ -58,6 +58,7 @@ rm -rf $RPM_BUILD_ROOT %dir %{_datadir}/livecd-tools %{_datadir}/livecd-tools/* %{_bindir}/image-creator +%{_bindir}/disk-creator %dir %{python_sitelib}/imgcreate %{python_sitelib}/imgcreate/*.py %{python_sitelib}/imgcreate/*.pyo diff --git a/tools/disk-creator b/tools/disk-creator index 52584f6..acd6bd7 100755 --- a/tools/disk-creator +++ b/tools/disk-creator @@ -25,10 +25,16 @@ import optparse import imgcreate def parse_options(args): - parser = optparse.OptionParser(usage = "%prog [--name=] ") + parser = optparse.OptionParser(usage = "%prog [--disk=] [--size=] ") parser.add_option("-n", "--name", type="string", dest="name", - help="Disk name") + help="Appliance name") + parser.add_option("-d", "--disk", type="string", dest="disk", + action="append", help="Disk file name") + parser.add_option("-s", "--size", type="float", dest="size", + action="append", help="Disk size in MB") + parser.add_option("-f", "--format", type="string", dest="format", + help="Disk format (raw, qcow2, vmdk, ...)") (options, args) = parser.parse_args() @@ -51,12 +57,45 @@ def main(): print >> sys.stderr, "Error loading kickstart file '%s' : %s" % (kscfg, e) return 1 + disks = [] + + print str(options.disk) + print str(options.size) + if options.disk is None: + name = imgcreate.build_name(kscfg) + size = 4096L * 1024L * 1024L + if options.size is not None: + if type(options.size) != float: + print >> sys.stderr, "Error too many disk sizes provided" + return 1 + size = options.size * 1024L * 1024L + + disks.append({ 'name': name, 'size': size }) + elif type(options.disk) == list: + if type(options.size) != list or len(options.size) != len(options.disk): + print >> sys.stderr, "Error must provide a size for each disk" + return 1 + + for i in range(len(options.disk)): + disks.append({ 'name': options.disk[i], 'size': options.size[i] * 1024L * 1024L }) + else: + size = 4096L * 1024L * 1024L + if options.size is not None: + if type(options.size) != float: + print >> sys.stderr, "Error too many disk sizes provided" + return 1 + size = options.size * 1024L * 1024L + + disks.append({ 'name': options.disk, 'size': size }) + + name = imgcreate.build_name(kscfg) if options.name: name = options.name - else: - name = imgcreate.build_name(kscfg) - creator = imgcreate.DiskImageCreator(ks, name) + format = "raw" + if options.format: + format = options.format + creator = imgcreate.DiskImageCreator(ks, name, disks, format) try: creator.create() -------------- next part -------------- # Kickstart file automatically generated by anaconda. install url --url http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Fedora/x86_64/os/ lang en_US.UTF-8 keyboard us network --device eth0 --bootproto dhcp rootpw --iscrypted $1$HNOucon/$m69RprODwQn4XjzVUi9TU0 firewall --disabled authconfig --enableshadow --enablemd5 selinux --disabled services --disabled=iptables,yum-updatesd,libvirtd,bluetooth,cups,gpm,pcscd --enabled=ntpd,dhcpd,xinetd,httpd,postgresql,ovirt-wui timezone --utc America/New_York text bootloader --location=mbr --driveorder=sda # The following is the partition information you requested # Note that any partitions you deleted are not expressed # here so unless you clear all partitions first, this is # not guaranteed to work zerombr clearpart --all --drives=sda part /boot --fstype ext3 --size=100 --ondisk=sda part swap --fstype swap --size=500 --ondisk=sda part /var/lib/pgsql --fstype ext3 --size=300 --ondisk=sdb part / --fstype ext3 --size=3000 --ondisk=sda part /home --fstype ext3 --size=500 --ondisk=sdb part /var --fstype ext3 --size=1000 --ondisk=sda #part /boot --fstype ext3 --size=100 --ondisk=sda #part pv.2 --size=0 --grow --ondisk=sda #volgroup VolGroup00 --pesize=32768 pv.2 #logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=512 #logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow repo --name=f8 --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=$basearch repo --name=f8-updates --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f8&arch=$basearch repo --name=freeipa --baseurl=http://freeipa.com/downloads/devel/rpms/F7/$basearch/ repo --name=ovirt --baseurl=http://ovirt.et.redhat.com/repos/ovirt/$basearch/ %packages @admin-tools @editors @system-tools @text-internet @core @base @hardware-support @web-server @sql-server @development-libs @legacy-fonts @development-tools radeontool fuse pax imake dhcp tftp-server tftp dhclient ipa-server ipa-admintools xinetd libvirt cyrus-sasl-gssapi iscsi-initiator-utils collectd ruby-libvirt ruby-postgres ovirt-wui firefox xorg-x11-xauth virt-viewer -libgcj -glib-java -valgrind -boost-devel -frysk -bittorrent -fetchmail -slrn -cadaver -mutt %post cat > /root/create_default_principals.py << \EOF #!/usr/bin/python import krbV import os, string, re import socket import shutil def kadmin_local(command): ret = os.system("/usr/kerberos/sbin/kadmin.local -q '" + command + "'") if ret != 0: raise default_realm = krbV.Context().default_realm # here, generate the libvirt/ principle for this machine, necessary # for taskomatic and host-browser this_libvirt_princ = 'libvirt/' + socket.gethostname() + '@' + default_realm kadmin_local('addprinc -randkey +requires_preauth ' + this_libvirt_princ) kadmin_local('ktadd -k /usr/share/ovirt-wui/ovirt.keytab ' + this_libvirt_princ) # We need to replace the KrbAuthRealms in the ovirt-wui http configuration # file to be the correct Realm (i.e. default_realm) ovirtconfname = '/etc/httpd/conf.d/ovirt-wui.conf' ipaconfname = '/etc/httpd/conf.d/ipa.conf' # make sure we skip this on subsequent runs of this script if string.find(file(ipaconfname, 'rb').read(), '') < 0: ipaconf = open(ipaconfname, 'r') ipatext = ipaconf.readlines() ipaconf.close() ipaconf2 = open(ipaconfname, 'w') print >>ipaconf2, "Listen 8089" print >>ipaconf2, "NameVirtualHost *:8089" print >>ipaconf2, "" for line in ipatext: newline = re.sub(r'(.*RewriteCond %{HTTP_HOST}.*)', r'#\1', line) newline = re.sub(r'(.*RewriteRule \^/\(.*\).*)', r'#\1', newline) newline = re.sub(r'(.*RewriteCond %{SERVER_PORT}.*)', r'#\1', newline) newline = re.sub(r'(.*RewriteCond %{REQUEST_URI}.*)', r'#\1', newline) ipaconf2.write(newline) print >>ipaconf2, "" ipaconf2.close() if string.find(file(ovirtconfname, 'rb').read(), '') < 0: ovirtconf = open(ovirtconfname, 'r') ovirttext = ovirtconf.readlines() ovirtconf.close() ovirtconf2 = open(ovirtconfname, 'w') print >>ovirtconf2, "NameVirtualHost *:80" print >>ovirtconf2, "" for line in ovirttext: newline = re.sub(r'(.*)KrbAuthRealms.*', r'\1KrbAuthRealms ' + default_realm, line) newline = re.sub(r'(.*)Krb5KeyTab.*', r'\1Krb5KeyTab /etc/httpd/conf/ipa.keytab', newline) ovirtconf2.write(newline) print >>ovirtconf2, "" ovirtconf2.close() EOF chmod +x /root/create_default_principals.py cat > /root/add_host_principal.py << \EOF #!/usr/bin/python import krbV import os import socket import shutil import sys def kadmin_local(command): ret = os.system("/usr/kerberos/sbin/kadmin.local -q '" + command + "'") if ret != 0: raise def get_ip(hostname): return socket.gethostbyname(hostname) if len(sys.argv) != 2: print "Usage: add_host_principal.py " sys.exit(1) default_realm = krbV.Context().default_realm ipaddr = get_ip(sys.argv[1]) libvirt_princ = 'libvirt/' + sys.argv[1] + '@' + default_realm outname = '/usr/share/ipa/html/' + ipaddr + '-libvirt.tab' # here, generate the libvirt/ principle for this machine, necessary # for taskomatic and host-browser kadmin_local('addprinc -randkey +requires_preauth ' + libvirt_princ) kadmin_local('ktadd -k ' + outname + ' ' + libvirt_princ) # make sure it is readable by apache os.chmod(outname, 0644) EOF chmod +x /root/add_host_principal.py cat > /usr/share/ovirt-wui/psql.cmds << \EOF CREATE USER ovirt WITH PASSWORD 'v23zj59an'; CREATE DATABASE ovirt; GRANT ALL PRIVILEGES ON DATABASE ovirt to ovirt; CREATE DATABASE ovirt_test; GRANT ALL PRIVILEGES ON DATABASE ovirt_test to ovirt; EOF chmod a+r /usr/share/ovirt-wui/psql.cmds cat > /etc/init.d/ovirt-app-first-run << \EOF #!/bin/bash # # ovirt-app-first-run First run configuration for Ovirt WUI appliance # # chkconfig: 3 99 01 # description: ovirt appliance first run configuration # # Source functions library . /etc/init.d/functions start() { service postgresql initdb echo "local all all trust" > /var/lib/pgsql/data/pg_hba.conf echo "host all all 127.0.0.1 255.255.255.0 trust" >> /var/lib/pgsql/data/pg_hba.conf service postgresql start su - postgres -c "/usr/bin/psql -f /usr/share/ovirt-wui/psql.cmds" cd /usr/share/ovirt-wui ; rake db:migrate /usr/bin/ovirt_grant_admin_privileges.sh admin } case "$1" in start) start ;; *) echo "Usage: ovirt {start}" exit 2 esac chkconfig ovirt-app-first-run off EOF chmod +x /etc/init.d/ovirt-app-first-run chkconfig ovirt-app-first-run on sed -i -e 's/\(.*\)disable\(.*\)= yes/\1disable\2= no/' /etc/xinetd.d/tftp # set up the yum repos cat > /etc/yum.repos.d/freeipa.repo << \EOF [freeipa] name=FreeIPA Development baseurl=http://freeipa.com/downloads/devel/rpms/F7/x86_64/ enabled=1 gpgcheck=0 EOF cat > /etc/yum.repos.d/ovirt.repo << \EOF [ovirt] name=Ovirt baseurl=http://ovirt.et.redhat.com/repos/ovirt/x86_64 enabled=1 gpgcheck=0 EOF # pretty login screen.. echo -e "" > /etc/issue echo -e " 888 888 \\033[0;32md8b\\033[0;39m 888 " >> /etc/issue echo -e " 888 888 \\033[0;32mY8P\\033[0;39m 888 " >> /etc/issue echo -e " 888 888 888 " >> /etc/issue echo -e " .d88b. Y88b d88P 888 888d888 888888 " >> /etc/issue echo -e " d88''88b Y88b d88P 888 888P' 888 " >> /etc/issue echo -e " 888 888 Y88o88P 888 888 888 " >> /etc/issue echo -e " Y88..88P Y888P 888 888 Y88b. " >> /etc/issue echo -e " 'Y88P' Y8P 888 888 'Y888 " >> /etc/issue echo -e "" >> /etc/issue echo -e " Admin node \\\\n " >> /etc/issue echo -e "" >> /etc/issue echo -e " Virtualization just got the \\033[0;32mGreen Light\\033[0;39m" >> /etc/issue echo -e "" >> /etc/issue cp /etc/issue /etc/issue.net echo "0.fedora.pool.ntp.org" >> /etc/ntp/step-tickers # remove the mod_auth_kerb, and make sure we get the one from freeipa rpm -e --nodeps mod_auth_kerb yum -y --disablerepo=* --enablerepo=freeipa install mod_auth_kerb # with the new libvirt (0.4.0), make sure we we setup gssapi in the mech_list sed -i -e 's/mech_list: digest-md5/#mech_list: digest-md5/' /etc/sasl2/libvirt.conf sed -i -e 's/#mech_list: gssapi/mech_list: gssapi/' /etc/sasl2/libvirt.conf # for firefox, we need to add the following to ~/.mozilla/firefox/zzzzz/prefs.js #echo 'user_pref("network.negotiate-auth.delegation-uris", ".redhat.com");' >> ~/.mozilla/firefox/zzzz/prefs.js #echo 'user_pref("network.negotiate-auth.trusted-uris", ".redhat.com");' >> ~/.mozilla/firefox/zzzz/prefs.js %end From berrange at redhat.com Sun Feb 17 21:54:08 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sun, 17 Feb 2008 21:54:08 +0000 Subject: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool In-Reply-To: <20080217212604.GA10935@redhat.com> References: <20080217021443.GH24669@redhat.com> <20080217212604.GA10935@redhat.com> Message-ID: <20080217215408.GC10935@redhat.com> On Sun, Feb 17, 2008 at 09:26:04PM +0000, Daniel P. Berrange wrote: > On Sun, Feb 17, 2008 at 02:14:43AM +0000, Daniel P. Berrange wrote: > > Future enhancements for this: > > > > - Allow splitting across multiple disks (sda, sdb, etc) > > > > - When staging final image, use qemu-img to generate qcow2, vmdk > > or raw files at user's choice. qcow2 would give huge size savings > > > > - Output XML file for use with 'virt-image' tool, so that the entire > > build and deploy process consists of nothing more than: > > > > # disk-creator ovirt-wui-appliance.ks > > # virt-image ovirt-wui-appliance.xml > > This new version of the patch implements all three of the above features. > > As an example, creating an appliance with 2 disks (sda & sdb), outputting > in qcow2 format: > > disk-creator --format qcow2 \ > --name ovirt-wui \ > --disk ovirt-wui-os --size 5000 \ > --disk ovirt-wui-data --size 1000 \ > ovirt-wui-appliance.ks > > You'll end up with ovirt-wui-os.qcow2, ovirt-wui-data.qcow2 and ovirt-wui.xml Opps, I meant to attach a copy of the ovirt-wui.xml for benefit of people not familiar with virt-image / libvirt. The two files attached to this mail are the ovirt-wui.xml created by disk-creator for feeding to virt-image. The second XML file is the libvirt XML generated from ovirt-wui.xml for the purposes of actually running the appliance in KVM The core difference between the two is that the virt-image XML format defines the *requirements* for running the VM, while the libvirt XML format defines a specific *deployment* of the VM. The former is generic to any HV, while the later is specific to the HV & host deployed under. Regards, Dan -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -------------- next part -------------- A non-text attachment was scrubbed... Name: ovirt-wui.xml Type: text/xml Size: 592 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ovirt-wui-vm.xml Type: text/xml Size: 965 bytes Desc: not available URL: From wtogami at redhat.com Mon Feb 18 01:49:28 2008 From: wtogami at redhat.com (Warren Togami) Date: Sun, 17 Feb 2008 20:49:28 -0500 Subject: [Fedora-livecd-list] Live ISO within initrd for PXE Boot? Message-ID: <47B8E428.20906@redhat.com> http://git.fedoraproject.org/git/?p=livecd;a=commit;h=e0f0269d3a8f8f310e7c5fdfb8af45892f419c13 > > The way it works is to bundle the complete ISO image inside the initrd. > The kernel and (bloated) initrd are downloaded using PXE in the normal > way, and the init script finds and loopback-mounts the ISO image and > booting continues as normal. Wow. I don't mean to offend, but this seems like an incredibly bad way of doing this. Isn't this really slow in the boot up because you must wait for the entire ISO to download? It also requires the client to have more than enough RAM to have the entire ISO in memory? It sounds like the entire memory used by the ISO remains unavailable to the booted system. I need something similar to boot read-only OS images over PXE boot for LTSP. Upstream LTSP5 uses nbd to serve a raw squashfs image as a network block device, which means only a tiny bit needs to be in the initrd and very little memory overhead. Parts of the read-only image are streamed over the network on demand. I'm waiting on Jeremy to get back regarding a long-term plan for supporting mayflower-like things within mkinitrd itself. NBD support was not accepted into mkinitrd because it would rely upon mayflower-like functionality to do right. Warren Togami wtogami at redhat.com From clalance at redhat.com Mon Feb 18 03:16:58 2008 From: clalance at redhat.com (Chris Lalancette) Date: Sun, 17 Feb 2008 22:16:58 -0500 Subject: [Fedora-livecd-list] Live ISO within initrd for PXE Boot? In-Reply-To: <47B8E428.20906@redhat.com> References: <47B8E428.20906@redhat.com> Message-ID: <47B8F8AA.5060400@redhat.com> Warren Togami wrote: > http://git.fedoraproject.org/git/?p=livecd;a=commit;h=e0f0269d3a8f8f310e7c5fdfb8af45892f419c13 >> The way it works is to bundle the complete ISO image inside the initrd. >> The kernel and (bloated) initrd are downloaded using PXE in the normal >> way, and the init script finds and loopback-mounts the ISO image and >> booting continues as normal. > > Wow. I don't mean to offend, but this seems like an incredibly bad way > of doing this. Isn't this really slow in the boot up because you must > wait for the entire ISO to download? It also requires the client to > have more than enough RAM to have the entire ISO in memory? It sounds > like the entire memory used by the ISO remains unavailable to the booted > system. Well, it depends on your definition of "bad". For the purposes I originally wrote it for, the ISO is going to be fairly small (~70MB or less), and the target machines will have a lot of memory. So for that situation, it works well enough, doesn't waste an appreciable amount of memory, and fits into existing tools fairly easily. > > I need something similar to boot read-only OS images over PXE boot for > LTSP. Upstream LTSP5 uses nbd to serve a raw squashfs image as a > network block device, which means only a tiny bit needs to be in the > initrd and very little memory overhead. Parts of the read-only image > are streamed over the network on demand. The problem with this is the same problem that a NFS/iSCSI root have; namely, that you have to setup another service alongside the PXE to get the data over. That increases the server-side setup complexity, something we are hoping to keep to a minimum with oVirt. That's not to say that the method probably isn't preferable, in general, however. And it's definitely something that we can look at doing in the future. I'll have to take a closer look at the LTSP stuff at some point. Chris Lalancette From dmc.fedora at filteredperception.org Mon Feb 18 03:29:12 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 17 Feb 2008 21:29:12 -0600 Subject: [Fedora-livecd-list] Live ISO within initrd for PXE Boot? In-Reply-To: <47B8E428.20906@redhat.com> References: <47B8E428.20906@redhat.com> Message-ID: <47B8FB88.80106@filteredperception.org> Warren Togami wrote: > http://git.fedoraproject.org/git/?p=livecd;a=commit;h=e0f0269d3a8f8f310e7c5fdfb8af45892f419c13 > >> >> The way it works is to bundle the complete ISO image inside the initrd. >> The kernel and (bloated) initrd are downloaded using PXE in the normal >> way, and the init script finds and loopback-mounts the ISO image and >> booting continues as normal. > > Wow. I don't mean to offend, but this seems like an incredibly bad way > of doing this. Isn't this really slow in the boot up because you must > wait for the entire ISO to download? It also requires the client to > have more than enough RAM to have the entire ISO in memory? It sounds > like the entire memory used by the ISO remains unavailable to the booted > system. > > I need something similar to boot read-only OS images over PXE boot for > LTSP. Upstream LTSP5 uses nbd to serve a raw squashfs image as a > network block device, which means only a tiny bit needs to be in the > initrd and very little memory overhead. Parts of the read-only image > are streamed over the network on demand. One architecture I've outlined here in the past, but haven't gotten around to implementing yet is- mount the squashfs via nfs or fuse-httpfs or the like, then otherwise do everything else the same. Then post-boot, allow the user if they wish to migrate the used squashfs either to ram or local disk via the same devicemapper mirror 'trick' I used for rebootless installation. Then subsequently (or alternately) you can use my rebootless installation technique to convert the LiveOS(network-style) type running OS into a completely normal installed running OS, without even having to reboot. bwahahaha... I forget the persons name, but I remember someone had already done the first part of that, who posted here and on anaconda-devel within the last year. -dmc > I'm waiting on Jeremy to get back regarding a long-term plan for > supporting mayflower-like things within mkinitrd itself. NBD support > was not accepted into mkinitrd because it would rely upon mayflower-like > functionality to do right. > > Warren Togami > wtogami at redhat.com > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From wtogami at redhat.com Mon Feb 18 03:33:40 2008 From: wtogami at redhat.com (Warren Togami) Date: Sun, 17 Feb 2008 22:33:40 -0500 Subject: [Fedora-livecd-list] Live ISO within initrd for PXE Boot? In-Reply-To: <47B8F8AA.5060400@redhat.com> References: <47B8E428.20906@redhat.com> <47B8F8AA.5060400@redhat.com> Message-ID: <47B8FC94.4050409@redhat.com> Chris Lalancette wrote: > Warren Togami wrote: >> http://git.fedoraproject.org/git/?p=livecd;a=commit;h=e0f0269d3a8f8f310e7c5fdfb8af45892f419c13 >>> The way it works is to bundle the complete ISO image inside the initrd. >>> The kernel and (bloated) initrd are downloaded using PXE in the normal >>> way, and the init script finds and loopback-mounts the ISO image and >>> booting continues as normal. >> Wow. I don't mean to offend, but this seems like an incredibly bad way >> of doing this. Isn't this really slow in the boot up because you must >> wait for the entire ISO to download? It also requires the client to >> have more than enough RAM to have the entire ISO in memory? It sounds >> like the entire memory used by the ISO remains unavailable to the booted >> system. > > Well, it depends on your definition of "bad". For the purposes I > originally wrote it for, the ISO is going to be fairly small (~70MB or > less), and the target machines will have a lot of memory. So for that > situation, it works well enough, doesn't waste an appreciable amount of > memory, and fits into existing tools fairly easily. Ah, I didn't realize that you were using livecd-tools and mayflower for a rescue or install type image. ~70MB really isn't so bad, and you are right about one less service to configure being a benefit. Warren Togami wtogami at redhat.com From wtogami at redhat.com Mon Feb 18 03:35:01 2008 From: wtogami at redhat.com (Warren Togami) Date: Sun, 17 Feb 2008 22:35:01 -0500 Subject: [Fedora-livecd-list] Live ISO within initrd for PXE Boot? In-Reply-To: <47B8F8AA.5060400@redhat.com> References: <47B8E428.20906@redhat.com> <47B8F8AA.5060400@redhat.com> Message-ID: <47B8FCE5.20903@redhat.com> /me wonders if tftp-server supports range requests. Then you could have a really slow and unreliable loopback mount over tftp. =) Warren From berrange at redhat.com Mon Feb 18 03:36:08 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 18 Feb 2008 03:36:08 +0000 Subject: [Fedora-livecd-list] Live ISO within initrd for PXE Boot? In-Reply-To: <47B8F8AA.5060400@redhat.com> References: <47B8E428.20906@redhat.com> <47B8F8AA.5060400@redhat.com> Message-ID: <20080218033608.GC29141@redhat.com> On Sun, Feb 17, 2008 at 10:16:58PM -0500, Chris Lalancette wrote: > Warren Togami wrote: > > http://git.fedoraproject.org/git/?p=livecd;a=commit;h=e0f0269d3a8f8f310e7c5fdfb8af45892f419c13 > >> The way it works is to bundle the complete ISO image inside the initrd. > >> The kernel and (bloated) initrd are downloaded using PXE in the normal > >> way, and the init script finds and loopback-mounts the ISO image and > >> booting continues as normal. > > > > Wow. I don't mean to offend, but this seems like an incredibly bad way > > of doing this. Isn't this really slow in the boot up because you must > > wait for the entire ISO to download? It also requires the client to > > have more than enough RAM to have the entire ISO in memory? It sounds > > like the entire memory used by the ISO remains unavailable to the booted > > system. > > Well, it depends on your definition of "bad". For the purposes I > originally wrote it for, the ISO is going to be fairly small (~70MB or > less), and the target machines will have a lot of memory. So for that > situation, it works well enough, doesn't waste an appreciable amount of > memory, and fits into existing tools fairly easily. Yep, the overhead in this context is utterly irrelevant. We're talking about scenario where the host will be running all its storage over iSCSI with Gig-E so 70 MB is nothing at all. The host will also be running multiple guest VMs with multi-GB of of RAM allocated to guests, to 70 MB in memory is again nothing at all. And 70 MB host image size is before we've even got serious about stripping down to minimal size. The simplicity of pulling down the ISO in the initial TFTP request easily wins here. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From berrange at redhat.com Mon Feb 18 03:42:32 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 18 Feb 2008 03:42:32 +0000 Subject: [Fedora-livecd-list] Live ISO within initrd for PXE Boot? In-Reply-To: <47B8FC94.4050409@redhat.com> References: <47B8E428.20906@redhat.com> <47B8F8AA.5060400@redhat.com> <47B8FC94.4050409@redhat.com> Message-ID: <20080218034232.GD29141@redhat.com> On Sun, Feb 17, 2008 at 10:33:40PM -0500, Warren Togami wrote: > Chris Lalancette wrote: > >Warren Togami wrote: > >>http://git.fedoraproject.org/git/?p=livecd;a=commit;h=e0f0269d3a8f8f310e7c5fdfb8af45892f419c13 > >>>The way it works is to bundle the complete ISO image inside the initrd. > >>>The kernel and (bloated) initrd are downloaded using PXE in the normal > >>>way, and the init script finds and loopback-mounts the ISO image and > >>>booting continues as normal. > >>Wow. I don't mean to offend, but this seems like an incredibly bad way > >>of doing this. Isn't this really slow in the boot up because you must > >>wait for the entire ISO to download? It also requires the client to > >>have more than enough RAM to have the entire ISO in memory? It sounds > >>like the entire memory used by the ISO remains unavailable to the booted > >>system. > > > >Well, it depends on your definition of "bad". For the purposes I > >originally wrote it for, the ISO is going to be fairly small (~70MB or > >less), and the target machines will have a lot of memory. So for that > >situation, it works well enough, doesn't waste an appreciable amount of > >memory, and fits into existing tools fairly easily. > > Ah, I didn't realize that you were using livecd-tools and mayflower for > a rescue or install type image. ~70MB really isn't so bad, and you are > right about one less service to configure being a benefit. It is not technically a rescue or an install image. The so called 'managed nodes' simply run guest VMs & are effectively stateless. You just boot up the minimal image containing only the libvirt daemon and enough utils to bring up networking and login to iSCSI targets. Once up it connects to the admin node and waits to be told to run guest VMs. All the VM's storage and any persistent config is off on iSCSI or in the admin node. With such a specific application use case & controlled environment is the perfect stateless host scenario. The admin will never even login to a managed node, if it breaks just deploy a new node - each node is totally disposable at any time (well bar a little VM downtime, or pre-emptive migration). Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From wtogami at redhat.com Mon Feb 18 03:50:59 2008 From: wtogami at redhat.com (Warren Togami) Date: Sun, 17 Feb 2008 22:50:59 -0500 Subject: [Fedora-livecd-list] cachedir conflict... bug? Message-ID: <47B900A3.5070401@redhat.com> Here's an interesting problem... I set my ImageCreator cachedir to /var/yum/cache to share my x86_64 laptop's cache. Maybe this was a bad idea, but an interesting thing happened. [root at newcaprica ltsp]# chroot-creator --target=/opt/ltsp/i386/ /etc/ltsp/ltsp-build-client-ks.cfg Mounting /opt/ltsp/i386/ for chroot installation Retrieving http://homemirror.togami.com/pub/fedora/linux/releases/8/Everything/i386/os/repodata/repomd.xml ...OK Retrieving http://homemirror.togami.com/pub/fedora/linux/updates/8/x86_64/repodata/repomd.xml ...OK The resulting chroot successfully completed installation, but chroot to run pretty much anything including /bin/bash failed. x86_64 and i386 packages mixed together in some broken way. [root at newcaprica opt]# yum clean metadata Loading "refresh-updatesd" plugin Loading "basearchonly" plugin 27 metadata files removed Cleaning out the metadata made it work as expected. [root at newcaprica ltsp]# chroot-creator --target=/opt/ltsp/i386/ /etc/ltsp/ltsp-build-client-ks.cfg Mounting /opt/ltsp/i386/ for chroot installation Retrieving http://homemirror.togami.com/pub/fedora/linux/releases/8/Everything/i386/os/repodata/repomd.xml ...OK Retrieving http://homemirror.togami.com/pub/fedora/linux/updates/8/i386/repodata/repomd.xml ...OK Retrieving http://homemirror.togami.com/pub/fedora/linux/updates/8/i386/repodata/primary.sqlite.bz2 ...OK So there was some kind of conflict between my x86_64 host laptop and the i386 chroot both trying to use the same yum cache directory. I'm guessing it was a bad idea to try to do so and this is unsupported. However I am very surprised that it didn't error out. Are there any genuine bugs in anything I described above? Shouldn't yum warn or error out when it sees the repodata arch conflict? I'm a little saddened that I can't share the same yum cache directories, because the RPMS themselves could peacefully co-exist if it were not for the metadata. Warren Togami wtogami at redhat.com From wtogami at redhat.com Mon Feb 18 04:08:31 2008 From: wtogami at redhat.com (Warren Togami) Date: Sun, 17 Feb 2008 23:08:31 -0500 Subject: [Fedora-livecd-list] cachedir conflict... bug? In-Reply-To: <47B900A3.5070401@redhat.com> References: <47B900A3.5070401@redhat.com> Message-ID: <47B904BF.10702@redhat.com> OK, this is a bigger problem than simply conflicting with the host's yum repodata cache. It can easily conflict with itself if you use a local persistent cache. Stepping back a bit to explain from the beginning: Instead of create() I use each step. One of create()'s steps is mount(). Instead of the defaults I use: mount(None,"/path/to/anywhere") This makes testing the image creator really fast because I don't have to grab packages from my mirror each time. In the previous message I described how this conflicted with my host's yum repodata when I used /var/cache/yum. I of course can avoid this conflict by setting it to anything else. But then I realized, it can easily conflict with itself leading to failure. If I use *any* hard-coded persistent cache directory with ImageCreator, create a i386 image and immediately follow it with a x86_64 image, then it is affected by the previous architecture's repodata. Surely this is a bug? Otherwise I have no choice but to include arch within cachedir's name, which seems bad. /var/cache/imagecreator-i386/ /var/cache/imagecreator-x86_64/ Warren Togami wtogami at redhat.com From jvonau at shaw.ca Mon Feb 18 04:12:37 2008 From: jvonau at shaw.ca (Jerry Vonau) Date: Sun, 17 Feb 2008 22:12:37 -0600 Subject: [Fedora-livecd-list] Live ISO within initrd for PXE Boot? In-Reply-To: <47B8FB88.80106@filteredperception.org> References: <47B8E428.20906@redhat.com> <47B8FB88.80106@filteredperception.org> Message-ID: <47B905B5.30707@shaw.ca> Douglas McClendon wrote: > Warren Togami wrote: >> >> I need something similar to boot read-only OS images over PXE boot for >> LTSP. Upstream LTSP5 uses nbd to serve a raw squashfs image as a >> network block device, which means only a tiny bit needs to be in the >> initrd and very little memory overhead. Parts of the read-only image >> are streamed over the network on demand. > > > One architecture I've outlined here in the past, but haven't gotten > around to implementing yet is- > > mount the squashfs via nfs or fuse-httpfs or the like, then otherwise do > everything else the same. Then post-boot, allow the user if they wish > to migrate the used squashfs either to ram or local disk via the same > devicemapper mirror 'trick' I used for rebootless installation. > > Then subsequently (or alternately) you can use my rebootless > installation technique to convert the LiveOS(network-style) type running > OS into a completely normal installed running OS, without even having to > reboot. bwahahaha... > > I forget the persons name, but I remember someone had already done the > first part of that, who posted here and on anaconda-devel within the > last year. Think that was me... I've hacked up anaconda's init to not exit, then call run-init, if the right boot flag is set. Why hack anaconda's init? Because all the network bits are there with a GUI to use to configure the network for nfs or searching for an iso image/cd. Then, if you don't want to type you could use a kickstart file/boot cmdline to set the boot arguments. I'm looking to try a reboot-less install from within anaconda. What I'm looking to do is to install a live(cd) image by anaconda via nfs,hd,cd. Once that is in place, exit anaconda, run-init on the newly cloned install, calling first-boot to configure and customize the rest of the package selection. Does this sound do-able/reasonable? Jerry From rjones at redhat.com Mon Feb 18 09:21:29 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 18 Feb 2008 09:21:29 +0000 Subject: [Fedora-livecd-list] Re: Live ISO within initrd for PXE Boot? In-Reply-To: <47B8E428.20906@redhat.com> References: <47B8E428.20906@redhat.com> Message-ID: <47B94E19.3040409@redhat.com> Warren Togami wrote: > http://git.fedoraproject.org/git/?p=livecd;a=commit;h=e0f0269d3a8f8f310e7c5fdfb8af45892f419c13 > >> >> The way it works is to bundle the complete ISO image inside the initrd. >> The kernel and (bloated) initrd are downloaded using PXE in the normal >> way, and the init script finds and loopback-mounts the ISO image and >> booting continues as normal. > > Wow. I don't mean to offend, but this seems like an incredibly bad way > of doing this. Isn't this really slow in the boot up because you must > wait for the entire ISO to download? It also requires the client to > have more than enough RAM to have the entire ISO in memory? It sounds > like the entire memory used by the ISO remains unavailable to the booted > system. It fits our purpose: - PXE boot will always happen over a fast LAN - image size isn't too large (under 200 MB for P2V and IIRC even less for ovirt) - machines are known to have sufficient RAM > I need something similar to boot read-only OS images over PXE boot for > LTSP. Upstream LTSP5 uses nbd to serve a raw squashfs image as a > network block device, which means only a tiny bit needs to be in the > initrd and very little memory overhead. Parts of the read-only image > are streamed over the network on demand. The server side of this is much harder to set up. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From wtogami at redhat.com Mon Feb 18 21:58:38 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 18 Feb 2008 16:58:38 -0500 Subject: [Fedora-livecd-list] PATCH: Chroot-Creator subclass and chroot-creator tool Message-ID: <47B9FF8E.6080001@redhat.com> ChrootCreator class and chroot-creator tool - install to a target chroot directory This is slightly updated from my previous post 3 days ago. Warren Togami wtogami at redhat.com From berrange at redhat.com Mon Feb 18 22:00:26 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 18 Feb 2008 22:00:26 +0000 Subject: [Fedora-livecd-list] PATCH: Chroot-Creator subclass and chroot-creator tool In-Reply-To: <47B9FF8E.6080001@redhat.com> References: <47B9FF8E.6080001@redhat.com> Message-ID: <20080218220026.GO30725@redhat.com> On Mon, Feb 18, 2008 at 04:58:38PM -0500, Warren Togami wrote: > ChrootCreator class and chroot-creator tool > - install to a target chroot directory > > This is slightly updated from my previous post 3 days ago. Your attachment was 0-bytes long Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From wtogami at redhat.com Mon Feb 18 22:06:53 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 18 Feb 2008 17:06:53 -0500 Subject: [Fedora-livecd-list] PATCH: Chroot-Creator subclass and chroot-creator tool Message-ID: <47BA017D.3040501@redhat.com> ChrootCreator class and chroot-creator tool - install to a target chroot directory It does not change the behavior of any existing user of LiveCD tools. This is a slightly updated from my previous post 3 days ago. Warren Togami wtogami at redhat.com From wtogami at redhat.com Mon Feb 18 22:15:20 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 18 Feb 2008 17:15:20 -0500 Subject: [Fedora-livecd-list] PATCH: Chroot-Creator subclass and chroot-creator tool In-Reply-To: <20080218220026.GO30725@redhat.com> References: <47B9FF8E.6080001@redhat.com> <20080218220026.GO30725@redhat.com> Message-ID: <47BA0378.4020806@redhat.com> Daniel P. Berrange wrote: > On Mon, Feb 18, 2008 at 04:58:38PM -0500, Warren Togami wrote: >> ChrootCreator class and chroot-creator tool >> - install to a target chroot directory >> >> This is slightly updated from my previous post 3 days ago. > > Your attachment was 0-bytes long > > Regards, > Dan. I'm not sure what's going on here. Prior to resending it I tested it by sending the mail to myself, and it worked. http://fedorapeople.org/~wtogami/temp/0001-ChrootCreator-class-and-chroot-creator-tool-instal.patch Uploaded it here. Warren Togami wtogami at redhat.com From dmc.fedora at filteredperception.org Mon Feb 18 22:40:00 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 18 Feb 2008 16:40:00 -0600 Subject: [Fedora-livecd-list] PATCH: Chroot-Creator subclass and chroot-creator tool In-Reply-To: <47BA0378.4020806@redhat.com> References: <47B9FF8E.6080001@redhat.com> <20080218220026.GO30725@redhat.com> <47BA0378.4020806@redhat.com> Message-ID: <47BA0940.6060205@filteredperception.org> Warren Togami wrote: > I'm not sure what's going on here. Prior to resending it I tested it by > sending the mail to myself, and it worked. > > http://fedorapeople.org/~wtogami/temp/0001-ChrootCreator-class-and-chroot-creator-tool-instal.patch Looks like you're hitting the old git formatted patch issue. Those 4 lines at the top (or at least one of them) confuse at least one mail server along the way. Remove those, and I'm pretty sure it will get through, and still apply with patch just fine. -dmc From berrange at redhat.com Mon Feb 18 23:03:45 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 18 Feb 2008 23:03:45 +0000 Subject: [Fedora-livecd-list] PATCH: Chroot-Creator subclass and chroot-creator tool In-Reply-To: <47BA0378.4020806@redhat.com> References: <47B9FF8E.6080001@redhat.com> <20080218220026.GO30725@redhat.com> <47BA0378.4020806@redhat.com> Message-ID: <20080218230345.GB6382@redhat.com> On Mon, Feb 18, 2008 at 05:15:20PM -0500, Warren Togami wrote: > Daniel P. Berrange wrote: > >On Mon, Feb 18, 2008 at 04:58:38PM -0500, Warren Togami wrote: > >>ChrootCreator class and chroot-creator tool > >>- install to a target chroot directory > >> > >>This is slightly updated from my previous post 3 days ago. > > > >Your attachment was 0-bytes long > > > >Regards, > >Dan. > > I'm not sure what's going on here. Prior to resending it I tested it by > sending the mail to myself, and it worked. The version of mailman on redhat.com is ancient & buggy, breaking if you send patches with git. > http://fedorapeople.org/~wtogami/temp/0001-ChrootCreator-class-and-chroot-creator-tool-instal.patch This patch only seems to have the chroot-creator CLI tool, and not the corresponding ChrootCreator class Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From wtogami at redhat.com Tue Feb 19 01:44:19 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 18 Feb 2008 20:44:19 -0500 Subject: [Fedora-livecd-list] PATCH: Chroot-Creator subclass and chroot-creator tool In-Reply-To: <20080218230345.GB6382@redhat.com> References: <47B9FF8E.6080001@redhat.com> <20080218220026.GO30725@redhat.com> <47BA0378.4020806@redhat.com> <20080218230345.GB6382@redhat.com> Message-ID: <47BA3473.4040402@redhat.com> Daniel P. Berrange wrote: > On Mon, Feb 18, 2008 at 05:15:20PM -0500, Warren Togami wrote: >> Daniel P. Berrange wrote: >>> On Mon, Feb 18, 2008 at 04:58:38PM -0500, Warren Togami wrote: >>>> ChrootCreator class and chroot-creator tool >>>> - install to a target chroot directory >>>> >>>> This is slightly updated from my previous post 3 days ago. >>> Your attachment was 0-bytes long >>> >>> Regards, >>> Dan. >> I'm not sure what's going on here. Prior to resending it I tested it by >> sending the mail to myself, and it worked. > > The version of mailman on redhat.com is ancient & buggy, breaking if you > send patches with git. > >> http://fedorapeople.org/~wtogami/temp/0001-ChrootCreator-class-and-chroot-creator-tool-instal.patch > > This patch only seems to have the chroot-creator CLI tool, and not the > corresponding ChrootCreator class > > Regards, > Dan. Oops. Forgot git commit -a. https://bugzilla.redhat.com/show_bug.cgi?id=433379 Both patches attached here now. Warren From vaarrun at gmail.com Tue Feb 19 09:35:20 2008 From: vaarrun at gmail.com (varun jain) Date: Tue, 19 Feb 2008 15:05:20 +0530 Subject: [Fedora-livecd-list] (no subject) Message-ID: received -------------- next part -------------- An HTML attachment was scrubbed... URL: From katzj at redhat.com Tue Feb 19 17:52:04 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 19 Feb 2008 12:52:04 -0500 Subject: [Fedora-livecd-list] PATCH: Chroot-Creator subclass and chroot-creator tool In-Reply-To: <20080218230345.GB6382@redhat.com> References: <47B9FF8E.6080001@redhat.com> <20080218220026.GO30725@redhat.com> <47BA0378.4020806@redhat.com> <20080218230345.GB6382@redhat.com> Message-ID: <1203443524.13019.13.camel@aglarond.local> On Mon, 2008-02-18 at 23:03 +0000, Daniel P. Berrange wrote: > On Mon, Feb 18, 2008 at 05:15:20PM -0500, Warren Togami wrote: > > I'm not sure what's going on here. Prior to resending it I tested it by > > sending the mail to myself, and it worked. > > The version of mailman on redhat.com is ancient & buggy, breaking if you > send patches with git. FWIW, it works just fine if you send the patches by creating them with git-format-patch and git-send-email. If you attach the formatted patch then that's when they get gobbled up. Jeremy From katzj at redhat.com Tue Feb 19 17:57:28 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 19 Feb 2008 12:57:28 -0500 Subject: [Fedora-livecd-list] PATCH: Chroot-Creator subclass and chroot-creator tool In-Reply-To: <47BA017D.3040501@redhat.com> References: <47BA017D.3040501@redhat.com> Message-ID: <1203443848.13019.17.camel@aglarond.local> On Mon, 2008-02-18 at 17:06 -0500, Warren Togami wrote: > ChrootCreator class and chroot-creator tool > - install to a target chroot directory > > It does not change the behavior of any existing user of LiveCD tools. It looks reasonable. My only somewhat fear is that we end up having a significant number of creator subclasses each of which is only used by one tool. Given that, it might be better at first to have the ChrootCreator class just in the chroot-creator tool. That helps to keep the "supported" API lower in the short-term and then if another tool ends up wanting to take advantage of the ChrootCreator, we can look at moving it into the main API. Does that seem reasonable to everyone? Jeremy From katzj at fedoraproject.org Tue Feb 19 18:05:44 2008 From: katzj at fedoraproject.org (Jeremy Katz) Date: Tue, 19 Feb 2008 11:05:44 -0700 Subject: [Fedora-livecd-list] imgcreate/creator.py Message-ID: <200802191805.m1JI5ifu020887@hosted1.fedoraproject.org> imgcreate/creator.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) New commits: commit d570c73c1912a6a8b0f21a383d9850e1189f9619 Author: Warren Togami Date: Thu Feb 14 18:23:13 2008 -0500 LiveCD Patch: Typo in _do_bindmounts() comment diff --git a/imgcreate/creator.py b/imgcreate/creator.py index c2ed770..a8c9d9b 100644 --- a/imgcreate/creator.py +++ b/imgcreate/creator.py @@ -274,8 +274,8 @@ class ImageCreator(object): """Mount various system directories onto _instroot. This method is called by mount(), but may also be used by subclasses - in order to re-mount the bindmounts after modifying the underyling the - underlying filesystem. + in order to re-mount the bindmounts after modifying the underyling + filesystem. """ for b in self.__bindmounts: From katzj at redhat.com Tue Feb 19 18:07:10 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 19 Feb 2008 13:07:10 -0500 Subject: [Fedora-livecd-list] cachedir conflict... bug? In-Reply-To: <47B900A3.5070401@redhat.com> References: <47B900A3.5070401@redhat.com> Message-ID: <1203444430.13019.26.camel@aglarond.local> On Sun, 2008-02-17 at 22:50 -0500, Warren Togami wrote: > I set my ImageCreator cachedir to /var/yum/cache to share my x86_64 > laptop's cache. Maybe this was a bad idea, but an interesting thing > happened. Don't do that. You're basically saying that you have a repository named foo but foo is two different things depending on how you run. [snip] > Are there any genuine bugs in anything I described above? > Shouldn't yum warn or error out when it sees the repodata arch conflict? repodata doesn't have an inherent archness. You can have repodata containing packages of all arches. Jeremy From katzj at redhat.com Tue Feb 19 18:09:01 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 19 Feb 2008 13:09:01 -0500 Subject: [Fedora-livecd-list] cachedir conflict... bug? In-Reply-To: <47B904BF.10702@redhat.com> References: <47B900A3.5070401@redhat.com> <47B904BF.10702@redhat.com> Message-ID: <1203444541.13019.28.camel@aglarond.local> On Sun, 2008-02-17 at 23:08 -0500, Warren Togami wrote: > If I use *any* hard-coded persistent cache directory with ImageCreator, > create a i386 image and immediately follow it with a x86_64 image, then > it is affected by the previous architecture's repodata. Yes, it's a cache. You're saying that you have a repository that's named the same thing (which is the only thing to differentiate between two repositories) and yet has different contents when you run it. Note that things like this are part of the reason why we, by default, instantiate a cache *per run* of livecd-creator. --cache is an option for those who know what they're doing. > Otherwise I have no choice but to include arch within cachedir's name, > which seems bad. > /var/cache/imagecreator-i386/ > /var/cache/imagecreator-x86_64/ If you're doing runs of both i386 and x86_64 on the same machine and want to keep a persistent cache between runs, this is what I would recommend. Jeremy From katzj at redhat.com Tue Feb 19 18:58:46 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 19 Feb 2008 13:58:46 -0500 Subject: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool In-Reply-To: <20080217021443.GH24669@redhat.com> References: <20080217021443.GH24669@redhat.com> Message-ID: <1203447526.13019.47.camel@aglarond.local> On Sun, 2008-02-17 at 02:14 +0000, Daniel P. Berrange wrote: > This patch adds support for another installation variant. The livecd-creator > produces ISO images which boot using syslinux. The image-creator creates a > single file containing a filesystem in which the OS is installated. This patch > adds a new disk-creator, which creates a single file containing a partitioned > disk with potentially many filesystems in which the OS is installed. Furthermore > it installs grub in the boot sector, so this image is immediately bootable in > a virtual machine. Seems reasonable enough and it's something I had started looking at. My biggest concerns end up being scope... the next thing someone will want to add is RAID. Or LVM. Or dm-crypt. And I sort of wonder where it ends. I already gets bugs on one copy of code like that and it's called anaconda ;-) > I've used this tool to create an instance of the oVirt web management appliance > from its kickstart recipe. Currently developers building the appliance have to > boot a VM using the F8 boot.iso and run the kickstart script in the VM and so > on. While this works, involves many steps with potential for failure. This new > tool reduces the problem to simply As opposed to virt-install --name ... ? I'm not convinced there's a huge gain in terms of number of places for failure :-/ All the above said, I'm not necessarily against a disk creator, I'm just a little wary at this point... > With the background information out of the way, here's some info about the > changes in this patch... Ob-side-note: your patch doesn't seem to be against master or at least, is missing some bits as it doesn't want to apply. > Most of the change here involves re-factoring the imgcreate/fs.py module. > The SparseExtLoopbackMount, SparseLoopbackMount, LoopbackMount classes all > have the built-in limitation that the image being produced corresponds to > a single filesystem / loop mount. With the disk creator, the image being > produced can be partitioned into multiple chunks, with many filesystems. > Furthermore, not all of them require loopback mounts, as the partitions > themselves are already visible via /dev/mapper/ > > So this patch separates the roles. There are now classes which deal with > accessing / creating disks: [snip] > The 'create' method must make the disk visible as a block device - eg > by calling losetup. For RawDisk, this is obviously a no-op. The 'cleanup' > method must undo the 'create' operation. Sounds okay... the API change involved is a little unfortunate, but I did caveat that the API in -14 isn't guaranteed, so it should be fine. > Next, up we have a new class 'PartitionedMount'. This takes a Disk object > and adds one or more partitions to it. It then creates further Disk and > Mount object instances for each partition. So, mounting a 'PartitionedMount' > object will in fact mount all its partitions (formatting the filesystems > or swap space as needed). It looks like you're calling parted directly here rather than using the python bindings? The latter is probably somewhat preferable. Also, there are probably some interesting questions about always assuming that you want an msdos partition table :-/ This goes back to my first point... [snip] > It doesn't currently care about --ondisk only outputting a single disk > image, but I intend to extend the CLI to allow creation of installs which > spawn multiple output disks. My only concern with doing it on the CLI is that it makes reproducability of the images more difficult. And then what happens if my config references two disks but I only gave one on the command line or other permutations. I wonder if we want to come up with some syntax like (warning: completely made up and not really thought about much at all yet :-) disk DISKA foo.img disk DISKB bar.img That might tie nicely with giving people an alternate way of defining their disks on a real kickstart too rather than depending on kernel naming. More thought required... > Aside from partitioning, DiskImageCreator will setup an fstab file containing > entries for all the filesystems and swap space. It will add the grub device > map file, and create a grub.cfg based off the installed kernel. It is able > to cope with a layout where grub config is on /, or a separate /boot partition. > We can't use grub-install since it doesn't understand loopdevices, so to do > the MBR install we invoke grub manually. Yeah, and this can be tricky. At least historically, there have been cases which setup wasn't sufficient for and we had to do the full install invocation. Which is why that's what anaconda does. Jeremy From berrange at redhat.com Tue Feb 19 19:16:51 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 19 Feb 2008 19:16:51 +0000 Subject: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool In-Reply-To: <1203447526.13019.47.camel@aglarond.local> References: <20080217021443.GH24669@redhat.com> <1203447526.13019.47.camel@aglarond.local> Message-ID: <20080219191651.GN17472@redhat.com> On Tue, Feb 19, 2008 at 01:58:46PM -0500, Jeremy Katz wrote: > On Sun, 2008-02-17 at 02:14 +0000, Daniel P. Berrange wrote: > > This patch adds support for another installation variant. The livecd-creator > > produces ISO images which boot using syslinux. The image-creator creates a > > single file containing a filesystem in which the OS is installated. This patch > > adds a new disk-creator, which creates a single file containing a partitioned > > disk with potentially many filesystems in which the OS is installed. Furthermore > > it installs grub in the boot sector, so this image is immediately bootable in > > a virtual machine. > > Seems reasonable enough and it's something I had started looking at. My > biggest concerns end up being scope... the next thing someone will want > to add is RAID. Or LVM. Or dm-crypt. And I sort of wonder where it > ends. I already gets bugs on one copy of code like that and it's called > anaconda ;-) Where to draw the line is an interesting question. If you consider the created appliance as primary serving for deployment in virtual machines, then I'd argue that RAID / crypt is out of scope. They would be a site-specific deployment question. If an admin wants encryption they can set it up in the host directly. Likewise RAID can be done in the host already so its redundant for guests. LVM would be useful if only to make adding storage to the appliance easier. So I'd declare that scope is limited to plain partitions + LVM. > > I've used this tool to create an instance of the oVirt web management appliance > > from its kickstart recipe. Currently developers building the appliance have to > > boot a VM using the F8 boot.iso and run the kickstart script in the VM and so > > on. While this works, involves many steps with potential for failure. This new > > tool reduces the problem to simply > > As opposed to virt-install --name ... ? I'm not convinced there's a > huge gain in terms of number of places for failure :-/ You have to have a working virtualization stack & it takes more resource overhead than just doing the chroot'd build. Emprically the part of our build process doing the guest based installs has been less reliable than the livecd-creator part. Havinga disk-creator will address that problem > > With the background information out of the way, here's some info about the > > changes in this patch... > > Ob-side-note: your patch doesn't seem to be against master or at least, > is missing some bits as it doesn't want to apply. I used a fresh git checkout from saturday for doing all the work against and don't see any changes since then. > > Most of the change here involves re-factoring the imgcreate/fs.py module. > > The SparseExtLoopbackMount, SparseLoopbackMount, LoopbackMount classes all > > have the built-in limitation that the image being produced corresponds to > > a single filesystem / loop mount. With the disk creator, the image being > > produced can be partitioned into multiple chunks, with many filesystems. > > Furthermore, not all of them require loopback mounts, as the partitions > > themselves are already visible via /dev/mapper/ > > > > So this patch separates the roles. There are now classes which deal with > > accessing / creating disks: > [snip] > > The 'create' method must make the disk visible as a block device - eg > > by calling losetup. For RawDisk, this is obviously a no-op. The 'cleanup' > > method must undo the 'create' operation. > > Sounds okay... the API change involved is a little unfortunate, but I > did caveat that the API in -14 isn't guaranteed, so it should be fine. If its really a problem, we've got the option of just leaving the existing classes unchanged & deprecating their use in favour of the new ones, but if no one is using the API seriously yet it might not be worth the hassle. > > Next, up we have a new class 'PartitionedMount'. This takes a Disk object > > and adds one or more partitions to it. It then creates further Disk and > > Mount object instances for each partition. So, mounting a 'PartitionedMount' > > object will in fact mount all its partitions (formatting the filesystems > > or swap space as needed). > > It looks like you're calling parted directly here rather than using the > python bindings? The latter is probably somewhat preferable. Also, > there are probably some interesting questions about always assuming that > you want an msdos partition table :-/ This goes back to my first > point... I didn't realize there were useful parted python bindings. I'll happily use them if that's desired. The use of msdos partitions can easily be addressed - I just didn't look to see if there's a kickstart syntax option for specifying partition table type yet. > [snip] > > It doesn't currently care about --ondisk only outputting a single disk > > image, but I intend to extend the CLI to allow creation of installs which > > spawn multiple output disks. > > My only concern with doing it on the CLI is that it makes > reproducability of the images more difficult. And then what happens if > my config references two disks but I only gave one on the command line > or other permutations. I wonder if we want to come up with some syntax > like (warning: completely made up and not really thought about much at > all yet :-) > disk DISKA foo.img > disk DISKB bar.img > > That might tie nicely with giving people an alternate way of defining > their disks on a real kickstart too rather than depending on kernel > naming. More thought required... To be honest we could simply name the disks according to the device names given in the kickstart file - eg ovirt-wui-sda.raw & ovirt-wui-sdb.raw. If we want to mandate the specification of '--size' flag for all partitions in the kickstart and not support '--grow', then we don't need any CLI flags for disk-creator at all. This would certainly aid reproducability > > Aside from partitioning, DiskImageCreator will setup an fstab file containing > > entries for all the filesystems and swap space. It will add the grub device > > map file, and create a grub.cfg based off the installed kernel. It is able > > to cope with a layout where grub config is on /, or a separate /boot partition. > > We can't use grub-install since it doesn't understand loopdevices, so to do > > the MBR install we invoke grub manually. > > Yeah, and this can be tricky. At least historically, there have been > cases which setup wasn't sufficient for and we had to do the full > install invocation. Which is why that's what anaconda does. On the flip side anaconda has a much broader use case than we have to worry about for creating appliances. Looking at the final grub commands that grub-install actually runs, there's nothing magic we can't do directly. The problem with grub-install is all the 'sanity' checking & probing it does before actually running grub, which simply doesn't apply to loop devices. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From jkeating at redhat.com Tue Feb 19 19:57:33 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 Feb 2008 14:57:33 -0500 Subject: [Fedora-livecd-list] cachedir conflict... bug? In-Reply-To: <1203444430.13019.26.camel@aglarond.local> References: <47B900A3.5070401@redhat.com> <1203444430.13019.26.camel@aglarond.local> Message-ID: <20080219145733.38ddc099@redhat.com> On Tue, 19 Feb 2008 13:07:10 -0500 Jeremy Katz wrote: > Don't do that. You're basically saying that you have a repository > named foo but foo is two different things depending on how you run. > > [snip] > > Are there any genuine bugs in anything I described above? > > Shouldn't yum warn or error out when it sees the repodata arch > > conflict? > > repodata doesn't have an inherent archness. You can have repodata > containing packages of all arches. FWIW in pungi I use a single cache name for all arches. However for every single run I expire the metadata and require fresh metadata be downloaded. This seems to work for me, not many people have complained about getting new repodata every run. -- 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: 197 bytes Desc: not available URL: From wtogami at redhat.com Tue Feb 19 20:09:54 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 19 Feb 2008 15:09:54 -0500 Subject: [Fedora-livecd-list] cachedir conflict... bug? In-Reply-To: <20080219145733.38ddc099@redhat.com> References: <47B900A3.5070401@redhat.com> <1203444430.13019.26.camel@aglarond.local> <20080219145733.38ddc099@redhat.com> Message-ID: <47BB3792.5080901@redhat.com> Jesse Keating wrote: > On Tue, 19 Feb 2008 13:07:10 -0500 > Jeremy Katz wrote: > >> Don't do that. You're basically saying that you have a repository >> named foo but foo is two different things depending on how you run. >> >> [snip] >>> Are there any genuine bugs in anything I described above? >>> Shouldn't yum warn or error out when it sees the repodata arch >>> conflict? >> repodata doesn't have an inherent archness. You can have repodata >> containing packages of all arches. > > FWIW in pungi I use a single cache name for all arches. However for > every single run I expire the metadata and require fresh metadata be > downloaded. This seems to work for me, not many people have complained > about getting new repodata every run. > What do you use to expire the metadata? That sounds very useful. I would like to keep a single cachedir mainly for the RPMS and not necessarily the metadata. Warren Togami wtogami at redhat.com From wtogami at redhat.com Tue Feb 19 20:32:04 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 19 Feb 2008 15:32:04 -0500 Subject: [Fedora-livecd-list] unmount failure kaboom Message-ID: <47BB3CC4.4090104@redhat.com> chroot-creator does: creator.mount() # --bind mount a directory like /opt/ltsp/i386 upon instroot creator.install() creator.configure() creator.unmount() # Umount all the bind mounts then unmount instroot ... creator.cleanup() # Recursively delete the temp directory Between unmount() and cleanup() in other LiveCD workflows is a time consuming step where an image is created. Unfortunately, in my case there is no time consuming step between unmount() and cleanup() which sometimes leads to this failure: Installing: xorg-x11-drv-spaceorb ##################### [308/308] umount: /var/tmp/imgcreate-C_SsuB/install_root: device is busy Thankfully none of the bind mounts from the host were still mounted during the recursive delete. But it did blow away the payload of the chroot-creator run. Is there any safe way to detect that processes within the chroot are truly done before trusting that the unmount was complete? Warren Togami wtogami at redhat.com From katzj at redhat.com Tue Feb 19 21:24:57 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 19 Feb 2008 16:24:57 -0500 Subject: [Fedora-livecd-list] cachedir conflict... bug? In-Reply-To: <20080219145733.38ddc099@redhat.com> References: <47B900A3.5070401@redhat.com> <1203444430.13019.26.camel@aglarond.local> <20080219145733.38ddc099@redhat.com> Message-ID: <1203456297.13019.51.camel@aglarond.local> On Tue, 2008-02-19 at 14:57 -0500, Jesse Keating wrote: > On Tue, 19 Feb 2008 13:07:10 -0500 > Jeremy Katz wrote: > > Don't do that. You're basically saying that you have a repository > > named foo but foo is two different things depending on how you run. > > > > [snip] > > > Are there any genuine bugs in anything I described above? > > > Shouldn't yum warn or error out when it sees the repodata arch > > > conflict? > > > > repodata doesn't have an inherent archness. You can have repodata > > containing packages of all arches. > > FWIW in pungi I use a single cache name for all arches. However for > every single run I expire the metadata and require fresh metadata be > downloaded. This seems to work for me, not many people have complained > about getting new repodata every run. That doesn't sound crazy. If someone were to provide the patch, I'd almost certainly apply it. Or I'll get to it "eventually" Jeremy From katzj at redhat.com Tue Feb 19 21:27:15 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 19 Feb 2008 16:27:15 -0500 Subject: [Fedora-livecd-list] unmount failure kaboom In-Reply-To: <47BB3CC4.4090104@redhat.com> References: <47BB3CC4.4090104@redhat.com> Message-ID: <1203456435.13019.55.camel@aglarond.local> On Tue, 2008-02-19 at 15:32 -0500, Warren Togami wrote: > Between unmount() and cleanup() in other LiveCD workflows is a time > consuming step where an image is created. Unfortunately, in my case > there is no time consuming step between unmount() and cleanup() which > sometimes leads to this failure: > > Installing: xorg-x11-drv-spaceorb ##################### [308/308] > umount: /var/tmp/imgcreate-C_SsuB/install_root: device is busy Do you know what's still running/accessing the install_root at that point? > Is there any safe way to detect that processes within the chroot are > truly done before trusting that the unmount was complete? Not really :-/ I have been thinking about switching to do umount -l instead of just umount, though. Which I think would be as effective. Can anyone think of any downsides of doing so? Jeremy From jkeating at redhat.com Tue Feb 19 21:51:51 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 Feb 2008 16:51:51 -0500 Subject: [Fedora-livecd-list] cachedir conflict... bug? In-Reply-To: <47BB3792.5080901@redhat.com> References: <47B900A3.5070401@redhat.com> <1203444430.13019.26.camel@aglarond.local> <20080219145733.38ddc099@redhat.com> <47BB3792.5080901@redhat.com> Message-ID: <20080219165151.063881c0@redhat.com> On Tue, 19 Feb 2008 15:09:54 -0500 Warren Togami wrote: > What do you use to expire the metadata? That sounds very useful. I > would like to keep a single cachedir mainly for the RPMS and not > necessarily the metadata. I use a yum call to clean the metadata and sqlite data. self.ayum.cleanMetadata() # clean metadata that might be in the cache from previous runs self.ayum.cleanSqlite() # clean metadata that might be in the cache from previous runs Some things to consider, don't allow multiple runs of livecd-creator to use the same cache at the same time. This could be... interesting. So a locking system is needed. I don't actually have a locking system in pungi yet, I've been playing fast and loose with it. -- 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: 197 bytes Desc: not available URL: From tim.wood at datawranglers.com Tue Feb 19 22:03:53 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Tue, 19 Feb 2008 15:03:53 -0700 Subject: [Fedora-livecd-list] cachedir conflict... bug? In-Reply-To: <20080219165151.063881c0@redhat.com> References: <47B900A3.5070401@redhat.com> <1203444430.13019.26.camel@aglarond.local> <20080219145733.38ddc099@redhat.com> <47BB3792.5080901@redhat.com> <20080219165151.063881c0@redhat.com> Message-ID: <47BB5249.3020008@datawranglers.com> Is there a way to clean the metadata from bash? Tim Jesse Keating wrote: > On Tue, 19 Feb 2008 15:09:54 -0500 > Warren Togami wrote: > > >> What do you use to expire the metadata? That sounds very useful. I >> would like to keep a single cachedir mainly for the RPMS and not >> necessarily the metadata. >> > > I use a yum call to clean the metadata and sqlite data. > > self.ayum.cleanMetadata() # clean metadata that might be in the cache from previous runs > self.ayum.cleanSqlite() # clean metadata that might be in the cache from previous runs > > > Some things to consider, don't allow multiple runs of livecd-creator to > use the same cache at the same time. This could be... interesting. So > a locking system is needed. I don't actually have a locking system in > pungi yet, I've been playing fast and loose with it. > > > ------------------------------------------------------------------------ > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > -- _________________________________ Tim Wood, CLP, RHCT 719.338.7484 (tel) The Data Wranglers Web, Database & more since since 1994 www.datawranglers.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Tue Feb 19 22:07:29 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 Feb 2008 17:07:29 -0500 Subject: [Fedora-livecd-list] cachedir conflict... bug? In-Reply-To: <47BB5249.3020008@datawranglers.com> References: <47B900A3.5070401@redhat.com> <1203444430.13019.26.camel@aglarond.local> <20080219145733.38ddc099@redhat.com> <47BB3792.5080901@redhat.com> <20080219165151.063881c0@redhat.com> <47BB5249.3020008@datawranglers.com> Message-ID: <20080219170729.6ff3d4a0@redhat.com> On Tue, 19 Feb 2008 15:03:53 -0700 Tim Wood wrote: > Is there a way to clean the metadata from bash? Erm.. I thought livecd-creator used a yum object instead of executing yum.... but yes. yum clean metadata dbcache It'll clean it from all enabled repos. Note: sharing system yum cache and compose tool yum cache is a pretty bad idea. I would not recommend it. -- 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: 197 bytes Desc: not available URL: From tim.wood at datawranglers.com Tue Feb 19 22:15:44 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Tue, 19 Feb 2008 15:15:44 -0700 Subject: [Fedora-livecd-list] cachedir conflict... bug? In-Reply-To: <20080219170729.6ff3d4a0@redhat.com> References: <47B900A3.5070401@redhat.com> <1203444430.13019.26.camel@aglarond.local> <20080219145733.38ddc099@redhat.com> <47BB3792.5080901@redhat.com> <20080219165151.063881c0@redhat.com> <47BB5249.3020008@datawranglers.com> <20080219170729.6ff3d4a0@redhat.com> Message-ID: <47BB5510.806@datawranglers.com> Worked like a champ. Thanks. FWIW, I try to err on the side of caution so I've never mixed up the system and livecd-tools caches. I have too much "fun" without trying to intentionally shoot my foot off ;-) Tim Jesse Keating wrote: > On Tue, 19 Feb 2008 15:03:53 -0700 > Tim Wood wrote: > > >> Is there a way to clean the metadata from bash? >> > > Erm.. I thought livecd-creator used a yum object instead of executing > yum.... but yes. > > yum clean metadata dbcache > > It'll clean it from all enabled repos. > > Note: sharing system yum cache and compose tool yum cache is a pretty > bad idea. I would not recommend it. > > > ------------------------------------------------------------------------ > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > -- _________________________________ Tim Wood, CLP, RHCT 719.338.7484 (tel) The Data Wranglers Web, Database & more since since 1994 www.datawranglers.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtogami at redhat.com Tue Feb 19 22:25:14 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 19 Feb 2008 17:25:14 -0500 Subject: [Fedora-livecd-list] ImageCreator "selinux --disable" problem Message-ID: <47BB574A.5000507@redhat.com> I am trying to reproduce the install behavior of anaconda --noselinux, where it installs a chroot without labels. [1] I need this for LTSP due to SELinux chroot limitations, and Dan Walsh confirms that this is my best option given these current limitations. First I discovered places in kickstart.py where it is supposed to be checking that SELinux-from-kickstart file setting was always returning true. I believe the attached patch fixes this part, although it could use some review. To my dismay it continued to install with labels. I then realized that creator.py's ImageCreator mount() method unconditionally bind mounted the system's /selinux directory, which is incorrect if "selinux --disabled" is defined in the kickstart file. Perhaps my understanding of python is not advanced, but it appears that there is no good way to check kickstart's selinux setting from the mount() method due to the way it is abstracted. Any ideas what could be done here? Warren Togami wtogami at redhat.com [1] OK, it really does have labels, but all the labels are the same. -------------- next part -------------- A non-text attachment was scrubbed... Name: imagecreator-selinux-disable.patch Type: text/x-patch Size: 1320 bytes Desc: not available URL: From asheesh at creativecommons.org Wed Feb 20 00:08:20 2008 From: asheesh at creativecommons.org (Asheesh Laroia) Date: Tue, 19 Feb 2008 16:08:20 -0800 (PST) Subject: [Fedora-livecd-list] bootloader --append="noapic" does nothing? Message-ID: I noticed when testing my Live CD on a Dell at the Creative Commons office that it would not boot without the noapic option. (The kernel complained about this, and told me to send in a debug report for APIC, which I might do later. We were planning to have this disc out very soon; it'd be great if the above issue were fixable for this release.) So, at the advice of http://www.informit.com/articles/article.aspx?p=1157197&seqNum=4 , I added this toward the start of my Kickstart file: bootloader --append="noapic" Alas, the resulting disc still does not pass "noapic" to the kernel. What am I supposed to do? http://buildbot.creativecommons.org:8080/builders/livecontent%20builder/builds/73/steps/compile/logs/stdio is the long, long log of us building that CD, in case any of that output is useful. -- Asheesh. -- The whole of life is futile unless you consider it as a sporting proposition. From asheesh at creativecommons.org Wed Feb 20 00:16:11 2008 From: asheesh at creativecommons.org (Asheesh Laroia) Date: Tue, 19 Feb 2008 16:16:11 -0800 (PST) Subject: [Fedora-livecd-list] Storing the image as UDF not IS9660 Message-ID: In adding the data I wanted to the Live CD, I quickly ran into the filename length limitation of ISO9660/Joliet. If I'm willing to break the Joliet standard, I can get files of length 102 on the disc. Normally the standard lets me use 64-character filenames. Meanwhile, as I understand things, UDF is the normal filesystem for DVDs, is pretty widely-supported, and supports 255-character-long paths, perhaps longer . It would even work for CDs; it's not as if you'd have to stop supporting generating CDs. Right now, you generate DVDs as large CDs; using UDF would let you generate CDs as if they were small DVDs. (Both work on most OSs, and besides, You would just switch to Have you guys thought about making livecd-creator output UDF-format filesystems rather than the limited ISO9660? -- Asheesh. -- * Knghtbrd is FAR too tempted to .sig this entire discussion... From tim.wood at datawranglers.com Wed Feb 20 00:30:56 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Tue, 19 Feb 2008 17:30:56 -0700 Subject: [Fedora-livecd-list] Corrupted RPMs Message-ID: <47BB74C0.5070501@datawranglers.com> The LiveCDs I've been trying to create today are all failing. In each case I'm getting what looks like corrupted rpms from official repositories. I've forced it to use three different repositories with similar results All of the RPMs in question are either release or update fedora 8 rpms. The only solutions I can think of vis-a-vis the RPMs is to some variant of rebuilding, trying all the mirrors or waaaaiiiitttting. Any other suggestions? Tim [snip] Retrieving http://linux.nssl.noaa.gov/fedora/linux/releases/8/Everything/i386/os/Packages/setuptool-1.19.3-1.fc8.i386.rpm ...OK Retrieving http://mirror.cc.vt.edu/pub/fedora/linux/updates/8/i386/rarian-0.6.0-3.fc8.i386.rpm ...OK Retrieving http://mirror.cc.vt.edu/pub/fedora/linux/updates/8/i386/rarian-compat-0.6.0-3.fc8.i386.rpm ...OK Retrieving http://linux.nssl.noaa.gov/fedora/linux/releases/8/Everything/i386/os/Packages/setup-2.6.10-1.fc8.noarch.rpm ...OK Reducing None to included packages only [snip] warning: setup-2.6.10-1.fc8: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 Installing: setup ##################### [ 2/800] [snip] Installing: bluecurve-icon-theme ##################### [266/800] /var/tmp/rpm-tmp.74071: line 1: touch: command not found Installing: fedora-release-notes ##################### [267/800] [snip] Installing: rarian-compat ##################### [364/800] add command failed could not open /etc/xml/catalog for saving add command failed could not open /etc/xml/catalog for saving error: %post(rarian-compat-0.6.0-3.fc8.i386) scriptlet failed, exit status 2 [snip] Pass 5: Checking group summary information tdw-sw-gateway-0: 91674/262144 files (0.3% non-contiguous), 517402/517402 blocks Traceback (most recent call last): File "/usr/bin/livecd-creator", line 132, in sys.exit(main()) File "/usr/bin/livecd-creator", line 122, in main creator.package() File "/usr/lib/python2.5/site-packages/imgcreate/creator.py", line 655, in package self._stage_final_image() File "/usr/lib/python2.5/site-packages/imgcreate/live.py", line 295, in _stage_final_image self._image, minimal_size) File "/usr/lib/python2.5/site-packages/imgcreate/fs.py", line 393, in create_image_minimizer cowloop.create() File "/usr/lib/python2.5/site-packages/imgcreate/fs.py", line 193, in create self.expand(create = True) File "/usr/lib/python2.5/site-packages/imgcreate/fs.py", line 179, in expand fd = os.open(self.lofile, flags) OSError: [Errno 20] Not a directory: '/var/tmp/imgcreate-zO-jIc/iso-HB_7Wh/LiveOS/osmin' From dex.mbox at googlemail.com Wed Feb 20 03:28:30 2008 From: dex.mbox at googlemail.com (dexter) Date: Wed, 20 Feb 2008 03:28:30 +0000 Subject: [Fedora-livecd-list] imgcreate/creator.py In-Reply-To: <200802191805.m1JI5ifu020887@hosted1.fedoraproject.org> References: <200802191805.m1JI5ifu020887@hosted1.fedoraproject.org> Message-ID: <200802200328.31220.dex.mbox@gmail.com> On Tue February 19 2008 18:05:44 Jeremy Katz wrote: > imgcreate/creator.py | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > New commits: > commit d570c73c1912a6a8b0f21a383d9850e1189f9619 > Author: Warren Togami > Date: Thu Feb 14 18:23:13 2008 -0500 > > LiveCD Patch: Typo in _do_bindmounts() comment > > diff --git a/imgcreate/creator.py b/imgcreate/creator.py > index c2ed770..a8c9d9b 100644 > --- a/imgcreate/creator.py > +++ b/imgcreate/creator.py > @@ -274,8 +274,8 @@ class ImageCreator(object): > """Mount various system directories onto _instroot. > > This method is called by mount(), but may also be used by > subclasses - in order to re-mount the bindmounts after modifying the > underyling the - underlying filesystem. > + in order to re-mount the bindmounts after modifying the underyling > + filesystem. > > """ > for b in self.__bindmounts: A typo in the typo s/underyling/underlying/ ...dex From orion at cora.nwra.com Wed Feb 20 04:07:10 2008 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Tue, 19 Feb 2008 21:07:10 -0700 (MST) Subject: [Fedora-livecd-list] Corrupted RPMs In-Reply-To: <47BB74C0.5070501@datawranglers.com> References: <47BB74C0.5070501@datawranglers.com> Message-ID: <49544.71.208.66.222.1203480430.squirrel@www.cora.nwra.com> > The LiveCDs I've been trying to create today are all failing. > > > Pass 5: Checking group summary information > > tdw-sw-gateway-0: 91674/262144 files (0.3% non-contiguous), 517402/517402 > blocks I suspect you're running to the problem Warren Togami reported earlier, and that I've clumsily reported here: https://bugzilla.redhat.com/show_bug.cgi?id=432521. If you look closer at the logs you'll probably see that it isn't able to umount the install_root. This results in the install_root not getting flushed to disk and so the filesystem is dirty. fsck comes along later and "cleans up" by removing random stuff. I'm trying to find out what is keeping the install_root busy... - Orion From orion at cora.nwra.com Wed Feb 20 04:12:37 2008 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Tue, 19 Feb 2008 21:12:37 -0700 (MST) Subject: [Fedora-livecd-list] Corrupted RPMs In-Reply-To: <49544.71.208.66.222.1203480430.squirrel@www.cora.nwra.com> References: <47BB74C0.5070501@datawranglers.com> <49544.71.208.66.222.1203480430.squirrel@www.cora.nwra.com> Message-ID: <49325.71.208.66.222.1203480757.squirrel@www.cora.nwra.com> >> The LiveCDs I've been trying to create today are all failing. >> >> >> Pass 5: Checking group summary information >> >> tdw-sw-gateway-0: 91674/262144 files (0.3% non-contiguous), >> 517402/517402 >> blocks > > > I suspect you're running to the problem Warren Togami reported earlier, > and that I've clumsily reported here: > https://bugzilla.redhat.com/show_bug.cgi?id=432521. > Sorry, that should be https://bugzilla.redhat.com/show_bug.cgi?id=430606 - Orion From tim.wood at datawranglers.com Wed Feb 20 05:44:13 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Tue, 19 Feb 2008 22:44:13 -0700 Subject: [Fedora-livecd-list] Corrupted RPMs In-Reply-To: <49325.71.208.66.222.1203480757.squirrel@www.cora.nwra.com> References: <47BB74C0.5070501@datawranglers.com> <49544.71.208.66.222.1203480430.squirrel@www.cora.nwra.com> <49325.71.208.66.222.1203480757.squirrel@www.cora.nwra.com> Message-ID: <47BBBE2D.6010304@datawranglers.com> That matches some other symptoms I'm seeing. I'm encountering this with kickstarts that worked about 2 weeks ago so it may be something recently introduced (or uncovered by such). Is there a log file that provides more info (beyond /var/log/messages)? I'll have to try some of the standard kickstarts tomorrow to see if they have the same problem ... because I suspect there's also a corrupt RPM issue. My suspicion is that the first corrupt RPM (setup) is causing the problems with the other RPMs. Tim orion at cora.nwra.com wrote: >>> The LiveCDs I've been trying to create today are all failing. >>> >>> >>> Pass 5: Checking group summary information >>> >>> tdw-sw-gateway-0: 91674/262144 files (0.3% non-contiguous), >>> 517402/517402 >>> blocks >>> >> I suspect you're running to the problem Warren Togami reported earlier, >> and that I've clumsily reported here: >> https://bugzilla.redhat.com/show_bug.cgi?id=432521. >> >> > > Sorry, that should be https://bugzilla.redhat.com/show_bug.cgi?id=430606 > > - Orion > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > -- _________________________________ Tim Wood, CLP, RHCT 719.338.7484 (tel) The Data Wranglers Web, Database & more since since 1994 www.datawranglers.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.wood at datawranglers.com Wed Feb 20 06:17:28 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Tue, 19 Feb 2008 23:17:28 -0700 Subject: [Fedora-livecd-list] Corrupted RPMs In-Reply-To: <47BBBE2D.6010304@datawranglers.com> References: <47BB74C0.5070501@datawranglers.com> <49544.71.208.66.222.1203480430.squirrel@www.cora.nwra.com> <49325.71.208.66.222.1203480757.squirrel@www.cora.nwra.com> <47BBBE2D.6010304@datawranglers.com> Message-ID: <47BBC5F8.90900@datawranglers.com> When I say matches other symptoms... sometimes files in the working directory (in /var/tmp/imgcreate* if I'm reading history right) never get released. So livecd-creator exits and the directory is still there. When I try to delete it (even with rm -rf as root), a long list of files report being tied up. If I reboot the machine, the files are freed and the directory and contents can be deleted. Tomorrow I'll have to try and do some weird sys-admin lsof-type checking on those files to see what's up. Tim From wtogami at redhat.com Wed Feb 20 07:50:07 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Feb 2008 02:50:07 -0500 Subject: [Fedora-livecd-list] ImageCreator "selinux --disable" problem In-Reply-To: <47BB574A.5000507@redhat.com> References: <47BB574A.5000507@redhat.com> Message-ID: <47BBDBAF.9030603@redhat.com> Warren Togami wrote: > I am trying to reproduce the install behavior of anaconda --noselinux, > where it installs a chroot without labels. [1] I need this for LTSP due > to SELinux chroot limitations, and Dan Walsh confirms that this is my > best option given these current limitations. > > First I discovered places in kickstart.py where it is supposed to be > checking that SELinux-from-kickstart file setting was always returning > true. I believe the attached patch fixes this part, although it could > use some review. > > To my dismay it continued to install with labels. I then realized that > creator.py's ImageCreator mount() method unconditionally bind mounted > the system's /selinux directory, which is incorrect if "selinux > --disabled" is defined in the kickstart file. > > Perhaps my understanding of python is not advanced, but it appears that > there is no good way to check kickstart's selinux setting from the > mount() method due to the way it is abstracted. > Hmm, I unmounted /selinux in a different way prior to install, and it still labeled the contents of the chroot unlike anaconda --noselinux. I will dig into anaconda source tomorrow to see if there is something I am missing. Warren From Timo.Penndorf at tu-dresden.de Wed Feb 20 11:22:55 2008 From: Timo.Penndorf at tu-dresden.de (Timo Penndorf) Date: Wed, 20 Feb 2008 12:22:55 +0100 Subject: [Fedora-livecd-list] ext3 issues Message-ID: <1203506575.10011.9.camel@localhost.localdomain> Hi, after creation of a live cd I get the error messages: EXT3-fs error (device loop0): ext3_xattr_block_get: inode 114831: bad block 655877 EXT3-fs error (device loop0): ext3_xattr_delete_inode: inode 114831: bad block 655877 These messages are repeated in a long sequence of entries with different inodes. The file system on the live cd is corrupted. I use a standard fedora installation with the follwoing package versions livecd-tools-013-1.fc8 e2fsprogs-1.40.4-1.fc8 libselinux-2.0.43-1.fc8 selinux-policy-3.0.8-84.fc8 selinux is in enforcing mode both on the build system as for the live cd. The used kickstart configuration worked fine on Fedora 7 and 6 (with disabled selinux) so what changes are important to fc8? Timo From kengert at redhat.com Wed Feb 20 12:30:10 2008 From: kengert at redhat.com (Kai Engert) Date: Wed, 20 Feb 2008 13:30:10 +0100 Subject: [Fedora-livecd-list] Simple persistence idea, /home only Message-ID: <47BC1D52.4070808@redhat.com> I've seen messages about complete persistence, which is, make sure all changes to the filesystem are persistent. However, for end user tasks it might be sufficient to offer persistence of the /home directory. Has the following idea been proposed already? I figure it would be easy to do. During boot, scan for a partition with a given label, say, "fedoralivehome". If present, that partition gets mounted as /home. As a consequence, all user settings and documents are kept across boots. An usb stick could be partitioned to have the second partition as /home. Does this idea make sense? Thanks, Kai -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3328 bytes Desc: S/MIME Cryptographic Signature URL: From katzj at redhat.com Wed Feb 20 17:44:21 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Feb 2008 12:44:21 -0500 Subject: [Fedora-livecd-list] cachedir conflict... bug? In-Reply-To: <20080219165151.063881c0@redhat.com> References: <47B900A3.5070401@redhat.com> <1203444430.13019.26.camel@aglarond.local> <20080219145733.38ddc099@redhat.com> <47BB3792.5080901@redhat.com> <20080219165151.063881c0@redhat.com> Message-ID: <1203529461.24402.35.camel@aglarond.local> On Tue, 2008-02-19 at 16:51 -0500, Jesse Keating wrote: > On Tue, 19 Feb 2008 15:09:54 -0500 > Warren Togami wrote: > > What do you use to expire the metadata? That sounds very useful. I > > would like to keep a single cachedir mainly for the RPMS and not > > necessarily the metadata. > > I use a yum call to clean the metadata and sqlite data. Why do you do the big hammer rather than just setting metadata_expire to be 0? Should have the same impact, but also allow the cached metadata to persist as long as the repomd matches Jeremy From katzj at fedoraproject.org Wed Feb 20 17:47:15 2008 From: katzj at fedoraproject.org (Jeremy Katz) Date: Wed, 20 Feb 2008 10:47:15 -0700 Subject: [Fedora-livecd-list] imgcreate/creator.py Message-ID: <200802201747.m1KHlF3O014007@hosted1.fedoraproject.org> imgcreate/creator.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit 6149c09920aaf5c53bd8e31013c0f4a5de206141 Author: Jeremy Katz Date: Wed Feb 20 12:44:42 2008 -0500 Fix typo noticed by dexter diff --git a/imgcreate/creator.py b/imgcreate/creator.py index a8c9d9b..c7b1046 100644 --- a/imgcreate/creator.py +++ b/imgcreate/creator.py @@ -274,7 +274,7 @@ class ImageCreator(object): """Mount various system directories onto _instroot. This method is called by mount(), but may also be used by subclasses - in order to re-mount the bindmounts after modifying the underyling + in order to re-mount the bindmounts after modifying the underlying filesystem. """ From katzj at redhat.com Wed Feb 20 17:57:13 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Feb 2008 12:57:13 -0500 Subject: [Fedora-livecd-list] bootloader --append="noapic" does nothing? In-Reply-To: References: Message-ID: <1203530233.24402.40.camel@aglarond.local> On Tue, 2008-02-19 at 16:08 -0800, Asheesh Laroia wrote: > I noticed when testing my Live CD on a Dell at the Creative Commons office > that it would not boot without the noapic option. (The kernel complained > about this, and told me to send in a debug report for APIC, which I might > do later. We were planning to have this disc out very soon; it'd be great > if the above issue were fixable for this release.) > > So, at the advice of > http://www.informit.com/articles/article.aspx?p=1157197&seqNum=4 , I added > this toward the start of my Kickstart file: > > bootloader --append="noapic" > > Alas, the resulting disc still does not pass "noapic" to the kernel. What > am I supposed to do? Which version of livecd-tools are you using for building your image? But note if you're doing this for a general-purpose image, you almost certainly don't want to add 'noapic' to the default. While it may help the specific machine you've tested on, it will cause problems on _more_ machines. Jeremy From katzj at redhat.com Wed Feb 20 17:59:34 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Feb 2008 12:59:34 -0500 Subject: [Fedora-livecd-list] Storing the image as UDF not IS9660 In-Reply-To: References: Message-ID: <1203530374.24402.44.camel@aglarond.local> On Tue, 2008-02-19 at 16:16 -0800, Asheesh Laroia wrote: > Meanwhile, as I understand things, UDF is the normal filesystem for DVDs, > is pretty widely-supported, and supports 255-character-long paths, perhaps > longer . It > would even work for CDs; it's not as if you'd have to stop supporting > generating CDs. Right now, you generate DVDs as large CDs; using UDF > would let you generate CDs as if they were small DVDs. (Both work on > most OSs, and besides, You would just switch to > > Have you guys thought about making livecd-creator output UDF-format > filesystems rather than the limited ISO9660? ISO9660 is still a lot more standard and common. Are there even any apps yet that will generate UTF instead? Jeremy From katzj at redhat.com Wed Feb 20 18:08:37 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Feb 2008 13:08:37 -0500 Subject: [Fedora-livecd-list] Corrupted RPMs In-Reply-To: <47BB74C0.5070501@datawranglers.com> References: <47BB74C0.5070501@datawranglers.com> Message-ID: <1203530917.24402.47.camel@aglarond.local> On Tue, 2008-02-19 at 17:30 -0700, Tim Wood wrote: > The LiveCDs I've been trying to create today are all failing. In each > case I'm getting what looks like corrupted rpms from official repositories. > I've forced it to use three different repositories with similar > results All of the RPMs in question are either release or update > fedora 8 rpms. The only solutions I can think of vis-a-vis the RPMs is > to some variant of rebuilding, trying all the mirrors or > waaaaiiiitttting. Any other suggestions? The scriptlet bits you're seeing aren't necessarily errors (well, there are some that should be filed as package bugs as the packages are likely missing proper Requires(post) bits).. > Traceback (most recent call last): .. This is the more interesting piece. It looks very similar to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=431287 which should have been fixed with commit ade8a8c33a6e3051ec9bf48d0bacdd1475a2aed5. Are you using git tip with the current configs? Or git tip with your own config? Jeremy From katzj at redhat.com Wed Feb 20 18:10:17 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Feb 2008 13:10:17 -0500 Subject: [Fedora-livecd-list] Simple persistence idea, /home only In-Reply-To: <47BC1D52.4070808@redhat.com> References: <47BC1D52.4070808@redhat.com> Message-ID: <1203531017.24402.50.camel@aglarond.local> On Wed, 2008-02-20 at 13:30 +0100, Kai Engert wrote: > I've seen messages about complete persistence, which is, make sure all > changes to the filesystem are persistent. > > However, for end user tasks it might be sufficient to offer persistence > of the /home directory. > > Has the following idea been proposed already? > I figure it would be easy to do. > > During boot, scan for a partition with a given label, say, "fedoralivehome". > If present, that partition gets mounted as /home. > As a consequence, all user settings and documents are kept across boots. > An usb stick could be partitioned to have the second partition as /home. > > Does this idea make sense? I've thought about it before, the problem ends up being that you really don't want to use, eg, a fat filesystem for the home directory which makes it a little trickier. It's definitely my fallback thinking at this point, although I do actually think we can get something along the line of dmc's patches merged... I just need to see what's up with the upstart conversion (as it also involved changes to how we halt and I didn't want to have to figure that side out twice :-) Jeremy From asheesh at creativecommons.org Wed Feb 20 18:16:50 2008 From: asheesh at creativecommons.org (Asheesh Laroia) Date: Wed, 20 Feb 2008 10:16:50 -0800 (PST) Subject: [Fedora-livecd-list] bootloader --append="noapic" does nothing? In-Reply-To: <1203530233.24402.40.camel@aglarond.local> References: <1203530233.24402.40.camel@aglarond.local> Message-ID: On Wed, 20 Feb 2008, Jeremy Katz wrote: >> Alas, the resulting disc still does not pass "noapic" to the kernel. >> What am I supposed to do? > > Which version of livecd-tools are you using for building your image? I'm running the version that yum installed on Fedora 8. # rpm -q livecd-tools livecd-tools-013-1.fc8 Is that a good version to be running? If not, what's the proper way to get a fresher version? > But note if you're doing this for a general-purpose image, you almost > certainly don't want to add 'noapic' to the default. While it may help > the specific machine you've tested on, it will cause problems on _more_ > machines. Hmm. Then what is a reasonable way to build an image that doesn't fail on neither that Dell in the corner nor on other people's machines? It's a pretty catastrophic failure on that machine, and I'd frankly rather the system run slowly on some machines and never catastrophically fail rather than catastrophically fail on some machines and work perfectly on others. Unrelated issue: the images I generate last night based on Fedora 8 + Fedora 8 updates fail to boot, complaining presumably from the initrd: WARNING: Cannot find root file system! Create symlink /dev/root and then exit this shell to continue the boot sequence. bash: no job control in this shell bash-3.2# _ I have disabled our use of the Fedora updates repository to see if that fixes this. (Do you guys know what's causing this? Is this probably related to this thread https://www.redhat.com/archives/fedora-livecd-list/2008-February/msg00135.html ?) I'll report back in a few hours, after the rebuild..... -- Asheesh. -- If I promised you the moon and the stars, would you believe it? -- Alan Parsons Project From katzj at redhat.com Wed Feb 20 18:17:21 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Feb 2008 13:17:21 -0500 Subject: [Fedora-livecd-list] ImageCreator "selinux --disable" problem In-Reply-To: <47BB574A.5000507@redhat.com> References: <47BB574A.5000507@redhat.com> Message-ID: <1203531441.24402.56.camel@aglarond.local> On Tue, 2008-02-19 at 17:25 -0500, Warren Togami wrote: > First I discovered places in kickstart.py where it is supposed to be > checking that SELinux-from-kickstart file setting was always returning > true. I believe the attached patch fixes this part, although it could > use some review. Looks reasonable enough. > To my dismay it continued to install with labels. I then realized that > creator.py's ImageCreator mount() method unconditionally bind mounted > the system's /selinux directory, which is incorrect if "selinux > --disabled" is defined in the kickstart file. > > Perhaps my understanding of python is not advanced, but it appears that > there is no good way to check kickstart's selinux setting from the > mount() method due to the way it is abstracted. It should work to take /selinux out of the list and then do if kickstart.selinux_enabled(self.ks): self.__bindmounts.append(BindChrootMount("/selinux", self._instroot, None)) Does that not work? And then also the macro change that we talked about on IRC Jeremy From jkeating at redhat.com Wed Feb 20 18:39:35 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Feb 2008 13:39:35 -0500 Subject: [Fedora-livecd-list] cachedir conflict... bug? In-Reply-To: <1203529461.24402.35.camel@aglarond.local> References: <47B900A3.5070401@redhat.com> <1203444430.13019.26.camel@aglarond.local> <20080219145733.38ddc099@redhat.com> <47BB3792.5080901@redhat.com> <20080219165151.063881c0@redhat.com> <1203529461.24402.35.camel@aglarond.local> Message-ID: <20080220133935.0e905e8a@redhat.com> On Wed, 20 Feb 2008 12:44:21 -0500 Jeremy Katz wrote: > Why do you do the big hammer rather than just setting metadata_expire > to be 0? Should have the same impact, but also allow the cached > metadata to persist as long as the repomd matches Because nobody had suggested it (: -- 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: 197 bytes Desc: not available URL: From katzj at redhat.com Wed Feb 20 18:42:45 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Feb 2008 13:42:45 -0500 Subject: [Fedora-livecd-list] bootloader --append="noapic" does nothing? In-Reply-To: References: <1203530233.24402.40.camel@aglarond.local> Message-ID: <1203532965.24402.62.camel@aglarond.local> On Wed, 2008-02-20 at 10:16 -0800, Asheesh Laroia wrote: > On Wed, 20 Feb 2008, Jeremy Katz wrote: > >> Alas, the resulting disc still does not pass "noapic" to the kernel. > >> What am I supposed to do? > > > > Which version of livecd-tools are you using for building your image? > > I'm running the version that yum installed on Fedora 8. [snip] > Is that a good version to be running? If not, what's the proper way to > get a fresher version? Yes, should be fine. I'm just trying to rule out "we broke it moving all the code around" as rawhide/current git right now has a lot moved around :) Looking at the rev, though, it doesn't look like we listen to --append (although we probably should) > > But note if you're doing this for a general-purpose image, you almost > > certainly don't want to add 'noapic' to the default. While it may help > > the specific machine you've tested on, it will cause problems on _more_ > > machines. > > Hmm. Then what is a reasonable way to build an image that doesn't fail on > neither that Dell in the corner nor on other people's machines? > > It's a pretty catastrophic failure on that machine, and I'd frankly rather > the system run slowly on some machines and never catastrophically fail > rather than catastrophically fail on some machines and work perfectly on > others. Running with noapic is a catastrophic failure for machines too. The right thing is to get the kernel bug fixed. Otherwise, you're just changing out one problem set for another one. And the kernel running in noapic mode is far far far far far less tested across hardware than the defaults. > Unrelated issue: the images I generate last night based on Fedora 8 + > Fedora 8 updates fail to boot, complaining presumably from the initrd: Has 2.6.24 landed in Fedora 8 updates? I vaguely remember having to make a tweak for it to work with livecd-tools, but I'm not remembering what that tweak was anymore Jeremy From asheesh at creativecommons.org Wed Feb 20 18:51:19 2008 From: asheesh at creativecommons.org (Asheesh Laroia) Date: Wed, 20 Feb 2008 10:51:19 -0800 (PST) Subject: [Fedora-livecd-list] bootloader --append="noapic" does nothing? In-Reply-To: <1203532965.24402.62.camel@aglarond.local> References: <1203530233.24402.40.camel@aglarond.local> <1203532965.24402.62.camel@aglarond.local> Message-ID: On Wed, 20 Feb 2008, Jeremy Katz wrote: > Yes, should be fine. I'm just trying to rule out "we broke it moving > all the code around" as rawhide/current git right now has a lot moved > around :) Looking at the rev, though, it doesn't look like we listen to > --append (although we probably should) Great. (-: > Running with noapic is a catastrophic failure for machines too. The > right thing is to get the kernel bug fixed. Otherwise, you're just > changing out one problem set for another one. And the kernel running in > noapic mode is far far far far far less tested across hardware than the > defaults. How depressing. (-; >> Unrelated issue: the images I generate last night based on Fedora 8 + >> Fedora 8 updates fail to boot, complaining presumably from the initrd: > > Has 2.6.24 landed in Fedora 8 updates? I vaguely remember having to > make a tweak for it to work with livecd-tools, but I'm not remembering > what that tweak was anymore Based on the build logs + the working discs I've generated, kernels as late as kernel-2.6.23.15-137.fc8.i686.rpm did work. FWIW, http://buildbot.creativecommons.org:8080/builders/livecontent%20builder/builds/76/steps/compile/logs/stdio is the build log for the one that failed, and http://buildbot.creativecommons.org:8080/builders/livecontent%20builder/builds/74/steps/compile/logs/stdio is the log for the last one that worked. Curiously, they have the same kernel version. -- Asheesh. -- The faster we go, the rounder we get. -- The Grateful Dead From wtogami at redhat.com Wed Feb 20 19:39:47 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Feb 2008 14:39:47 -0500 Subject: [Fedora-livecd-list] [PATCH] selinux --disabled fixes Message-ID: <47BC8203.3080604@redhat.com> The attached patch seems to fix "selinux --disabled" and other parts related to selinux. I have only tested it with chroot-creator with the "selinux --disabled" case in kickstart. Existing users might want to verify that it doesn't change their behavior because this makes changes to the base classes. Warren Togami wtogami at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: selinux-disabled-fix.patch Type: text/x-patch Size: 2540 bytes Desc: not available URL: From asheesh at creativecommons.org Wed Feb 20 20:40:29 2008 From: asheesh at creativecommons.org (Asheesh Laroia) Date: Wed, 20 Feb 2008 12:40:29 -0800 (PST) Subject: [Fedora-livecd-list] bootloader --append="noapic" does nothing? In-Reply-To: References: <1203530233.24402.40.camel@aglarond.local> Message-ID: On Wed, 20 Feb 2008, Asheesh Laroia wrote: > Unrelated issue: the images I generate last night based on Fedora 8 + Fedora > 8 updates fail to boot, complaining presumably from the initrd: > > WARNING: Cannot find root file system! > > Create symlink /dev/root and then exit this shell to continue the > boot > sequence. > > bash: no job control in this shell > bash-3.2# _ > > I have disabled our use of the Fedora updates repository to see if that fixes > this. (Do you guys know what's causing this? Is this probably related to > this thread > https://www.redhat.com/archives/fedora-livecd-list/2008-February/msg00135.html > ?) I'll report back in a few hours, after the rebuild..... For what it's worth, http://buildbot.creativecommons.org:8080/builders/livecontent%20builder/builds/78/steps/compile/logs/stdio is the build log for the build I just did that doesn't include Fedora 8 Updates, and that didn't have the above problem. -- Asheesh. -- "They make a desert and call it peace." -- Tacitus (55?-120?) From donvogt2001 at yahoo.com Wed Feb 20 20:47:11 2008 From: donvogt2001 at yahoo.com (don vogt) Date: Wed, 20 Feb 2008 12:47:11 -0800 (PST) Subject: [Fedora-livecd-list] Simple persistance idea Message-ID: <502982.69176.qm@web84114.mail.mud.yahoo.com> I've seen messages about complete persistence, which is, make sure all changes to the filesystem are persistent. However, for end user tasks it might be sufficient to offer persistence of the /home directory. Kai Said---------------------------------------- Has the following idea been proposed already? I figure it would be easy to do. During boot, scan for a partition with a given label, say, "fedoralivehome". If present, that partition gets mounted as /home. As a consequence, all user settings and documents are kept across boots. An usb stick could be partitioned to have the second partition as /home. Does this idea make sense? Thanks, Kai Kai said-------------------------------------------- That is essentially the way Centos -5.0 works (worked?) although it saves /etc also. I posted this on this list as a suggestion quite a while ago, but i don't know what happened. I supposed that people smarter than me had better ideas. The CentOS implemention is pretty simple. They put a change in the local startup init script that looks for a set name. aproximatlty CENTOSBACKUP and then untars what is in it. On exit another script in the shutdown sequence asks if you want to save your data and if so where to save it. If you answer yes the script tars /home and /etc into that file. Since it is open software, I guess you could just pirate the parts of the script you need. There must be many holes in this procedure. I am going back in my hole. From jsteer at bitscout.com Wed Feb 20 20:59:06 2008 From: jsteer at bitscout.com (Jon Steer) Date: Wed, 20 Feb 2008 15:59:06 -0500 Subject: [Fedora-livecd-list] bootloader --append="noapic" does nothing? In-Reply-To: <1203532965.24402.62.camel@aglarond.local> References: <1203530233.24402.40.camel@aglarond.local> <1203532965.24402.62.camel@aglarond.local> Message-ID: <74e6f65d0802201259o7481cb08l31f190872c231eba@mail.gmail.com> The kernel is the issue.. I tried a number of things, but finally had to regress back. If you have a tweak I'd LOVE to know what it is. thanks, jon On Wed, Feb 20, 2008 at 1:42 PM, Jeremy Katz wrote: > On Wed, 2008-02-20 at 10:16 -0800, Asheesh Laroia wrote: > > On Wed, 20 Feb 2008, Jeremy Katz wrote: > > >> Alas, the resulting disc still does not pass "noapic" to the kernel. > > >> What am I supposed to do? > > > > > > Which version of livecd-tools are you using for building your image? > > > > I'm running the version that yum installed on Fedora 8. > [snip] > > Is that a good version to be running? If not, what's the proper way to > > get a fresher version? > > Yes, should be fine. I'm just trying to rule out "we broke it moving > all the code around" as rawhide/current git right now has a lot moved > around :) Looking at the rev, though, it doesn't look like we listen > to --append (although we probably should) > > > > But note if you're doing this for a general-purpose image, you almost > > > certainly don't want to add 'noapic' to the default. While it may > help > > > the specific machine you've tested on, it will cause problems on > _more_ > > > machines. > > > > Hmm. Then what is a reasonable way to build an image that doesn't fail > on > > neither that Dell in the corner nor on other people's machines? > > > > It's a pretty catastrophic failure on that machine, and I'd frankly > rather > > the system run slowly on some machines and never catastrophically fail > > rather than catastrophically fail on some machines and work perfectly on > > others. > > Running with noapic is a catastrophic failure for machines too. The > right thing is to get the kernel bug fixed. Otherwise, you're just > changing out one problem set for another one. And the kernel running in > noapic mode is far far far far far less tested across hardware than the > defaults. > > > Unrelated issue: the images I generate last night based on Fedora 8 + > > Fedora 8 updates fail to boot, complaining presumably from the initrd: > > Has 2.6.24 landed in Fedora 8 updates? I vaguely remember having to make > a tweak for it to work with livecd-tools, but I'm not remembering what that > tweak was anymore > > 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 wtogami at redhat.com Wed Feb 20 22:05:40 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Feb 2008 17:05:40 -0500 Subject: [Fedora-livecd-list] Why --bind mount /var/cache/yum? Message-ID: <47BCA434.6010604@redhat.com> imgcreate/creator.py: # bind mount system directories into _instroot for (f, dest) in [("/sys", None), ("/proc", None), ("/dev", None), ("/dev/pts", None), (cachesrc, "/var/cache/yum")]: self.__bindmounts.append(BindChrootMount(f, self._instroot, dest)) Anyone know why we are --bind mounting /var/cache/yum from the host into the chroot during install when we aren't using it? Warren Togami wtogami at redhat.com From katzj at redhat.com Wed Feb 20 23:10:27 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Feb 2008 18:10:27 -0500 Subject: [Fedora-livecd-list] [PATCH] selinux --disabled fixes In-Reply-To: <47BC8203.3080604@redhat.com> References: <47BC8203.3080604@redhat.com> Message-ID: <1203549027.24402.93.camel@aglarond.local> On Wed, 2008-02-20 at 14:39 -0500, Warren Togami wrote: > The attached patch seems to fix "selinux --disabled" and other parts > related to selinux. I have only tested it with chroot-creator with the > "selinux --disabled" case in kickstart. Existing users might want to > verify that it doesn't change their behavior because this makes changes > to the base classes. Looks good, applied. Thanks Jeremy From katzj at redhat.com Wed Feb 20 23:12:39 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Feb 2008 18:12:39 -0500 Subject: [Fedora-livecd-list] bootloader --append="noapic" does nothing? In-Reply-To: References: <1203530233.24402.40.camel@aglarond.local> Message-ID: <1203549159.24402.94.camel@aglarond.local> On Wed, 2008-02-20 at 12:40 -0800, Asheesh Laroia wrote: > On Wed, 20 Feb 2008, Asheesh Laroia wrote: > > Unrelated issue: the images I generate last night based on Fedora 8 + Fedora > > 8 updates fail to boot, complaining presumably from the initrd: > > > > WARNING: Cannot find root file system! > > > > Create symlink /dev/root and then exit this shell to continue the > > boot > > sequence. > > > > bash: no job control in this shell > > bash-3.2# _ > > > > I have disabled our use of the Fedora updates repository to see if that fixes > > this. (Do you guys know what's causing this? Is this probably related to > > this thread > > https://www.redhat.com/archives/fedora-livecd-list/2008-February/msg00135.html > > ?) I'll report back in a few hours, after the rebuild..... > > For what it's worth, > http://buildbot.creativecommons.org:8080/builders/livecontent%20builder/builds/78/steps/compile/logs/stdio > is the build log for the build I just did that doesn't include Fedora 8 > Updates, and that didn't have the above problem. There's nothing obvious that jumps out at me. The best thing is probably just to diff package lists between working and not and see which package it is which triggers things. Because it'sd efinitly sounding like a package which has changed behavior Jeremy From katzj at redhat.com Wed Feb 20 23:13:48 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Feb 2008 18:13:48 -0500 Subject: [Fedora-livecd-list] Why --bind mount /var/cache/yum? In-Reply-To: <47BCA434.6010604@redhat.com> References: <47BCA434.6010604@redhat.com> Message-ID: <1203549228.24402.97.camel@aglarond.local> On Wed, 2008-02-20 at 17:05 -0500, Warren Togami wrote: > imgcreate/creator.py: > # bind mount system directories into _instroot > for (f, dest) in [("/sys", None), ("/proc", None), ("/dev", None), > ("/dev/pts", None), > (cachesrc, "/var/cache/yum")]: > self.__bindmounts.append(BindChrootMount(f, self._instroot, > dest)) > > Anyone know why we are --bind mounting /var/cache/yum from the host into > the chroot during install when we aren't using it? We're bind mounting the cache source (which is either the persistent dir or a directory under the builddir) onto /var/cache/yum, not the host's /var/cache/yum Jeremy From katzj at fedoraproject.org Wed Feb 20 23:27:40 2008 From: katzj at fedoraproject.org (Jeremy Katz) Date: Wed, 20 Feb 2008 16:27:40 -0700 Subject: [Fedora-livecd-list] imgcreate/creator.py imgcreate/kickstart.py Message-ID: <200802202327.m1KNRe34021124@hosted1.fedoraproject.org> imgcreate/creator.py | 8 +++++++- imgcreate/kickstart.py | 10 ++++++---- 2 files changed, 13 insertions(+), 5 deletions(-) New commits: commit e98a30558acc58275ee2c4469e3c4f8bea9b566f Author: Warren Togami Date: Wed Feb 20 14:39:47 2008 -0500 selinux --disabled fixes The attached patch seems to fix "selinux --disabled" and other parts related to selinux. It ensures that if SELinux is disabled, no labels are set on files as well as not running restorecon or bind-mounting /selinux diff --git a/imgcreate/creator.py b/imgcreate/creator.py index c7b1046..11fce2d 100644 --- a/imgcreate/creator.py +++ b/imgcreate/creator.py @@ -435,10 +435,14 @@ class ImageCreator(object): # bind mount system directories into _instroot for (f, dest) in [("/sys", None), ("/proc", None), ("/dev", None), - ("/dev/pts", None), ("/selinux", None), + ("/dev/pts", None), (cachesrc, "/var/cache/yum")]: self.__bindmounts.append(BindChrootMount(f, self._instroot, dest)) + # /selinux should only be mounted if selinux is enabled (enforcing or permissive) + if kickstart.selinux_enabled(self.ks): + self.__bindmounts.append(BindChrootMount("/selinux", self._instroot, None)) + self._do_bindmounts() os.symlink("../proc/mounts", self._instroot + "/etc/mtab") @@ -551,6 +555,8 @@ class ImageCreator(object): if kickstart.exclude_docs(self.ks): rpm.addMacro("_excludedocs", "1") + if not kickstart.selinux_enabled(self.ks): + rpm.addMacro("__file_context_path", "%{nil}") try: self.__select_packages(ayum) diff --git a/imgcreate/kickstart.py b/imgcreate/kickstart.py index a7e0723..30156d8 100644 --- a/imgcreate/kickstart.py +++ b/imgcreate/kickstart.py @@ -370,7 +370,7 @@ class SelinuxConfig(KickstartConfig): f = file(path, "w+") os.chmod(path, 0644) - if not ksselinux.selinux: + if ksselinux.selinux == ksconstants.SELINUX_DISABLED: return if not os.path.exists(self.path("/sbin/restorecon")): return @@ -381,9 +381,11 @@ class SelinuxConfig(KickstartConfig): if os.path.exists(self.path("/usr/sbin/lokkit")): args = ["/usr/sbin/lokkit", "-f", "--quiet", "--nostart"] - if ksselinux.selinux: + if ksselinux.selinux == ksconstants.SELINUX_ENFORCING: args.append("--selinux=enforcing") - else: + if ksselinux.selinux == ksconstants.SELINUX_PERMISSIVE: + args.append("--selinux=permissive") + if ksselinux.selinux == ksconstants.SELINUX_DISABLED: args.append("--selinux=disabled") self.call(args) @@ -483,4 +485,4 @@ def get_post_scripts(ks): return scripts def selinux_enabled(ks): - return ks.handler.selinux.selinux + return ks.handler.selinux.selinux == ksconstants.SELINUX_ENFORCING From wtogami at redhat.com Wed Feb 20 23:40:05 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Feb 2008 18:40:05 -0500 Subject: [Fedora-livecd-list] i586 needed, how? Message-ID: <47BCBA55.1000701@redhat.com> anaconda --targetarch=i586 would install i586 packages instead of i686. I need chroot-creator to do the equivalent so the resulting chroot can work on both i586 and i686 clients. i586 clients are common with LTSP. It was suggested that I test "setarch i586" after removing /etc/platform/rpm. The resulting chroot was still i686. Any suggestions as to what is the best way the equivalent of anaconda's --targetarch= can be implemented in ImageCreator? Warren Togami wtogami at redhat.com From katzj at redhat.com Wed Feb 20 23:49:38 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Feb 2008 18:49:38 -0500 Subject: [Fedora-livecd-list] i586 needed, how? In-Reply-To: <47BCBA55.1000701@redhat.com> References: <47BCBA55.1000701@redhat.com> Message-ID: <1203551378.24402.101.camel@aglarond.local> On Wed, 2008-02-20 at 18:40 -0500, Warren Togami wrote: > anaconda --targetarch=i586 would install i586 packages instead of i686. > I need chroot-creator to do the equivalent so the resulting chroot can > work on both i586 and i686 clients. i586 clients are common with LTSP. > > It was suggested that I test "setarch i586" after removing > /etc/platform/rpm. The resulting chroot was still i686. Given that 'setarch i586' doesn't do anything different from 'setarch i686', that's hardly surprising. > Any suggestions as to what is the best way the equivalent of anaconda's > --targetarch= can be implemented in ImageCreator? The cleanest thing would be to actually get 'setarch i586' to do something nice for i586. Then it wouldn't require hacks in the tool chain at all. Otherwise, it's going to be more difficult as the only things that yum uses are uname -m and /etc/rpm/platform Jeremy From katzj at redhat.com Thu Feb 21 01:01:32 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Feb 2008 20:01:32 -0500 Subject: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool In-Reply-To: <20080219191651.GN17472@redhat.com> References: <20080217021443.GH24669@redhat.com> <1203447526.13019.47.camel@aglarond.local> <20080219191651.GN17472@redhat.com> Message-ID: <1203555692.24402.110.camel@aglarond.local> On Tue, 2008-02-19 at 19:16 +0000, Daniel P. Berrange wrote: > On Tue, Feb 19, 2008 at 01:58:46PM -0500, Jeremy Katz wrote: > > On Sun, 2008-02-17 at 02:14 +0000, Daniel P. Berrange wrote: > > > This patch adds support for another installation variant. The livecd-creator > > > produces ISO images which boot using syslinux. The image-creator creates a > > > single file containing a filesystem in which the OS is installated. This patch > > > adds a new disk-creator, which creates a single file containing a partitioned > > > disk with potentially many filesystems in which the OS is installed. Furthermore > > > it installs grub in the boot sector, so this image is immediately bootable in > > > a virtual machine. > > > > Seems reasonable enough and it's something I had started looking at. My > > biggest concerns end up being scope... the next thing someone will want > > to add is RAID. Or LVM. Or dm-crypt. And I sort of wonder where it > > ends. I already gets bugs on one copy of code like that and it's called > > anaconda ;-) > > Where to draw the line is an interesting question. If you consider the created > appliance as primary serving for deployment in virtual machines, then I'd > argue that RAID / crypt is out of scope. They would be a site-specific deployment > question. If an admin wants encryption they can set it up in the host directly. > Likewise RAID can be done in the host already so its redundant for guests. The admin of the virtual machine isn't necessarily the admin of the host, though. At which point encryption, at least, becomes relevant. > LVM would be useful if only to make adding storage to the appliance easier. > > So I'd declare that scope is limited to plain partitions + LVM. Others could well argue differently, though, is my point. And especially when you're already saying that LVM is desirable, I start to lean towards really think that this is the wrong approach. > > > I've used this tool to create an instance of the oVirt web management appliance > > > from its kickstart recipe. Currently developers building the appliance have to > > > boot a VM using the F8 boot.iso and run the kickstart script in the VM and so > > > on. While this works, involves many steps with potential for failure. This new > > > tool reduces the problem to simply > > > > As opposed to virt-install --name ... ? I'm not convinced there's a > > huge gain in terms of number of places for failure :-/ > > You have to have a working virtualization stack & it takes more resource > overhead than just doing the chroot'd build. Emprically the part of our > build process doing the guest based installs has been less reliable than > the livecd-creator part. Havinga disk-creator will address that problem You have to have a working virt stack to *use* virtualization or test things. I'm not sure that't eh argument to use. And as far as reliability, what bugs are you talking about? livecd-creator has managed to have lower numbers of bugs largely due to a) less functionality and b) less users. > > > With the background information out of the way, here's some info about the > > > changes in this patch... > > > > Ob-side-note: your patch doesn't seem to be against master or at least, > > is missing some bits as it doesn't want to apply. > > I used a fresh git checkout from saturday for doing all the work against > and don't see any changes since then. Are you sure it's diff'd against master and not something earlier of yours? As it doesn't include all of imgcreate/disk.py and you created it. > > Sounds okay... the API change involved is a little unfortunate, but > I > > did caveat that the API in -14 isn't guaranteed, so it should be > fine. > > If its really a problem, we've got the option of just leaving the > existing > classes unchanged & deprecating their use in favour of the new ones, > but > if no one is using the API seriously yet it might not be worth the > hassle. Probably not worth the hassle, I was just calling it out to see if anyone else noticed and thought so. > > > Aside from partitioning, DiskImageCreator will setup an fstab file containing > > > entries for all the filesystems and swap space. It will add the grub device > > > map file, and create a grub.cfg based off the installed kernel. It is able > > > to cope with a layout where grub config is on /, or a separate /boot partition. > > > We can't use grub-install since it doesn't understand loopdevices, so to do > > > the MBR install we invoke grub manually. > > > > Yeah, and this can be tricky. At least historically, there have been > > cases which setup wasn't sufficient for and we had to do the full > > install invocation. Which is why that's what anaconda does. > > On the flip side anaconda has a much broader use case than we have to worry > about for creating appliances. Looking at the final grub commands that > grub-install actually runs, there's nothing magic we can't do directly. The > problem with grub-install is all the 'sanity' checking & probing it does > before actually running grub, which simply doesn't apply to loop devices. By install, I didn't mean grub-install, I meant running the (lower-level) install command from the grub shell. We really should be sure to have as much consistency as we can here Jeremy From jvonau at shaw.ca Thu Feb 21 01:04:49 2008 From: jvonau at shaw.ca (Jerry Vonau) Date: Wed, 20 Feb 2008 19:04:49 -0600 Subject: [Fedora-livecd-list] i586 needed, how? In-Reply-To: <47BCBA55.1000701@redhat.com> References: <47BCBA55.1000701@redhat.com> Message-ID: <47BCCE31.80005@shaw.ca> Warren Togami wrote: > anaconda --targetarch=i586 would install i586 packages instead of i686. > I need chroot-creator to do the equivalent so the resulting chroot can > work on both i586 and i686 clients. i586 clients are common with LTSP. > It broke about the same time the yum back-end came into use. > It was suggested that I test "setarch i586" after removing > /etc/platform/rpm. The resulting chroot was still i686. > > Any suggestions as to what is the best way the equivalent of anaconda's > --targetarch= can be implemented in ImageCreator? Here is what I use in my ks file: %packages @base-x @base @core @admin-tools @dial-up @hardware-support @printing kernel.i586 -glibc glibc.i386 openssl.i386 -pm-utils pm-utils.i386 memtest86+ works for me, YMMV Jerry From tim.wood at datawranglers.com Thu Feb 21 01:27:38 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Wed, 20 Feb 2008 18:27:38 -0700 Subject: [Fedora-livecd-list] Corrupted RPMs In-Reply-To: <1203530917.24402.47.camel@aglarond.local> References: <47BB74C0.5070501@datawranglers.com> <1203530917.24402.47.camel@aglarond.local> Message-ID: <47BCD38A.8050809@datawranglers.com> Actually I haven't been using the git version. I just installed the git version and built a LiveCD. The errors are identical other than the creator.py error being in line 661 instead of 655. Knowing not what a git tip is, I suspect the answer is "current config" although I'm always open to enlightenment on new-to-me terms. Tim >> Traceback (most recent call last): >> > .. > > This is the more interesting piece. It looks very similar to > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=431287 which should > have been fixed with commit ade8a8c33a6e3051ec9bf48d0bacdd1475a2aed5. > Are you using git tip with the current configs? Or git tip with your > own config? > > Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvonau at shaw.ca Thu Feb 21 01:52:44 2008 From: jvonau at shaw.ca (Jerry Vonau) Date: Wed, 20 Feb 2008 19:52:44 -0600 Subject: [Fedora-livecd-list] i586 needed, how? In-Reply-To: <47BCCE31.80005@shaw.ca> References: <47BCBA55.1000701@redhat.com> <47BCCE31.80005@shaw.ca> Message-ID: <47BCD96C.5020103@shaw.ca> Jerry Vonau wrote: > Warren Togami wrote: >> anaconda --targetarch=i586 would install i586 packages instead of >> i686. I need chroot-creator to do the equivalent so the resulting >> chroot can work on both i586 and i686 clients. i586 clients are >> common with LTSP. >> > > It broke about the same time the yum back-end came into use. > And I found is my fix (posted to anaconda-devel Oct/07), you'll need to update the line numbers. --- yuminstall.py.orig 2007-10-08 16:03:59.000000000 -0500 +++ yuminstall.py 2007-10-08 21:07:06.000000000 -0500 @@ -900,6 +900,20 @@ 'system-config-securitylevel-tui']: self.selectPackage(pkg) + def fake586(self): + ### Jerry's hack ### + myarch = rhpl.arch.canonArch + log.info("Detected %s as arch", myarch) + # now allow an override with targetarch=i586 on the command line + if flags.targetarch == "i586": + myarch2 = flags.targetarch + log.info("Detected cmdline targetarch %s as arch", myarch2) + # now make the current install believe it, too + for pkg586 in ['glibc.i386', 'kernel.i586']: + self.selectPackage(pkg586) + log.info("Selected %s for installation", pkg586) + ### end ### + def doPostSelection(self, anaconda): # Only solve dependencies on the way through the installer, not the way back. if anaconda.dir == DISPATCH_BACK: @@ -909,6 +923,7 @@ self.ayum.dsCallback = dscb # do some sanity checks for kernel and bootloader + self.fake586() self.selectBestKernel(anaconda) self.selectBootloader() self.selectFSPackages(anaconda.id.fsset, anaconda.id.diskset) From berrange at redhat.com Thu Feb 21 01:57:08 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 21 Feb 2008 01:57:08 +0000 Subject: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool In-Reply-To: <1203555692.24402.110.camel@aglarond.local> References: <20080217021443.GH24669@redhat.com> <1203447526.13019.47.camel@aglarond.local> <20080219191651.GN17472@redhat.com> <1203555692.24402.110.camel@aglarond.local> Message-ID: <20080221015708.GB27367@redhat.com> On Wed, Feb 20, 2008 at 08:01:32PM -0500, Jeremy Katz wrote: > On Tue, 2008-02-19 at 19:16 +0000, Daniel P. Berrange wrote: > > On Tue, Feb 19, 2008 at 01:58:46PM -0500, Jeremy Katz wrote: > > > On Sun, 2008-02-17 at 02:14 +0000, Daniel P. Berrange wrote: > > > > This patch adds support for another installation variant. The livecd-creator > > > > produces ISO images which boot using syslinux. The image-creator creates a > > > > single file containing a filesystem in which the OS is installated. This patch > > > > adds a new disk-creator, which creates a single file containing a partitioned > > > > disk with potentially many filesystems in which the OS is installed. Furthermore > > > > it installs grub in the boot sector, so this image is immediately bootable in > > > > a virtual machine. > > > > > > Seems reasonable enough and it's something I had started looking at. My > > > biggest concerns end up being scope... the next thing someone will want > > > to add is RAID. Or LVM. Or dm-crypt. And I sort of wonder where it > > > ends. I already gets bugs on one copy of code like that and it's called > > > anaconda ;-) > > > > Where to draw the line is an interesting question. If you consider the created > > appliance as primary serving for deployment in virtual machines, then I'd > > argue that RAID / crypt is out of scope. They would be a site-specific deployment > > question. If an admin wants encryption they can set it up in the host directly. > > Likewise RAID can be done in the host already so its redundant for guests. > > The admin of the virtual machine isn't necessarily the admin of the > host, though. At which point encryption, at least, becomes relevant. > > > LVM would be useful if only to make adding storage to the appliance easier. > > > > So I'd declare that scope is limited to plain partitions + LVM. > > Others could well argue differently, though, is my point. And > especially when you're already saying that LVM is desirable, I start to > lean towards really think that this is the wrong approach. Sure, you can say the same thing about the liveCD creator too, saying it ought to support X, Y & Z. One could argue that the live CD creator should just be a regular anaconda install in a VM, with a simple shell script to turn the resulting installed VM disk image into an ISO. We can say the scope of the live-creator is to only ever install an ext3 FS inside a squashfs inside an ISO. Similarly we can say the scope of this tool is to do a partitioned disk + LVM. Any more complex disk setup can be done in the host, or re-configured post install. Or they can use the live CD creator APIs to create custom subclasses to implement whatever setup they desire. > > > > I've used this tool to create an instance of the oVirt web management appliance > > > > from its kickstart recipe. Currently developers building the appliance have to > > > > boot a VM using the F8 boot.iso and run the kickstart script in the VM and so > > > > on. While this works, involves many steps with potential for failure. This new > > > > tool reduces the problem to simply > > > > > > As opposed to virt-install --name ... ? I'm not convinced there's a > > > huge gain in terms of number of places for failure :-/ > > > > You have to have a working virtualization stack & it takes more resource > > overhead than just doing the chroot'd build. Emprically the part of our > > build process doing the guest based installs has been less reliable than > > the livecd-creator part. Havinga disk-creator will address that problem > > You have to have a working virt stack to *use* virtualization or test > things. I'm not sure that't eh argument to use. And as far as > reliability, what bugs are you talking about? livecd-creator has > managed to have lower numbers of bugs largely due to a) less > functionality and b) less users. The host you use virtualization on, is not neccessarily the same as the host you build your images on though. If people don't have hardware virt in their dev machine it can be beneficial to build images via this tool, in preference to use the very slow QEMU emulator. Even in they do have virtualization the CPU & particularly memory overhead of building in the host is reduced. One specific bug is that the disk image ends up with the hostname of the guest VM embedded in /etc/sysconfig/network & /etc/hosts. Another was that the user in question wanted to run the tool on a host without hardware virt support. > > > > With the background information out of the way, here's some info about the > > > > changes in this patch... > > > > > > Ob-side-note: your patch doesn't seem to be against master or at least, > > > is missing some bits as it doesn't want to apply. > > > > I used a fresh git checkout from saturday for doing all the work against > > and don't see any changes since then. > > Are you sure it's diff'd against master and not something earlier of > yours? As it doesn't include all of imgcreate/disk.py and you created > it. I'll re-post it tomorrow - I've split the refactoring out from the new code to make it clearer to understand. > > > > Aside from partitioning, DiskImageCreator will setup an fstab file containing > > > > entries for all the filesystems and swap space. It will add the grub device > > > > map file, and create a grub.cfg based off the installed kernel. It is able > > > > to cope with a layout where grub config is on /, or a separate /boot partition. > > > > We can't use grub-install since it doesn't understand loopdevices, so to do > > > > the MBR install we invoke grub manually. > > > > > > Yeah, and this can be tricky. At least historically, there have been > > > cases which setup wasn't sufficient for and we had to do the full > > > install invocation. Which is why that's what anaconda does. > > > > On the flip side anaconda has a much broader use case than we have to worry > > about for creating appliances. Looking at the final grub commands that > > grub-install actually runs, there's nothing magic we can't do directly. The > > problem with grub-install is all the 'sanity' checking & probing it does > > before actually running grub, which simply doesn't apply to loop devices. > > By install, I didn't mean grub-install, I meant running the > (lower-level) install command from the grub shell. We really should be > sure to have as much consistency as we can here Ah ok - there's a mis-communication here - it doesn't use the lower level 'install' command - it uses the high level 'setup' command. Explicitly the commands run are: device (hd0) /dev/loop0 root (hd0,0) setup --stage2=/path/to/chroot/boot/grub/stage2 --prefix=/boot/grub (hd0) Which is identical to the set of commands that grub-install would run if it were clever enough to deal with loop devices. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From orion at cora.nwra.com Thu Feb 21 03:17:50 2008 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Wed, 20 Feb 2008 20:17:50 -0700 (MST) Subject: [Fedora-livecd-list] i586 needed, how? In-Reply-To: <47BCCE31.80005@shaw.ca> References: <47BCBA55.1000701@redhat.com> <47BCCE31.80005@shaw.ca> Message-ID: <2643.71.208.66.222.1203563870.squirrel@www.cora.nwra.com> > Warren Togami wrote: >> anaconda --targetarch=i586 would install i586 packages instead of i686. >> I need chroot-creator to do the equivalent so the resulting chroot can >> work on both i586 and i686 clients. i586 clients are common with LTSP. >> > > > Here is what I use in my ks file: > > %packages > @base-x > @base > @core > @admin-tools > @dial-up > @hardware-support > @printing > kernel.i586 I just found I had to specify kernel.i686 to *not* get kernel i586 on my builds. - Orion From berrange at redhat.com Thu Feb 21 03:32:18 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 21 Feb 2008 03:32:18 +0000 Subject: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool In-Reply-To: <20080221015708.GB27367@redhat.com> References: <20080217021443.GH24669@redhat.com> <1203447526.13019.47.camel@aglarond.local> <20080219191651.GN17472@redhat.com> <1203555692.24402.110.camel@aglarond.local> <20080221015708.GB27367@redhat.com> Message-ID: <20080221033218.GA10437@redhat.com> On Thu, Feb 21, 2008 at 01:57:08AM +0000, Daniel P. Berrange wrote: > On Wed, Feb 20, 2008 at 08:01:32PM -0500, Jeremy Katz wrote: > > On Tue, 2008-02-19 at 19:16 +0000, Daniel P. Berrange wrote: > > > > > from its kickstart recipe. Currently developers building the appliance have to > > > > > boot a VM using the F8 boot.iso and run the kickstart script in the VM and so > > > > > on. While this works, involves many steps with potential for failure. This new > > > > > tool reduces the problem to simply > > > > > > > > As opposed to virt-install --name ... ? I'm not convinced there's a > > > > huge gain in terms of number of places for failure :-/ > > > > > > You have to have a working virtualization stack & it takes more resource > > > overhead than just doing the chroot'd build. Emprically the part of our > > > build process doing the guest based installs has been less reliable than > > > the livecd-creator part. Havinga disk-creator will address that problem > > > > You have to have a working virt stack to *use* virtualization or test > > things. I'm not sure that't eh argument to use. And as far as > > reliability, what bugs are you talking about? livecd-creator has > > managed to have lower numbers of bugs largely due to a) less > > functionality and b) less users. > > The host you use virtualization on, is not neccessarily the same as the host > you build your images on though. If people don't have hardware virt in their > dev machine it can be beneficial to build images via this tool, in preference > to use the very slow QEMU emulator. Even in they do have virtualization the > CPU & particularly memory overhead of building in the host is reduced. One > specific bug is that the disk image ends up with the hostname of the guest > VM embedded in /etc/sysconfig/network & /etc/hosts. Another was that the user > in question wanted to run the tool on a host without hardware virt support. Some other examples of scenarios where you want to build appliance images but do not have virtualization capabilities directly accessible. - Machines where the user's primary OS is running under an embedded hypervisor. QEMU is tolerable for booting an image to verify that it works, but building the image in QEMU is too slow to be practical. - Building images to deploy to a virtual machine hosted by an ISP, eg linode.com where you have either option of providing a pre-installed disk image, or using one the ISP built for you. - The virtualization technology on your local machine may be different from the target machine. eg you can run VirtualBox on your deskop, but want to build Xen based images to deploy to Amazon's EC2 hosting environment. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From dmc.fedora at filteredperception.org Thu Feb 21 03:50:45 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 20 Feb 2008 21:50:45 -0600 Subject: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool In-Reply-To: <20080221033218.GA10437@redhat.com> References: <20080217021443.GH24669@redhat.com> <1203447526.13019.47.camel@aglarond.local> <20080219191651.GN17472@redhat.com> <1203555692.24402.110.camel@aglarond.local> <20080221015708.GB27367@redhat.com> <20080221033218.GA10437@redhat.com> Message-ID: <47BCF515.8030901@filteredperception.org> Daniel P. Berrange wrote: > On Thu, Feb 21, 2008 at 01:57:08AM +0000, Daniel P. Berrange wrote: >> On Wed, Feb 20, 2008 at 08:01:32PM -0500, Jeremy Katz wrote: >>> On Tue, 2008-02-19 at 19:16 +0000, Daniel P. Berrange wrote: >>>>>> from its kickstart recipe. Currently developers building the appliance have to >>>>>> boot a VM using the F8 boot.iso and run the kickstart script in the VM and so >>>>>> on. While this works, involves many steps with potential for failure. This new >>>>>> tool reduces the problem to simply >>>>> As opposed to virt-install --name ... ? I'm not convinced there's a >>>>> huge gain in terms of number of places for failure :-/ >>>> You have to have a working virtualization stack & it takes more resource >>>> overhead than just doing the chroot'd build. Emprically the part of our >>>> build process doing the guest based installs has been less reliable than >>>> the livecd-creator part. Havinga disk-creator will address that problem >>> You have to have a working virt stack to *use* virtualization or test >>> things. I'm not sure that't eh argument to use. And as far as >>> reliability, what bugs are you talking about? livecd-creator has >>> managed to have lower numbers of bugs largely due to a) less >>> functionality and b) less users. >> The host you use virtualization on, is not neccessarily the same as the host >> you build your images on though. If people don't have hardware virt in their >> dev machine it can be beneficial to build images via this tool, in preference >> to use the very slow QEMU emulator. Even in they do have virtualization the >> CPU & particularly memory overhead of building in the host is reduced. One >> specific bug is that the disk image ends up with the hostname of the guest >> VM embedded in /etc/sysconfig/network & /etc/hosts. Another was that the user >> in question wanted to run the tool on a host without hardware virt support. > > Some other examples of scenarios where you want to build appliance images but > do not have virtualization capabilities directly accessible. > > - Machines where the user's primary OS is running under an embedded hypervisor. > QEMU is tolerable for booting an image to verify that it works, but building > the image in QEMU is too slow to be practical. Obviously, since my project uses precisely that (qemu) I'll defend a bit: Some examples of where 'too slow to be practical' is IMHO an oversweeping generalization- - when a few hours or overnight is not a big deal - when you can use a standardized pre-existing image as a base (that might have taken hours to build once), and all you need to do is add or remove a small set of packages, which only takes a few minutes - in the future, when qemu, either via kvm/kqemu or just plain faster hardware, reduces the install time from hours to minutes, and the simplicity and security of no-root-privs becomes more valuable than the time saved using alternate methods (at least for some usage cases). Naturally these might not be situations you are interested in, but I think your statement of 'too slow to be practical' was an oversimplification which you knew I would take the bait and defend ;) Basically, I do agree that with the current relative immaturity of these sorts of imaging tools, we do find ourselves repeatedly building the 'long run'. But in the future, I see a pipeline and polishedness, where you have one or more standard images built and cached (because disk is cheap), and further one-off appliances are quickly built as minor modifications of those cached images. But that's just the itch I'm scratching... I grant that for your purposes, running disk-creator as root is clearly better for the sorts of virtualization tasks you seem to be targeting (right now). > - Building images to deploy to a virtual machine hosted by an ISP, eg linode.com > where you have either option of providing a pre-installed disk image, or using > one the ISP built for you. > > - The virtualization technology on your local machine may be different from the > target machine. eg you can run VirtualBox on your deskop, but want to build > Xen based images to deploy to Amazon's EC2 hosting environment. > Yup, two more cases where qemu (or *cough* perhaps vmware ;) can fit the bill, if you aren't in a massive hurry. -dmc From berrange at redhat.com Thu Feb 21 04:08:36 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 21 Feb 2008 04:08:36 +0000 Subject: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool In-Reply-To: <47BCF4E5.3050804@filteredperception.org> References: <20080217021443.GH24669@redhat.com> <1203447526.13019.47.camel@aglarond.local> <20080219191651.GN17472@redhat.com> <1203555692.24402.110.camel@aglarond.local> <20080221015708.GB27367@redhat.com> <20080221033218.GA10437@redhat.com> <47BCF4E5.3050804@filteredperception.org> Message-ID: <20080221040836.GB10437@redhat.com> On Wed, Feb 20, 2008 at 09:49:57PM -0600, Douglas McClendon wrote: > Daniel P. Berrange wrote: > > > >Some other examples of scenarios where you want to build appliance images > >but > >do not have virtualization capabilities directly accessible. > > > > - Machines where the user's primary OS is running under an embedded > > hypervisor. > > QEMU is tolerable for booting an image to verify that it works, but > > building > > the image in QEMU is too slow to be practical. > > > Obviously, since my project uses precisely that (qemu) I'll defend a > bit: Some examples of where 'too slow to be practical' is IMHO an > oversweeping generalization- > > - when a few hours or overnight is not a big deal Yes it is a big deal because it directly impacts the amount of development and testing I can do in any single day. If it takes 15 minutes to build an image I can get through many many build & test cycles in a day. If it takes overnight then I can only do one build & test. For some people it may not be a big deal to wait overnight, but for many people it it totally impractical to wait this long. > - in the future, when qemu, either via kvm/kqemu or just plain faster > hardware, reduces the install time from hours to minutes, and the > simplicity and security of no-root-privs becomes more valuable than the > time saved using alternate methods (at least for some usage cases). KQEMU is essentially unmaintained & you can't assume access to KVM since it requires hardeware virtualization & even if your hardware has such capabilities there are plenty of scenarios where the end user will not be able to use them. > Naturally these might not be situations you are interested in, but I > think your statement of 'too slow to be practical' was an > oversimplification which you knew I would take the bait and defend ;) You're imagining things - if you choose to use QEMU for your project I've no problem with that - that's your choice to make. It is simply not practical for my day-to-day work to wait for installs inside QEMU emulator to complete. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From dmc.fedora at filteredperception.org Thu Feb 21 04:14:12 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 20 Feb 2008 22:14:12 -0600 Subject: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool In-Reply-To: <20080221040836.GB10437@redhat.com> References: <20080217021443.GH24669@redhat.com> <1203447526.13019.47.camel@aglarond.local> <20080219191651.GN17472@redhat.com> <1203555692.24402.110.camel@aglarond.local> <20080221015708.GB27367@redhat.com> <20080221033218.GA10437@redhat.com> <47BCF4E5.3050804@filteredperception.org> <20080221040836.GB10437@redhat.com> Message-ID: <47BCFA94.3050903@filteredperception.org> Daniel P. Berrange wrote: > On Wed, Feb 20, 2008 at 09:49:57PM -0600, Douglas McClendon wrote: >> Daniel P. Berrange wrote: >>> Some other examples of scenarios where you want to build appliance images >>> but >>> do not have virtualization capabilities directly accessible. >>> >>> - Machines where the user's primary OS is running under an embedded >>> hypervisor. >>> QEMU is tolerable for booting an image to verify that it works, but >>> building >>> the image in QEMU is too slow to be practical. >> >> Obviously, since my project uses precisely that (qemu) I'll defend a >> bit: Some examples of where 'too slow to be practical' is IMHO an >> oversweeping generalization- >> >> - when a few hours or overnight is not a big deal ^^^^ I thought I went far enough out of my way to subclass my points so that you wouldn't think I was suggesting that they applied to your day to day work. Some people are in such a hurry that when they drive, they tailgate people that are already going a few miles over the speedlimit. When that happens to me, I slow way down :) > > Yes it is a big deal because it directly impacts the amount of development > and testing I can do in any single day. If it takes 15 minutes to build > an image I can get through many many build & test cycles in a day. If it > takes overnight then I can only do one build & test. For some people it > may not be a big deal to wait overnight, but for many people it it totally > impractical to wait this long. > >> - in the future, when qemu, either via kvm/kqemu or just plain faster >> hardware, reduces the install time from hours to minutes, and the >> simplicity and security of no-root-privs becomes more valuable than the >> time saved using alternate methods (at least for some usage cases). > > KQEMU is essentially unmaintained & you can't assume access to KVM > since it requires hardeware virtualization & even if your hardware has > such capabilities there are plenty of scenarios where the end user will > not be able to use them. Sure, but this is all one reason why I have always found qemu to be so awesome. It has a solid fallback functionality and performance, even when you don't have hardware assist, or root perms to throw in a kernel driver. > >> Naturally these might not be situations you are interested in, but I >> think your statement of 'too slow to be practical' was an >> oversimplification which you knew I would take the bait and defend ;) > > You're imagining things - if you choose to use QEMU for your project > I've no problem with that - that's your choice to make. It is simply > not practical for my day-to-day work to wait for installs inside QEMU > emulator to complete. Sorry Dan, but YOU are imagining things. Precisely, you are imagining that anything I said implied in any way that my style solution would be a benefit to you over your style solutions. What exactly was I imagining? I mean, I imagine all kinds of things, but it sounded kind of derogatory the way you said it, like I was imagining false technical arguments to be true. -dmc From kengert at redhat.com Thu Feb 21 08:30:14 2008 From: kengert at redhat.com (Kai Engert) Date: Thu, 21 Feb 2008 09:30:14 +0100 Subject: [Fedora-livecd-list] Simple persistence idea, /home only In-Reply-To: <1203531017.24402.50.camel@aglarond.local> References: <47BC1D52.4070808@redhat.com> <1203531017.24402.50.camel@aglarond.local> Message-ID: <47BD3696.20906@redhat.com> Jeremy Katz wrote: > On Wed, 2008-02-20 at 13:30 +0100, Kai Engert wrote: > >> I've seen messages about complete persistence, which is, make sure all >> changes to the filesystem are persistent. >> >> However, for end user tasks it might be sufficient to offer persistence >> of the /home directory. >> >> Has the following idea been proposed already? >> I figure it would be easy to do. >> >> During boot, scan for a partition with a given label, say, "fedoralivehome". >> If present, that partition gets mounted as /home. >> As a consequence, all user settings and documents are kept across boots. >> An usb stick could be partitioned to have the second partition as /home. >> >> Does this idea make sense? >> > > I've thought about it before, the problem ends up being that you really > don't want to use, eg, a fat filesystem for the home directory which > makes it a little trickier. I think it's ok to require an ext2/ext3 filesystem for fedoralivehome. Kai -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3328 bytes Desc: S/MIME Cryptographic Signature URL: From Timo.Penndorf at tu-dresden.de Thu Feb 21 09:33:07 2008 From: Timo.Penndorf at tu-dresden.de (Timo Penndorf) Date: Thu, 21 Feb 2008 10:33:07 +0100 Subject: [Fedora-livecd-list] ext3 issues In-Reply-To: <1203506575.10011.9.camel@localhost.localdomain> References: <1203506575.10011.9.camel@localhost.localdomain> Message-ID: <1203586387.7382.6.camel@localhost.localdomain> Hi, according to the ext3 issues there are some related issues. At the end of the build process the temporary ext3 image could not bee unmounted: umount: /var/tmp/imgcreate-O5Rka3/install_root: device is busy umount: /var/tmp/imgcreate-O5Rka3/install_root: device is busy ioctl: LOOP_CLR_FD: Device or resource busy umount: /var/tmp/imgcreate-O5Rka3/install_root: device is busy umount: /var/tmp/imgcreate-O5Rka3/install_root: device is busy e2fsck 1.40.4 (31-Dec-2007) with lsof I see that: lsof | grep install_root livecd-cr 3118 root mem REG 7,0 50768 491561 /var/tmp/imgcreate-O5Rka3/install_root/lib/libnss_files-2.7.so As the image could not bee unmounted there are errors on it Pass 1: Checking inodes, blocks, and sizes Extended attribute block 34355 has reference count 237, should be 236. Fix? yes Pass 2: Checking directory structure Entry 'mtab' in /etc (12) has invalid inode #: 262146. Clear? yes Entry 'ks-script-GabkYA' in /tmp (1091) has invalid inode #: 278530. Clear? yes Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: -89383 -90561 Fix? yes Free blocks count wrong for group #2 (0, counted=2). Fix? yes Free blocks count wrong (149470, counted=149472). Fix? yes So why livecd-creator links against libraries of the live cd? I think livecd-creator should only use the build system! Timo Am Mittwoch, den 20.02.2008, 12:22 +0100 schrieb Timo Penndorf: > Hi, > > after creation of a live cd I get the > error messages: > > EXT3-fs error (device loop0): ext3_xattr_block_get: inode 114831: bad > block 655877 > EXT3-fs error (device loop0): ext3_xattr_delete_inode: inode 114831: bad > block 655877 > > > These messages are repeated in a long sequence of entries with different > inodes. The file system on the live cd is corrupted. > > I use a standard fedora installation with the follwoing package versions > > livecd-tools-013-1.fc8 > e2fsprogs-1.40.4-1.fc8 > libselinux-2.0.43-1.fc8 > selinux-policy-3.0.8-84.fc8 > > selinux is in enforcing mode both on the build system as for the live > cd. > > The used kickstart configuration worked fine on Fedora 7 and 6 (with > disabled selinux) so what changes are important to fc8? > > > > Timo > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list -- +--------------------------------------+ | | | Dipl.-Ing. Timo Penndorf | | | | Institut f?r Verarbeitungsmaschinen | | und Mobile Arbeitsmaschinen | | | | Technische Universit?t Dresden | | 01062 Dresden | | | | Tel: 0351 463 34972 | | Fax: 0351 463 37731 | | | +--------------------------------------+ +--------------------------------------+ | | | Dipl.-Ing. Timo Penndorf | | | | Institute of Processing Machines | | and Mobile Machinery | | | | Dresden University of Technology | | D-01062 Dresden | | | | Tel: 0049 351 463 34972 | | Fax: 0049 351 463 37731 | | | +--------------------------------------+ From katzj at redhat.com Thu Feb 21 13:46:57 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 21 Feb 2008 08:46:57 -0500 Subject: [Fedora-livecd-list] Corrupted RPMs In-Reply-To: <47BCD38A.8050809@datawranglers.com> References: <47BB74C0.5070501@datawranglers.com> <1203530917.24402.47.camel@aglarond.local> <47BCD38A.8050809@datawranglers.com> Message-ID: <1203601617.24402.118.camel@aglarond.local> On Wed, 2008-02-20 at 18:27 -0700, Tim Wood wrote: > Actually I haven't been using the git version. I just installed the > git version and built a LiveCD. The errors are identical other than > the creator.py error being in line 661 instead of 655. > > Knowing not what a git tip is, I suspect the answer is "current > config" although I'm always open to enlightenment on new-to-me terms. git tip is the current HEAD of the tree. Which version had you been using? Jeremy From tim.wood at datawranglers.com Thu Feb 21 15:54:30 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Thu, 21 Feb 2008 08:54:30 -0700 Subject: [Fedora-livecd-list] Corrupted RPMs In-Reply-To: <1203601617.24402.118.camel@aglarond.local> References: <47BB74C0.5070501@datawranglers.com> <1203530917.24402.47.camel@aglarond.local> <47BCD38A.8050809@datawranglers.com> <1203601617.24402.118.camel@aglarond.local> Message-ID: <47BD9EB6.1020705@datawranglers.com> The rawhide version. Is it true that when I do a git clone, I'm grabbing the head of the tree? Tim Jeremy Katz wrote: > On Wed, 2008-02-20 at 18:27 -0700, Tim Wood wrote: > >> Actually I haven't been using the git version. I just installed the >> git version and built a LiveCD. The errors are identical other than >> the creator.py error being in line 661 instead of 655. >> >> Knowing not what a git tip is, I suspect the answer is "current >> config" although I'm always open to enlightenment on new-to-me terms. >> > > git tip is the current HEAD of the tree. Which version had you been > using? > > Jeremy > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > -- _________________________________ Tim Wood, CLP, RHCT 719.338.7484 (tel) The Data Wranglers Web, Database & more since since 1994 www.datawranglers.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From katzj at redhat.com Thu Feb 21 16:08:32 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 21 Feb 2008 11:08:32 -0500 Subject: [Fedora-livecd-list] Corrupted RPMs In-Reply-To: <47BD9EB6.1020705@datawranglers.com> References: <47BB74C0.5070501@datawranglers.com> <1203530917.24402.47.camel@aglarond.local> <47BCD38A.8050809@datawranglers.com> <1203601617.24402.118.camel@aglarond.local> <47BD9EB6.1020705@datawranglers.com> Message-ID: <1203610112.24402.145.camel@aglarond.local> On Thu, 2008-02-21 at 08:54 -0700, Tim Wood wrote: > The rawhide version. Then I'd definitely check to make sure your config has a change similar to ade8a8c33a6e3051ec9bf48d0bacdd1475a2aed5 or it will definitely blow up. > Is it true that when I do a git clone, I'm grabbing the head of the > tree? Yep! Jeremy From orion at cora.nwra.com Thu Feb 21 16:31:28 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 21 Feb 2008 09:31:28 -0700 Subject: [Fedora-livecd-list] ext3 issues -> nss_files In-Reply-To: <1203586387.7382.6.camel@localhost.localdomain> References: <1203506575.10011.9.camel@localhost.localdomain> <1203586387.7382.6.camel@localhost.localdomain> Message-ID: <47BDA760.4090108@cora.nwra.com> Timo Penndorf wrote: > with lsof I see that: > > lsof | grep install_root > livecd-cr 3118 root mem REG 7,0 50768 > 491561 /var/tmp/imgcreate-O5Rka3/install_root/lib/libnss_files-2.7.so > As another indication that something else seems to be broken with nss_files: Installing: apr-util ################### [ 494/1183] warning: group tty does not exist - using root tty is in the /etc/group installed by setup as the 2nd package installed, so group tty definitely should exist. Maybe time to abandon livecd-creator on F8 and move to rawhide? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From sundaram at fedoraproject.org Thu Feb 21 16:40:39 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 21 Feb 2008 22:10:39 +0530 Subject: [Fedora-livecd-list] Whats the story with compressed caching? Message-ID: <47BDA987.4060802@fedoraproject.org> Hi http://linuxcompressed.sourceforge.net/ Are we using it in Fedora? Any plans to? Rahul From katzj at redhat.com Thu Feb 21 16:46:33 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 21 Feb 2008 11:46:33 -0500 Subject: [Fedora-livecd-list] Whats the story with compressed caching? In-Reply-To: <47BDA987.4060802@fedoraproject.org> References: <47BDA987.4060802@fedoraproject.org> Message-ID: <1203612393.24402.147.camel@aglarond.local> On Thu, 2008-02-21 at 22:10 +0530, Rahul Sundaram wrote: > http://linuxcompressed.sourceforge.net/ > > Are we using it in Fedora? Any plans to? Since it's not upstream ... Also, it's somewhat off-topic for this list Jeremy From tim.wood at datawranglers.com Thu Feb 21 16:46:43 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Thu, 21 Feb 2008 09:46:43 -0700 Subject: [Fedora-livecd-list] Corrupted RPMs In-Reply-To: <1203610112.24402.145.camel@aglarond.local> References: <47BB74C0.5070501@datawranglers.com> <1203530917.24402.47.camel@aglarond.local> <47BCD38A.8050809@datawranglers.com> <1203601617.24402.118.camel@aglarond.local> <47BD9EB6.1020705@datawranglers.com> <1203610112.24402.145.camel@aglarond.local> Message-ID: <47BDAAF3.5060407@datawranglers.com> I was using the rawhide version. I'm now using one built with git clone/make install a day or two ago. FWIW... how do I check to see if I've got that change? Tim Jeremy Katz wrote: > On Thu, 2008-02-21 at 08:54 -0700, Tim Wood wrote: > >> The rawhide version. >> > > Then I'd definitely check to make sure your config has a change similar > to ade8a8c33a6e3051ec9bf48d0bacdd1475a2aed5 or it will definitely blow > up. > > >> Is it true that when I do a git clone, I'm grabbing the head of the >> tree? >> > > Yep! > > Jeremy > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > -- _________________________________ Tim Wood, CLP, RHCT 719.338.7484 (tel) The Data Wranglers Web, Database & more since since 1994 www.datawranglers.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Thu Feb 21 16:58:27 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 21 Feb 2008 22:28:27 +0530 Subject: [Fedora-livecd-list] Whats the story with compressed caching? In-Reply-To: <1203612393.24402.147.camel@aglarond.local> References: <47BDA987.4060802@fedoraproject.org> <1203612393.24402.147.camel@aglarond.local> Message-ID: <47BDADB3.6070806@fedoraproject.org> Jeremy Katz wrote: > On Thu, 2008-02-21 at 22:10 +0530, Rahul Sundaram wrote: >> http://linuxcompressed.sourceforge.net/ >> >> Are we using it in Fedora? Any plans to? > > Since it's not upstream ... > > Also, it's somewhat off-topic for this list Not so much, considering that it has been mentored via Fedora and this https://lists.ubuntu.com/archives/sounder/2008-February/011089.html Looks we could drop it if it doesn't get upstream without incurring ongoing maintenance. Rahul From notting at redhat.com Thu Feb 21 17:04:34 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 Feb 2008 12:04:34 -0500 Subject: [Fedora-livecd-list] Whats the story with compressed caching? In-Reply-To: <47BDADB3.6070806@fedoraproject.org> References: <47BDA987.4060802@fedoraproject.org> <1203612393.24402.147.camel@aglarond.local> <47BDADB3.6070806@fedoraproject.org> Message-ID: <20080221170434.GG6258@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > Not so much, considering that it has been mentored via Fedora and this > > https://lists.ubuntu.com/archives/sounder/2008-February/011089.html > > Looks we could drop it if it doesn't get upstream without incurring ongoing > maintenance. You can't drop features that you add for your users to rely on. You're stuck with them. That's *why* we say things need to be upstream. Bill From katzj at redhat.com Thu Feb 21 17:56:53 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 21 Feb 2008 12:56:53 -0500 Subject: [Fedora-livecd-list] Corrupted RPMs In-Reply-To: <47BDAAF3.5060407@datawranglers.com> References: <47BB74C0.5070501@datawranglers.com> <1203530917.24402.47.camel@aglarond.local> <47BCD38A.8050809@datawranglers.com> <1203601617.24402.118.camel@aglarond.local> <47BD9EB6.1020705@datawranglers.com> <1203610112.24402.145.camel@aglarond.local> <47BDAAF3.5060407@datawranglers.com> Message-ID: <1203616613.24402.152.camel@aglarond.local> On Thu, 2008-02-21 at 09:46 -0700, Tim Wood wrote: > I was using the rawhide version. I'm now using one built with git > clone/make install a day or two ago. FWIW... how do I check to see if > I've got that change? You can either use 'git show ' (where is the commit id) or you can visit the gitweb (http://git.fedorahosted.org/git/?p=livecd;a=summary) and put the commit into the search box. Jeremy From dimitar.ouzounoff at gmail.com Thu Feb 21 21:33:05 2008 From: dimitar.ouzounoff at gmail.com (Dimitar Uzunov) Date: Thu, 21 Feb 2008 22:33:05 +0100 Subject: [Fedora-livecd-list] Cannot boot properly - can't find root, no job controll Message-ID: <869a8fe20802211333r5bfdc1fj376fef8b5967ae28@mail.gmail.com> Hello! I downloaded and burned the XFCE spin, but unfortunatelly the loading process suddenly stops and I get a complaint that it cannot find the root file system and that the shell has no job controll and I'm left with just a shell - what do I need to do to boot properly? I'm including a VM screenshot (same result as booting from the CD). Thanks in advance, --Dimitar -------------- next part -------------- A non-text attachment was scrubbed... Name: nojobcontroll.png Type: image/png Size: 12023 bytes Desc: not available URL: From mustafa4336 at yahoo.com Fri Feb 22 02:35:24 2008 From: mustafa4336 at yahoo.com (Mustafa AL) Date: Thu, 21 Feb 2008 18:35:24 -0800 (PST) Subject: [Fedora-livecd-list] Could you please take me out of your mail list Message-ID: <604136.55465.qm@web50612.mail.re2.yahoo.com> Could you please take me out of your mail list --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pemboa at gmail.com Fri Feb 22 02:37:56 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 21 Feb 2008 20:37:56 -0600 Subject: [Fedora-livecd-list] Could you please take me out of your mail list In-Reply-To: <604136.55465.qm@web50612.mail.re2.yahoo.com> References: <604136.55465.qm@web50612.mail.re2.yahoo.com> Message-ID: <16de708d0802211837q85eeba2t8834c739e80cd1c5@mail.gmail.com> On Thu, Feb 21, 2008 at 8:35 PM, Mustafa AL wrote: > Could you please take me out of your mail list > > ________________________________ > > Looking for last minute shopping deals? Find them fast with Yahoo! Search. > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > Please read every link in this email -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From gary at mlbassoc.com Sat Feb 23 11:43:30 2008 From: gary at mlbassoc.com (Gary Thomas) Date: Sat, 23 Feb 2008 04:43:30 -0700 Subject: [Fedora-livecd-list] Using kickstart Message-ID: <47C006E2.8090901@mlbassoc.com> I'm running anaconda-11.4.0.37 (+ patches from git to handle custom/fixed partitioning). I can see from the scripts that 'liveinst' is supposed to handle kickstart files. However, when I try it, anaconda doesn't seem to even care... # liveinst --text ks=nfs:192.168.1.101:/tftpboot/ks/custom.ks Looking at the install log (/tmp/anaconda.log), I can see this get passed into anaconda, but no other mention of it. The install process just simply carries on just like I never used the ks= option at all. Am I missing something [fundamental] here? Thanks -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From katzj at redhat.com Sun Feb 24 18:45:57 2008 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 24 Feb 2008 13:45:57 -0500 Subject: [Fedora-livecd-list] Using kickstart In-Reply-To: <47C006E2.8090901@mlbassoc.com> References: <47C006E2.8090901@mlbassoc.com> Message-ID: <1203878757.1431.0.camel@aglarond.local> On Sat, 2008-02-23 at 04:43 -0700, Gary Thomas wrote: > I'm running anaconda-11.4.0.37 (+ patches from git to handle > custom/fixed partitioning). > > I can see from the scripts that 'liveinst' is supposed to > handle kickstart files. However, when I try it, anaconda > doesn't seem to even care... > > # liveinst --text ks=nfs:192.168.1.101:/tftpboot/ks/custom.ks The handling of grabbing kickstart files is all in the loader -- the second stage expects that the ks.cfg is local, and thus, that the path is a local path Jeremy From katzj at redhat.com Mon Feb 25 18:22:07 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 25 Feb 2008 13:22:07 -0500 Subject: [Fedora-livecd-list] RFC: Remove explicit initrd creation from livecd creation Message-ID: <1203963727.10761.17.camel@aglarond.local> I've made the first step[1] towards actually getting the initrd for livecds to be created as part of the "normal" mkinitrd that gets run when the kernel is installed in rawhide. This, though, means that running mayflower from livecd-creator is fairly overkill and even likely to cause problems as the two are unlikely to be kept in sync. Therefore, I'd like to propose removing mayflower and the calls to use it from the livecd build process. This, though, would mean that pre-Fedora 9 images would need a little bit of config work to continue building them with git livecd-tools. Basically, for those configs, we'd likely end up just wanting to pull livecd-tools into their manifest and then have the %post of the config run mayflower. I'll fix up the F8 configs when doing so, but will probably drop the < F8 configs from the package. Anyone see any real problems with this? Jeremy [1] At this point, it's pretty crude but it at least moves us in the right direction and gets us to stop thinking "oh we can just change livecd-tools and change the boot" From jiesun66 at yahoo.com Tue Feb 26 21:17:22 2008 From: jiesun66 at yahoo.com (jie sun) Date: Tue, 26 Feb 2008 13:17:22 -0800 (PST) Subject: [Fedora-livecd-list] livecd-tools failed on fc7 due to can't stat /etc/hosts and /etc/sysconfig/network Message-ID: <262752.3973.qm@web31602.mail.mud.yahoo.com> Hi Jeremy, livecd-creator always failed on fc7 because it can not access/update /etc/hosts and /etc/sysconfig/network files to figure out the ip address so it can't set up the mysql database connection correctly. So even though it can create iso image file but it won't work because the mysql connection is not set up. livecd-creator on fc8 work fine without problem. Regards, Jie --------------------------------- Never miss a thing. Make Yahoo your homepage. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivazqueznet at gmail.com Tue Feb 26 23:50:24 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 26 Feb 2008 18:50:24 -0500 Subject: [Fedora-livecd-list] livecd-tools failed on fc7 due to can't stat /etc/hosts and /etc/sysconfig/network In-Reply-To: <262752.3973.qm@web31602.mail.mud.yahoo.com> References: <262752.3973.qm@web31602.mail.mud.yahoo.com> Message-ID: <1204069824.1838.14.camel@ignacio.lan> On Tue, 2008-02-26 at 13:17 -0800, jie sun wrote: > livecd-creator always failed on fc7 because it can not > access/update /etc/hosts and /etc/sysconfig/network files to figure > out the ip address so it can't set up the mysql database connection > correctly. So even though it can create iso image file but it won't > work because the mysql connection is not set up. What does livecd-creator use mysql for? -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at fedoraproject.org Wed Feb 27 03:27:55 2008 From: katzj at fedoraproject.org (Jeremy Katz) Date: Tue, 26 Feb 2008 20:27:55 -0700 Subject: [Fedora-livecd-list] imgcreate/fs.py Message-ID: <200802270327.m1R3RtQ7021812@hosted1.fedoraproject.org> imgcreate/fs.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit 04298ddc7bb8f0aef55a54b6c2367a6387c8100a Author: Jeremy Katz Date: Tue Feb 26 22:27:45 2008 -0500 Temporarily use 128 byte inodes to avoid hitting #434893 256 byte inodes are currently causing the loss of xattrs on resize. esandeen is working on a fix, but to keep things from being broken for now, let's just fall back diff --git a/imgcreate/fs.py b/imgcreate/fs.py index 9ca3a3e..2dafd4b 100644 --- a/imgcreate/fs.py +++ b/imgcreate/fs.py @@ -201,7 +201,7 @@ class SparseExtLoopbackMount(SparseLoopbackMount): def __format_filesystem(self): rc = subprocess.call(["/sbin/mkfs." + self.fstype, "-F", "-L", self.fslabel, - "-m", "1", "-b", str(self.blocksize), + "-m", "1", "-b", str(self.blocksize), "-I128", self.lofile, str(self.size / self.blocksize)]) if rc != 0: From tim.wood at datawranglers.com Wed Feb 27 05:46:29 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Tue, 26 Feb 2008 22:46:29 -0700 Subject: [Fedora-livecd-list] Corrupted RPM/unbootable LiveCD problem solved In-Reply-To: <1203616613.24402.152.camel@aglarond.local> References: <47BB74C0.5070501@datawranglers.com> <1203530917.24402.47.camel@aglarond.local> <47BCD38A.8050809@datawranglers.com> <1203601617.24402.118.camel@aglarond.local> <47BD9EB6.1020705@datawranglers.com> <1203610112.24402.145.camel@aglarond.local> <47BDAAF3.5060407@datawranglers.com> <1203616613.24402.152.camel@aglarond.local> Message-ID: <47C4F935.2080102@datawranglers.com> I verified the problems with a fresh install of f8 with updates (not rawhide) and livecd-tools from git. So, I uninstalled the git version of LiveCD Tools, disabled the development repo in YUM (LiveCD tools was the only package enabled) and reinstalled LiveCD tools with GIT. For some reason it choked on my RPM cache, so I've turned cacheing off for now. I've just finished creating my second livecd under this setup (2 different kickstarts, fwiw). As an aside, I'm still receiving the same errors on the same particular RPMs so I'm pretty convince it's not related to RPMs. IMVHO (I think I'm going to get blasted for this theory) it's probably wise not to mix LiveCD tools for a future version of Fedora with a production release of Fedora. The last time I ran into weird bad juju with LiveCD Tools was when I mixed a git pre-release of the F8 version of LiveCD Tools with a F7 dev vm. Tim From tim.wood at datawranglers.com Wed Feb 27 06:05:38 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Tue, 26 Feb 2008 23:05:38 -0700 Subject: [Fedora-livecd-list] Suggestions for LiveCD Development LiveCD In-Reply-To: <1203616613.24402.152.camel@aglarond.local> References: <47BB74C0.5070501@datawranglers.com> <1203530917.24402.47.camel@aglarond.local> <47BCD38A.8050809@datawranglers.com> <1203601617.24402.118.camel@aglarond.local> <47BD9EB6.1020705@datawranglers.com> <1203610112.24402.145.camel@aglarond.local> <47BDAAF3.5060407@datawranglers.com> <1203616613.24402.152.camel@aglarond.local> Message-ID: <47C4FDB2.7040001@datawranglers.com> I'm starting to work on a LiveCD Development LiveCD designed to create livecd's and (if desired) burn them onto media (cd, usb, etc) ... and ... keep a light footprint. So far, I'm working with a fork of the XFCE kickstart. I've added livecd-tools, emacs, wget, curl, samba-client --for mounting shares with kickstarts. If someone has already created such a beast, please scream now ;-) If not, I'm open to suggestions about packages to include. The obvious ones are a good GUI text editor, an IDE and a CD/DVD burning package. I've got favorites in each category, but none are great choices for this situation (e.g. waaay too bloated). In the, my bloody to-do-list has too much compost on it, I'm going to ask people to not make suggestions about all the cool things like firefox bookmarks that such a beast needs. My brain has definitely already gone there and I promptly beat it with a beer ;-). Tim From wtogami at redhat.com Wed Feb 27 07:44:57 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 27 Feb 2008 02:44:57 -0500 Subject: [Fedora-livecd-list] Novell's "Split Image" LiveCD Message-ID: <47C514F9.9090105@redhat.com> http://lists.berlios.de/pipermail/kiwi-devel/2008-February/000324.html Due to the unavailability of aufs or unionfs, apparently Novell is using something they call "split image" where every directory is writable. I didn't look into the details yet. Anybody have any clue how this works? Warren Togami wtogami at redhat.com From katzj at redhat.com Wed Feb 27 15:10:00 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 27 Feb 2008 10:10:00 -0500 Subject: [Fedora-livecd-list] Corrupted RPM/unbootable LiveCD problem solved In-Reply-To: <47C4F935.2080102@datawranglers.com> References: <47BB74C0.5070501@datawranglers.com> <1203530917.24402.47.camel@aglarond.local> <47BCD38A.8050809@datawranglers.com> <1203601617.24402.118.camel@aglarond.local> <47BD9EB6.1020705@datawranglers.com> <1203610112.24402.145.camel@aglarond.local> <47BDAAF3.5060407@datawranglers.com> <1203616613.24402.152.camel@aglarond.local> <47C4F935.2080102@datawranglers.com> Message-ID: <1204125000.13241.2.camel@aglarond.local> On Tue, 2008-02-26 at 22:46 -0700, Tim Wood wrote: > IMVHO (I think I'm going to get blasted for this theory) it's probably > wise not to mix LiveCD tools for a future version of Fedora with a > production release of Fedora. The last time I ran into weird bad juju > with LiveCD Tools was when I mixed a git pre-release of the F8 version > of LiveCD Tools with a F7 dev vm. As I've said, I really *don't* test running on "stable" releases that often as all of my main machines run the development tree. I'm very open to fixes for running on at least the last Fedora release, but at the same time, it's probably going to require someone helping out and running more often on the stable release. Because I end up doing one of those test runs at most probably once a month. And since starting school, not even that. Jeremy From katzj at redhat.com Wed Feb 27 15:11:56 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 27 Feb 2008 10:11:56 -0500 Subject: [Fedora-livecd-list] Novell's "Split Image" LiveCD In-Reply-To: <47C514F9.9090105@redhat.com> References: <47C514F9.9090105@redhat.com> Message-ID: <1204125116.13241.4.camel@aglarond.local> On Wed, 2008-02-27 at 02:44 -0500, Warren Togami wrote: > http://lists.berlios.de/pipermail/kiwi-devel/2008-February/000324.html > Due to the unavailability of aufs or unionfs, apparently Novell is using > something they call "split image" where every directory is writable. > > I didn't look into the details yet. > Anybody have any clue how this works? Based purely on the mail, it sounds exactly like how the stateless rwtab bits work. Except with the added complication of xml instead of just doing it with a text file ;-) Jeremy From tim.wood at datawranglers.com Wed Feb 27 17:35:04 2008 From: tim.wood at datawranglers.com (Tim Wood) Date: Wed, 27 Feb 2008 10:35:04 -0700 Subject: [Fedora-livecd-list] Corrupted RPM/unbootable LiveCD problem solved In-Reply-To: <1204125000.13241.2.camel@aglarond.local> References: <47BB74C0.5070501@datawranglers.com> <1203530917.24402.47.camel@aglarond.local> <47BCD38A.8050809@datawranglers.com> <1203601617.24402.118.camel@aglarond.local> <47BD9EB6.1020705@datawranglers.com> <1203610112.24402.145.camel@aglarond.local> <47BDAAF3.5060407@datawranglers.com> <1203616613.24402.152.camel@aglarond.local> <47C4F935.2080102@datawranglers.com> <1204125000.13241.2.camel@aglarond.local> Message-ID: <47C59F48.4010603@datawranglers.com> I am guinea pig, hear me squeak! ;-) Tim Jeremy Katz wrote: > On Tue, 2008-02-26 at 22:46 -0700, Tim Wood wrote: > >> IMVHO (I think I'm going to get blasted for this theory) it's probably >> wise not to mix LiveCD tools for a future version of Fedora with a >> production release of Fedora. The last time I ran into weird bad juju >> with LiveCD Tools was when I mixed a git pre-release of the F8 version >> of LiveCD Tools with a F7 dev vm. >> > > As I've said, I really *don't* test running on "stable" releases that > often as all of my main machines run the development tree. I'm very > open to fixes for running on at least the last Fedora release, but at > the same time, it's probably going to require someone helping out and > running more often on the stable release. Because I end up doing one of > those test runs at most probably once a month. And since starting > school, not even that. > > Jeremy > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > -- _________________________________ Tim Wood, CLP, RHCT 719.338.7484 (tel) The Data Wranglers Web, Database & more since since 1994 www.datawranglers.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From katzj at fedoraproject.org Wed Feb 27 18:39:45 2008 From: katzj at fedoraproject.org (Jeremy Katz) Date: Wed, 27 Feb 2008 11:39:45 -0700 Subject: [Fedora-livecd-list] 3 commits - config/livecd-fedora-8-base-desktop.ks imgcreate/live.py tools/mayflower Message-ID: <200802271839.m1RIdjxF021866@hosted1.fedoraproject.org> config/livecd-fedora-8-base-desktop.ks | 15 imgcreate/live.py | 54 -- tools/mayflower | 805 --------------------------------- 3 files changed, 21 insertions(+), 853 deletions(-) New commits: commit 0812e699f503f8ac1a63ecf7d9ee9874fb7ea168 Author: Jeremy Katz Date: Tue Feb 26 17:56:25 2008 -0500 Remove mayflower diff --git a/tools/mayflower b/tools/mayflower deleted file mode 100755 index 162d4d4..0000000 --- a/tools/mayflower +++ /dev/null @@ -1,805 +0,0 @@ -#!/bin/bash - -# mayflower - flexible mkinitrd replacement -# -# Copyright 2006 David Zeuthen -# -# Licensed under the GPLv2. See the file COPYING for details. -# Inspired by similar programs from a bunch of other distributions. -# - -# Override any TMPDIR setting from the environment, since this script is -# run in a chroot: a nonstandard $TMPDIR setting would make mktemp fail. -export TMPDIR=/tmp - -usage() { - echo "$0 [--help] " - echo - echo "example: $0 /boot/myinitramfs.img \`uname -r\`" -} - -opt_allow_overwrite=0 -opt_verbose=0 -INITRAMFS_TARGET="" -KERNEL="" -while [ $# -gt 0 ] ; do - case $1 in - --help) - usage - exit 0 - ;; - -f) - opt_allow_overwrite=1 - ;; - --allow-missing) - echo "Ignore option $1 for /sbin/mkinitrd compatibility" - ;; - -v|--verbose) - opt_verbose=1 - ;; - *) - if [ -z "$INITRAMFS_TARGET" ] ; then - INITRAMFS_TARGET=$1 - elif [ -z "$KERNEL" ] ; then - KERNEL=$1 - else - echo "Unknown option or parameter \"$1\"" - echo - usage - exit 1 - fi - ;; - *) - ;; - esac - - shift -done - -if [ -z "$INITRAMFS_TARGET" -o -z "$KERNEL" ] ; then - usage - exit 1 -fi - -if [ "$opt_allow_overwrite" == "0" ] ; then - if [ -e $INITRAMFS_TARGET ] ; then - echo "Image $INITRAMFS_TARGET already exists. Use -f to overwrite" - exit 1 - fi -fi - -echo "Building an initramfs at $INITRAMFS_TARGET for kernel $KERNEL" - -TEMPDIR=`mktemp -d` || exit 1 -pushd $TEMPDIR > /dev/null -mkdir initramfs_dir -cd initramfs_dir - -# Make directory structure -mkdir bin sbin dev sys proc lib lib/udev sysroot etc etc/udev etc/udev/rules.d - -cp /sbin/losetup sbin -cp /sbin/blockdev sbin -cp /sbin/dmsetup sbin -cp /bin/dd bin -cp /bin/cut bin - -# we explicitly load these, so should be sure they're present -MODULES="loop dm_snapshot " - -if [ -e /etc/mayflower.conf ] ; then - source /etc/mayflower.conf -fi - -# TODO: right now we only recognize MODULES... add support for more -# options such as 'include all modules neccessary to mount the mount -# point /mnt/temp_os_install' etc. - -MODULES+=" " - -if [ "$opt_verbose" == "1" ] ; then - echo "Kernel modules requested: $MODULES" - echo -fi -rm -f modules - -for m in $MODULES ; do - char=$(echo $m | cut -c1) - if [ $char = '=' ]; then - NAME=$(echo $m | cut -c2-) - if [ "$NAME" = "ata" ]; then - if [ -f /lib/modules/$KERNEL/modules.libata ]; then - MODS="$MODS $(cat /lib/modules/$KERNEL/modules.libata |sed -e 's/.ko//')" - else - MODS="$MODS $(cat /lib/modules/$KERNEL/modules.block |egrep '(ata|ahci)' |sed -e 's/.ko//')" - fi - else - MODS="$MODS $(cat /lib/modules/$KERNEL/modules.$NAME |sed -e 's/.ko//')" - fi - else - MODS="$MODS $m" - fi -done - -for m in $MODS ; do - /sbin/modprobe --set-version $KERNEL --show-depends $m >> modules 2>/dev/null -done - -cat modules | awk '{ print $2 }' | sort -u > modules2 -rm -f modules -MODULES_FILES=`cat modules2` -rm -f modules2 - -mkdir -p lib/modules/$KERNEL/ - -# Copy kernel modules over -for f in $MODULES_FILES ; do - if [ "$opt_verbose" == "1" ] ; then - echo "Copying kernel module $f" - fi - cp $f lib/modules/$KERNEL/ -done - -# Build module deps file so we can use modprobe -if [ "$opt_verbose" == "1" ] ; then - /sbin/depmod -b `pwd` -v $KERNEL -else - /sbin/depmod -b `pwd` -v $KERNEL > /dev/null -fi - -# Copy /etc/fstab over -cp /etc/fstab etc - -# Copy modprobe.conf and friends over -if [ -e /etc/modprobe.conf ] ; then - cp /etc/modprobe.conf etc -fi -cp -R /etc/modprobe.d etc - -# Copy binaries over -cp /bin/echo bin -cp /bin/sleep bin -cp /bin/bash bin -cp /bin/mount bin -cp /bin/umount bin -[ -x /usr/sbin/eject ] && cp /usr/sbin/eject sbin -cp /bin/ls bin -cp /bin/mknod bin -cp /bin/mkdir bin -cp /bin/chmod bin -cp /bin/ln bin -cp /bin/cat bin -cp /usr/bin/kill bin -cp /bin/rm bin - -cp /sbin/udevsettle sbin -cp /sbin/udevtrigger sbin -cp /sbin/udevd sbin -cp /sbin/insmod sbin -cp /sbin/modprobe sbin -cp /sbin/pidof sbin -cp /sbin/killall5 sbin -cp /sbin/nash sbin - -cp /lib/udev/vol_id lib/udev - -# symlink niceties -ln -s bash bin/sh - -# Not really required but nice -[ -x /usr/bin/tree ] && cp /usr/bin/tree bin -[ -x /usr/bin/less ] && cp /usr/bin/less bin -cp /bin/env bin -cp /bin/grep bin -cp /bin/dmesg bin -cp /sbin/lsmod sbin - -# if we have the iso checker, we want it -[ -x /usr/lib/anaconda-runtime/checkisomd5 ] && cp /usr/lib/anaconda-runtime/checkisomd5 bin -[ -x /usr/bin/checkisomd5 ] && cp /usr/bin/checkisomd5 bin - -# Copy all required shared libs -for i in bin/* sbin/* lib/udev/*; do - ldd $i | sed 's|.*=>||g' | awk '/\// { print $1 }' | while read lib ; do - if [ "$opt_verbose" == "1" ] ; then - echo "Copying DSO $l" - fi - cp --parents $lib . - done -done - -cat > sbin/run-init <<'EOF' -#!/sbin/nash -setuproot -switchroot -EOF -chmod 755 sbin/run-init - -# Write out init -cat > init <<'EOF' -#!/bin/bash - -emergency_shell() -{ - echo "Bug in initramfs /init detected. Dropping to a shell. Good luck!" - echo - bash -} -trap "emergency_shell" 0 2 - -# exit immediately if a command fails -set -e - -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 -mknod /dev/kmsg c 1 11 -mkdir /dev/pts -mkdir -m 1777 /dev/shm -ln -s /proc/self/fd /dev/fd -ln -s fd/0 /dev/stdin -ln -s fd/1 /dev/stdout -ln -s fd/2 /dev/stderr - -mount -n -t proc proc /proc -mount -n -t sysfs sysfs /sys - -echo "" > /proc/sys/kernel/hotplug - -# Declare all variables here.. mostly for housekeeping -# -init="/sbin/init" -root_ro=0 -root_rw=0 -root="" -rootflags="" -rootfstype="" -quiet=0 -shell=0 -eshell=0 -live_ram=0 -check_iso=0 -live_locale="" - -# Parse kernel commandline options -# -for o in `cat /proc/cmdline` ; do - case $o in - init=*) - init=${o#init=} - ;; - ro) - root_ro=1 - ;; - rw) - root_rw=1 - ;; - quiet) - quiet=1 - ;; - shell) - shell=1 - ;; - eshell) - eshell=1 - ;; - live_ram) - live_ram=1 - ;; - live_locale=*) - live_locale=${o#live_locale=} - ;; - check) - check_iso=1 - ;; - blacklist=*) - blacklist=${o#blacklist=} - echo "blacklist $blacklist" >> /etc/modprobe.conf - ;; - *) - m=$(echo $o |cut -s -d . -f 1) - opt=$(echo $o |cut -s -d . -f 2-) - if [ -z "$m" -o -z "$opt" ]; then - continue - fi - p=$(echo $opt |cut -s -d = -f 1) - v=$(echo $opt |cut -s -d = -f 2-) - if [ -z "$p" -o -z "$v" ]; then - continue - fi - echo "options $m $p=$v" >> /etc/modprobe.conf - ;; - esac -done - -if [ "$quiet" != "1" ] ; then - echo "kernel commandline: `cat /proc/cmdline`" -fi - -# First, read rootfs target from embedded /etc/fstab file -# -if [ -f /etc/fstab ] ; then - root=$(cat /etc/fstab | while read d m f o r; do if [ "$m" == "/" ] ; then echo $d; fi; done) - rootflags=$(cat /etc/fstab | while read d m f o r; do if [ "$m" == "/" ] ; then echo $o; fi; done) - rootfstype=$(cat /etc/fstab | while read d m f o r; do if [ "$m" == "/" ] ; then echo $f; fi; done) - if [ "$quiet" != "1" ] ; then - echo "fstab suggests root=$root" - echo "fstab suggests rootflags=$rootflags" - echo "fstab suggests rootfstype=$rootfstype" - # Handle the case with bogus /etc/fstab pointing to /dev/root - # which by definition does not exist... - # - if [ "$root" == "/dev/root" ] ; then - echo "WARNING: Bogus /etc/fstab file - cannot have /dev/root as the device for /" - root="" - rootflags="" - rootfstype="" - fi - fi -fi - -# Users can override rootfs target on the kernel commandline -# -for o in `cat /proc/cmdline` ; do - case $o in - root=*) - root=${o#root=} - ;; - rootflags=*) - rootflags=${o#rootflags=} - ;; - rootfstype=*) - rootfstype=${o#rootfstype=} - ;; - esac -done - -# Print out what we are going to do -# -if [ "$quiet" != "1" ] ; then - echo "init=$init" - echo "root=$root" - echo "rootflags=$rootflags" - echo "rootfstype=$rootfstype" - echo "root_ro=$root_ro" - echo "root_rw=$root_rw" -fi - -waitforsymlink=0 -# generate udev rules to generate /dev/root symlink -if [ -z $root ] ; then - root=/dev/something -else - case $root in - /dev/disk/by-label/*) - LABEL=${root#/dev/disk/by-label/} - echo "SUBSYSTEM==\"block\", PROGRAM=\"/lib/udev/vol_id -l %N\", RESULT==\"$LABEL\", SYMLINK+=\"root\"" > /etc/udev/rules.d/00-label.rules - if [ "$quiet" != "1" ] ; then - echo "Added udev rule 00-label.rules:" - cat /etc/udev/rules.d/00-label.rules - fi - waitforsymlink=1 - thingtomount=/dev/root - ;; - CDLABEL=*) - CDLABEL=${root#CDLABEL=} - echo "KERNEL==\"hd[a-z]\", BUS==\"ide\", SYSFS{removable}==\"1\", ATTRS{media}==\"cdrom\", PROGRAM=\"/lib/udev/vol_id -l %N\", RESULT==\"$CDLABEL\", SYMLINK+=\"root\"" > /etc/udev/rules.d/00-cdlabel.rules - echo "KERNEL==\"sr[0-9]\", PROGRAM=\"/lib/udev/vol_id -l %N\", RESULT==\"$CDLABEL\", SYMLINK+=\"root\"" >> /etc/udev/rules.d/00-cdlabel.rules - echo "KERNEL==\"scd[0-9]\", PROGRAM=\"/lib/udev/vol_id -l %N\", RESULT==\"$CDLABEL\", SYMLINK+=\"root\"" >> /etc/udev/rules.d/00-cdlabel.rules - echo "KERNEL==\"pcd[0-9]\", PROGRAM=\"/lib/udev/vol_id -l %N\", RESULT==\"$CDLABEL\", SYMLINK+=\"root\"" >> /etc/udev/rules.d/00-cdlabel.rules - if [ "$quiet" != "1" ] ; then - echo "Added udev rule 00-cdlabel.rules:" - cat /etc/udev/rules.d/00-cdlabel.rules - fi - waitforsymlink=1 - thingtomount=/dev/root - ;; - LABEL=*) - LABEL=${root#LABEL=} - echo "SUBSYSTEM==\"block\", PROGRAM=\"/lib/udev/vol_id -l %N\", RESULT==\"$LABEL\", SYMLINK+=\"root\"" > /etc/udev/rules.d/00-label.rules - if [ "$quiet" != "1" ] ; then - echo "Added udev rule 00-label.rules:" - cat /etc/udev/rules.d/00-label.rules - fi - waitforsymlink=1 - thingtomount=/dev/root - ;; - /dev/disk/by-id/*) - UUID=${root#/dev/disk/by-id/} - echo "SUBSYSTEM==\"block\", PROGRAM=\"/lib/udev/vol_id -u %N\", RESULT==\"$UUID\", SYMLINK+=\"root\"" > /etc/udev/rules.d/01-uuid.rules - if [ "$quiet" != "1" ] ; then - echo "Added udev rule 01-uuid.rules:" - cat /etc/udev/rules.d/01-uuid.rules - fi - waitforsymlink=1 - thingtomount=/dev/root - ;; - UUID=*) - UUID=${root#UUID=} - echo "SUBSYSTEM==\"block\", PROGRAM=\"/lib/udev/vol_id -u %N\", RESULT==\"$UUID\", SYMLINK+=\"root\"" > /etc/udev/rules.d/01-uuid.rules - if [ "$quiet" != "1" ] ; then - echo "Added udev rule 01-uuid.rules:" - cat /etc/udev/rules.d/01-uuid.rules - fi - waitforsymlink=1 - thingtomount=/dev/root - ;; - /dev/*) - ln -s $root /dev/root - thingtomount=$root - ;; - *) - thingtomount=$root - ;; - esac -fi - -echo "udev_log=\"error\"" >> /etc/udev/udev.conf - -# rules for loading modules -# -echo -n "ACTION==\"add\", SUBSYSTEM==\"?*\", ENV{MODALIAS}==\"?*\", RUN+=\"/sbin/modprobe $" >> /etc/udev/rules.d/10-modprobe.rules -echo "env{MODALIAS}\"" >> /etc/udev/rules.d/10-modprobe.rules -echo "ACTION==\"add\", SUBSYSTEM==\"scsi_device\" RUN+=\"/sbin/modprobe sg\"" >> /etc/udev/rules.d/10-modprobe.rules -echo "ACTION==\"add\", SUBSYSTEM==\"scsi_device\", SYSFS{type}==\"0|7|14\", RUN+=\"/sbin/modprobe sd_mod\"" >> /etc/udev/rules.d/10-modprobe.rules -echo "ACTION==\"add\", SUBSYSTEM==\"scsi_device\", SYSFS{type}==\"[45]\", RUN+=\"/sbin/modprobe sr_mod\"" >> /etc/udev/rules.d/10-modprobe.rules -echo "SUBSYSTEM==\"mmc\", RUN+=\"/sbin/modprobe mmc_block\"" >> /etc/udev/rules.d/10-modprobe.rules - -# FIXME: hack since sr_mod seems to fail to get loaded sometimes (#239657) -/sbin/modprobe sr_mod - -/sbin/modprobe loop max_loop=16 - -if [ "$quiet" != "1" ] ; then - echo "starting udevd" -fi -/sbin/udevd --daemon - -if [ "$quiet" != "1" ] ; then - echo "creating devices" -fi -/sbin/udevtrigger - -if [ "$quiet" != "1" ] ; then - echo "waiting for system to settle" -fi -/sbin/udevsettle --timeout=30 || : - - -if [ "$shell" == "1" ] ; then - echo "Shell requested on kernel commandline. Exit to continue booting." - echo - bash -fi - -# don't wait for "mtd0" as no device file will appear -# and don't worry about this if $thingtomount is a regular file -if [ "$root" != "mtd0" -a ! -f "$thingtomount" ] ; then - - # If we don't have the /dev/root link.. ask the user to create.. - if [ "$waitforsymlink" != "1" ] ; then - if [ ! -L /dev/root ] ; then - echo - echo "--------------------------------------" - echo "WARNING: Cannot find root file system!" - echo "--------------------------------------" - echo - echo "Create symlink /dev/root and then exit this shell to continue" - echo "the boot sequence." - echo - bash - fi - fi - - # udevsettle might return before slow devices such as USB are in shape - # Wait up to 60 seconds for them to appear... - # - if [ ! -b /dev/root ] ; then - if [ "$quiet" != "1" ] ; then - echo "no root yet, udev rule will write symlink..." - echo - echo "waiting up to 60 seconds before dropping to emergency shell." - fi - COUNTDOWN=60 - while [ "x$COUNTDOWN" != "x0" ] ; do - if [ "$quiet" != "1" ] ; then - echo -n "." - fi - COUNTDOWN=$(($COUNTDOWN - 1)) - /bin/sleep 1 - if [ -e /dev/root ] ; then - COUNTDOWN=0 - fi - done - fi - - if [ ! -b /dev/root ] ; then - echo - echo "--------------------------------------" - echo "WARNING: Cannot find root file system!" - echo "--------------------------------------" - echo - echo "Create symlink /dev/root and then exit this shell to continue" - echo "the boot sequence." - echo - bash - fi - - if [ "$quiet" != "1" ] ; then - echo "mounting /dev/root" - ls -l /dev/root - fi - - if [ -z $rootfstype ] ; then - rootfstype=auto - fi - -fi - -if [ "x$check_iso" == "x1" -a -x /bin/checkisomd5 -a "x$rootfstype" == "xiso9660" ]; then - echo "Verifying ISO image..." - /bin/checkisomd5 --verbose /dev/root - if [ $? -ne 0 ]; then - echo "Are you SURE you want to continue?" - echo "Press Enter to continue or ctrl-alt-del to reboot." - read - fi -fi - -if [ "x$root_ro" == "x1" ] ; then - if [ -z $rootflags ] ; then - rootflags="ro" - else - rootflags="$rootflags,ro" - fi -fi - -if [ "x$root_rw" == "x1" ] ; then - if [ -z $rootflags ] ; then - rootflags="rw" - else - rootflags="$rootflags,rw" - fi -fi - -if [ -z $rootflags ] ; then - mountoptions="" -else - mountoptions=" -o$rootflags" -fi - -mount -n -t $rootfstype $mountoptions $thingtomount /sysroot -RES=$? - -if [ "$RES" != "0" ] ; then - echo "---------------------------------" - echo "WARNING: Cannot mount rootfs!" - echo "---------------------------------" - echo - echo "Dropping to a shell. " - echo "Mount rootfs at /sysroot and exit shell to continue. Good luck!" - echo - bash -fi - -# Now get ready to leave the initramfs -# - -# only pass kernel command line if we're launching /sbin/init -if [ "$init" == "/sbin/init" ] ; then - initargs=$(cat /proc/cmdline) -else - initargs="" -fi - -# live cd helper function -do_live_from_base_loop() { - # create a sparse file for the overlay - dd if=/dev/null of=/overlay bs=1024 count=1 seek=$((512*1024)) 2> /dev/null - OVERLAY_LOOPDEV=$( losetup -f ) - losetup $OVERLAY_LOOPDEV /overlay - - # set up the snapshot - echo 0 `blockdev --getsize $BASE_LOOPDEV` snapshot $BASE_LOOPDEV $OVERLAY_LOOPDEV p 8 | dmsetup create live-rw - - # set up new /dev/root symlink - rm -f /dev/root - ln -s /dev/mapper/live-rw /dev/root - - mount -n /dev/mapper/live-rw /sysroot - # here you can modify the rw ext3 fs for testing if you don't want to - # respin the entire rootfs (which takes ages). Example - # - # echo foo > /sysroot/etc/bar.conf - # - # We also use it to dynamically set the system locale from the boot - # menu on live cd's. - # - if [ "$live_locale" != "" ] ; then - echo "LANG=$live_locale" > /sysroot/etc/sysconfig/i18n - fi - - # copy over module options - [ -f /etc/modprobe.conf ] && cat /etc/modprobe.conf >> /sysroot/etc/modprobe.conf - - # create rule so udev creates /dev/live symlink on real rootfs - if [ -n "$CDLABEL" ]; then - echo "KERNEL==\"hd[a-z]\", BUS==\"ide\", SYSFS{removable}==\"1\", ATTRS{media}==\"cdrom\", PROGRAM=\"/lib/udev/vol_id -l %N\", RESULT==\"$CDLABEL\", SYMLINK+=\"live\"" >> /sysroot/etc/udev/rules.d/50-udev* - echo "KERNEL==\"sr[0-9]\", PROGRAM=\"/lib/udev/vol_id -l %N\", RESULT==\"$CDLABEL\", SYMLINK+=\"live\"" >> /sysroot/etc/udev/rules.d/50-udev* - echo "KERNEL==\"scd[0-9]\", PROGRAM=\"/lib/udev/vol_id -l %N\", RESULT==\"$CDLABEL\", SYMLINK+=\"live\"" >> /sysroot/etc/udev/rules.d/50-udev* - echo "KERNEL==\"pcd[0-9]\", PROGRAM=\"/lib/udev/vol_id -l %N\", RESULT==\"$CDLABEL\", SYMLINK+=\"live\"" >> /sysroot/etc/udev/rules.d/50-udev* - elif [ -n "$LABEL" ]; then - echo "KERNEL==\"hd[a-z]\", PROGRAM=\"/lib/udev/vol_id -l %N\", RESULT==\"$LABEL\", SYMLINK+=\"live\"" >> /sysroot/etc/udev/rules.d/50-udev* - echo "KERNEL==\"hd[a-z][0-9]*\", PROGRAM=\"/lib/udev/vol_id -l %N\", RESULT==\"$LABEL\", SYMLINK+=\"live\"" >> /sysroot/etc/udev/rules.d/50-udev* - echo "KERNEL==\"sd[a-z]\", PROGRAM=\"/lib/udev/vol_id -l %N\", RESULT==\"$LABEL\", SYMLINK+=\"live\"" >> /sysroot/etc/udev/rules.d/50-udev* - echo "KERNEL==\"sd[a-z][0-9]*\", PROGRAM=\"/lib/udev/vol_id -l %N\", RESULT==\"$LABEL\", SYMLINK+=\"live\"" >> /sysroot/etc/udev/rules.d/50-udev* - elif [ -n "$UUID" ]; then - echo "KERNEL==\"hd[a-z]\", PROGRAM=\"/lib/udev/vol_id -u %N\", RESULT==\"$UUID\", SYMLINK+=\"live\"" >> /sysroot/etc/udev/rules.d/50-udev* - echo "KERNEL==\"hd[a-z][0-9]*\", PROGRAM=\"/lib/udev/vol_id -u %N\", RESULT==\"$UUID\", SYMLINK+=\"live\"" >> /sysroot/etc/udev/rules.d/50-udev* - echo "KERNEL==\"sd[a-z]\", PROGRAM=\"/lib/udev/vol_id -u %N\", RESULT==\"$UUID\", SYMLINK+=\"live\"" >> /sysroot/etc/udev/rules.d/50-udev* - echo "KERNEL==\"sd[a-z][0-9]*\", PROGRAM=\"/lib/udev/vol_id -u %N\", RESULT==\"$UUID\", SYMLINK+=\"live\"" >> /sysroot/etc/udev/rules.d/50-udev* - fi - - # add rules for loop devices created by this mayflower generated init - # i.e. /dev/live-osimg, /dev/live-osmin, /dev/live-overlay, - # and /dev/live-squashed - if [ -b "$SQUASHED_LOOPDEV" ]; then - echo "KERNEL==\"${SQUASHED_LOOPDEV#/dev/}\" SYMLINK+=\"live-squashed\"" >> /sysroot/etc/udev/rules.d/50-udev* - fi - if [ -b "$OSMIN_SQUASHED_LOOPDEV" ]; then - echo "KERNEL==\"${OSMIN_SQUASHED_LOOPDEV#/dev/}\" SYMLINK+=\"live-squashed-osmin\"" >> /sysroot/etc/udev/rules.d/50-udev* - fi - if [ -b "$OSMIN_LOOPDEV" ]; then - echo "KERNEL==\"${OSMIN_LOOPDEV#/dev/}\" SYMLINK+=\"live-osmin\"" >> /sysroot/etc/udev/rules.d/50-udev* - fi - echo "KERNEL==\"${BASE_LOOPDEV#/dev/}\" SYMLINK+=\"live-osimg\"" >> /sysroot/etc/udev/rules.d/50-udev* - echo "KERNEL==\"${OVERLAY_LOOPDEV#/dev/}\" SYMLINK+=\"live-overlay\"" >> /sysroot/etc/udev/rules.d/50-udev* - - mount -n -o ro,remount /sysroot -} - -# we might have a genMinInstDelta delta file for anaconda to take advantage of -if [ -e /sysroot/LiveOS/osmin.img ]; then - OSMINSQFS=/sysroot/LiveOS/osmin.img -fi - -if [ -n "$OSMINSQFS" ]; then - # decompress the delta data - dd if=$OSMINSQFS of=/osmin.img 2> /dev/null - OSMIN_SQUASHED_LOOPDEV=$( losetup -f ) - losetup $OSMIN_SQUASHED_LOOPDEV /osmin.img - mkdir -p /squashfs.osmin - mount -n -t squashfs -o ro $OSMIN_SQUASHED_LOOPDEV /squashfs.osmin - OSMIN_LOOPDEV=$( losetup -f ) - losetup $OSMIN_LOOPDEV /squashfs.osmin/osmin - umount -l /squashfs.osmin -fi - -# we might have an uncompressed embedded ext3 to use as rootfs (uncompressed live) -# -if [ -e /sysroot/LiveOS/ext3fs.img ]; then - EXT3FS="/sysroot/LiveOS/ext3fs.img" -fi - -if [ -n "$EXT3FS" ] ; then - if [ "$quiet" != "1" ] ; then - echo "setting up embedded ext3 fs " - fi - - mkdir -p /dev/mapper - mknod /dev/mapper/control c 10 63 - modprobe dm_snapshot - - BASE_LOOPDEV=$( losetup -f ) - losetup $BASE_LOOPDEV $EXT3FS - umount -l /sysroot - - do_live_from_base_loop -fi - -# we might have an embedded ext3 on squashfs to use as rootfs (compressed live) -# -if [ -e /sysroot/LiveOS/squashfs.img ]; then - SQUASHED="/sysroot/LiveOS/squashfs.img" -fi - -if [ -e "$SQUASHED" ] ; then - - if [ "$quiet" != "1" ] ; then - echo "setting up embedded squash -> ext3 fs " - fi - - mkdir -p /dev/mapper - mknod /dev/mapper/control c 10 63 - modprobe dm_snapshot - - if [ "$live_ram" == "1" ] ; then - echo "Copying live image to RAM..." - echo "(this may take a few minutes)" - dd if=$SQUASHED of=/squashed.img bs=512 2> /dev/null - umount -n /sysroot - echo "Done copying live image to RAM." - eject -p /dev/root - SQUASHED="/squashed.img" - fi - - SQUASHED_LOOPDEV=$( losetup -f ) - losetup $SQUASHED_LOOPDEV $SQUASHED - mkdir -p /squashfs - mount -n -t squashfs -o ro $SQUASHED_LOOPDEV /squashfs - - BASE_LOOPDEV=$( losetup -f ) - losetup $BASE_LOOPDEV /squashfs/LiveOS/ext3fs.img - - umount -l /squashfs - if [ "$live_ram" == "0" ] ; then - umount -l /sysroot - fi - - do_live_from_base_loop -fi - -if [ -b "$OSMIN_LOOPDEV" ]; then - # set up the devicemapper snapshot device, which will merge - # the normal live fs image, and the delta, into a minimzied fs image - echo "0 $( blockdev --getsize $BASE_LOOPDEV ) snapshot $BASE_LOOPDEV $OSMIN_LOOPDEV p 8" | dmsetup create --readonly live-osimg-min -fi - -if [ "$eshell" == "1" ] ; then - echo "Shell requested on kernel commandline." - echo "Rootfs is mounted ro on /sysroot. Exit to continue booting." - echo - bash -fi - -if [ -x /sysroot$init ] ; then - - # Leave initramfs and transition to rootfs - kill `pidof udevd` - if [ "$quiet" != "1" ] ; then - echo "transfering control to $init" - fi - - exec /sbin/run-init - echo "---------------------------------" - echo "WARNING: Error switching to real rootfs!" - echo "---------------------------------" - echo - echo "Dropping to a shell. Good luck!" - echo - bash -else - echo "---------------------------------------------------------" - echo "WARNING: Requested $init binary does not exist on rootfs." - echo "---------------------------------------------------------" - echo - echo "Dropping to a shell. Good luck!" - echo - bash -fi - -EOF - -chmod a+x init - -if [ "$opt_verbose" == "1" ] ; then - tree -s . - echo - cat -n init - echo -fi - - -find . | cpio --quiet -o -H newc | gzip -9 > ../initramfs -popd > /dev/null -rm -f $INITRAMFS_TARGET -cp $TEMPDIR/initramfs $INITRAMFS_TARGET -rm -rf $TEMPDIR - -echo "Done; initramfs is $(du -h $INITRAMFS_TARGET | awk '{print $1}')." -echo -exit 0 commit 11dbd0bb5ba4b845e80109e990e4e780ca402218 Author: Jeremy Katz Date: Tue Feb 26 17:56:16 2008 -0500 Fix up Fedora 8 configs to still be able to boot We need to run mayflower in the config now rather than depending on livecd-creator running it itself diff --git a/config/livecd-fedora-8-base-desktop.ks b/config/livecd-fedora-8-base-desktop.ks index 2cf42b5..febfc97 100644 --- a/config/livecd-fedora-8-base-desktop.ks +++ b/config/livecd-fedora-8-base-desktop.ks @@ -22,6 +22,9 @@ repo --name=updates --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?rep kernel memtest86+ +# for live initrd +livecd-tools + # save some space -specspo -esc @@ -158,11 +161,16 @@ chmod 755 /etc/rc.d/init.d/fedora-live /sbin/restorecon /etc/rc.d/init.d/fedora-live /sbin/chkconfig --add fedora-live -# save a little bit of space at least... -rm -f /boot/initrd* # make sure there aren't core files lying around rm -f /core* +# make the initrd we care about +rm -f /boot/initrd*.img +cp /etc/sysconfig/mkinitrd /etc/mayflower.conf +ver=`ls /boot/vmlinuz* |head -n 1 |sed -e 's;/boot/vmlinuz-;;'` +/usr/lib/livecd-creator/mayflower -f /boot/initrd-$ver.img $ver +rm -f /etc/mayflower.conf + %end @@ -175,4 +183,7 @@ if [ "$(uname -i)" = "i386" -o "$(uname -i)" = "x86_64" ]; then if [ ! -d $LIVE_ROOT/LiveOS ]; then mkdir -p $LIVE_ROOT/LiveOS ; fi cp /usr/bin/livecd-iso-to-disk $LIVE_ROOT/LiveOS fi + +# move the initrd we created to be the booted one +mv $INSTALL_ROOT/boot/initrd-*.img $LIVE_ROOT/isolinux/initrd0.img %end commit 2d81880202d017bc802316cc60354597391e1030 Author: Jeremy Katz Date: Tue Feb 26 17:54:54 2008 -0500 Stop using mayflower for building the live initrd mkinitrd is starting to gain some support for building initrds for live systems. We should just use that initrd rather than creating our own and carrying our own infrastructure for this. diff --git a/imgcreate/live.py b/imgcreate/live.py index bbb17ef..13dd84d 100644 --- a/imgcreate/live.py +++ b/imgcreate/live.py @@ -26,8 +26,6 @@ from imgcreate.errors import * from imgcreate.fs import * from imgcreate.creator import * -MAYFLOWER_PATH = "/usr/lib/livecd-creator/mayflower" - class LiveImageCreatorBase(LoopImageCreator): """A base class for LiveCD image creators. @@ -177,6 +175,7 @@ class LiveImageCreatorBase(LoopImageCreator): if not base_on is None: self.__base_on_iso(base_on) LoopImageCreator._mount_instroot(self) + self.__write_initrd_conf(self._instroot + "/etc/sysconfig/mkinitrd") def __ensure_isodir(self): if self.__isodir is None: @@ -185,7 +184,6 @@ class LiveImageCreatorBase(LoopImageCreator): def _create_bootconfig(self): """Configure the image so that it's bootable.""" - self.__create_initramfs() self._configure_bootloader(self.__ensure_isodir()) def _get_post_scripts_env(self, in_chroot): @@ -196,26 +194,13 @@ class LiveImageCreatorBase(LoopImageCreator): return env - # - # Try to use mayflower if running from git tree - # - def __mayflower_path(self): - if not globals().has_key("__file__"): - return MAYFLOWER_PATH - - pydir = os.path.abspath(os.path.dirname(__file__)) - if pydir.startswith("/usr/lib"): - return MAYFLOWER_PATH - - git_mayflower = os.path.join(pydir, "../tools/mayflower") - if not os.path.exists(git_mayflower): - return MAYFLOWER_PATH - - return git_mayflower - - def __write_mayflower_conf(self, path): + def __write_initrd_conf(self, path): + if not os.path.exists(os.path.dirname(path)): + makedirs(os.path.dirname(path)) f = open(path, "a") + f.write('LIVEOS="yes"\n') + f.write('PROBE="no"\n') f.write('MODULES+="squashfs ext3 ext2 vfat msdos "\n') f.write('MODULES+="sr_mod sd_mod ide-cd "\n') @@ -233,27 +218,6 @@ class LiveImageCreatorBase(LoopImageCreator): f.close() - def __create_initramfs(self): - mayflower = self.__mayflower_path() - if not os.path.isfile(mayflower): - raise CreatorError("livecd-creator not correctly installed : " - "%s not found" % MAYFLOWER_PATH) - - shutil.copy(mayflower, self._instroot + "/sbin") - - self.__write_mayflower_conf(self._instroot + "/etc/mayflower.conf") - - kernels = self._get_kernel_versions() - for kernel in kernels: - for version in kernels[kernel]: - subprocess.call(["/sbin/mayflower", "-f", - "/boot/livecd-initramfs-%s.img" % (version,), - version], - preexec_fn=self._chroot), - - os.unlink(self._instroot + "/sbin/mayflower") - os.unlink(self._instroot + "/etc/mayflower.conf") - def __create_iso(self, isodir): iso = self._outdir + "/" + self.name + ".iso" @@ -371,9 +335,8 @@ class x86LiveImageCreator(LiveImageCreatorBase): shutil.copyfile(bootdir + "/vmlinuz-" + version, isodir + "/isolinux/vmlinuz" + index) - shutil.copyfile(bootdir + "/livecd-initramfs-" + version + ".img", + shutil.copyfile(bootdir + "/initrd-" + version + ".img", isodir + "/isolinux/initrd" + index + ".img") - os.unlink(bootdir + "/livecd-initramfs-" + version + ".img") is_xen = False if os.path.exists(bootdir + "/boot/xen.gz-" + version[:-3]): @@ -572,9 +535,8 @@ class ppcLiveImageCreator(LiveImageCreatorBase): shutil.copyfile(bootdir + "/vmlinuz-" + version, destdir + "/vmlinuz") - shutil.copyfile(bootdir + "/livecd-initramfs-" + version + ".img", + shutil.copyfile(bootdir + "/initrd-" + version + ".img", destdir + "/initrd.img") - os.unlink(bootdir + "/livecd-initramfs-" + version + ".img") def __get_basic_yaboot_config(self, **args): return """ From katzj at redhat.com Wed Feb 27 18:42:53 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 27 Feb 2008 13:42:53 -0500 Subject: [Fedora-livecd-list] Corrupted RPM/unbootable LiveCD problem solved In-Reply-To: <47C59F48.4010603@datawranglers.com> References: <47BB74C0.5070501@datawranglers.com> <1203530917.24402.47.camel@aglarond.local> <47BCD38A.8050809@datawranglers.com> <1203601617.24402.118.camel@aglarond.local> <47BD9EB6.1020705@datawranglers.com> <1203610112.24402.145.camel@aglarond.local> <47BDAAF3.5060407@datawranglers.com> <1203616613.24402.152.camel@aglarond.local> <47C4F935.2080102@datawranglers.com> <1204125000.13241.2.camel@aglarond.local> <47C59F48.4010603@datawranglers.com> Message-ID: <1204137773.13241.6.camel@aglarond.local> Patches accepted :-) The problem is that a lot of times, it requires really seeing the problems and sticking in debugging to fix. Sometimes I'm psychic enough to be able to fix based on just descriptions of the problem but sadly not often enough :-) Jeremy On Wed, 2008-02-27 at 10:35 -0700, Tim Wood wrote: > I am guinea pig, hear me squeak! ;-) > > Tim > > Jeremy Katz wrote: > > On Tue, 2008-02-26 at 22:46 -0700, Tim Wood wrote: > > > > > IMVHO (I think I'm going to get blasted for this theory) it's probably > > > wise not to mix LiveCD tools for a future version of Fedora with a > > > production release of Fedora. The last time I ran into weird bad juju > > > with LiveCD Tools was when I mixed a git pre-release of the F8 version > > > of LiveCD Tools with a F7 dev vm. > > > > > > > As I've said, I really *don't* test running on "stable" releases that > > often as all of my main machines run the development tree. I'm very > > open to fixes for running on at least the last Fedora release, but at > > the same time, it's probably going to require someone helping out and > > running more often on the stable release. Because I end up doing one of > > those test runs at most probably once a month. And since starting > > school, not even that. > > > > Jeremy > > > > -- > > Fedora-livecd-list mailing list > > Fedora-livecd-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > > > > > > -- > _________________________________ > Tim Wood, CLP, RHCT > 719.338.7484 (tel) > > The Data Wranglers > Web, Database & more since since 1994 > www.datawranglers.com > -- > 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 Wed Feb 27 18:43:10 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 27 Feb 2008 13:43:10 -0500 Subject: [Fedora-livecd-list] RFC: Remove explicit initrd creation from livecd creation In-Reply-To: <1203963727.10761.17.camel@aglarond.local> References: <1203963727.10761.17.camel@aglarond.local> Message-ID: <1204137790.13241.8.camel@aglarond.local> On Mon, 2008-02-25 at 13:22 -0500, Jeremy Katz wrote: > Anyone see any real problems with this? No one complained, so I just pushed these changes Jeremy From ka0sm0nk at yahoo.com Wed Feb 27 22:39:07 2008 From: ka0sm0nk at yahoo.com (Miroslav Tomic) Date: Wed, 27 Feb 2008 14:39:07 -0800 (PST) Subject: [Fedora-livecd-list] liveinst won't run Message-ID: <834257.23178.qm@web51906.mail.re2.yahoo.com> Dear list members, I'm using livecd-creator for the first time, and for a test, I've used livecd-fedora-8-desktop.ks. The only thing I've changed in the kickstart file is setting the local repo and setting the different language (and not the keyboard) in livecd-fedora-8-base-desktop.ks. Everything went just fine during build. I've burnt the LiveCD.iso that I've got, tested the media and let the system boot. The first thing I've noticed are some misspelled characters during boot, which are language specific, but it's something that doesn't bother me at all. After the system has booted, I've noticed that there was no icon on the desktop that should let me install the distro. So I've ran /usr/bin/liveinst but it failed to install. The output is attached and I have no idea what could be wrong. The way I see it, it has something to do with indexes, as far as regarding the last line, stating "Index error: list index out of range"... Have looked at scripts and lines mentioned in the error output, but have not noticed anything anusual... but then again, I'm not that good at python... One more thing: I've built two Live CD's - one of them has used only packages from Everything repo (which should be the packages Fedora's LiveCD i686 is build upon) and another one was using both Everything and Updates repo's packages (so it had updated packages) - but the result was the same, giving me the same error... Any ideas where to look? Thank you in advance! Regards. ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -------------- next part -------------- A non-text attachment was scrubbed... Name: error.png Type: image/png Size: 87332 bytes Desc: pat1180589245 URL: From katzj at fedoraproject.org Wed Feb 27 22:59:44 2008 From: katzj at fedoraproject.org (Jeremy Katz) Date: Wed, 27 Feb 2008 15:59:44 -0700 Subject: [Fedora-livecd-list] imgcreate/live.py Message-ID: <200802272259.m1RMxiOs028840@hosted1.fedoraproject.org> imgcreate/live.py | 7 +++++++ 1 file changed, 7 insertions(+) New commits: commit 48a7de783beb7a28d6ed4deadbacee5aa91c6831 Author: Jeremy Katz Date: Wed Feb 27 17:59:41 2008 -0500 Remove our /etc/sysconfig/mkinitrd Leaving our /etc/sysconfig/mkinitrd around breaks later installs, so we should just remove it diff --git a/imgcreate/live.py b/imgcreate/live.py index 13dd84d..0474d59 100644 --- a/imgcreate/live.py +++ b/imgcreate/live.py @@ -177,6 +177,13 @@ class LiveImageCreatorBase(LoopImageCreator): LoopImageCreator._mount_instroot(self) self.__write_initrd_conf(self._instroot + "/etc/sysconfig/mkinitrd") + def _unmount_instroot(self): + try: + os.unlink(self._instroot + "/etc/sysconfig/mkinitrd") + except: + pass + LoopImageCreator._unmount_instroot(self) + def __ensure_isodir(self): if self.__isodir is None: self.__isodir = self._mkdtemp("iso-") From jiesun66 at yahoo.com Thu Feb 28 16:14:08 2008 From: jiesun66 at yahoo.com (jie sun) Date: Thu, 28 Feb 2008 08:14:08 -0800 (PST) Subject: [Fedora-livecd-list] livecd-creator in fc7 can't access /etc/hosts and /etc/sysconfig/network Message-ID: <720456.32547.qm@web31606.mail.mud.yahoo.com> Hi, when I put cp /etc/hosts /etc/hosts.me in %post section in my ks file and run livecd-creator --config=my ks, I always got error message saying cannot stat /etc/hosts: no such file or directory. The same for /etc/sysconfig/network file. It seems livecd-creator in fc7 can not access both /etc/hosts and /etc/sysconfig/network file. In fc8, I had no such problem. Any idea why livecd-creator in fc7 can not access /etc/hosts file? Regards, Jie ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtogami at redhat.com Thu Feb 28 18:59:21 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 28 Feb 2008 13:59:21 -0500 Subject: [Fedora-livecd-list] [PATCH] Create a minimal /dev instead of bind mounting the host's /dev Message-ID: <47C70489.2000105@redhat.com> http://fedorapeople.org/~wtogami/temp/0001-Create-a-minimal-dev-instead-of-bind-mounting-the-h.patch [PATCH] Create a minimal /dev instead of bind mounting the host's /dev This can help to avoid possible issues where the system mistakenly configures itself to things in the host system's /dev. This also removes the possibility of accidentally deleting the host's /dev. I have only tested it with chroot-creator, so you may want to test it in the Live case before committing it. Warren Togami wtogami at redhat.com From jiesun66 at yahoo.com Thu Feb 28 21:41:17 2008 From: jiesun66 at yahoo.com (jie sun) Date: Thu, 28 Feb 2008 13:41:17 -0800 (PST) Subject: [Fedora-livecd-list] liveinst failed on my own live iso Message-ID: <853215.88065.qm@web31601.mail.mud.yahoo.com> I try to run liveinst after I run livecd-creator to create a live cd iso on fc7. And I got the following errror: [root at localhost tmp]# liveinst FATAL: Module md not found. /usr/sbin/setenforce: SELinux is disabled Probing for video card: ATI Technologies Inc Rage XL Graphical installation not available... Starting text mode. Traceback (most recent call first): File "/usr/lib/anaconda/livecd.py", line 289, in doPostInstall f.close() File "/usr/lib/anaconda/backend.py", line 233, in doPostInstall anaconda.backend.doPostInstall(anaconda) File "/usr/lib/anaconda/dispatch.py", line 203, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 126, in gotoNext self.moveStep() File "/usr/lib/anaconda/text.py", line 605, in run anaconda.dispatch.gotoNext() File "/usr/sbin/anaconda", line 955, in anaconda.intf.run(anaconda) IOError: [Errno 22] Invalid argument /usr/sbin/setenforce: SELinux is disabled [root at localhost tmp]# Any idea? ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary at mlbassoc.com Fri Feb 29 09:48:53 2008 From: gary at mlbassoc.com (Gary Thomas) Date: Fri, 29 Feb 2008 02:48:53 -0700 Subject: [Fedora-livecd-list] Kickstart ignored? Message-ID: <47C7D505.6040304@mlbassoc.com> Running a system built with anaconda-11.4.0.40 (and friends), the kickstart commands seem to be ignored when run from liveinst. # liveinst --text ks=/tmp/ks.cfg or # liveinst --text ksdev=eth0 ks=nfs:192.168.1.101:/tmp/ks.cfg Am I doing something wrong? I really want to get this working so I can do [scripted] installs from a livecd image. Thanks From rjones at redhat.com Fri Feb 29 11:23:11 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 29 Feb 2008 11:23:11 +0000 Subject: [Fedora-livecd-list] 3 commits - config/livecd-fedora-8-base-desktop.ks imgcreate/live.py tools/mayflower In-Reply-To: <200802271839.m1RIdjxF021866@hosted1.fedoraproject.org> References: <200802271839.m1RIdjxF021866@hosted1.fedoraproject.org> Message-ID: <20080229112311.GA3002@amd.home.annexia.org> On Wed, Feb 27, 2008 at 11:39:45AM -0700, Jeremy Katz wrote: > tools/mayflower | 805 --------------------------------- > Remove mayflower I haven't been following this, but what replaces mayflower? Please note that the following addition to mayflower was necessary for PXE booting to work, so I want to know if this change needs to go upstream somewhere. # don't wait for "mtd0" as no device file will appear # and don't worry about this if $thingtomount is a regular file if [ "$root" != "mtd0" -a ! -f "$thingtomount" ] ; then Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From jvonau at shaw.ca Fri Feb 29 14:46:09 2008 From: jvonau at shaw.ca (Jerry Vonau) Date: Fri, 29 Feb 2008 08:46:09 -0600 Subject: [Fedora-livecd-list] Kickstart ignored? In-Reply-To: <47C7D505.6040304@mlbassoc.com> References: <47C7D505.6040304@mlbassoc.com> Message-ID: <47C81AB1.10607@shaw.ca> Gary Thomas wrote: > Running a system built with anaconda-11.4.0.40 (and friends), the > kickstart commands seem to be ignored when run from liveinst. > # liveinst --text ks=/tmp/ks.cfg > or > # liveinst --text ksdev=eth0 ks=nfs:192.168.1.101:/tmp/ks.cfg > > Am I doing something wrong? > Jeremy said that the ks file needs to be local at this point, stage1 grabs the ks file, but there is no stage1 with a cd install. > I really want to get this working so I can do [scripted] installs > from a livecd image. > > Thanks > Is the network up at this point? If not..... A work-around would be to script the grabbing of the ks file yourself and copying it /tmp. Use wget for a http/ftp source or maybe mount the nfs server and copy over the ks file. Then use something like this: liveinst --text ks=/tmp/ks.cfg Jerry From gary at mlbassoc.com Fri Feb 29 15:07:49 2008 From: gary at mlbassoc.com (Gary Thomas) Date: Fri, 29 Feb 2008 08:07:49 -0700 Subject: [Fedora-livecd-list] Kickstart ignored? In-Reply-To: <47C81AB1.10607@shaw.ca> References: <47C7D505.6040304@mlbassoc.com> <47C81AB1.10607@shaw.ca> Message-ID: <47C81FC5.9040302@mlbassoc.com> Jerry Vonau wrote: > Gary Thomas wrote: >> Running a system built with anaconda-11.4.0.40 (and friends), the >> kickstart commands seem to be ignored when run from liveinst. >> # liveinst --text ks=/tmp/ks.cfg >> or >> # liveinst --text ksdev=eth0 ks=nfs:192.168.1.101:/tmp/ks.cfg >> >> Am I doing something wrong? >> > > Jeremy said that the ks file needs to be local at this point, stage1 > grabs the ks file, but there is no stage1 with a cd install. > >> I really want to get this working so I can do [scripted] installs >> from a livecd image. >> >> Thanks >> > > Is the network up at this point? If not..... > > A work-around would be to script the grabbing of the ks file yourself > and copying it /tmp. Use wget for a http/ftp source or maybe mount the > nfs server and copy over the ks file. > > Then use something like this: > liveinst --text ks=/tmp/ks.cfg Precisely what I already did (see the first example above) From jvonau at shaw.ca Fri Feb 29 17:41:18 2008 From: jvonau at shaw.ca (Jerry Vonau) Date: Fri, 29 Feb 2008 11:41:18 -0600 Subject: [Fedora-livecd-list] Kickstart ignored? In-Reply-To: <47C81FC5.9040302@mlbassoc.com> References: <47C7D505.6040304@mlbassoc.com> <47C81AB1.10607@shaw.ca> <47C81FC5.9040302@mlbassoc.com> Message-ID: <47C843BE.1030308@shaw.ca> Gary Thomas wrote: > Jerry Vonau wrote: >> Gary Thomas wrote: >>> Running a system built with anaconda-11.4.0.40 (and friends), the >>> kickstart commands seem to be ignored when run from liveinst. >>> # liveinst --text ks=/tmp/ks.cfg >>> or >>> # liveinst --text ksdev=eth0 ks=nfs:192.168.1.101:/tmp/ks.cfg >>> >>> Am I doing something wrong? >>> >> >> Jeremy said that the ks file needs to be local at this point, stage1 >> grabs the ks file, but there is no stage1 with a cd install. >> >>> I really want to get this working so I can do [scripted] installs >>> from a livecd image. >>> >>> Thanks >>> >> >> Is the network up at this point? If not..... >> >> A work-around would be to script the grabbing of the ks file yourself >> and copying it /tmp. Use wget for a http/ftp source or maybe mount the >> nfs server and copy over the ks file. >> >> Then use something like this: >> liveinst --text ks=/tmp/ks.cfg > > Precisely what I already did (see the first example above) Just so I'm clear here, you burned the iso with this file in /tmp? Looking through /usr/sbin/anaconda I see: op.add_option("--kickstart", dest="ksfile") but no --ks= so I don't think anaconda is using the ks file. Perhaps "liveinst --text --kickstart=/tmp/ks.cfg" would do the trick here. That is setup in the livecd ks file, which would need to be edited: if strstr "\`cat /proc/cmdline\`" liveinst ; then /usr/sbin/liveinst --kickstart=\$ks fi if strstr "\`cat /proc/cmdline\`" textinst ; then /usr/sbin/liveinst --text --kickstart=\$ks fi Hoping I'm on the right track, Jerry From gary at mlbassoc.com Fri Feb 29 17:56:06 2008 From: gary at mlbassoc.com (Gary Thomas) Date: Fri, 29 Feb 2008 10:56:06 -0700 Subject: [Fedora-livecd-list] Kickstart ignored? In-Reply-To: <47C843BE.1030308@shaw.ca> References: <47C7D505.6040304@mlbassoc.com> <47C81AB1.10607@shaw.ca> <47C81FC5.9040302@mlbassoc.com> <47C843BE.1030308@shaw.ca> Message-ID: <47C84736.9030000@mlbassoc.com> Jerry Vonau wrote: > Gary Thomas wrote: >> Jerry Vonau wrote: >>> Gary Thomas wrote: >>>> Running a system built with anaconda-11.4.0.40 (and friends), the >>>> kickstart commands seem to be ignored when run from liveinst. >>>> # liveinst --text ks=/tmp/ks.cfg >>>> or >>>> # liveinst --text ksdev=eth0 ks=nfs:192.168.1.101:/tmp/ks.cfg >>>> >>>> Am I doing something wrong? >>>> >>> >>> Jeremy said that the ks file needs to be local at this point, stage1 >>> grabs the ks file, but there is no stage1 with a cd install. >>> >>>> I really want to get this working so I can do [scripted] installs >>>> from a livecd image. >>>> >>>> Thanks >>>> >>> >>> Is the network up at this point? If not..... >>> >>> A work-around would be to script the grabbing of the ks file yourself >>> and copying it /tmp. Use wget for a http/ftp source or maybe mount >>> the nfs server and copy over the ks file. >>> >>> Then use something like this: >>> liveinst --text ks=/tmp/ks.cfg >> >> Precisely what I already did (see the first example above) > > Just so I'm clear here, you burned the iso with this file in /tmp? No, I downloaded the kickstart file into /tmp after the livecd was booted, but before I called liveinst. > Looking through /usr/sbin/anaconda I see: > op.add_option("--kickstart", dest="ksfile") > but no --ks= so I don't think anaconda is using the ks file. > > Perhaps "liveinst --text --kickstart=/tmp/ks.cfg" would do the trick > here. That is setup in the livecd ks file, which would need to be edited: > > if strstr "\`cat /proc/cmdline\`" liveinst ; then > /usr/sbin/liveinst --kickstart=\$ks > fi > > if strstr "\`cat /proc/cmdline\`" textinst ; then > /usr/sbin/liveinst --text --kickstart=\$ks > fi > > Hoping I'm on the right track, Thanks - I'll look more closely at how these options are passed around.