On Wed, 2009-12-02 at 14:38 -0500, Doug Ledford wrote:
> So, I'd like to be able to test mdadm changes before checking them into
> CVS and building them in rawhide. To do that, I'd like to be able to
> spin a rescue CD from my local rawhide mirror and boot into it on my
> test box. Can someone tell me, in very simple terms a kernel engineer
> can understand ;-), how I go about creating my own rescue CD images?
>
> (Please keep me on the Cc: since I'm not subbed to the list, thanks)

1) get a box fully updated to rawhide
2) yum install pungi fedora-kickstarts
2) (as root) pungi -c /usr/share/spin-kickstarts/fedora-install-fedora.ks --destdir=/path/ --nosource --nodebuginfo -GCB

This assumes that /var/cache/pungi/ has enough space to store 4~ gigs of
rpms, and that your destdir is the same filesystem so hardlinks can be
made from the cache (or else you'll need an additional 4~ gigs of
storage in your destpath).

-GCB is Gather (download the packages), Createrepo (obvious),
Buildinstall (make the install images, including boot.iso (there is no
more rescue image, boot.iso has stage1 and stage2)).

You can edit the fedora-install-fedora file to taste, defining local
mirrors or reducing the package set.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

On 12/02/2009 02:38 PM, Doug Ledford wrote:
> So, I'd like to be able to test mdadm changes before checking them into
> CVS and building them in rawhide. To do that, I'd like to be able to
> spin a rescue CD from my local rawhide mirror and boot into it on my
> test box. Can someone tell me, in very simple terms a kernel engineer
> can understand ;-), how I go about creating my own rescue CD images?
>
> (Please keep me on the Cc: since I'm not subbed to the list, thanks)

So, to not answer your question , a better thing to do here is probably
for us to make sure that wherever we're calling mdadm checks
/tmp/updates correctly (there appear to be a couple of places that
don't do this right now) and then for you to make an updates image[1]
with the new mdadm in it, and specify a url to the image on the command
line.

[1]: (cd /sbin ; echo mdadm | cpio -H newc --quiet -o)| gzip -9 > updates.img

--
Peter

I'd like to start a religion. That's where the money is.
-- L. Ron Hubbard to Lloyd Eshbach, in 1949;
quoted by Eshbach in _Over My Shoulder_.

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

> > So, I'd like to be able to test mdadm changes before checking them into
> > CVS and building them in rawhide. To do that, I'd like to be able to
> > spin a rescue CD from my local rawhide mirror and boot into it on my
> > test box. Can someone tell me, in very simple terms a kernel engineer
> > can understand ;-), how I go about creating my own rescue CD images?
> >
> > (Please keep me on the Cc: since I'm not subbed to the list, thanks)
>
> So, to not answer your question , a better thing to do here is probably
> for us to make sure that wherever we're calling mdadm checks
> /tmp/updates correctly (there appear to be a couple of places that
> don't do this right now) and then for you to make an updates image[1]
> with the new mdadm in it, and specify a url to the image on the command
> line.

mdadm (and a bunch of other programs) is run by
iutil.execWithPulseProgress, which appears to be using os.execvp, which
in turn uses $PATH to find the command. /tmp/updates should be in the
$PATH due to loader putting it there. Sounds like as long as the new
mdadm is in /tmp/updates, everything is already in place.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

On 12/02/2009 05:12 PM, Chris Lumens wrote:
>>> So, I'd like to be able to test mdadm changes before checking them into
>>> CVS and building them in rawhide. To do that, I'd like to be able to
>>> spin a rescue CD from my local rawhide mirror and boot into it on my
>>> test box. Can someone tell me, in very simple terms a kernel engineer
>>> can understand ;-), how I go about creating my own rescue CD images?
>>>
>>> (Please keep me on the Cc: since I'm not subbed to the list, thanks)
>>
>> So, to not answer your question , a better thing to do here is probably
>> for us to make sure that wherever we're calling mdadm checks
>> /tmp/updates correctly (there appear to be a couple of places that
>> don't do this right now) and then for you to make an updates image[1]
>> with the new mdadm in it, and specify a url to the image on the command
>> line.
>
> mdadm (and a bunch of other programs) is run by
> iutil.execWithPulseProgress, which appears to be using os.execvp, which
> in turn uses $PATH to find the command. /tmp/updates should be in the
> $PATH due to loader putting it there. Sounds like as long as the new
> mdadm is in /tmp/updates, everything is already in place.

I was more thinking of:

pjones4:~/devel/hosted.fp.o/anaconda$ git grep '/mdadm' .
70-anaconda.rules:IMPORT{program}="$env{ANACBIN}/mdadm --detail --export $tempnode"
70-anaconda.rules:ENV{ID_FS_TYPE}=="linux_raid_member ", IMPORT{program}="$env{ANACBIN}/mdadm --examine --export $tempnode"
70-anaconda.rules:ENV{ID_FS_TYPE}=="isw_raid_member", IMPORT{program}="$env{ANACBIN}/mdadm --examine --export $tempnode"
loader/shutdown.c: ignore = system("/sbin/mdadm --wait-clean --scan");

(lots of other stuff trimmed)
--
Peter

I'd like to start a religion. That's where the money is.
-- L. Ron Hubbard to Lloyd Eshbach, in 1949;
quoted by Eshbach in _Over My Shoulder_.

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

On 12/02/2009 05:13 PM, Peter Jones wrote:

> I was more thinking of:
>
> pjones4:~/devel/hosted.fp.o/anaconda$ git grep '/mdadm' .
> 70-anaconda.rules:IMPORT{program}="$env{ANACBIN}/mdadm --detail --export $tempnode"
> 70-anaconda.rules:ENV{ID_FS_TYPE}=="linux_raid_member ", IMPORT{program}="$env{ANACBIN}/mdadm --examine --export $tempnode"
> 70-anaconda.rules:ENV{ID_FS_TYPE}=="isw_raid_member", IMPORT{program}="$env{ANACBIN}/mdadm --examine --export $tempnode"
> loader/shutdown.c: ignore = system("/sbin/mdadm --wait-clean --scan");
>
> (lots of other stuff trimmed)

Of course, on further consideration an updates image won't work with these
three examples anyway.
--
Peter

I'd like to start a religion. That's where the money is.
-- L. Ron Hubbard to Lloyd Eshbach, in 1949;
quoted by Eshbach in _Over My Shoulder_.

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

On 12/02/2009 12:01 PM, Jesse Keating wrote:

On Wed, 2009-12-02 at 14:38 -0500, Doug Ledford wrote:

So, I'd like to be able to test mdadm changes before checking them into
CVS and building them in rawhide. To do that, I'd like to be able to
spin a rescue CD from my local rawhide mirror and boot into it on my
test box. Can someone tell me, in very simple terms a kernel engineer
can understand ;-), how I go about creating my own rescue CD images?

(Please keep me on the Cc: since I'm not subbed to the list, thanks)


1) get a box fully updated to rawhide
2) yum install pungi fedora-kickstarts
2) (as root) pungi -c /usr/share/spin-kickstarts/fedora-install-fedora.ks --destdir=/path/ --nosource --nodebuginfo -GCB

This assumes that /var/cache/pungi/ has enough space to store 4~ gigs of
rpms, and that your destdir is the same filesystem so hardlinks can be
made from the cache (or else you'll need an additional 4~ gigs of
storage in your destpath).


As a step-by-step, I find that recipe (using F12 pungi) to be unreliable.
Selinux *must* be non-enforcing at pungi time, else pungi produces images
with non-functional selinux. [The fundamental problem is that selinux
is not virtualizable.]

Furthermore, that recipe fails the second time because certain parts
of the recipe don't check for conflicts with old or conflicting files
in some directories. The recipe also fails if /tmp is too small,
and forgets some nice labels on the .isos.

I find that something such as this is necessary in order to get
reliable, fully-functional output from pungi:
-----
VERSION=12
DESTDIR=/disk-with-12GB-free-space/Fedora$VERSION
ARCH=x86_64

rm -rf $DESTDIR/work/$ARCH
rm -rf $DESTDIR/$VERSION/$ARCH

mkdir -p $DESTDIR/work/$ARCH/tmp
export TMPDIR=$DESTDIR/work/$ARCH/tmp

/usr/sbin/setenforce 0

pungi -c /usr/share/.../...-fedora.ks --destdir=$DESTDIR --name Fedora
--ver $VERSION --nosource --nodebuginfo -GCB
-----

--

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list