Fedora 14 RC1 available for testing

[AdamW]

Hi, everyone. Just to note for those who haven't seen that RC1 is now up. If you have spare time to help us test it, that would be really great. It can be found here (http://serverbeach1.fedoraproject.org/pub/alt/stage/14.RC1/). I've put up a News thread (http://forums.fedoraforum.org/showthread.php?t=253156) with instructions on how to help with the formal release validation testing. This thread can be for general RC1 discussion. Thanks everyone!

[ryptyde]

Downloaded the Fedora-14-i686-Live-Desktop.iso and successfully installed to a 2GB usb flash drive with Liveusb-creator from a F13 install. Booted the F14 rc1 usb from a Sony laptop to the desktop with no problem.
Started checking the functions and noticed that I could not connect to the web through ethernet connection but
worked with the onboard wireless.

Decided to install to the laptop and everything worked fine using the default setting to use the whole drive. Took
about 10 minutes to complete and login to the fresh install desktop and still no ethernet connectivity. Took the
same usb device and booted it from an Emachines desktop with no problem getting to a desktop but same thing there no ethernet connectivity. Hooked up my Belkin wireless dongle to the desktop and it worked and connected fine.

The ethernet card for the desktop is RTL-8139 and the laptop is a Marvell Tech. 88E8036. Any ideas as to getting the ethernet working or has anyone else tried the live image with similar results.

phil

[CSchwangler]

I installed RC1 on a laptop and ethernet worked from the beginning. I used the desktop liveCD (Gnome) and put it on a 1GB USB stick with the dd command. Did you notice any error messages, e.g. in /var/log/messages?

[aim]

Hi, everyone. Just to note for those who haven't seen that RC1 is now up. If you have spare time to help us test it, that would be really great. It can be found here (http://serverbeach1.fedoraproject.org/pub/alt/stage/14.RC1/). I've put up a News thread (http://forums.fedoraforum.org/showthread.php?t=253156) with instructions on how to help with the formal release validation testing. This thread can be for general RC1 discussion. Thanks everyone!

Installed from netinst RC1 and everything works fine except of the internet connection. It worked fine too, but for unknown reason asked for a wlan connection even when ethernet was available.

don't think it's a bug, but this behavior should be fixed before 15, IMHO.

[ryptyde]

I installed RC1 on a laptop and ethernet worked from the beginning. I used the desktop liveCD (Gnome) and put it on a 1GB USB stick with the dd command. Did you notice any error messages, e.g. in /var/log/messages?

According to the log the device was activated and the NetworkManager panel icon said "Wired network connection 'Auto eth0' active" but could not ping google.com. I used the wireless connection to install "system-config-network" and "system-config-services" and looked for anything that may be disabled. Made a few changes to allow "http and https" and in services enabled httpd and after a reboot the ethernet appears to be working as it should and pinging google and starting firefox now works. So my ethernet problem is solved at this point. :)

phil

[Mister B]

I installed it on my Acer 5740 laptop and it's mostly working well. WiFi, sound and webcam all work without a hitch.

I initially tried shrinking a Windows 7 NTFS partion, but the installer keeps crashing. I was able to install on a USB flash drive no problem.

[Dangermouse]

Working well for me, and gnome shell seems to be running perfect now (at last)

[arowana]

Dont know if this belongs here, but hope this helps

Folder-Zoom in Nautilus shows strange behaviour in 14-i686 and 14-x86_64 as well. I experienced this since 14Beta.

[tox]

Working well for me, and gnome shell seems to be running perfect now (at last)

glad to see you got Gnome-shell going in F14 cause i cant. says i dont have 3D Hardware or some crap like that. might add i was using the opensource Nvidia driver

[Dangermouse]

glad to see you got Gnome-shell going in F14 cause i cant. says i dont have 3D Hardware or some crap like that. might add i was using the opensource Nvidia driver
Yeh i had to install the nvidia driver from nvidia, the rpmfusion nvidia driver just doesnt work for me nor anyone else in f14 from what i can tell.

[tox]

Yeh i had to install the nvidia driver from nvidia, the rpmfusion nvidia driver just doesnt work for me nor anyone else in f14 from what i can tell.

not that im overly conerned with Gnome-shell not working. since its only gonna be a Addon to Gnome3.

[AdamW]

detox: you need to do 'yum install mesa-dri-drivers-experimental' to get 3D support with nouveau, and even then, whether gnome-shell will work isn't a sure thing. I have two NVIDIA systems; gnome-shell works fine with nouveau on one of them (this one) but is badly broken on the other. nouveau 3D support is still fairly early.

dangermouse: he said he was using 'the open source driver' (i.e. nouveau), not nvidia installed from RPM Fusion. nvidia from Fusion should work but the problem is that the tool used to configure X for it, nvidia-config-display, doesn't, because of https://bugzilla.redhat.com/show_bug.cgi?id=623742 , so if you just install the driver from RPM Fusion, xorg.conf won't be set up right and it won't work. This should be workaroundable somehow, but I haven't really tested it.

[AdamW]

mister b: how exactly did the installer crash when you tried to resize an NTFS partition? did you report the crash?

[tox]

glad to see you got Gnome-shell going in F14 cause i cant. says i dont have 3D Hardware or some crap like that. might add i was using the opensource Nvidia driver

detox: you need to do 'yum install mesa-dri-drivers-experimental' to get 3D support with nouveau, and even then, whether gnome-shell will work isn't a sure thing. I have two NVIDIA systems; gnome-shell works fine with nouveau on one of them (this one) but is badly broken on the other. nouveau 3D support is still fairly early.
yeah i used that driver Ads, it would not work , when i install F15 looks like i'll have to use the blob driver

[AdamW]

detox: ah, fair enough. like I said, it doesn't work in all cases by any means yet :/

[Mister B]

mister b: how exactly did the installer crash when you tried to resize an NTFS partition? did you report the crash?

I haven't had a chance to report it yet, I'll try to tomorrow. The entire installer crashes when I selected the "Shrink Partition" option and hit the Next button.

[AdamW]

huh, okay. that sounds screwy. anyone else seen that?

[stanmc]

I'm running the RC1 desktop from a live cd. I can't figure out how to get to the desired tests. I've looked at what I think is the matrix and I'm not "getting it". So I'm going to have to tell you what I see on my four chosen computers --sorry.

The first computer is an old HP 1.1GHz Intel chip with 512mb and a DVD-rom drive and an onboard video intel card 2mb system ram (yuck). The system navigates through the menus well. It is stable. The network came up perfectly and I get appropriate performance from Firefox. As a live-cd run it is slow as it should be. I'm sure it will perform on par when it is on the hard-drive.

The second computer is a dual core AMD 5600+ with 2GB ram and an nvidia n210 video card with 512mb onboard ram. Perfect performance. The system found the ethernet connection without any problems. cat /proc/cpuinfo thinks the cpu is a 1.0 GHz when it is 2.8 as I recall.

The third computer is an old favorite that is way out of date, but I thought I would try it anyway. Compaq Presario 1200 laptop 770 MHz 320MB. Wouldn't boot from the CD. I'm going to do the preupgrade when Fedora 14 goes final. It runs Fedora 13 very well considering its limitation.

The fourth computer is an AMD 1090T six-core running at 3.5GHz according to cat /proc/cpuinfo. It runs the FAH smp project for Stanford as its/my main purpose. I'm writing this while in Fedora 14 RC1. All things seem to be going correctly or up to par. Video is fine as well as ethernet.

I can't wait to do a preupgrade to all of the current linux computers (#2 is WinXP soon to be Win7 Pro).

[AdamW]

Awesome, thanks for testing.

So, here's how the matrices work...

you go to one of them - let's say the desktop matrix (https://fedoraproject.org/wiki/Test_Results:Fedora_14_Final_RC1_Desktop). The matrix is just a table. Each row relates to one specific test - the test linked in the 'Test Case' column. After the 'Test Case' column come columns for each of the desktops covered by validation testing. So you pick a test from the 'Test Case' column, run the test, and enter your result for it into the cell in the row for that test and under the correct desktop. So if you did the desktop_login test on KDE, you'd put your result in the 'QA:Testcase_desktop_login' row , under the 'KDE Plasma Desktop' column heading. How to input results is explained in the key.

Hope that helped! For the installation matrix it's much the same, except it's got a flashier CSS layout so there's four expandable sections of tests, you can expand and collapse the sections as you like, and instead of different desktop environments, there's columns for results from 32-bit and 64-bit installs.

[Pumpino]

Just testing the live x86_64 image. After launching the installer and selecting custom disk setup, Anaconda crashes as soon as a NTFS partition is clicked.

I know you previously advised that PreUpgrade no longer fails when NTFS partitions are present. I tried a few days ago and it failed, but I'm not sure if the mirror it downloaded from had the revised Anaconda package. I'm not sure whether these two bugs are related, either, but it's pretty dodgy when a single mouse click on a NTFS partition shuts down the install process. :)

Will you be spinning another live CD prior to 2/11?

EDIT: I avoided clicking on my NTFS partitions and the installer completed successfully.

[ddkay]

There seems to be an issue with an ntpd 'leak' and SELinux on the XFCE spin

[bcc]

New with fedora14, running most gui applications as root (when logged into the window system as a regular user) results in a cryptic error:
GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: (connection->initialization_error == NULL)
followed by a core dump. Example applications include emacs, gthumb, eog. I know that generally speaking one doesn't want to run things as root, but emacs is a killer-ap for system administration.

I've been able to work around this bug by un-setting the DBUS_SESSION_BUS_ADDRESS environment variable for root shells.

[Pumpino]

I've just encountered the issue with running GUI applications as root, too. I tried launching gEdit after trying both "su" and "su -" and it refused to launch. I was trying to edit /etc/yum.repos.d/fedora.repo to get mirrors working in order to download packages. Given that nano is not installed by default, it made editing the file challenging, as I was unable to download nano until after editing the file. ;)

[bennachie]

A live CD burned to a USB stick using "dd" worked perfectly for me installing (with manual partition selection) on a Compaq C700 laptop. One minor GUI glitch is that the desktop trash icon doesn't exhibit the normal behaviour of becoming "full" when you drag files to it (by contrast, the smaller icon in the panel works just fine).

The installation was quick and clean. However, given that lots of useful stuff can't be fitted into the CD any more, perhaps Fedora should follow the example of Mint 10 and offer users the opportunity to upgrade to a "DVD edition". Such an edition might, in this case, include OpenOffice (or LibreOffice, of course), and the associated Java bits and pieces.

[Pumpino]

I've found another minor bug. I installed Acrobat Reader from the Adobe repo. It fails to launch from the office menu, so I ran it from a terminal. Running it as a user or as root produces the following error:
# acroread
/opt/Adobe/Reader9/Reader/intellinux/bin/acroread: error while loading shared libraries: libcrypto.so.0.9.8: cannot enable executable stack as shared object requires: Permission denied

I'm surprised these sort of bugs have slipped through the cracks this far into the release schedule, especially the NTFS bug. Hopefully these issues are addressed by creating new ISOs.

[bennachie]

Before somebody jumps on Pumpino for using acroread, I should point out the Evince has some long-standing bugs that have yet to be corrected. In fairness to the developers, the current version does, at long last, once again render some documents correctly that were handled perfectly back in the days of Fedora 8 and 9.

However, Evince still does not handle printers well, and freezes are commonplace (naturally, they always occur at the most inconvenient moment). Okular, by contrast, seems to work very well, and I don't have to bother with acroread in Kubuntu.

In consequence, those of us who would like to use Gnome on Fedora (or Ubuntu, for that matter) for serious work, have to grit our teeth and install acroread. Of course, I'd be very happy to see the fundamental problem fixed. However, Fedora 14 will not be much practical use to me unless the immediate glitch is corrected.

BTW, acroread works perfectly on Ubuntu and Mint.

[AdamW]

I use Evince quite a lot and never have seen it freeze in F14. You should report bugs and attach the PDFs that cause it to freeze, otherwise it's not likely to get fixed. If no-one reports bugs, they usually won't get fixed.

"I've found another minor bug. I installed Acrobat Reader from the Adobe repo. It fails to launch from the office menu, so I ran it from a terminal. Running it as a user or as root produces the following error:
# acroread
/opt/Adobe/Reader9/Reader/intellinux/bin/acroread: error while loading shared libraries: libcrypto.so.0.9.8: cannot enable executable stack as shared object requires: Permission denied"

Sounds to me that SELinux is preventing acroread from doing something it wants to do. That's not really a bug; acroread really shouldn't be doing that, it's a fundamentally unsound thing to do. To work around it, try setting SELinux to permissive. There's probably a specific SELinux check you can disable in your SELinux configuration to work around it permanently, I don't know what that would be off the top of my head.

"I know you previously advised that PreUpgrade no longer fails when NTFS partitions are present. I tried a few days ago and it failed, but I'm not sure if the mirror it downloaded from had the revised Anaconda package."

As you say, I can't do much with this unless you can be sure whether you were using the Anaconda with the fix for that particular issue - https://bugzilla.redhat.com/show_bug.cgi?id=637319 . The fix went into anaconda-14.22-1.fc14 , which was pushed stable on Oct 21st.

I don't think whatever bug you're hitting with your NTFS partition is the same bug, though I can't be 100% sure. I don't believe anyone else has reported such an issue, so it may be specific to your configuration. I'll do a quick test here in a minute.

BTW:

"In consequence, those of us who would like to use Gnome on Fedora (or Ubuntu, for that matter) for serious work, have to grit our teeth and install acroread."

I do wish people wouldn't make sweeping generalizations like this. 'Serious work' differs for everyone. 'Serious work' for many people does not ever involve PDFs.

[AdamW]

New with fedora14, running most gui applications as root (when logged into the window system as a regular user) results in a cryptic error:
GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: (connection->initialization_error == NULL)
followed by a core dump. Example applications include emacs, gthumb, eog. I know that generally speaking one doesn't want to run things as root, but emacs is a killer-ap for system administration.

I've been able to work around this bug by un-setting the DBUS_SESSION_BUS_ADDRESS environment variable for root shells.

I can reproduce this by running gedit after 'su', but (unlike Pumpino), I can't reproduce it when running gedit after 'su -'. 'su' , 'gedit' hits this bug, for me, but 'su -', 'gedit' causes gedit to run fine as root, with no errors on the console.

[AdamW]

And no, there won't be any new ISOs. RC1 was declared gold yesterday. None of the issues raised here would have blocked the release if raised earlier, with the possible exception of Pumpino's NTFS issue if it affects all NTFS partitions (though I doubt that's the case).

[bennachie]

@AdamW

I (and others) have reported the printing bugs in Evince before. They are probably hard to track down (anything to do with printing involves complex inter-relationships between packages) and they are still present. It's the printing process that freezes, not Evince itself, but the phenomenon only occurs when the printing is initiated from Evince. Sometimes (but alas, not always) the printer can be persuaded to work by going via Print Preview. Go figure!

OK, I accept your comment about over-generalisations. Since I have to deal with banks, credit card companies, booking agencies, consultancies, software developers, technical writers, and so forth regularly, I'm always dealing with PDF documents (and I often have to send reports in that format to companies and government agencies, including our beloved Tax Office). I can only agree that others doing serious work may be able to avoid them.

[Mister B]

I was able to test it again.

I'm using the x64 LiveCD. When I select Custom partitioning it lists my drives. I choose my third NTFS partiition and hit edit and get the crash. It says "An unhandled exception has occurred. This is most likely a bug.. PLease save a copy of the detailed exception and file a bug report."

Here's a link to the output:

http://pastebin.com/rwe1UP1v

[Pumpino]

That's what I get although from memory, I don't even get to click on edit; it crashes as soon as I single-click on an NTFS partition.

Adam, can you replicate this bug and are there plans to fix it? I've gotten around it by manually entering entries to /etc/fstab after the installation, but new users may need to resize their Windows NTFS partition prior to installing, and this bug would prevent them from doing this.

[AdamW]

ah, I thought you were saying the printing problems and freezes were different bugs. I don't print PDFs very often, though I have done it and not seen any trouble.

[AdamW]

OK, I can recreate the NTFS issue by clicking on an NTFS partition in the partition editing dialog, yeah. (This may be a consequence of the fix for the NTFS upgrade issue, actually). I'll report a bug and post the link here.

This shouldn't entirely stop you from resizing an NTFS partition, as you can actually do that from the *previous* screen. If someone could test that it'd be good (I know it doesn't work for me, but my test NTFS partition is a 1GB partition with nothing on it, which is a long way from the real world).

[Pumpino]

Thanks for confirming the bug. And sorry, I missed your posts at the bottom of the previous page - you'd actually responded to my previous posts. :)

---------- Post added at 10:59 AM GMT ---------- Previous post was at 10:55 AM GMT ----------

Re. the Acrobat issue and disabling SELinux. I installed the policyutils-gui package as I always do, since it's not included on the live CD. Has the SELinux management interface been changed? I can't see a simple way of disabling it as in previous Fedora releases.

[AdamW]

well, this sucks: looks like the bug was reported and fixed -

https://bugzilla.redhat.com/show_bug.cgi?id=627153

but it came after anaconda was frozen for F14 and the issue was never flagged as a possible blocker or NTH issue for F14 to have the fix pulled into the F14 branch. :( We'll have to document it.

[Mister B]

OK, I can recreate the NTFS issue by clicking on an NTFS partition in the partition editing dialog, yeah. (This may be a consequence of the fix for the NTFS upgrade issue, actually). I'll report a bug and post the link here.

This shouldn't entirely stop you from resizing an NTFS partition, as you can actually do that from the *previous* screen. If someone could test that it'd be good (I know it doesn't work for me, but my test NTFS partition is a 1GB partition with nothing on it, which is a long way from the real world).

I was able to shrink the NTFS partition from the previous screen using the Shrink option. My install proceeded fine from there. Edit Ext4 and LVM partitions was OK as well.

[Pumpino]

but it came after anaconda was frozen for F14 and the issue was never flagged as a possible blocker

Yes, it's hard to believe that it was reported over two months ago and not incorporated into F14 at any stage through the betas and RCs. No point identifying and reporting significant bugs if they're not resolved for upcoming releases. Bummer! :)

[bcc]

I can reproduce this by running gedit after 'su', but (unlike Pumpino), I can't reproduce it when running gedit after 'su -'. 'su' , 'gedit' hits this bug, for me, but 'su -', 'gedit' causes gedit to run fine as root, with no errors on the console.Yes, that would be because your second test doesn't inherit the DBUS_SESSION_BUS_ADDRESS environment variable mentioned previously, whereas your first test does.

---------- Post added at 10:19 PM GMT ---------- Previous post was at 10:17 PM GMT ----------

And no, there won't be any new ISOs. RC1 was declared gold yesterday. None of the issues raised here would have blocked the release if raised earlier, with the possible exception of Pumpino's NTFS issue if it affects all NTFS partitions (though I doubt that's the case).
Hopefully that is not to imply that issues raised here that don't happen to be release blockers are being ignored.

[smr54]

Yes, it's hard to believe that it was reported over two months ago and not incorporated into F14 at any stage through the betas and RCs. No point identifying and reporting significant bugs if they're not resolved for upcoming releases. Bummer! :)

Don't stop reporting bugs. Yes, sometimes, important ones get overlooked, or, more frustrating, aren't considered important by whoever is responsible for it. On the other hand, a heck of a lot of them get fixed, and Fedora's made some real effort on this, with volunteers triaging bugs.

So even though this important one got overlooked, that becomes less and less common (especially for something like this, which I think can generally be considered pretty important.)

[Pumpino]

Adam, I've tried PreUpgrade again on the machine with NTFS that failed a few days ago. It displayed Anaconda's version as 14.22 this time.

This time, it didn't hang at the "finding storage devices" page. What it did do was spit out the following:

"Error enabling swap device UUID...device has not been created. The /etc/fstab on your upgrade partition does not reference a valid swap space. Press ok to exit installer".

I booted back into F13 and changed UUID to /dev/sda5 in /etc/fstab, rebooted, and the upgrade progressed successfully.

[MorphingDragon]

Adobe Reader won't launch, SELinux blocks it and I can't figure out how to unblock it using the SELinux tools.

:/

Apart from that it works fine, on my Laptop and in VMWare.

[Pumpino]

Yes, as I posted previously, after installing policyutils-gui on a CD-based installation, I'm unable to work out how to disable SELinux, as the interface seems to have changed. Can someone advise how to disable SELinux in F14? Thanks.

[Hansvon]

Yes, as I posted previously, after installing policyutils-gui on a CD-based installation, I'm unable to work out how to disable SELinux, as the interface seems to have changed. Can someone advise how to disable SELinux in F14? Thanks.

Set SELINUX=disabled in /etc/selinux/config and reboot

[Wayne]

Drat and double drat..... Thought I'd take the KDE RC for a spin but haven't got any blank CDs! Will have to install Virtualbox and wanted to avoid it! Can't get any CDs till Sunday...

[Hansvon]

You don't have any USB key either? :p

[Wayne]

You don't have any USB key either? :p

Nothing so technically advanced here, still in the dark ages and using CD/DVD drives :rolleyes:

The only USB Thumb Drive I have is a whopping 250Mb! ;)

[Pumpino]

Set SELINUX=disabled in /etc/selinux/config and reboot

You're a legend. Thanks. :)

[Mister B]

well, this sucks: looks like the bug was reported and fixed -

https://bugzilla.redhat.com/show_bug.cgi?id=627153

but it came after anaconda was frozen for F14 and the issue was never flagged as a possible blocker or NTH issue for F14 to have the fix pulled into the F14 branch. :( We'll have to document it.

Is this going to be fixed before final release? This looks like a really nasty bug to send out in a finished product.

[tox]

Is this going to be fixed before final release? This looks like a really nasty bug to send out in a finished product.

if you look it's probbaly fixed in anaconda-15.1-1 which means F15. whether its fixed in F14 i dunno

[AdamW]

Is this going to be fixed before final release? This looks like a really nasty bug to send out in a finished product.

No. We can't fix bugs in the installer after finalizing the release. It's not really a terrible bug if you can resize from the previous screen, as there's not many situations (I can't actually think of any) where you actually need to edit an NTFS partition to complete an install, aside from resizing.

That puts the bug into 'doctor it hurts' territory (for the uninitiated -

Patient: Doctor, it hurts when I do this!
Doctor: Don't do that, then.)

so we'll document it and say 'don't edit NTFS partitions in the installer, do it pre- or post-install instead, if you need to resize it, use the option at the previous screen'.

[AdamW]

Yes, that would be because your second test doesn't inherit the DBUS_SESSION_BUS_ADDRESS environment variable mentioned previously, whereas your first test does.

Indeed. It always pays to be intentionally dumb when testing, though. If you decide you know what's causing the bug and test only according to that situation, it backfires when you turn out to be wrong about what's causing the bug. =) And Pumpino said he could reproduce when using 'su -', which made it doubly important to check.

---------- Post added at 10:19 PM GMT ---------- Previous post was at 10:17 PM GMT ----------

Hopefully that is not to imply that issues raised here that don't happen to be release blockers are being ignored.

No, what it means is that they won't be fixed as part of the release. Ones that can be fixed as updates will be. Ones that can't (installer issues, basically) will be documented.

[AdamW]

Yes, it's hard to believe that it was reported over two months ago and not incorporated into F14 at any stage through the betas and RCs. No point identifying and reporting significant bugs if they're not resolved for upcoming releases. Bummer! :)

Well, let me give you some more context.

What used to happen is that the anaconda team would throw just about any changes they wrote into the anaconda branch for whatever release was pending - even very late in a cycle. So we'd have absurd situations where we were at Final RC stage, or something, identified a single blocker bug in anaconda, and had to take an anaconda build with twenty other unrelated changes in order to fix it. Which would inevitably lead to a bunch of other regressions and we'd be playing Blocker Bug Whack-a-Mole for the next three days.

So anaconda team improved their process vastly and we now have a dual-layer branch policy for anaconda. There's always a branch for the current Branched release and anaconda devs try to exercise discretion with what fixes are pushed there at all times. Particularly after Beta stage, they're very conservative with regards to what gets pushed there. When Alpha, Beta and Final releases are in TC/RC stage, they 'branch the branch', so we have a branch of anaconda-14 called anaconda-14-beta or something, and *only* fixes which are absolutely required to get the Alpha or Beta or Final out go there. Fixes for later in the release cycle go into the anaconda-14 branch and get queued until after the current release point is done.

This makes things a hell of a lot more stable, but it does mean we have to be proactive to make sure desired fixes get in. As there's no planned QA testing that involves NTFS partitions (which as I said is an obvious oversight and one we'll fix for F15), and no-one actively brought the bug to the attention of QA or proposed it as a release blocker or nice-to-have, it never got flagged as release blocker or NTH or raised with the anaconda team to a level of importance sufficient to get it in the F14 branch. There's various ways we can refine the process to try and avoid that in future, and we will, don't worry.

Aside from all of that, the idea that there's "no point identifying and reporting significant bugs if they're not resolved for upcoming releases" obviously isn't the case - it's still better to know it's going to be fixed in the next release than not be sure if it's *ever* going to be fixed, right? I mean, it still sucks, but it sucks slightly less. =)

[Pumpino]

It's not really a terrible bug if you can resize from the previous screen, as there's not many situations (I can't actually think of any) where you actually need to edit an NTFS partition to complete an install, aside from resizing.

What about a newbie that wants to specify where a NTFS data partition is mounted so that they don't need to manually edit /etc/fstab following the installation? Most newbies would not know what syntax to enter into /etc/fstab in order to achieve this. :)

Thanks for the detailed explanation about the Anaconda process.

[mwesten]

Ohhh, but I love Blocker Bug Whack-a-Mole!

This is always fun too. :D

http://www.youtube.com/watch?v=Q_udqEp_YR4

[arowana]

So am I right to assume you do not care about bugs in Nautilus (and that kind) at this stage, because you are searching release-blockers only?

[RahulSundaram]

Hi,

That's not right. Always report any bugs you catch to bugzilla. If they are not release critical, they can be fixed via updates.

[CSchwangler]

You need to understand the different approaches between Fedora and, for example Debian.
Debian values stability over everything else, so Debian attempts to fix any bug before they release a new versions. This necessarily means, that release dates are not fixes, i.e. "it is ready when it is ready".
Fedora aims to show off the latest technology in Linux land and therefore, release dates are more important than bug fixes except for blocker bugs, which would have serious negative effects on user experience.
It is not that Fedora developers would be evil since they ignore particular bugs, its just that they have to get out a release at a certain point in time.

[RahulSundaram]

Hi,

Actually, no distribution attempts to fix every bug and none can. They all have to prioritze some bug fixes over others since there are hundreds of thousands of components and they definitely will have some bugs at release time which can be fixed post release. Every major distribution has the concept of blocker bugs and Fedora has in the past even including this release, postponed a release to fix issues and the release criteria keeps expanding every release to cover more. There is no mandate in Fedora to get a release out in time over fixing important problems and while we can debate over individual bugs (overlooked or otherwise) and we should, the overall process is not THAT dissimilar.

[smr54]

Keep in mind, (sigh, can't believe it's _me_, the complainer about regression, saying this), that developers lose either way--they'll miss a bug, and people will say, HOW could you have released it with that???, or they'll hold off to fix something, and be told , WHAT is wrong with you, why is the release date pushed back again???, so it's kind of a lose/lose situation.

[arowana]

Hi,
thank you all for quick reply :)

i was not complaing about ignored bugs or Fedora at alll. Just had the perception that AdamW was mainly looking for bugs in the installer, since the rest of the release seems to be in a kind of freeze.

Dont want to feel like being off-topic when complaining about small issues :confused:

F14 impression: have two installations for office-work since Beta-release (64bit and my backup notebook with 32bit), did not notice any big issues. I actually like it very much. Nautilus Zoom in Icon View does not work. Sometimes Nautilus crashes when removing USB keys (killed by signal 11 SIGSEGV, whatever it means).

---

(For the Artwork: i like Fedora/Gnome for being consistent, investing in details (like unicolored navigation icons) and not being too flashy. Ubuntu (except for the new font) is a big artwork disaster, Linux Mint pretending to be something like Mac OS ten years ago seems to move the same direction. I have to work with Mac OS everyday and prefer default Gnome the way it is (Nautilus, Clearlooks..). Fedoras identity seems to be strong enough to withstand imitating other operating systems, I really hope you keep up refining your own tools step by step and keep that consistent approach.)

[stevea]

I'm using Fedora-14-Beta-x86_64-Live on a new laptop.

Two issues.

1) When I use the "install to disk" icon I am asked to change the hostname, which I do.
"localhost.localdomain" => "crucibulum.localdomain"
however after reboot and working through the firstboot without problem, the new hostname is not set.
The 'hostname' command reports "localhost.localdomain".
The file /etc/sysconfig/network contains the line:
HOSTNAME=localhost.localdomain

2) The second issue is related to laptop screen backlighthting.
The laptop (Lenovo T510) has both Intel integrated graphics and Nvidia NVS3100 with "Optimus" technology.
When the Intel IGP is enabled in BIOS all is normal (15brightness levels)
When Only the Nvidia is enabled, and using the Nouveau driver, the initial screen backlight brightness is inherited from the BIOS, however after the first brightness change the brightness is restricted to a low range from black/off to about half of the normal.

As an aside suspend, hibernate work as expected.

[RahulSundaram]

1) Beta had that bug in the installer. Fixed for the general release

https://www.redhat.com/archives/anaconda-devel-list/2010-October/msg00000.html

2) Perhaps check and report a bug

[leigh123linux]

I'm using Fedora-14-Beta-x86_64-Live on a new laptop.

Two issues.

1) When I use the "install to disk" icon I am asked to change the hostname, which I do.
"localhost.localdomain" => "crucibulum.localdomain"
however after reboot and working through the firstboot without problem, the new hostname is not set.
The 'hostname' command reports "localhost.localdomain".
The file /etc/sysconfig/network contains the line:
HOSTNAME=localhost.localdomain

2) The second issue is related to laptop screen backlighthting.
The laptop (Lenovo T510) has both Intel integrated graphics and Nvidia NVS3100 with "Optimus" technology.
When the Intel IGP is enabled in BIOS all is normal (15brightness levels)
When Only the Nvidia is enabled, and using the Nouveau driver, the initial screen backlight brightness is inherited from the BIOS, however after the first brightness change the brightness is restricted to a low range from black/off to about half of the normal.

As an aside suspend, hibernate work as expected.

I doubt you will get anywhere with optimus as nvidia refuse to support it under Linux.

http://www.nvnews.net/vbulletin/showthread.php?t=144750&highlight=optimus

[smr54]

Working pretty well for me. Undocumented changes in LDAP, splitting /etc/ldap.conf into pam_ldap.conf and nss_ldap.conf. (There is mention in /usr/share/doc, but I see nothing in release notes.)

Once I got that sorted, seems to be working normally so far. (Haven't done the big update that apparently came through a day or two ago, but RC1, at least, has been working normally.)

[Mister B]

Working pretty well for me. Undocumented changes in LDAP, splitting /etc/ldap.conf into pam_ldap.conf and nss_ldap.conf. (There is mention in /usr/share/doc, but I see nothing in release notes.)

Once I got that sorted, seems to be working normally so far. (Haven't done the big update that apparently came through a day or two ago, but RC1, at least, has been working normally.)

Probably part of http://fedoraproject.org/wiki/FedoraCryptoConsolidation

[RahulSundaram]

Hi

Do send your feedback on that as per

http://docs.fedoraproject.org/en-US/Fedora/14/html/Release_Notes/sect-Release_Notes-Welcome_to_Fedora_14.html#sect-Release_Notes-Feedback

[stevea]

I doubt you will get anywhere with optimus as nvidia refuse to support it under Linux.

http://www.nvnews.net/vbulletin/showthread.php?t=144750&highlight=optimus

Off topic,
I didn't imply optimus would be supported, but be careful when staring in your crystal ball.
The vga_switcheroo feature in 2.6.35 allows one to select the vid for display device and power the 'other' interface up/down. Of course getting X11 to cooperate is another matter. I'll wager it's a year off.

In my case - I want max battery life but also high screen resolution, and the laptop makers have some dumb idea that if you want a hi-res screen threfore you don't want just an IGP. So I own an nvidia chipset I don't really want. It's powered off. Low probability it will see 20 hours of use in the next 4 years.

[smr54]

I added the feedback mentioned.

I would guess that in theory, at least, if the system authconfig tools work perfectly, folks might not even notice. However, there are so many different possibilities for ldap, that often manual fine tuning may be necessary.

[jayfree]

I would like to try F14 RC1 but..."I have a Dell studio xps 13 (1340) triple booting two fedoras (12 and 14 RC1) and windows vista.
I swapped out an intel 5100agn that worked in all 3 os's, for a 6200agn. The new card works in f12 and windows, but f14 beta hangs while booting. I booted f14 into single user and issued ifconfig wlan1 up to see what happens. The machine froze and all I got was the screenshot I am posting, that's it. Any help would be appreciated." from my other post

[AdamW]

arowana: so, a few things =)

Fedora 14 was declared gold last Tuesday, that means nothing will change in the release images or repository since then. Once we hit gold, as far as the actual bits that make up Fedora are concerned, it's as if we've released: the images are done, the static repositories are frozen, and all changes now go out as official updates. In practice, the last date any changes were accepted was the date of RC1, which I think was the previous Thursday or Friday.

The reason there's a week between the images being declared gold and being released is to provide time for the update mechanism to be set up and checked, the release documentation to be finalized, the web sites to be prepared and so on - all the ancillary work which goes on around the actual bits.

Prior to the gold date, yes, there is a period when the release is frozen and only fixes for blocker or nice-to-have bugs are accepted into the release repo (which is what will form the images). Non-blocker / nice-to-have fixes, after that point, can only go down a path which eventually results in them being available as official updates on the day of release.

Blocker bugs are not only installer bugs, though. Blocker bugs are anything which infringe any of the release criteria:

https://fedoraproject.org/wiki/Fedora_14_Alpha_Release_Criteria
https://fedoraproject.org/wiki/Fedora_14_Beta_Release_Criteria
https://fedoraproject.org/wiki/Fedora_14_Final_Release_Criteria

which is a range substantially wider than just anaconda. Additionally, 'nice to have' bugs can be just about anything; the definition of a nice-to-have bug is simply one we think has a significant enough impact on the release that if a fix becomes available it should be taken into the release even through a freeze period. It's an intentionally flexible concept and there's no strict rules about what can constitute a nice-to-have bug, though there are general principles that usually apply.

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

and finally, as noted above, this doesn't mean we 'don't care' about non-blocker bugs once we're in a freeze period. Blocker bugs take highest priority, followed by nice-to-haves, but that doesn't mean other bugs are entirely ignored; they can still be fixed and a fix submitted so it will be available as a 0-day update, as mentioned above, and this often happens. As mentioned in this thread, there's a big pile of updates already available for people who installed F14-RC1; these are the zero-day updates in question.

[arowana]

Adam W.; thanks for your long and interesting reply! Like me, i am sure a lot of Fedora-users have very blurry pictures about your work. Your post helps clearing it up, so you should copy parts of it for upcoming questions regarding Fedora 15. It should actually help people getting closer to offer useful help. Thank you!

[unnilennium]

i've got a daily image of fedora 14 dated 27-10, is more updated than rc1? i've installed it in my laptop, and my opiniion is that it rock, but for a dependency problem, i can't install virtualbox, neither ose or puel, and i've returned to 13 in the meantime... but next week i'll try again the setup. thanks for the useful information.

[stevea]

I'm using Fedora-14-Beta-x86_64-Live on a new laptop.

Two issues.
[...]
2) The second issue is related to laptop screen backlighthting.
The laptop (Lenovo T510) has both Intel integrated graphics and Nvidia NVS3100 with "Optimus" technology.
When the Intel IGP is enabled in BIOS all is normal (15brightness levels)
When Only the Nvidia is enabled, and using the Nouveau driver, the initial screen backlight brightness is inherited from the BIOS, however after the first brightness change the brightness is restricted to a low range from black/off to about half of the normal.


This is a Gnome issue. In KDE the brightness works as expected.