Hey, guys. I would love to do the right thing and actually write this stuff up and submit it properly, but I'm kind of overwhelmed at the moment and just wanted to dump it somewhere quick and hope it winds up in the right documentation :/ Much of this probably needs to go in the Release Notes, Install Guide, or both. I haven't checked at all if you've actually already done this, so apologies if it's already covered.
Note that I could be somewhat wrong in my understanding of any of this stuff. If you're at all confused or thinking 'that doesn't sound right', poke Brian Lane (bcl on IRC) for clarification. CCing Brian so he can correct any really egregious mistakes in the below.
# btrfs is not available as a target filesystem for installation in F17: https://bugzilla.redhat.com/show_bug.cgi?id=787341 . This is temporary. What happened is clumens rewrote the storage backend to handle btrfs much better, with support for its native volume management and mirroring / striping and all its other cool features. The plan was that the UI for this would be part of the big anaconda UI rewrite. However, the UI rewrite got delayed to F18. So F17 has the new backend but old UI code from the time when the backend treated btrfs as just a fairly 'dumb' filesystem like ext4. That combination results in a hard crash when trying to use btrfs at all. Instead of trying to revert the storage backend or hurriedly write new UI for btrfs in the old UI code, anaconda team decided to just disable btrfs support for one release.
# The big 'noloader' change - https://fedoraproject.org/wiki/Anaconda/Features/NoLoader - has some consequences, many are documented at that feature page. the 'askmethod' parameter you used to be able to pass to anaconda so it would let you interactively select a remote repository during stage1 from which you could download stage2 and also packages for installation is now gone; with the new anaconda design it just doesn't fit in any more. there really isn't a stage split in anaconda any more, there's no 'mini-anaconda' that runs first in text mode and which could prompt you for where to get its bigger brother. So the remaining methods of repository selection are to use the 'repo=' parameter (or 'inst.repo=') at boot time or to do it interactively during the package selection phase of the install. If you're doing a direct kernel boot and need to pull anaconda itself from the network, the 'repo=' parameter is used to say where to find it. See https://bugzilla.redhat.com/show_bug.cgi?id=804506 and https://bugzilla.redhat.com/show_bug.cgi?id=805166 . Similar for 'asknetwork'.
# Lots of anaconda parameters are spitting out a deprecation message saying that in future they should be prefixed with inst. e.g. passing 'repo=XXX' will spit out a message saying you should use 'inst.repo=XXX'. Brian, didn't we find that inst.repo was actually broken in some cases where repo= works, though? Or is that fixed now, and the notes should encourage people to use inst.foo forthwith?
# This isn't actually new but it's something the Install Guide currently doesn't cover and should. The section on creating media with dd - https://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/Makin... - should note that, if you dd a DVD image to a USB stick, unless you pass a 'repo=hd:' parameter (or possibly 'inst.repo=hd:', see above...) pointing to the stick in some way (UUID, expected mount point, label, whatever), the stick will act like the boot.iso. That is, it won't actually use the packages on the stick. It'll require a network connection, and pull in all the packages remotely. If you use livecd-iso-to-disk (which really ought to get renamed...) to write the DVD ISO to a stick, it adds a repo= parameter to the config for you, which is one reason it's better to use l-i-t-d.
# Bill Nottingham and I, somewhat sneakily, stuck NetworkManager into @core last week. Amazingly, the torch-and-pitchfork-bearing mob has not yet found us. See https://bugzilla.redhat.com/show_bug.cgi?id=693602 for details, including ass-covering statistics on why we did this (so the network actually freaking works out of the box on a minimal install), how many additional packages this causes to be installed (not many) and how much extra disk space it causes to be used (not much). You should still be able to install without NetworkManager if you really, really want to, by using a kickstart in which it's specifically excluded in the %packages section, and you can still 'yum remove' it.
I feel like I had other things to mention but I forget them now. If they come to mind, I'll send another mail. Thanks!
Thanks very much, Adam.
I'll work on incorporating these changes into the Installation Guide.
Cheers,
Jack
On 03/28/2012 05:28 AM, Adam Williamson wrote:
Hey, guys. I would love to do the right thing and actually write this stuff up and submit it properly, but I'm kind of overwhelmed at the moment and just wanted to dump it somewhere quick and hope it winds up in the right documentation :/ Much of this probably needs to go in the Release Notes, Install Guide, or both. I haven't checked at all if you've actually already done this, so apologies if it's already covered.
Note that I could be somewhat wrong in my understanding of any of this stuff. If you're at all confused or thinking 'that doesn't sound right', poke Brian Lane (bcl on IRC) for clarification. CCing Brian so he can correct any really egregious mistakes in the below.
# btrfs is not available as a target filesystem for installation in F17: https://bugzilla.redhat.com/show_bug.cgi?id=787341 . This is temporary. What happened is clumens rewrote the storage backend to handle btrfs much better, with support for its native volume management and mirroring / striping and all its other cool features. The plan was that the UI for this would be part of the big anaconda UI rewrite. However, the UI rewrite got delayed to F18. So F17 has the new backend but old UI code from the time when the backend treated btrfs as just a fairly 'dumb' filesystem like ext4. That combination results in a hard crash when trying to use btrfs at all. Instead of trying to revert the storage backend or hurriedly write new UI for btrfs in the old UI code, anaconda team decided to just disable btrfs support for one release.
# The big 'noloader' change - https://fedoraproject.org/wiki/Anaconda/Features/NoLoader - has some consequences, many are documented at that feature page. the 'askmethod' parameter you used to be able to pass to anaconda so it would let you interactively select a remote repository during stage1 from which you could download stage2 and also packages for installation is now gone; with the new anaconda design it just doesn't fit in any more. there really isn't a stage split in anaconda any more, there's no 'mini-anaconda' that runs first in text mode and which could prompt you for where to get its bigger brother. So the remaining methods of repository selection are to use the 'repo=' parameter (or 'inst.repo=') at boot time or to do it interactively during the package selection phase of the install. If you're doing a direct kernel boot and need to pull anaconda itself from the network, the 'repo=' parameter is used to say where to find it. See https://bugzilla.redhat.com/show_bug.cgi?id=804506 and https://bugzilla.redhat.com/show_bug.cgi?id=805166 . Similar for 'asknetwork'.
# Lots of anaconda parameters are spitting out a deprecation message saying that in future they should be prefixed with inst. e.g. passing 'repo=XXX' will spit out a message saying you should use 'inst.repo=XXX'. Brian, didn't we find that inst.repo was actually broken in some cases where repo= works, though? Or is that fixed now, and the notes should encourage people to use inst.foo forthwith?
# This isn't actually new but it's something the Install Guide currently doesn't cover and should. The section on creating media with dd - https://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/Makin... - should note that, if you dd a DVD image to a USB stick, unless you pass a 'repo=hd:' parameter (or possibly 'inst.repo=hd:', see above...) pointing to the stick in some way (UUID, expected mount point, label, whatever), the stick will act like the boot.iso. That is, it won't actually use the packages on the stick. It'll require a network connection, and pull in all the packages remotely. If you use livecd-iso-to-disk (which really ought to get renamed...) to write the DVD ISO to a stick, it adds a repo= parameter to the config for you, which is one reason it's better to use l-i-t-d.
# Bill Nottingham and I, somewhat sneakily, stuck NetworkManager into @core last week. Amazingly, the torch-and-pitchfork-bearing mob has not yet found us. See https://bugzilla.redhat.com/show_bug.cgi?id=693602 for details, including ass-covering statistics on why we did this (so the network actually freaking works out of the box on a minimal install), how many additional packages this causes to be installed (not many) and how much extra disk space it causes to be used (not much). You should still be able to install without NetworkManager if you really, really want to, by using a kickstart in which it's specifically excluded in the %packages section, and you can still 'yum remove' it.
I feel like I had other things to mention but I forget them now. If they come to mind, I'll send another mail. Thanks!
docs@lists.stg.fedoraproject.org
-
Adam Williamson -
Jack Reed