Fedora 16 Beta Arrives With Continued Work

[phoronix]

Phoronix: Fedora 16 Beta Arrives With Continued Work

Fedora 16 Alpha was released back in August, but today it has been replaced by Fedora 16 Beta...

http://www.phoronix.com/vr.php?view=OTk2Mw

[edgan]

I am glad to see GRUB2 being added. I just upgraded a server from F13 to F14 to F15. After I tried to reboot I found GRUB1 wouldn't boot, no matter what I did. It seems to be a bug in GRUB1. So I took GRUB2 from F16, and it worked great.

I am also hoping to see serious improvements in Gnome 3.2 over Gnome 3.

I reviewed their blocker bug list, and would be nice bug list. I didn't really see anything too serious on it. It would suggest F16 is in good shape.

[AdamW]

I reviewed their blocker bug list, and would be nice bug list. I didn't really see anything too serious on it. It would suggest F16 is in good shape.

you want the honest take on that? I wouldn't be 100% sure. the grub2 / gpt migration is exposing quite a few issues in the install process; it's just fundamentally a disruptive change to a process which has been pretty stable for a while now, and it's inevitable that it causes some bugs. We're pretty confident that our programmed testing means the things we explicitly test work, but all the stuff which isn't programmatically tested but which we can usually rely on pretty strongly to keep working is a bit less reliable. I know of quite a few messy cases in the Beta code.

things like complex manual partitioning setups, upgrades, and EFI installs are going to be a bit more fragile in f16 than previously.

For f17, grub2 should be able to handle EFI installs, which will make that whole thicket less complex (a lot of the complexity in F16 stems from the fact that we need to use grub-legacy to handle EFI installs still), but there will be a complete re-design of the anaconda UI which will inevitably bring its own issues.

I'd expect around F18 things should start getting back to the sort of 'background stability' we've had with the bootloader and anaconda partitioning code not really changing much for the last few releases.

[liam]

... things like complex manual partitioning setups, upgrades, and EFI installs are going to be a bit more fragile in f16 than previously...

I really hope this isn't true. I don't know that I've ever been able to get through a fedora install without anaconda failing (especially bad when I use a dvd and specify packages to install). Partitioning has been especially unreliable for me (I do use manual partitions but nothing outrageous: /tmp, /home, /var, things like that). I'm downloading the beta now so we'll see.

[AdamW]

I really hope this isn't true. I don't know that I've ever been able to get through a fedora install without anaconda failing (especially bad when I use a dvd and specify packages to install). Partitioning has been especially unreliable for me (I do use manual partitions but nothing outrageous: /tmp, /home, /var, things like that). I'm downloading the beta now so we'll see.

Er, why would you do that? If you don't make a /tmp partition Fedora will set it up as a tmpfs, which is usually a far better option. And why would you want a /var partition? Why would you need to be able to somehow separate that stuff from your other partitions in a way which an rsync wouldn't achieve just as well?

I've always found it odd how people tend to overpartition things. The only partitions I can even see an argument for in most circumstances are /boot and /home.

[edgan]

you want the honest take on that? I wouldn't be 100% sure. the grub2 / gpt migration is exposing quite a few issues in the install process; it's just fundamentally a disruptive change to a process which has been pretty stable for a while now, and it's inevitable that it causes some bugs. We're pretty confident that our programmed testing means the things we explicitly test work, but all the stuff which isn't programmatically tested but which we can usually rely on pretty strongly to keep working is a bit less reliable. I know of quite a few messy cases in the Beta code.

things like complex manual partitioning setups, upgrades, and EFI installs are going to be a bit more fragile in f16 than previously.

For f17, grub2 should be able to handle EFI installs, which will make that whole thicket less complex (a lot of the complexity in F16 stems from the fact that we need to use grub-legacy to handle EFI installs still), but there will be a complete re-design of the anaconda UI which will inevitably bring its own issues.

I'd expect around F18 things should start getting back to the sort of 'background stability' we've had with the bootloader and anaconda partitioning code not really changing much for the last few releases.

I am not really worried about EFI, personally. It has been fairly broken for years now. I understand it is more important now with UEFI, but it is workaroundable.

[edgan]

Er, why would you do that? If you don't make a /tmp partition Fedora will set it up as a tmpfs, which is usually a far better option. And why would you want a /var partition? Why would you need to be able to somehow separate that stuff from your other partitions in a way which an rsync wouldn't achieve just as well?

I've always found it odd how people tend to overpartition things. The only partitions I can even see an argument for in most circumstances are /boot and /home.

People wanting to break everything into pieces comes back from the old days. I have largely given up on it myself, even though I started with Unix in the pre-Linux days. Things were different back then. They really wanted to mount stuff read-only. They put things on different drives, because drives were so small. It might have also made sense with older filesystems with much smaller limits on number of directories and files.

I actually try to avoid breaking /boot out unless I am doing software raid. I almost always break out /home. Sometimes /var in it's place. One good reason to break things out, avoid one fileystem getting really corrupt taking everything with it. Not that I have had much of a problem with that.

One thing that does annoy me is the orgy of new tmpfs filesystems. Complicates things further, and trades one problem for another. I like a nice clean df or mount output, but now they are a complete mess.

Fedora 15:
6 regular mount points
31 virtual filesystems
- 17 /sys
- 7 /dev
- 3 /proc
- 2 /var
- 1 /run
- 1 /media

[liam]

Er, why would you do that? If you don't make a /tmp partition Fedora will set it up as a tmpfs, which is usually a far better option. And why would you want a /var partition? Why would you need to be able to somehow separate that stuff from your other partitions in a way which an rsync wouldn't achieve just as well?

I've always found it odd how people tend to overpartition things. The only partitions I can even see an argument for in most circumstances are /boot and /home.

Unfortunately I've learned this from experience.
In the past I've had various issues with Gnome not working (various issues) but after some amount of trouble I determined the problem was /var being low on space. Since then I'd had similar problems with /tmp (not necessarily Gnome related).
So since then I've moved to lvm, setup additional volumes, and not used every bit of space on disk when installing (something Fedora really should examine)..
Obviously /boot has to be partitioned if you are using lvm, and /home is convenient for upgrading purposes (but I keep an additional lv for data).
Regardless, anaconda should work in these circumstances pretty much flawlessly. However, my experiences with it have been anything but smooth.
As for tmpfs, RAM is much more expensive than disk, and the items in /tmp aren't usually in need of the high performance a ramdisk structure would provide, so I'd much prefer to use a /tmp.

[AdamW]

edgan: most of those have actually been around for a while but were previously suppressed from the 'mount' output, AIUI.

liam: tmpfses have, essentially, a 'low priority' for memory - if you start running out of memory, tmpfs'es get moved to swap space. regardless, partitioning out /tmp shouldn't cause any problems that I can think of. I'm not sure what issues you ran into, but it'd be best to report them to bugzilla when it happens. the anaconda team is pretty responsive to bug reports.

[Drago]

One reason to move /var is when you use SSD, and you want to lower drive wear.