First experience with F18-ALPHA-TC1

[Joachim Backes]

Hi Testers,

I downloaded the install ISO of F18-ALPHA-TC1-x86_64 from

http://dl.fedoraproject.org/pub/alt/stage/18-Alpha-TC1/.

If booting the burned DVD with "Installation", after some seconds the
installation stops with "/dev/root does not exist". I did this inside
VirtualBox, but same results if booting my real machine with the DVD.

MoBo: Asrock ConRoe1333-DVI/H, 4 MB memory.

The VirtualBox boot window (tty.jpg) and the tail of the jounalctl
output (journalctl.jpg) have been attached.

Kind regards

Joachim Backes <joachim.backes(a)rhrk.uni-kl.de&gt;

https://www-user.rhrk.uni-kl.de/~backes

[A.J. Werkman`]

Hi,

Exactly the same here. No difference in screen output too. Only I used 
i386 on bare metal.


Koos.

Op 13-8-2012 11:59, Joachim Backes schreef:
>  Hi Testers,
>
>  I downloaded the install ISO of F18-ALPHA-TC1-x86_64 from
>
>  http://dl.fedoraproject.org/pub/alt/stage/18-Alpha-TC1/.
>
>  If booting the burned DVD with "Installation", after some seconds the
>  installation stops with "/dev/root does not exist". I did this inside
>  VirtualBox, but same results if booting my real machine with the DVD.
>
>  MoBo: Asrock ConRoe1333-DVI/H, 4 MB memory.
>
>  The VirtualBox boot window (tty.jpg) and the tail of the jounalctl
>  output (journalctl.jpg) have been attached.
>
>  Kind regards
>
>  Joachim Backes <joachim.backes(a)rhrk.uni-kl.de&gt;
>
>  https://www-user.rhrk.uni-kl.de/~backes
>
>  
Op 13-8-2012 11:59, Joachim Backes schreef:
>  Hi Testers,
>
>  I downloaded the install ISO of F18-ALPHA-TC1-x86_64 from
>
>  http://dl.fedoraproject.org/pub/alt/stage/18-Alpha-TC1/.
>
>  If booting the burned DVD with "Installation", after some seconds the
>  installation stops with "/dev/root does not exist". I did this inside
>  VirtualBox, but same results if booting my real machine with the DVD.
>
>  MoBo: Asrock ConRoe1333-DVI/H, 4 MB memory.
>
>  The VirtualBox boot window (tty.jpg) and the tail of the jounalctl
>  output (journalctl.jpg) have been attached.
>
>  Kind regards
>
>  Joachim Backes <joachim.backes(a)rhrk.uni-kl.de&gt;
>
>  https://www-user.rhrk.uni-kl.de/~backes
>
>

[Vadim Rutkovsky]

Hi,

This bug has been filed as
https://bugzilla.redhat.com/show_bug.cgi?id=847644

В Пн., 13/08/2012 в 12:55 +0200, A.J. Werkman пишет:
>  Hi,
>  
>  Exactly the same here. No difference in screen output too. Only I used
>  i386 on bare metal.
>  
>  
>  Koos.
>  
>  Op 13-8-2012 11:59, Joachim Backes schreef:
>  
>  > Hi Testers,
>  > 
>  > I downloaded the install ISO of F18-ALPHA-TC1-x86_64 from
>  > 
>  > http://dl.fedoraproject.org/pub/alt/stage/18-Alpha-TC1/.
>  > 
>  > If booting the burned DVD with "Installation", after some seconds the
>  > installation stops with "/dev/root does not exist". I did this inside
>  > VirtualBox, but same results if booting my real machine with the DVD.
>  > 
>  > MoBo: Asrock ConRoe1333-DVI/H, 4 MB memory.
>  > 
>  > The VirtualBox boot window (tty.jpg) and the tail of the jounalctl
>  > output (journalctl.jpg) have been attached.
>  > 
>  > Kind regards
>  > 
>  > Joachim Backes <joachim.backes(a)rhrk.uni-kl.de&gt;
>  > 
>  > https://www-user.rhrk.uni-kl.de/~backes
>  > 
>  > 
>  
>  Op 13-8-2012 11:59, Joachim Backes schreef:
>  
>  > Hi Testers,
>  > 
>  > I downloaded the install ISO of F18-ALPHA-TC1-x86_64 from
>  > 
>  > http://dl.fedoraproject.org/pub/alt/stage/18-Alpha-TC1/.
>  > 
>  > If booting the burned DVD with "Installation", after some seconds the
>  > installation stops with "/dev/root does not exist". I did this inside
>  > VirtualBox, but same results if booting my real machine with the DVD.
>  > 
>  > MoBo: Asrock ConRoe1333-DVI/H, 4 MB memory.
>  > 
>  > The VirtualBox boot window (tty.jpg) and the tail of the jounalctl
>  > output (journalctl.jpg) have been attached.
>  > 
>  > Kind regards
>  > 
>  > Joachim Backes <joachim.backes(a)rhrk.uni-kl.de&gt;
>  > 
>  > https://www-user.rhrk.uni-kl.de/~backes
>  > 
>  > 
>

[Petr Schindler]

Hi,

there is missing root parameter on boot line. If you add
'root=live:CDLABEL=Fedora\x2018-Alpha-TC1\x20x86_64' to boot line, you
will be able to boot. But it won't help you much, there is a problem
within anaconda, which should be fixed, so this TC is not working.

On Po, 2012-08-13 at 14:18 +0300, Vadim Rutkovsky wrote:
>  Hi,
>  
>  This bug has been filed as
>  https://bugzilla.redhat.com/show_bug.cgi?id=847644
>  
>  В Пн., 13/08/2012 в 12:55 +0200, A.J. Werkman пишет:
>  > Hi,
>  > 
>  > Exactly the same here. No difference in screen output too. Only I used
>  > i386 on bare metal.
>  > 
>  > 
>  > Koos.
>  > 
>  > Op 13-8-2012 11:59, Joachim Backes schreef:
>  > 
>  > > Hi Testers,
>  > > 
>  > > I downloaded the install ISO of F18-ALPHA-TC1-x86_64 from
>  > > 
>  > > http://dl.fedoraproject.org/pub/alt/stage/18-Alpha-TC1/.
>  > > 
>  > > If booting the burned DVD with "Installation", after some seconds
> the
>  > > installation stops with "/dev/root does not exist". I did this
> inside
>  > > VirtualBox, but same results if booting my real machine with the DVD.
>  > > 
>  > > MoBo: Asrock ConRoe1333-DVI/H, 4 MB memory.
>  > > 
>  > > The VirtualBox boot window (tty.jpg) and the tail of the jounalctl
>  > > output (journalctl.jpg) have been attached.
>  > > 
>  > > Kind regards
>  > > 
>  > > Joachim Backes <joachim.backes(a)rhrk.uni-kl.de&gt;
>  > > 
>  > > https://www-user.rhrk.uni-kl.de/~backes
>  > > 
>  > > 
>  > 
>  > Op 13-8-2012 11:59, Joachim Backes schreef:
>  > 
>  > > Hi Testers,
>  > > 
>  > > I downloaded the install ISO of F18-ALPHA-TC1-x86_64 from
>  > > 
>  > > http://dl.fedoraproject.org/pub/alt/stage/18-Alpha-TC1/.
>  > > 
>  > > If booting the burned DVD with "Installation", after some seconds
> the
>  > > installation stops with "/dev/root does not exist". I did this
> inside
>  > > VirtualBox, but same results if booting my real machine with the DVD.
>  > > 
>  > > MoBo: Asrock ConRoe1333-DVI/H, 4 MB memory.
>  > > 
>  > > The VirtualBox boot window (tty.jpg) and the tail of the jounalctl
>  > > output (journalctl.jpg) have been attached.
>  > > 
>  > > Kind regards
>  > > 
>  > > Joachim Backes <joachim.backes(a)rhrk.uni-kl.de&gt;
>  > > 
>  > > https://www-user.rhrk.uni-kl.de/~backes
>  > > 
>  > > 
>  > 
>

[Chris Lumens]

>  But it won't help you much, there is a problem
>  within anaconda, which should be fixed, so this TC is not working. 
And it certainly won't be fixed if you don't tell us what the problem
is.

- Chris

[Vadim Rutkovsky]

Hi Chris,

Not sure if I've supplied enough information as most of the files listed on
"How to debug installation problems" wiki page are missing, but here is
what I've got:

1) Installation end up with a screen -
http://ompldr.org/vZjNhdw/QEMU_001.png

2) # anaconda
Traceback (most recent call last):
  File "/sbin/anaconda", line 34, in <module>
    from tempfile import mkstemp
  File "/usr/lib64/python2.7/tempfile.py", line 34, in <module>
    from random import Random as _Random
  File "/usr/lib64/python2.7/random.py", line 49, in <module>
    import hashlib as _hashlib
  File "/usr/lib64/python2.7/hashlib.py", line 110, in <module>
    import _hashlib
ImportError: libgssapi_krb5.so.2: cannot open shared object file: No such
file or directory

3) Contents of /tmp/syslog - http://fpaste.org/ZJtN/

No other files were created in /tmp

Feel free to request more information.

2012/8/13 Chris Lumens <clumens(a)redhat.com&gt;

>  > But it won't help you much, there is a problem
>  > within anaconda, which should be fixed, so this TC is not working.
>
>  And it certainly won't be fixed if you don't tell us what the problem
>  is.
>
>  - Chris
>  --
>  test mailing list
>  test(a)lists.fedoraproject.org
>  To unsubscribe:
>  https://admin.fedoraproject.org/mailman/listinfo/test
>  


-- 
Vadim Rutkovsky

[Chris Lumens]

>  1) Installation end up with a screen -
>  http://ompldr.org/vZjNhdw/QEMU_001.png 
Okay, this is hiding the real error message.  I've got a fix for it
committed and I'll be doing another build for f18-branch later today.

>  2) # anaconda
>  Traceback (most recent call last):
>    File "/sbin/anaconda", line 34, in <module>
>      from tempfile import mkstemp
>    File "/usr/lib64/python2.7/tempfile.py", line 34, in <module>
>      from random import Random as _Random
>    File "/usr/lib64/python2.7/random.py", line 49, in <module>
>      import hashlib as _hashlib
>    File "/usr/lib64/python2.7/hashlib.py", line 110, in <module>
>      import _hashlib
>  ImportError: libgssapi_krb5.so.2: cannot open shared object file: No such
>  file or directory 
Huh, I've not seen that in any of the images I've built.  I'll take a
look later and see if anything stands out.

- Chris

[Chuck Forsberg WA7KGX]

What is Fedora coming to when a release candidate
install won't even pass go?

-- 
Chuck Forsberg WA7KGX N2469R     caf(a)omen.com   www.omen.com
Developer of Industrial ZMODEM(Tm) for Embedded Applications
   Omen Technology Inc      "The High Reliability Software"
10255 NW Old Cornelius Pass Portland OR 97231   503-614-0430

[Kevin Fenzi]

On Mon, 13 Aug 2012 12:10:14 -0700
Chuck Forsberg WA7KGX N2469R <caf(a)omen.com&gt; wrote:

>  What is Fedora coming to when a release candidate
>  install won't even pass go? 
I don't guess we will know yet, since this is a "TC" , ie "Test
candidate". 

It's doing it's job just fine, pointing out things that need to be
fixed very soon before RC's are made. 

kevin

[Adam Williamson]

On 2012-08-13 12:10, Chuck Forsberg WA7KGX N2469R wrote:
>  What is Fedora coming to when a release candidate
>  install won't even pass go? 
It is not, in any sense, a release candidate.

It is a test compose of the Alpha. Alpha comes before Beta which comes 
before Final. For each of Alpha, Beta and Final, we do test composes and 
then release candidates. The first test compose of the Alpha is by 
definition the earliest and most likely-to-be-broken non-automated 
compose we ever create for a given release.

What are Chucks coming to when they can't even tell a test compose from 
a release candidate? ;)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Adam Jackson]

On 8/13/12 10:33 PM, Adam Williamson wrote:

>  It is a test compose of the Alpha. Alpha comes before Beta which
> comes
>  before Final. For each of Alpha, Beta and Final, we do test composes and
>  then release candidates. The first test compose of the Alpha is by
>  definition the earliest and most likely-to-be-broken non-automated
>  compose we ever create for a given release. 
In fairness, many projects choose not to abuse nomenclature like this. 
Seeing announce messages saying ALPHA HAS GONE GOLD makes my skin crawl, 
too.  Alphas are not gold anything.

It would be far more honest to just call this alpha 1.

- ajax

[Josh Boyer]

On Tue, Aug 14, 2012 at 8:21 AM, Adam Jackson <ajax(a)redhat.com&gt; wrote:
>  On 8/13/12 10:33 PM, Adam Williamson wrote:
>
> > It is a test compose of the Alpha. Alpha comes before Beta which comes
> > before Final. For each of Alpha, Beta and Final, we do test composes and
> > then release candidates. The first test compose of the Alpha is by
> > definition the earliest and most likely-to-be-broken non-automated
> > compose we ever create for a given release.
>
>
>  In fairness, many projects choose not to abuse nomenclature like this.
>  Seeing announce messages saying ALPHA HAS GONE GOLD makes my skin crawl,
>  too.  Alphas are not gold anything.
>
>  It would be far more honest to just call this alpha 1. 
fwiw, I agree.

josh

[Adam Williamson]

On 2012-08-14 5:26, Josh Boyer wrote:
>  On Tue, Aug 14, 2012 at 8:21 AM, Adam Jackson <ajax(a)redhat.com&gt;
>
>  wrote:
> > On 8/13/12 10:33 PM, Adam Williamson wrote:
> >
> >> It is a test compose of the Alpha. Alpha comes before Beta which 
> >> comes
> >> before Final. For each of Alpha, Beta and Final, we do test 
> >> composes and
> >> then release candidates. The first test compose of the Alpha is by
> >> definition the earliest and most likely-to-be-broken non-automated
> >> compose we ever create for a given release.
> >
> >
> > In fairness, many projects choose not to abuse nomenclature like 
> > this.
> > Seeing announce messages saying ALPHA HAS GONE GOLD makes my skin 
> > crawl,
> > too.  Alphas are not gold anything.
> >
> > It would be far more honest to just call this alpha 1.
>
>  fwiw, I agree. 
We've discussed various ways to re-jig the structure in the past, but 
something that simplistic certainly isn't it. We have specific 
requirements for the Alpha, Beta and Final releases: they _must_ meet 
those requirements in order to be shipped. The TCs and RCs are 
absolutely not intended to be general test images (though they sometimes 
get abused in that way), they exist for the specific purpose of doing 
validation testing to ensure the 'official' Alpha, Beta and Final 
releases meet the requirements. Note that for a long time, the TCs and 
RCs were not distributed outside the RH VPN, partly to avoid this kind 
of confusion. I think it's correct that we now _do_ distribute them 
publicly, but note that we do not use the full Fedora mirror structure 
for this and we do not make a proper press announcement of them: they 
are officially announced _only_ on this list, and the announcement mail 
makes it very clear that they exist for the specific purpose of doing 
validation testing.

I think we actually have a very strong process in place here, which is 
clearly defined and achieves useful goals: you can go look up the Alpha, 
Beta and Final release criteria - call them 'release definitions' if you 
like - and know with reasonable certainty that you're getting the 
functionality described there, at a minimum, when you download a Fedora 
Alpha, Beta or Final release. If we just slapped 'Alpha X' names on the 
TCs and shipped them, you'd be in a much more uncertain state. F18 Alpha 
TC1 is actually an excellent example of this: it does not boot at all, 
and even if you hack the kernel command line to make it boot, anaconda 
fails to initialize and there is absolutely no way you can hack around 
that. In other words, Alpha TC1 is functionally useless, it is DOA. I 
can see no possible benefit to the project in shipping out such an image 
to the general public with an 'Alpha 1' label on it, it would do nothing 
but harm to Fedora.

We _need_ to generate such DOA images: we wouldn't know if a Fedora 
image composed from the F18 tree of yesterday would be bootable and 
installable unless we _generate such an image and try it out_. By the 
principles of Fedora, such test images should be made openly available 
to the Fedora QA community, not just to Red Hat staff. But it doesn't 
serve the interests of the wider public to have such test images pushed 
out as if they were 'proper' pre-releases. They really aren't. They're 
test builds.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Adam Jackson]

On 8/15/12 2:40 AM, Adam Williamson wrote:

>  We've discussed various ways to re-jig the structure in the past,
> but
>  something that simplistic certainly isn't it. We have specific
>  requirements for the Alpha, Beta and Final releases: they _must_ meet
>  those requirements in order to be shipped. 
I was not saying the requirements were broken.  I was saying the naming 
was broken.

- ajax

[Jaroslav Reznik]

----- Original Message -----
>  On 8/13/12 10:33 PM, Adam Williamson wrote:
>  
>  > It is a test compose of the Alpha. Alpha comes before Beta which
>  > comes
>  > before Final. For each of Alpha, Beta and Final, we do test
>  > composes and
>  > then release candidates. The first test compose of the Alpha is by
>  > definition the earliest and most likely-to-be-broken non-automated
>  > compose we ever create for a given release.
>  
>  In fairness, many projects choose not to abuse nomenclature like
>  this.
>  Seeing announce messages saying ALPHA HAS GONE GOLD makes my skin
>  crawl,
>  too.  Alphas are not gold anything.
>  
>  It would be far more honest to just call this alpha 1. 
Sorry, I don't get it - is the problem calling Alpha gold, as it's
definitely not gold final release. What's the difference between
Alpha and Alpha 1? You mean TCX should be Alpha X (and RC, "final"
Alpha?). It was already stated that TCs are not for general public,
so in this case it would be non-sense to release Alpha XYZ :)

R.

>  - ajax
>  
>  --
>  test mailing list
>  test(a)lists.fedoraproject.org
>  To unsubscribe:
>  https://admin.fedoraproject.org/mailman/listinfo/test

[Adam Jackson]

On 8/15/12 9:42 AM, Jaroslav Reznik wrote:

> > It would be far more honest to just call this alpha 1.
>
>  Sorry, I don't get it - is the problem calling Alpha gold, as it's
>  definitely not gold final release. 
Calling alpha "gold" is a problem, sure.

Calling test composes something with "alpha" in the name is also a problem.

OLPC's "Atest" "Btest" pattern was fairly nice for this.

- ajax

[Chris Murphy]

On Aug 15, 2012, at 9:09 AM, Adam Jackson wrote:
>  
>  Calling test composes something with "alpha" in the name is also a problem.
The word "alpha" describes the test compose because TC1 by itself could apply to
either the pre-alpha, pre-beta, or pre-final releases. So if alpha isn't used as a
descriptor, then you need to come up with something equally unambiguous to replace the
current naming scheme, which I find unambiguous.

Are you proposing something like:

ATest1, ATest2, ATest3, and then once alpha release criteria are met, the last test is
renamed to Alpha? And likewise there would be BTest1, BTest2, BTest3, and the last one,
which meats beta release criteria, it is renamed to Beta?

*shrug* OK. I am however confused on the distinction between TC's and RC's.

Chris Murphy

[Bruno Wolff III]

On Wed, Aug 15, 2012 at 11:20:43 -0600,
   Chris Murphy <lists(a)colorremedies.com&gt; wrote:
> *shrug* OK. I am however confused on the distinction between TC's and RC's.
TCs can be built when there are still blockers. In theory we shouldn't even 
be trying to compose RCs without believing all blockers are resolved.

I think TCs have been less advertised than RCs in the past. Though recently 
it seems they are geting announced pretty similarly. (Though probably less 
people look at TCs.)

[Adam Williamson]

On Wed, 2012-08-15 at 11:20 -0600, Chris Murphy wrote:
>  On Aug 15, 2012, at 9:09 AM, Adam Jackson wrote:
>  > 
>  > Calling test composes something with "alpha" in the name is also a
> problem.
>  
>  The word "alpha" describes the test compose because TC1 by itself could apply
> to either the pre-alpha, pre-beta, or pre-final releases. So if alpha isn't used as a
> descriptor, then you need to come up with something equally unambiguous to replace the
> current naming scheme, which I find unambiguous.
>  
>  Are you proposing something like:
>  
>  ATest1, ATest2, ATest3, and then once alpha release criteria are met, the last test is
> renamed to Alpha? And likewise there would be BTest1, BTest2, BTest3, and the last one,
> which meats beta release criteria, it is renamed to Beta?
>  
>  *shrug* OK. I am however confused on the distinction between TC's and RC's.
The difference is described in the candidate build request SOP:

https://fedoraproject.org/wiki/QA:SOP_compose_request

"A test compose is defined as a set of Fedora images built, from the
current Branched tree, shortly prior to the Change Deadline (freeze) for
one of the three Fedora release phases (Alpha, Beta and Final), for the
purposes of performing release validation testing. It differs from a
release candidate in that it is built before, not after, the Change
Deadline and hence there is no possibility of its being declared gold
and released as the Alpha, Beta or Final release."

"A release candidate is defined as a set of Fedora images built, from
the current Branched tree, after the Change Deadline (freeze) for one of
the three Fedora release phases (Alpha, Beta and Final) and using a
package set which is not known to contain any blocker bugs, for the
purposes of performing release validation testing. It differs from a
test compose in that it is built after the Change Deadline and may be
declared gold and released as the Alpha, Beta or Final release if it
passes all validation tests."

So, this actually brings up a problem with the general idea of adjusting
the TC/RC naming process; we could really name TCs whatever the hell we
like, but that doesn't apply to RCs. Fedora RCs are true 'release
candidates': they are built precisely as if they were going to be the
actual released image. RC images don't have Alpha-RC1 or Alpha-RC2 or
Beta-RC3 or whatever in their filenames and so on: they just say 'Alpha'
or 'Beta'. When one of the builds passes validation we simply declare
that build to be the official build and release it as-is: the build
itself does not get changed in any way, we don't have to do a new
'proper' build from the same base or rename any files, we literally take
the 'approved RC' images and release them.

There are obviously good reasons for doing things this way - it's the
most foolproof system for ensuring that what we actually release,
actually works, because what we actually release is precisely what we
tested. Not a rebuild, not a rename, the precise same thing.

We could refer to them as something different in discussion and
announcement emails, I guess, but the thing is...they really _are_
release candidates. This is precisely the right name for them. I'm not
sure any other name actually makes sense. Though if anyone has a smart
idea, please...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Scott Poore]

----- Original Message -----
>  From: "Petr Schindler" <pschindl(a)redhat.com&gt;
>  To: test(a)lists.fedoraproject.org
>  Sent: Monday, August 13, 2012 6:42:16 AM
>  Subject: Re: First experience with F18-ALPHA-TC1
>  
>  Hi,
>  
>  there is missing root parameter on boot line. If you add
>  'root=live:CDLABEL=Fedora\x2018-Alpha-TC1\x20x86_64' to boot line,
>  you
>  will be able to boot. But it won't help you much, there is a problem
>  within anaconda, which should be fixed, so this TC is not working.
>   
Petr, Or anyone that can help,

Should the root= parameter work from a virt-install kickstart as well?  

virt-install --connect=qemu:///system \
--network=bridge:virbr0 \
--initrd-inject=./fed.ks \
--extra-args="root=live:CDLABEL=Fedora\x2018-Alpha-TC1\x20x86_64 ks=file:/fed.ks
console=tty0 console=ttyS0,115200 serial" \
--name=f18 \
--disk path=/data/VirtualMachines/f18.img,format=qcow2 \
--ram 1024 \
--vcpus=1 \
--check-cpu \
--hvm \
--location=/data/isos/F18TC1_x86_64.iso \
--nographics

I realize that won't resolve the anaconda issue that's being fixed but,
shouldn't this get past the issue mounting the root filesystem?  Or, am I missing
something?

Thanks,
Scott

[Brian C. Lane]

On Mon, Aug 13, 2012 at 01:19:18PM -0400, Scott Poore wrote:
>  ----- Original Message -----
>  > From: "Petr Schindler" <pschindl(a)redhat.com&gt;
>  > To: test(a)lists.fedoraproject.org
>  > Sent: Monday, August 13, 2012 6:42:16 AM
>  > Subject: Re: First experience with F18-ALPHA-TC1
>  > 
>  > Hi,
>  > 
>  > there is missing root parameter on boot line. If you add
>  > 'root=live:CDLABEL=Fedora\x2018-Alpha-TC1\x20x86_64' to boot line,
>  > you
>  > will be able to boot. But it won't help you much, there is a problem
>  > within anaconda, which should be fixed, so this TC is not working.
>  > 
>  
>  Petr, Or anyone that can help,
>  
>  Should the root= parameter work from a virt-install kickstart as well?  
>  
>  virt-install --connect=qemu:///system \
>  --network=bridge:virbr0 \
>  --initrd-inject=./fed.ks \
>  --extra-args="root=live:CDLABEL=Fedora\x2018-Alpha-TC1\x20x86_64 ks=file:/fed.ks
> console=tty0 console=ttyS0,115200 serial" \
>  --name=f18 \
>  --disk path=/data/VirtualMachines/f18.img,format=qcow2 \
>  --ram 1024 \
>  --vcpus=1 \
>  --check-cpu \
>  --hvm \
>  --location=/data/isos/F18TC1_x86_64.iso \
>  --nographics
>  
>  I realize that won't resolve the anaconda issue that's being fixed but,
> shouldn't this get past the issue mounting the root filesystem?  Or, am I missing
> something? 
root= really shouldn't be needed, anaconda-dracut is supposed to sort
that out on media boots.

What you have above isn't booting from the iso though, it uses the
vmlinuz and initrd (that's what --location does), so you also need to
mount the iso using --cdrom

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

First experience with F18-ALPHA-TC1 (virt-install help)

[Scott Poore]

----- Original Message -----
>  From: "Brian C. Lane" <bcl(a)redhat.com&gt;
>  
>  root= really shouldn't be needed, anaconda-dracut is supposed to sort
>  that out on media boots.
>  
>  What you have above isn't booting from the iso though, it uses the
>  vmlinuz and initrd (that's what --location does), so you also need to
>  mount the iso using --cdrom 
I thought with virt-install I needed to use --location to be able to kickstart.  Is there
a way to do it with --cdrom too?  Does that require recreating the iso with my ks.cfg in
isolinux/?

Thanks

>  
>  --
>  Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA
>  (PST8PDT)
>

First experience with F18-ALPHA-TC1 (virt-install help)

[Brian C. Lane]

On Mon, Aug 13, 2012 at 11:02:19PM -0400, Scott Poore wrote:
>  
>  
>  ----- Original Message -----
>  > From: "Brian C. Lane" <bcl(a)redhat.com&gt;
>  > 
>  > root= really shouldn't be needed, anaconda-dracut is supposed to sort
>  > that out on media boots.
>  > 
>  > What you have above isn't booting from the iso though, it uses the
>  > vmlinuz and initrd (that's what --location does), so you also need to
>  > mount the iso using --cdrom
>  
>  I thought with virt-install I needed to use --location to be able to kickstart.  Is there
> a way to do it with --cdrom too?  Does that require recreating the iso with my ks.cfg in
> isolinux/? 
You can kickstart from a network source with just --cdrom, but if you
want to use a local kickstart file you need to use --location and
--cdrom so that anaconda can find stage2.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

First experience with F18-ALPHA-TC1 (virt-install help)

[Scott Poore]

----- Original Message -----
>  From: "Brian C. Lane" <bcl(a)redhat.com&gt; 
...
>  You can kickstart from a network source with just --cdrom, but if
> you
>  want to use a local kickstart file you need to use --location and
>  --cdrom so that anaconda can find stage2. 
I get an error (and have for as long as I can remember) when I try using --cdrom and
--location together:
...
ERROR    Only one install method can be used (--location URL, --cdrom CD/ISO, --pxe,
--import, --boot hd|cdrom|...)
...

Or, are you talking about using --disk path=/path/to/iso,device=cdrom?  That seemed to
work for me but, I'm not entirely sure that it actually booted from the iso.  Is there
a way to tell?

FYI, this is what I just tried:

# virt-install --connect=qemu:///system --network=bridge:virbr0 --name=$VMNAME --disk
path=$DISKIMAGE,format=qcow2,size=8 --disk=path=$OSIMG,device=cdrom --ram 1024 --vcpus=1
--check-cpu --hvm --location=$OSIMG --vnc --video=vga
--extra-args="ks=file:/fed.ks" --initrd-inject=fed.ks 

>  
>  --
>  Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA
>  (PST8PDT)
>  
>  --
>  test mailing list
>  test(a)lists.fedoraproject.org
>  To unsubscribe:
>  https://admin.fedoraproject.org/mailman/listinfo/test

First experience with F18-ALPHA-TC1 (virt-install help)

[Brian C. Lane]

On Mon, Aug 27, 2012 at 12:15:56PM -0400, Scott Poore wrote:
>  
>  
>  ----- Original Message -----
>  > From: "Brian C. Lane" <bcl(a)redhat.com&gt;
>  ...
>  > You can kickstart from a network source with just --cdrom, but if you
>  > want to use a local kickstart file you need to use --location and
>  > --cdrom so that anaconda can find stage2.
>  
>  I get an error (and have for as long as I can remember) when I try using --cdrom and
> --location together:
>  ...
>  ERROR    Only one install method can be used (--location URL, --cdrom CD/ISO, --pxe,
> --import, --boot hd|cdrom|...)
>  ...
>  
>  Or, are you talking about using --disk path=/path/to/iso,device=cdrom?  That seemed to
> work for me but, I'm not entirely sure that it actually booted from the iso.  Is there
> a way to tell? 
Whoops, yes, sorry about that. It doesn't boot from the iso, it still
boots from the --location, but it makes the iso available to me mounted.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)