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@rhrk.uni-kl.de
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@rhrk.uni-kl.de
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@rhrk.uni-kl.de
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@rhrk.uni-kl.de
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@rhrk.uni-kl.de
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@rhrk.uni-kl.de
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@rhrk.uni-kl.de
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@redhat.com
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@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
- Installation end up with a screen -
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.
- # 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
What is Fedora coming to when a release candidate install won't even pass go?
On Mon, 13 Aug 2012 12:10:14 -0700 Chuck Forsberg WA7KGX N2469R caf@omen.com 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
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? ;)
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
On Tue, Aug 14, 2012 at 8:21 AM, Adam Jackson ajax@redhat.com 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
On 2012-08-14 5:26, Josh Boyer wrote:
On Tue, Aug 14, 2012 at 8:21 AM, Adam Jackson ajax@redhat.com 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.
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
----- 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@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
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
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
On Wed, Aug 15, 2012 at 11:20:43 -0600, Chris Murphy lists@colorremedies.com 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.)
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...
----- Original Message -----
From: "Petr Schindler" pschindl@redhat.com To: test@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
On Mon, Aug 13, 2012 at 01:19:18PM -0400, Scott Poore wrote:
----- Original Message -----
From: "Petr Schindler" pschindl@redhat.com To: test@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
----- Original Message -----
From: "Brian C. Lane" bcl@redhat.com
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)
On Mon, Aug 13, 2012 at 11:02:19PM -0400, Scott Poore wrote:
----- Original Message -----
From: "Brian C. Lane" bcl@redhat.com
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.
----- Original Message -----
From: "Brian C. Lane" bcl@redhat.com
...
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@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
On Mon, Aug 27, 2012 at 12:15:56PM -0400, Scott Poore wrote:
----- Original Message -----
From: "Brian C. Lane" bcl@redhat.com
...
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.
-
A.J. Werkman` -
Adam Jackson -
Adam Williamson -
Brian C. Lane -
Bruno Wolff III -
Chris Lumens -
Chris Murphy -
Chuck Forsberg WA7KGX -
Jaroslav Reznik -
Joachim Backes -
Josh Boyer -
Kevin Fenzi -
Petr Schindler -
Scott Poore -
Vadim Rutkovsky