Downloaded BETA.TC1 x86_64 DVD.iso and did an install on a VBox guest.
No glitches encountered during the install.
One nit: NetworkManager isn't activated during the install so firstboot isn't network connected for the NTP setup dialogue.
Looks good to me.
On Wed, 2011-03-30 at 13:36 -0400, Gregory Woodbury wrote:
Downloaded BETA.TC1 x86_64 DVD.iso and did an install on a VBox guest.
No glitches encountered during the install.
One nit: NetworkManager isn't activated during the install so firstboot isn't network connected for the NTP setup dialogue.
When performing a media-based (non-network) installation, networking is not enabled by default. If you perform an installation that uses a network-based package repository, networking will be enabled by default.
For the media-based (non-network) use case, you can manually enable networking by selecting 'Start automatically' for the appropriate device from the network configuration dialog.
http://docs.fedoraproject.org/en-US/Fedora/14/html/Installation_Guide/sn-Net...
Thanks, James
On Wed, 2011-03-30 at 13:44 -0400, James Laska wrote:
On Wed, 2011-03-30 at 13:36 -0400, Gregory Woodbury wrote:
Downloaded BETA.TC1 x86_64 DVD.iso and did an install on a VBox guest.
No glitches encountered during the install.
One nit: NetworkManager isn't activated during the install so firstboot isn't network connected for the NTP setup dialogue.
When performing a media-based (non-network) installation, networking is not enabled by default. If you perform an installation that uses a network-based package repository, networking will be enabled by default.
For the media-based (non-network) use case, you can manually enable networking by selecting 'Start automatically' for the appropriate device from the network configuration dialog.
http://docs.fedoraproject.org/en-US/Fedora/14/html/Installation_Guide/sn-Net...
Selecting the NTP checkbox during firstboot should probably bring up a network connection if one isn't already up, though.
On Wed, Mar 30, 2011 at 10:50:56AM -0700, Adam Williamson wrote:
On Wed, 2011-03-30 at 13:44 -0400, James Laska wrote:
On Wed, 2011-03-30 at 13:36 -0400, Gregory Woodbury wrote:
Downloaded BETA.TC1 x86_64 DVD.iso and did an install on a VBox guest.
No glitches encountered during the install.
One nit: NetworkManager isn't activated during the install so firstboot isn't network connected for the NTP setup dialogue.
When performing a media-based (non-network) installation, networking is not enabled by default. If you perform an installation that uses a network-based package repository, networking will be enabled by default.
I just did a default installation in Virtual Box, using the netboot.iso. One thing--I don't remember if this is a new improvement or not, but I find it automatically finds the server and gets the packages--I seem to remember I used to have to manually enter the url.
Using network, as per what Adam says below, had my network running at boot. I like the default wallpaper too, nice choices.
As it was a virtual machine (I guess that's the reason) Gnome 3 failed to load. I then enabled 3D acceleration in VBox and gave it the maximum allowable memory (128MB), and tried again. (This doesn't affect me in real life, where I do minimal installations and use openbox, but I was curious.) However, still no Gnome 3. I seem to remember this being a known issue--or perhaps not even considered an issue, that it won't work in many VMs.
I see that if one adds the user to adminstrative groups, they are added to wheel, and that sudo now works. (In one of the earlier alphas, it didn't).
All in all, seems to be running rather well at least in this cursory test installation.
Selecting the NTP checkbox during firstboot should probably bring up a network connection if one isn't already up, though.
Correct in my case at least, see above.
On 03/30/2011 12:14 PM, Scott Robbins wrote:
I just did a default installation in Virtual Box, using the netboot.iso.
Since Fedora ships qemu-kvm and not VirtualBox, I would be more interested in people trying out kvm virtualization to give our own products better testing.
On Wed, 2011-03-30 at 12:20 -0600, Eric Blake wrote:
On 03/30/2011 12:14 PM, Scott Robbins wrote:
I just did a default installation in Virtual Box, using the netboot.iso.
Since Fedora ships qemu-kvm and not VirtualBox, I would be more interested in people trying out kvm virtualization to give our own products better testing.
Don't worry, a lot of people test that config too (it's actually in our validation test suite).
On 03/30/2011 06:29 PM, Adam Williamson wrote:
On Wed, 2011-03-30 at 12:20 -0600, Eric Blake wrote:
On 03/30/2011 12:14 PM, Scott Robbins wrote:
I just did a default installation in Virtual Box, using the netboot.iso.
Since Fedora ships qemu-kvm and not VirtualBox, I would be more interested in people trying out kvm virtualization to give our own products better testing.
Don't worry, a lot of people test that config too (it's actually in our validation test suite).
Perhaps it would be a nice idea to gather feed back from reporters using other virtualsation solutions as in what they like and dislike with ours and what they like and dislike in the other one as well?
JBG
On Wed, 2011-03-30 at 18:40 +0000, "Jóhann B. Guðmundsson" wrote:
On 03/30/2011 06:29 PM, Adam Williamson wrote:
On Wed, 2011-03-30 at 12:20 -0600, Eric Blake wrote:
On 03/30/2011 12:14 PM, Scott Robbins wrote:
I just did a default installation in Virtual Box, using the netboot.iso.
Since Fedora ships qemu-kvm and not VirtualBox, I would be more interested in people trying out kvm virtualization to give our own products better testing.
Don't worry, a lot of people test that config too (it's actually in our validation test suite).
Perhaps it would be a nice idea to gather feed back from reporters using other virtualsation solutions as in what they like and dislike with ours and what they like and dislike in the other one as well?
The differences between various virt suites are pretty well known, really...
On 03/30/2011 06:51 PM, Adam Williamson wrote:
The differences between various virt suites are pretty well known, really...
Well I was personally thinking about graphical application usage comparison against virt-manager but since you mentioned that the differences is well know then there is no point in doing that.
JBG
On Wed, 2011-03-30 at 19:04 +0000, "Jóhann B. Guðmundsson" wrote:
On 03/30/2011 06:51 PM, Adam Williamson wrote:
The differences between various virt suites are pretty well known, really...
Well I was personally thinking about graphical application usage comparison against virt-manager but since you mentioned that the differences is well know then there is no point in doing that.
I've seen quite a few comparison reviews and so on, so I'm not sure we'd be providing anything new by doing another evaluation.
On Wed, Mar 30, 2011 at 12:26:13PM -0700, Adam Williamson wrote:
I've seen quite a few comparison reviews and so on, so I'm not sure we'd be providing anything new by doing another evaluation.
To side with Adam on this, most reviews are dated within 3 months anyway. Seriously, evil though Oracle is, they update VB regularly, KVM is always being updated, and so is VMware, to the point where any comparison quickly becomes inaccurate.
Just did a new install on a netbook--this time I went for my usual minimal installation. It failed on bind-libs. This strikes me as ood for two reasons--why would bind-libs be included in a minimal installation, and why would it cause the installation to fail?
I thought I had seen, somewhere along the line, that anaconda had been made more robust and wouldn't die on a failed package, especially when the package is non-essential. Is that simply my imagination playing tricks? (Googling doesn't bring me any sign of it.)
Even if it is the case, from what I see on CentOS with whatrequires bind-libs, it's really not necessary for a minimal installation.
(Ironically, trying a complete install earlier worked perfectly.)
Would someone be able to tell me if I am imagining things about Anaconda being so fragile? Seems that most other installers are able to recover from something like that, so it should be doable.
The bind-libs being included in a minimal install sounds like a possible bug, but the same argument could probably be made for anything not essential to boot into a shell. I'm guessing that it was just a glitch in the image downloaded on this install, or a network burp, but the bigger concern, IMHO, is anaconda being so fragile. (Especially if it's not supposed to be, but as mentioned above, I can't find anything to support that, so am beginning to think I misunderstood, or perhaps scanned over, something in the past.)
I think I'm most annoyed over my failing memory. Running the install a second time, everything was fine.
Thanks for any feedback, (especially on whether there was or wasn't an anaconda fix).
On Wed, 2011-03-30 at 14:14 -0400, Scott Robbins wrote:
As it was a virtual machine (I guess that's the reason) Gnome 3 failed to load. I then enabled 3D acceleration in VBox and gave it the maximum allowable memory (128MB), and tried again. (This doesn't affect me in real life, where I do minimal installations and use openbox, but I was curious.) However, still no Gnome 3. I seem to remember this being a known issue--or perhaps not even considered an issue, that it won't work in many VMs.
Yeah, it's a known issue. In theory we should be able to make it work with VBox's acceleration passthrough, in practice it doesn't, yet. It's mentioned in Common Bugs.
On Thu, Mar 31, 2011 at 02:14, Scott Robbins scottro@nyc.rr.com wrote:
On Wed, Mar 30, 2011 at 10:50:56AM -0700, Adam Williamson wrote:
On Wed, 2011-03-30 at 13:44 -0400, James Laska wrote:
On Wed, 2011-03-30 at 13:36 -0400, Gregory Woodbury wrote:
Downloaded BETA.TC1 x86_64 DVD.iso and did an install on a VBox
guest.
No glitches encountered during the install.
One nit: NetworkManager isn't activated during the install so
firstboot
isn't network connected for the NTP setup dialogue.
When performing a media-based (non-network) installation, networking is not enabled by default. If you perform an installation that uses a network-based package repository, networking will be enabled by
default.
I just did a default installation in Virtual Box, using the netboot.iso. One thing--I don't remember if this is a new improvement or not, but I find it automatically finds the server and gets the packages--I seem to remember I used to have to manually enter the url.
Using network, as per what Adam says below, had my network running at boot. I like the default wallpaper too, nice choices.
As it was a virtual machine (I guess that's the reason) Gnome 3 failed to load. I then enabled 3D acceleration in VBox and gave it the maximum allowable memory (128MB), and tried again. (This doesn't affect me in real life, where I do minimal installations and use openbox, but I was curious.) However, still no Gnome 3. I seem to remember this being a known issue--or perhaps not even considered an issue, that it won't work in many VMs.
About the graphics, I accidentally got a VirtualBox Guest Additions 4.0.5 (yes, it's a development build) ISO which supports Fedora 15 by fully supporting gold release of xorg-server 1.10. It was originally posted in vbox-users mailing list some a week ago. http://www.virtualbox.org/download/testcase/VBoxGuestAdditions-r70636.iso
On Thu, Mar 31, 2011 at 09:00:03AM +0800, bsfmig wrote:
On Thu, Mar 31, 2011 at 02:14, Scott Robbins scottro@nyc.rr.com wrote:
As it was a virtual machine (I guess that's the reason) Gnome 3 failed to load. I then enabled 3D acceleration in VBox and gave it the maximum allowable memory (128MB), and tried again. (This doesn't affect me in real life, where I do minimal installations and use openbox, but I was curious.) However, still no Gnome 3. I seem to remember this being a known issue--or perhaps not even considered an issue, that it won't work in many VMs.About the graphics, I accidentally got a VirtualBox Guest Additions 4.0.5 (yes, it's a development build) ISO which supports Fedora 15 by fully supporting gold release of xorg-server 1.10. It was originally posted in vbox-users mailing list some a week ago. http://www.virtualbox.org/download/testcase/VBoxGuestAdditions-r70636.iso
Interesting. Thank you. I'll probably be lazy and wait till VirtualBox tells me it has a newer version available. :)
On 03/30/2011 05:50 PM, Adam Williamson wrote:
Selecting the NTP checkbox during firstboot should probably bring up a network connection if one isn't already up, though.
Hum not sure that would be something we wanted as in application to have the control start and stop over network connections.
I'm not even sure if NTP should be configurable in Firstboot in graphical installations since the novice end user has absolutely no idea what that it is.
But then again I've always thought Firstboot existence be a bit odd from end users perspective you simply should just be able to create a non root user account in Anaconda and configure the rest within the *DE.
JBG
On 30/03/2011 19:50, Adam Williamson wrote:
On Wed, 2011-03-30 at 13:44 -0400, James Laska wrote:
On Wed, 2011-03-30 at 13:36 -0400, Gregory Woodbury wrote:
Downloaded BETA.TC1 x86_64 DVD.iso and did an install on a VBox guest.
No glitches encountered during the install.
One nit: NetworkManager isn't activated during the install so firstboot isn't network connected for the NTP setup dialogue.
When performing a media-based (non-network) installation, networking is not enabled by default. If you perform an installation that uses a network-based package repository, networking will be enabled by default.
For the media-based (non-network) use case, you can manually enable networking by selecting 'Start automatically' for the appropriate device from the network configuration dialog.
http://docs.fedoraproject.org/en-US/Fedora/14/html/Installation_Guide/sn-Net...
Selecting the NTP checkbox during firstboot should probably bring up a network connection if one isn't already up, though.
Kindly please provide me with the web address where I may find this
BETA.TC1 x86_64 to download Thanks Johan
On 03/30/2011 06:44 PM, Johan Scheepers wrote:
Kindly please provide me with the web address where I may find this
http://alt.fedoraproject.org/pub/alt/stage/15-Beta.TC1/
JBG
On Wed, Mar 30, 2011 at 08:44:00PM +0200, Johan Scheepers wrote:
On 30/03/2011 19:50, Adam Williamson wrote:
Selecting the NTP checkbox during firstboot should probably bring up a network connection if one isn't already up, though.
Kindly please provide me with the web address where I may find this
Blah, I realized I gave bogus information before--I didn't mean that NTP brought up the network, only that the network was up. I misread what Adam had written, interpreting it as If the network is up, NTP will work. Apologies to any who were confused.
It looks as if, from this one test install, as if adding the user to admin users automatically adds them to wheel, and that in /etc/sudoers, wheel is already able to execute all commands (whereas in the past, that line was commented out.) Was that just an oddity, or is it by design?
(I can see it being a good idea to stop confusing Ubuntu migrants, but it's one of those bikeshed things that will probably cause 100 post threads.) :)
To pick a nit, I think xterm should be in the default install. Anyway, again, (I think I said this), it basically looks pretty smooth.
On Wed, Mar 30, 2011 at 3:46 PM, Scott Robbins scottro@nyc.rr.com wrote:
It looks as if, from this one test install, as if adding the user to admin users automatically adds them to wheel, and that in /etc/sudoers, wheel is already able to execute all commands (whereas in the past, that line was commented out.) Was that just an oddity, or is it by design?
From what (little?) I understand, it's by design.
-- Jared Smith Fedora Project Leader
On 03/31/2011 03:20 AM, Jared K. Smith wrote:
On Wed, Mar 30, 2011 at 3:46 PM, Scott Robbins scottro@nyc.rr.com wrote:
It looks as if, from this one test install, as if adding the user to admin users automatically adds them to wheel, and that in /etc/sudoers, wheel is already able to execute all commands (whereas in the past, that line was commented out.) Was that just an oddity, or is it by design? From what (little?) I understand, it's by design.
I can confirm it is, It should really should have gone through the feature process but noone bothered to do one and it is going to take some extra time to get it documented in the release notes as a result of this but I fully intend to followup when I can.
Rahul
On Thu, Mar 31, 2011 at 07:27:24AM +0530, Rahul Sundaram wrote:
On 03/31/2011 03:20 AM, Jared K. Smith wrote:
On Wed, Mar 30, 2011 at 3:46 PM, Scott Robbins scottro@nyc.rr.com wrote:
It looks as if, from this one test install, as if adding the user to admin users automatically adds them to wheel, and that in /etc/sudoers, wheel is already able to execute all commands (whereas in the past, that line was commented out.) Was that just an oddity, or is it by design? From what (little?) I understand, it's by design.
I can confirm it is, It should really should have gone through the feature process but noone bothered to do one and it is going to take some extra time to get it documented in the release notes as a result of this but I fully intend to followup when I can.
Thanks for the confirmation. Actually, I think many Fedora users are people who come from Ubuntu and its offshoots, so this will probably avoid some confusion.
When installing over the network and providing IP address through boot options I noticed in the log a message saying it couldn't find updates.img with the reason "name resolution error". As I did not expect to load a updates.img this didn't effect me. But further on in the installation I saw no networking problem and all the packages were fetched as expected.
Could it be that networking is activated after anaconda tries to load updates.img or am I looking at an artefact.
Koos.
Op 30-3-2011 19:36, Gregory Woodbury schreef:
Downloaded BETA.TC1 x86_64 DVD.iso and did an install on a VBox guest.
No glitches encountered during the install.
One nit: NetworkManager isn't activated during the install so firstboot isn't network connected for the NTP setup dialogue.
Looks good to me.
-- G.Wolfe Woodbury aka redwolfe (proventesters)
X still gets locked up when resuming from suspend for a Radeon X800 based upon the R430 chip and using the R300 Gallium driver. There is a corresponding bug report (643700) but there has been no activity for half a year after this issue had shown up for the first time under F14 whereas everything worked fine for the previous release F13. Because with GNOME shell, the whole desktop gets locked up, this is a serious issue for F15 possibly affecting many users. Anybody with similar problems or success stories? Thanks, ~C
-
A.J. Werkman` -
Adam Williamson -
bsfmig -
Christoph Frieben -
Eric Blake -
Gregory Woodbury -
James Laska -
Jared K. Smith -
Johan Scheepers -
Jóhann B. Guðmundsson -
Rahul Sundaram -
Scott Robbins