Again: I'm perfectly happy if it is rejected as a feature. I don't
really care either way. What I'd really hate to see is a checkbox in the
installer so we are compelled to test both variations...
Yeah, I won't be adding any checkboxes to have people pick their /tmp
style.
- Chris
--
devel
Yesterday night I noticed an IRC conversation on #fedora-desktop
about this, and suggested that an actual window would be a lot
better than a notification.
Kalev, Matthias and the people there agreed with me, so I went
ahead and wrote some code that does just that [1].
Screenshots can be
Just out of curiosity: Your description makes me assume that the
installer in the future still don't do things like partitioning,
formating or installing a basic set of packages in the background while
the user (which has a high latency/response time) is asked questions
about the root
Now my understanding of that doesn't include anything about removing
custom partitioning. It's all about splitting up the functionality of
anaconda into two distinct parts - the GUI configuration part, which I
would expect still to contain custom partitioning, and a back-end that
implements
That's my understanding as well so it's not removing functionality but
rather the underlying mechanism and implementation of them. This is good
because it will allow a consistent outcome whether using the GUI, a
kickstart file or something else like media and appliance creator and
likely
Just tried (and failed) update f15-f16. Using dvd (most reliable method).
Went fine until I hit an error, trying to update ipython. At this point,
anaconda just quit. No hints given what the issue was. No offer to try to
report the error.
It mentioned that it _might_ be caused by a
I just uploaded a new version of systemd into F15, which establishes a
directory /run in the root directory. Most likely you'll sooner or later
stumble over it, so here's an explanation what this is and why this is.
On behalf of everyone at anaconda, thanks for fixing something we've all
This was the same realization that
led to the removal of the labeled minimal install, too many people
just wanted to argue over the meaning of the term minimal.
? There's still a 'minimal' radio button in the installer at the package
set selection stage. I know, I just clicked on it
1) Fedora 16 ships with BTRFS as the default root filesystem.
2) Fedora 16 ships without LVM as the volume manager and instead use
BTRFS's built in volume management, again just for the default.
2) Anaconda support. I've already talked with Will Woods about this
some. Really anaconda will
1) GRUB support. Edward Shishkin did GRUB1 patches for BTRFS a while
ago, but they were obviously never merged upstream and were also not
included into fedora. These would either need to be cleaned up and
put into our grub package, or we'd need to put /boot on a different
filesystem.
Hmm, also what does this do to PXE booting. IIRC there is a (relatively
low) limit on the size of the initrd loaded by pxelinux.
It's worked fine for me in all systems tested.
- Chris
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
* btrfs (Is this ready to be default? :) If so, would that warrant a
change in our lvm by default setup?
I don't think we are quite ready for this yet. I do have btrfs
strategy on my todo list, though. I'm hoping we can start talking at
FUDCon about what we want btrfs to do for us,
8f4340dc86f515cd2f6571c06b790ab420f719b2
Author: Chris Lumens clum...@redhat.com
Date: Fri Sep 24 15:52:18 2010 -0400
btrfs will be a supported filesystem in F15 (josef).
Overall, this sounds like a fine plan to me.
- Chris
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo
So I'm in the process of upgrading (using preupgrade) from F13 to
F14, something I typically do around the RC phase, anyway, that's
beside the point. All the packages have been installed, but I'm at the
point where I get Finishing upgrade process. This may take a little
while and a
Anaconda goes though everything step-by-step instead, asking one
question after another, doing some work inbetween (partitining), asking
more questions (packages to install) ...
We have worked a little to reduce this over time, too. If you remember
we used to have a confirmation screen
Useless waste of time. Just grab Ubuntu iso and see a stunning gap in
both technology and usability between anaconda and their own
installed.
Does the Ubuntu installer support installing to iscsi? Multipath?
CCISS? Fully automated installation? Install over VNC? Installation
from NFS, ISO
- downloads updates in parallel too
Package updates?
- uses IP geolocation to guess the user's timezone and keyboard
settings (it's been 100% correct for me each time)
We can do this, it's just never really been brought up. I'd like to
rework a lot of the l10n stuff anyway, there just
Shipping 2 different installers is a recipe for disaster from a user and
QA perspective.Choose one between Ubiquity, Debian-installer and Anaconda.
We only ship one installer, and that is anaconda. I suppose you could
argue over whether livecd is its own thing or not, but that's a nitpicky
Perhaps having a simple vesa arg to anaconda to force a vesa Xserver
would provide a quick and simple work-around. It seems like this might
be a simple hack to add to anaconda. A short-hand for xdriver=vesa
Why do we need a shorthand for an argument you should only have to type
once?
Hmm, I wasn't aware that Anaconda even asks a question about the
runlevel. Given that I am too lazy to try this out now, what exactly is
this question? i.e. does it ask Are you installing a server or a
deskop? or what does it ask?
The default runlevel is inferred based upon packages installed
Rescue environment aside, it'd be nice to avoid failing the upgrade
because of insufficient space in /boot. I think 200 MB default /boot
prove to be too small---perhaps 500 MB should be the new default?
Of course, it already is:
users do not need to find devel packages from the PackageKit GUI, we need to
search useful packages from here, that is my opinion...
This line of thinking needs to stop. Developers are users, too, and
development packages ending up in the search results is not such a bad
thing. Those packages
Would it be possible to put spin kickstarts on the common install DVD,
with an option in anaconda to choose them (and notes that network access
may be required for some packages)? This would give an easier way to
install alternate spins, without having to download and burn lots of
CDs, boot,
23 matches
Mail list logo
