> 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
> How is that possible to implement with a:
> 1. Show GUI, write kickstart.
> 2. Process kickstart.
> design?
We're not literally going to have one program that you use to construct
a kickstart file, write the file out, and then spawn a separate program
do to the processing of. We are using kicks
> 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
> 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
> implemen
> 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 pas
> 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 cause
> 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
lon
> > 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 cli
> > 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
> > file
> 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
> 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
hile now:
commit 8f4340dc86f515cd2f6571c06b790ab420f719b2
Author: Chris Lumens
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/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, poss
>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" an
> having /usr on a different partition such as
> http://bugzilla.redhat.com/#626007, which is what led to this?
If you read the entire commit message, you'll see:
commit 1ae53648c9e3460eb63837b4c20bc860018979f0
Author: Chris Lumens
Date: Mon Oct 18 11:09:36 2010 -0400
Don'
> 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 af
> 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
de
> - 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 jus
> 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, IS
> 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? xd
> 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 inst
> 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:
http://git.fedoraproject.org/git/?p=anaconda.git;a=commit;h=
> 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 package
> 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, b
25 matches
Mail list logo
