A few impressions from a quick F11 preview test. I burned the livecd iso to CD - then test booted the CD on a Dell D610 laptop. Worked but rather slow since files constantly being pulled from the CD. With the livecd still running I did a "yum install livecd-tools" and then plugged in a usbkey and made a bootable F11 Preview usbkey with a persistent storage area.
This booted nicely and quite fast. Wireless networking in gnome worked well to a WPA2 access point, and I noted that the NetworkManager options at last has the option to make the wireless connection available to all users - although I did not test this I presume that this means it will have wireless active on bootup next time.
A few tests on the menus and everything worked that I tested. No major faults apart from when I shut down using the gnome direct shutdown and the system hung before it shut down propoerly. There is an existing bz on hang during shutdown so it is possible what I saw was the same bug.
Anyway first impressions are favourable and this looks generally like F11 will be a good release.
One thing that needs to be clarified is how the availability of ext4 will affect install decisions for systems already running F10. Although I did not install to HD, when F11 is released the decision will need to be made to switch over to ext4 or not for at least some of the partitions on the system - at present I use / and /opt as separate partitions with /home as a subdirectory of /opt - without a /boot separate partition then I guess the only option will be to keep the root partition as ext3 for the present since grub won't honour ext4 yet. However if the main HD was re-partitioned to make a new /boot partition then I guess /boot left as ext3 with anaconda reformatting the root partition as ext4 for the install will be a way forward?
For /opt I suppose that making a backup ahead of the install and then getting the install to reformat /opt as ext4 as well and then copying back (rsync -X) to /opt from backup will preserve the files intact on the reformatted partition?
I guess that most people develop their own way of "upgrading" from one release to the next but this is an area that is generally not extensively documented apart from lots of bits of answers spread out over many questions on forums. I prefer clean installs every time but I still need to keep user areas and personalised files etc in /opt preserved for use in the new system.
On Thu, 2009-04-30 at 01:16 -0700, Mike Cloaked wrote:
One thing that needs to be clarified is how the availability of ext4 will affect install decisions for systems already running F10. Although I did not install to HD, when F11 is released the decision will need to be made to switch over to ext4 or not for at least some of the partitions on the system
- at present I use / and /opt as separate partitions with /home as a
subdirectory of /opt - without a /boot separate partition then I guess the only option will be to keep the root partition as ext3 for the present since grub won't honour ext4 yet. However if the main HD was re-partitioned to make a new /boot partition then I guess /boot left as ext3 with anaconda reformatting the root partition as ext4 for the install will be a way forward?
Rahul has written a great FAQ around the transition to ext4 at https://fedoraproject.org/wiki/Ext4_in_Fedora_11 that should address your questions. You're encouraged to take a look and provide feedback on the talk page or the previous thread [1].
Thanks, James
[1] https://www.redhat.com/archives/fedora-test-list/2009-April/msg01642.html
On Thu, Apr 30, 2009 at 08:08:58AM -0400, James Laska wrote:
On Thu, 2009-04-30 at 01:16 -0700, Mike Cloaked wrote:
One thing that needs to be clarified is how the availability of ext4 will affect install decisions for systems already running F10. Although I did not install to HD, when F11 is released the decision will need to be made to switch over to ext4 or not for at least some of the partitions on the system
- at present I use / and /opt as separate partitions with /home as a
subdirectory of /opt - without a /boot separate partition then I guess the only option will be to keep the root partition as ext3 for the present since grub won't honour ext4 yet. However if the main HD was re-partitioned to make a new /boot partition then I guess /boot left as ext3 with anaconda reformatting the root partition as ext4 for the install will be a way forward?
Rahul has written a great FAQ around the transition to ext4 at https://fedoraproject.org/wiki/Ext4_in_Fedora_11 that should address your questions. You're encouraged to take a look and provide feedback on the talk page or the previous thread [1].
David Nalley, the beat writer for file systems in the F11 release notes, said he'd make sure this page was referenced in the release notes as well.
On Thu, 2009-04-30 at 01:16 -0700, Mike Cloaked wrote:
I guess that most people develop their own way of "upgrading" from one release to the next but this is an area that is generally not extensively documented apart from lots of bits of answers spread out over many questions on forums. I prefer clean installs every time but I still need to keep user areas and personalised files etc in /opt preserved for use in the new system.
Yeah, that's a fairly common use case for upgrades. As you've mentioned, I suspect people have developed their own best practices over time. I'd be curious for your feedback on the current documented upgrade method:
http://docs.fedoraproject.org/install-guide/f10/en_US/ch-upgrading-system.ht...
The install-guide also recommends a partitioning scheme intended to preserve user data by creating a separate '/home' partition [1]. This doesn't quite meet your needs of preserving system configuration data in '/etc'. If you end up repeatedly using the same authentication/user configuration files on many systems, you might consider moving that data to a network service (NIS, ldap/krb) on another system?
Thanks, James
[1] http://docs.fedoraproject.org/install-guide/f10/en_US/sn-partitioning-advice...
James Laska wrote:
time. I'd be curious for your feedback on the current documented upgrade method:
http://docs.fedoraproject.org/install-guide/f10/en_US/ch-upgrading-system.ht...
The install-guide also recommends a partitioning scheme intended to preserve user data by creating a separate '/home' partition [1]. This doesn't quite meet your needs of preserving system configuration data in '/etc'. If you end up repeatedly using the same authentication/user
A couple of points: The first reference is really to an "upgrade" of an existing system - what I do is to do a clean install but leave the /opt partition ( and which contains a subdirectory home that I bind mount to /home in the root directory. Before configuring the new system a yum update is done to ensure any post release fixes are in place for the system as a whole. Also prior to doing an install of a newer system, I make a backup or /etc and /var and then run a clean install (which includes reformatting the / partition so it is really clean) rather than an upgrade.
After that is complete the root partition contains a virgin installed system, and in the past I have then manually taken the user lines from the backup copies in /etc/passwd, /etc/group /etc/shadow and /etc/gshadow and therefore restored the user login data. Then I bind mount the home directory from the /opt subdirectory to /home in the root partition and add a line to fstab to make it permanent.
Then I go through the config files for ntp, named, dhcp etc etc as necessary copying back the configs from the backup files that were made before the the install.
When I went to F10 from F9 I decided to do things a little differently since there were a lot of changes to KDE so I did not want the old KDE 3.5 configs lying around in the user areas, so I allowed the system to create new user areas with their /home directories in the root partition, and then copied these to new areas in the /opt partition (this also allowed the newer password hash method to be in place and so enhancing security!) - and tediously copied the rest of the user area files to the new home directories as well as things like the Firefox and Thundebird profile info into the new home directory areas.
So an "upgrade" using a clean install does take some time - but it presumably results in a lower risk of problems appearing compared to running a simple yum upgrade - no doubt others will relate their own experiences in this kind of change? I had not though about storing passwords centrally since my use is mainly machines with only up to three or four users, and sometimes only a single user apart from root.
However I would be interested in hearing how others achieve their change to newer versions of Fedora?
On Thu, 30 Apr 2009 06:12:07 -0700 (PDT) Mike Cloaked wrote:
However I would be interested in hearing how others achieve their change to newer versions of Fedora?
I'm very similar to you, always doing a fresh install then replicating my previous setup. I also have home on a separate disk subdirectory, but don't do any fancy bind mounting, I just replace /home with a symlink once I'm ready to fully transition to the new system.
I have everything backed up, but I also keep my old fedora around, always installing the new one on a different partition (actually I have several fedoras around, but one is my "primary").
I'll fiddle with the new fedora from time to time, replicating all the setup I have on the old fedora until I think it is working well, when I finally switch to using the new fedora as the new primary. That mostly just means changing my stand-alone grub partition's default boot so it chainloads the new fedora rather than the old one, but I keep the old one around for reference when I find something missing in the new one, I can see what I did in the old one.
I keep a big text file with a list of all the things I do to the system, and when I find something missing, I try to add it to that file so I'll always have an up to date checklist.
Tom Horsley-3 wrote:
On Thu, 30 Apr 2009 06:12:07 -0700 (PDT) Mike Cloaked wrote:
However I would be interested in hearing how others achieve their change to newer versions of Fedora?
I'm very similar to you, always doing a fresh install then replicating my previous setup. I also have home on a separate disk subdirectory, but don't do any fancy bind mounting, I just replace /home with a symlink once I'm ready to fully transition to the new system.
I should comment on that - on systems prior to F10 I used to have /home as a symlink to a home directory on another partition - but that caused real (avc denial) problems when I ran F10 which was the first time I used SElinux in earnest - so now I used a bind mount rather than a symlink and SElinux does not complain. Since SElinux is there by default now, and with no install option to disable it I decided to climb the SElinux learning curve, and now all my systems run with SElinux enabled for F10 - I am now happy with that though there are a few tweaks needed for some applications to work without avc denials.
I also use bind mounts for mail directories that are stored locally using dovecot imap so that my previous system's email is not lost during install of a new system.
No doubt there will be some "tweaking" needed for F11 also!
On Thu, Apr 30, 2009 at 07:52:06AM -0700, Mike Cloaked wrote:
I should comment on that - on systems prior to F10 I used to have /home as a symlink to a home directory on another partition - but that caused real (avc denial) problems when I ran F10 which was the first time I used SElinux in earnest - so now I used a bind mount rather than a symlink and SElinux does not complain. Since SElinux is there by default now, and with no install option to disable it I decided to climb the SElinux learning curve, and now all my systems run with SElinux enabled for F10 - I am now happy with that though there are a few tweaks needed for some applications to work without avc denials.
I also use bind mounts for mail directories that are stored locally using dovecot imap so that my previous system's email is not lost during install of a new system.
SELinux can have problems with bind mounts as well, because when the system is relabelled, the "wrong" path will label all the files incorrectly.
On Thu, 30 Apr 2009 07:52:06 -0700 (PDT) Mike Cloaked wrote:
Since SElinux is there by default now
My checklist of things to do to systems has putting selinux=0 on the kernel boot options near the top of the list (and editing /etc/selinux/config to say DISABLED - belt and suspenders :-).
On Thu, 2009-04-30 at 11:24 -0400, Tom Horsley wrote:
On Thu, 30 Apr 2009 07:52:06 -0700 (PDT) Mike Cloaked wrote:
Since SElinux is there by default now
My checklist of things to do to systems has putting selinux=0 on the kernel boot options near the top of the list (and editing /etc/selinux/config to say DISABLED - belt and suspenders :-).
Editing the config above as well as selinux=0 is the same thing. You can just edit the file and that will do it.
--- On Thu, 4/30/09, Mike Chambers mike@miketc.net wrote:
From: Mike Chambers mike@miketc.net Subject: Re: F11 Preview - test with usbkey - upgrade partitions To: "For testers of Fedora Core development releases" fedora-test-list@redhat.com Date: Thursday, April 30, 2009, 3:52 PM On Thu, 2009-04-30 at 11:24 -0400, Tom Horsley wrote:
On Thu, 30 Apr 2009 07:52:06 -0700 (PDT) Mike Cloaked wrote:
Since SElinux is there by default now
My checklist of things to do to systems has putting
selinux=0
on the kernel boot options near the top of the list (and editing /etc/selinux/config to say DISABLED -
belt
and suspenders :-).
Editing the config above as well as selinux=0 is the same thing. You can just edit the file and that will do it.
Guess he wan't to make sure that it(selinux) is disabled for good. That is why he used "Belt and Suspenders" :)
The use of selinux=0, is what BLAG does.
Regards,
Antonio
On Thu, Apr 30, 2009 at 06:12:07AM -0700, Mike Cloaked wrote:
A couple of points: The first reference is really to an "upgrade" of an existing system - what I do is to do a clean install but leave the /opt partition ( and which contains a subdirectory home that I bind mount to /home in the root directory. Before configuring the new system a yum update is done to ensure any post release fixes are in place for the system as a whole. Also prior to doing an install of a newer system, I make a backup or /etc and /var and then run a clean install (which includes reformatting the / partition so it is really clean) rather than an upgrade.
However I would be interested in hearing how others achieve their change to newer versions of Fedora?
I've started keeping space for two (sometimes more) separate boot and root partitions on all my systems. That way I can format and do a fresh install on one of them for the next Fedora release, while keeping my current stable release intact in case there are problems. Disk space is cheap these days, and you only really need about 8-16 gig for each install's / partition--leaning towards 16 gig these days, but that still beats the 32+ gig that Vista wants to even do a basic install.
I always share a single 2-4 gig swap between all installs.
In most of the rest of the disk space I keep a separate /home partition that is shared between the installs, but I backup the dot-files in each home directory before booting a new release, just in case the configuration settings aren't forwards- or backwards-compatible, so I can go back to the old stable release by restoring the dot-files if necessary. I'm usually the only user, so this isn't so complicated as it might be with a multiuser system.
I use an LVM setup with an encrypted Physical Volume and keep the /'s and swaps on there. Sometimes I've kept /home on there as well, and sometimes I've made a separate LVM Volume Group for /home (although this slows down boot if encrypted separately, since there needs to be two luksOpen's instead of just one). In either case, I leave some free space inside the LVM Volume Groups that aren't allocated to any Logical Volumes so I can grow either the root partition(s) or /home as necessary. I've done online filesystem resizing on LVM and LUKS encrypted PVs or LVs and it works great. Shrinking is harder since it can't be done online, hence the decision to always leave free space for growth from the start.
Another strategy I've used in the past is to leave room for a few /boot partitions at the beginning of the disk, and split the remainder of the disk into multiple equally sized PV partitions, from 3 all the way up to 10 in one case. The reason for doing that was to allow for flexibility in reallocating PV space from one VG to another, in case I decide that the "system" VG or the "data" VG needs more space. This method has fallen out of favor with LUKS, though, since you really want to limit the amount of separate LUKS containers (PVs or LVs) you have due to the aforementioned slowdown during bootup--at least on systems that are booted often (laptops).
Finally, I've combined the above strategies with software RAID mirroring (mdraid RAID1) on two disks for redundancy of my data. It has already saved my butt several times.
-
Antonio Olivares -
Chuck Anderson -
James Laska -
Mike Chambers -
mike cloaked -
Paul W. Frields -
Tom Horsley