On Mon, 2012-12-03 at 01:10 -0600, Michael Cronenworth wrote: > > Getting to the first anaconda UI screen took a good 1-2 minutes. I > > wasn't sure if the VM had locked up as I had no indication of work being > > done. I can see people being frustrated with the wait and rebooting a > > few times and then posting on @test or @users that F18 won't install. That's not normal, it should only take a few seconds after dracut concludes (during which you can see that Stuff is Happening). Did you file a bug?

On 12/03/2012 03:19 PM, Adam Williamson wrote: > On Mon, 2012-12-03 at 01:10 -0600, Michael Cronenworth wrote: >> > Getting to the first anaconda UI screen took a good 1-2 minutes. I >> > wasn't sure if the VM had locked up as I had no indication of work being >> > done. I can see people being frustrated with the wait and rebooting a >> > few times and then posting on @test or @users that F18 won't install. > That's not normal, it should only take a few seconds after dracut > concludes (during which you can see that Stuff is Happening). Did you > file a bug? > I just tried this with a Vbox VM. After hitting "return" on the initial page the screen when white for about 15 seconds. Then some lines were printed to the screen. The last one informing that /dev/sr0 had been mounted read-only. It then sat there for another 5 minutes before the Welcome screen appeared with the language selection dialog displayed. During the 5 minutes the activity indicator remained on for the DVD. I just filed https://bugzilla.redhat.com/show_bug.cgi?id=882828 with the description above since I don't have a clue at the moment how to gather additional information.

On 12/03/2012 04:31 PM, Adam Williamson wrote: > On Mon, 2012-12-03 at 16:02 +0800, Ed Greshko wrote: >> On 12/03/2012 03:19 PM, Adam Williamson wrote: >>> On Mon, 2012-12-03 at 01:10 -0600, Michael Cronenworth wrote: >>>>> Getting to the first anaconda UI screen took a good 1-2 minutes. I >>>>> wasn't sure if the VM had locked up as I had no indication of work being >>>>> done. I can see people being frustrated with the wait and rebooting a >>>>> few times and then posting on @test or @users that F18 won't install. >>> That's not normal, it should only take a few seconds after dracut >>> concludes (during which you can see that Stuff is Happening). Did you >>> file a bug? >>> >> I just tried this with a Vbox VM. >> >> After hitting "return" on the initial page the screen when white for >> about 15 seconds. Then some lines were printed to the screen. The >> last one informing that /dev/sr0 had been mounted read-only. It then >> sat there for another 5 minutes before the Welcome screen appeared >> with the language selection dialog displayed. During the 5 minutes >> the activity indicator remained on for the DVD. >> >> I just filed https://bugzilla.redhat.com/show_bug.cgi?id=882828 with >> the description above since I don't have a clue at the moment how to >> gather additional information. > Ah - I was forgetting about this: the default option is to check the > medium first, right? That accounts for the delay. I believe there's > already a bug for showing progress during media check. > > If you pick the option that skips the media check, does that resolve the > delay? Yes, and I closed by BZ as a dup of https://bugzilla.redhat.com/show_bug.cgi?id=874486 I didn't realize, and it isn't apparent to my old eyes, that the second line on the initial screen on booting the DVD is the default when you hit return. I'm used to the "default" being first in the list.

On 12/03/2012 02:40 AM, Adam Williamson wrote: > Yeah, I seem to recall we've been round that merry-go-round before, and > somehow it's happening again. The first entry should indeed be the > default, so we should re-jig the order, I think. Should a new bug be created for this or does one already exist?

On 12/03/2012 10:41 AM, Adam Williamson wrote: > Probably file a new one. What component should it be filed under?

> I didn't realize, and it isn't apparent to my old eyes, that the > second line on the initial screen on booting the DVD is the default > when you hit return. I'm used to the "default" being first in the > list. Yeah, I seem to recall we've been round that merry-go-round before, and somehow it's happening again. The first entry should indeed be the default, so we should re-jig the order, I think.

On 12/03/2012 12:08 PM, Andre Robatino wrote: > The current defaults are mediacheck for install images and no mediacheck for > lives, so to keep that, the choice is to either make the order of menu entries > different on installs vs. lives, or keep them the same, and have the default not > be the first entry on one of them. Media checks have always been optional. Why are they the default now?

Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=883086

Or make mediacheck the default on lives :)

1) The logic behind the steps required to entire custom partitioning is wordy. It should be a simple step of asking the user "Do it for me!" or "Let me do it!" and not a couple paragraphs of text no one will read.

At no point in all that did you actually assign a mount point to it. I think you may be hitting the label/mount point confusion here. 'Boot' is not a mount point: it is the label of that partition. If I'm reading this correctly, at this point in the process, you have nothing set to be mounted at /boot. All you've done is say you'd like to format the partition called Boot in your existing F18 install, but you haven't said you'd actually like to use it in the new install in any way.

> >At this point a "Boot 500MB" partition is added, but the old "ext4 > >500MB" partition line is still displayed. Well yes, you didn't say that partition should be removed. Why would it disappear?

> >1) The logic behind the steps required to entire custom partitioning is > >wordy. It should be a simple step of asking the user "Do it for me!" or > >"Let me do it!" and not a couple paragraphs of text no one will read. So, wait, we have a couple of people in the thread suggesting that what the installer needs is more explanatory text, and now you're suggesting that explanatory text is wordy paragraphs no one will read?:)

I've actually suggested that to dlehman myself, but apparently Mo wasn't keen on it, but I haven't discussed it directly with her. A compromise I suggested was to name the expander more clearly. 'Customize' gives you no idea what's behind it.

This kind of change is very disruptive and won't happen post-Beta. Also, we can't do that anyway: the reason there's a date/time spoke during anaconda at all is because on some systems the clock is completely wrong - like 30 years wrong - and that can affect some package scripts. So the spoke exists to make sure you have an opportunity to set the correct date/time prior to package install beginning. Moving the spoke to during package installation would defeat its purpose. If we didn't need to be sure date/time could be set prior to package install on some systems, there would be no such spoke in anaconda at all, and it'd be done at firstboot instead.

There's a solution to this. Hard code the date in the installer when the ISO is created. We know today's date and it could be set in the installer before the UI starts. Then it doesn't matter what the person's system is set to. It doesn't need to be accurate to the exact second, but the year would be accurate and that should be more than enough to pass package script checks.

https://bugzilla.redhat.com/show_bug.cgi?id=883182 I wasn't sure on the component. Feel free to correct. Thanks!

I'm not understanding the problem in the bug.

Chronyd should, and as far as I know does, update both the system clock and hardware clock once (on startup), when it has internet access to get a time sync from a server. If chronyd doesn't have network access, then simply it's up to the user to set the date/time. If there isn't a trusted time source, the hardware clock shouldn't be touched by software via assumption.

expecting that) and I found them under the F18 beta partitioning without a mount point. When I added a mount point the partition was duplicated so for example I had a 500MB ext4 partition and gave it a /boot mount point, which created a 500MB "Boot" ext4 partition leaving the original partition still on my screen.