Hi,
I'm using Fedora Core 3.
I've developed a firstboot python module which can detect other OS(currently only windows) partitions and add entries to the fstab. It also creates a user group which has access to those partitions.
The version of firstboot is 1.3.33-2.
I would like to know whether the firstboot developers are interested in seeing and using it in future releases of Fedora. If so, I'll send the module as an E-mail attachment.
With regards, Prasad H.L.
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Prasad H.L. wrote:
Hi,
I'm using Fedora Core 3.
I've developed a firstboot python module which can detect other OS(currently only windows) partitions and add entries to the fstab. It also creates a user group which has access to those partitions.
The version of firstboot is 1.3.33-2.
I would like to know whether the firstboot developers are interested in seeing and using it in future releases of Fedora. If so, I'll send the module as an E-mail attachment.
With regards, Prasad H.L.
Please file it in bugzilla.redhat.com against firstboot with your module as an attachment
regards Rahul
On Mon, 2005-05-30 at 01:56 -0700, Prasad H.L. wrote:
I've developed a firstboot python module which can detect other OS(currently only windows) partitions and add entries to the fstab. It also creates a user group which has access to those partitions.
I'm wondering if this is best done automatically in anaconda (the installer), rather than getting the user to do it manually during firstboot?
Currently anaconda does this on PPC, and enters the OS X partition in yaboot automatically...
I would like to know whether the firstboot developers are interested in seeing and using it in future releases of Fedora. If so, I'll send the module as an E-mail attachment.
But yeah, as Rahul mentioned, Bugzilla it.
On Mon, 2005-05-30 at 01:56 -0700, Prasad H.L. wrote:
Hi,
I'm using Fedora Core 3.
I've developed a firstboot python module which can detect other OS(currently only windows) partitions and add entries to the fstab. It also creates a user group which has access to those partitions.
The version of firstboot is 1.3.33-2.
I would like to know whether the firstboot developers are interested in seeing and using it in future releases of Fedora. If so, I'll send the module as an E-mail attachment.
I'm pretty sure this is not the right way to tackle the problem. For a while before FC3 we've actually had HAL/fstab-sync add these automatically upon every boot. It worked great for all file systems that hal knows about (vfat, ntfs, ext3, reiserfs, hfs, hfs+, xfs, ...) and it was really usable. It worked great both on my Mac and x86 laptops which dual booted with other operating systems.
However, we disabled it because there are the following risks:
a) sometimes we could pick up an ataraid physical volume and mistake it for a real partition with e.g. vfat filesystem (supposed it was one of the PV's for a mirror), add it to the /etc/fstab and have it automounted and then we would risk data corruption. This never happened though (e.g. no bug was filed), but I didn't want to run the risk...
b) Auto-mounting ext3 filesystems is dangerous since with FC3 and forward because we write extended attributes on ext3 which might panic older 2.4 kernels.
(but note that at least all supported Red Hat distros with 2.4 have got kernel updates to cope with this; still vocal users complained when in fact they should just have kept their systems upgraded)
What I want to do for FC5 is to have a gconf setting that can be toggled whether we should automount and display such drives in computer:/// in Nautilus. Whether this should option will be in the Nautilus or gnome-volume-manager preferences is another question.
Another option is to set this preference in the installer: if you're installing a "Personal Desktop" set it to TRUE, if you're installing a server FALSE. We may also ask the question in firstboot though this is a bad idea as most target users won't understand the question.
Hope this helps, David
On 6/7/05, David Zeuthen david@fubar.dk wrote:
Another option is to set this preference in the installer: if you're installing a "Personal Desktop" set it to TRUE, if you're installing a server FALSE. We may also ask the question in firstboot though this is a bad idea as most target users won't understand the question.
If you don't expose the boolean during firstboot, do you plan to make ui available to expose this to an admin for later reconfiguration? If people experience problem a or problem b or some other wacky issue because they run a locally compiled kernel, leaving that option buried in the bowels of gconf with no ui exposed to switch the state isn't going to help anyone.
-jef
On Tue, 2005-06-07 at 12:08 -0400, Jeff Spaleta wrote:
On 6/7/05, David Zeuthen david@fubar.dk wrote:
Another option is to set this preference in the installer: if you're installing a "Personal Desktop" set it to TRUE, if you're installing a server FALSE. We may also ask the question in firstboot though this is a bad idea as most target users won't understand the question.
If you don't expose the boolean during firstboot, do you plan to make ui available to expose this to an admin for later reconfiguration? If people experience problem a or problem b or some other wacky issue because they run a locally compiled kernel, leaving that option buried in the bowels of gconf with no ui exposed to switch the state isn't going to help anyone.
Well, for admins I suppose that gconf-editor is pretty good? Btw, all this is still a bit up in the air; I suppose it's easier to discuss in detail once it's actually implemented...
David
On 6/7/05, David Zeuthen david@fubar.dk wrote:
Well, for admins I suppose that gconf-editor is pretty good?
gconf-editor can be..adequate.. under certain conditions. The primary one being you know exactly what boolean you are looking for before you go looking for it and its not a critically important setting. I would suggest that a boolean that can have serious system-wide effects like the problems you described in your post isn't something people shouldn't have to troll through the gconf tree for.. in a panic. We aren't talking about turning on metacity wireframe window moving to get a slight speedup on low end hardware. You mentioned potential data corruption situations... i think thats important enough to expose in sort sort of dedicated ui. Potentially important enough to be a firstboot dialog.
-jef
On Tue, 2005-06-07 at 13:26 -0400, Jeff Spaleta wrote:
On 6/7/05, David Zeuthen david@fubar.dk wrote:
Well, for admins I suppose that gconf-editor is pretty good?
gconf-editor can be..adequate.. under certain conditions. The primary one being you know exactly what boolean you are looking for before you go looking for it and its not a critically important setting. I would suggest that a boolean that can have serious system-wide effects like the problems you described in your post isn't something people shouldn't have to troll through the gconf tree for.. in a panic. We aren't talking about turning on metacity wireframe window moving to get a slight speedup on low end hardware. You mentioned potential data corruption situations... i think thats important enough to expose in sort sort of dedicated ui. Potentially important enough to be a firstboot dialog.
You make some good points here. At this point, I don't really know, I *think* we may want to put it somewhere in the install/firstboot and perhaps also ask other questions so it looks like
[ ] Automatically mount internal fixed drives (1) [x] Automatically mount external storage devices (2) [ ] Require password for write access to external storage (3) [x] Ignore SCSI drives for auto mounting (4) [x] Except optical drives (5)
where (2) and (3) is needed for lock down; think either a) system in a library where people are not allowed to copy material to USB sticks; or b) an enterprise with low trust in their people ;-). That's this article: http://www.pbs.org/cringely/pulpit/pulpit20040916.html - search for ''epoxy''.
Also, (4) and (5) is needed for the "enthusiast user" that uses SCSI drives; by default we ignore them since we can't really tell apart a Fiber Channel controller with 500 drivers from the enthusiast with his, say, two SCSI drives - we don't want the former to get 500+ icons on the desktop for mounted drives (I had a bug report about that pre-FC3), however, we do want the latter to work...
So, it's all pretty complex if you want to auto mount drives in a sane way without screwing everyone. For the UI for these options, I think we need some of the interaction/ usability guys to say whether we can ask the user these questions :-). We'll see..
Cheers, David
Hi.
Alan Cox alan@redhat.com wrote:
There are some ugly ones using snapshots, basically snapshot it and fsck the snapshot.
Then maybe we should avoid adding unclean file systems to fstab automagically.
On Mer 8 juin 2005 12:21, David Zeuthen a écrit :
You make some good points here. At this point, I don't really know, I *think* we may want to put it somewhere in the install/firstboot
Firstboot is the same dead end as kudzu and sequential initscripts. Modern systems have a complex life, parameters need to be changed at any point of time, not only during 'initialisation'.
This BTW is one reason why rpm plays in another category than windows-style installers that only care about the initial state.
and perhaps also ask other questions so it looks like
[ ] Automatically mount internal fixed drives (1) [x] Automatically mount external storage devices (2) [ ] Require password for write access to external storage (3) [x] Ignore SCSI drives for auto mounting (4) [x] Except optical drives (5)
[x] Except usb drives (6)
Regards,
On Wed, Jun 08, 2005 at 01:54:22PM +0200, Nicolas Mailhot wrote:
Modern systems have a complex life, parameters need to be changed at any point of time, not only during 'initialisation'.
This does not make asking for these parameters explicitly at the time the system comes up first a bad idea, doesn't it?
Ralf Ertzinger wrote:
On Wed, Jun 08, 2005 at 01:54:22PM +0200, Nicolas Mailhot wrote:
Modern systems have a complex life, parameters need to be changed at any point of time, not only during 'initialisation'.
This does not make asking for these parameters explicitly at the time the system comes up first a bad idea, doesn't it?
Ok, there a couple of problems with this approach. * Firstboot is not available for non-graphical installations. Could be solvable using a first login wizard * The installer has been in general very easy to understand and follow. These type of questions are not easily understood by end users to make good choices on what to do. Might be better to just choose the "best" option as default and push these choices into a advanced section/ provide them with documentation and a easy way to change the options after the installation is complete.
regards Rahul
On Mer 8 juin 2005 15:02, Ralf Ertzinger a écrit :
On Wed, Jun 08, 2005 at 01:54:22PM +0200, Nicolas Mailhot wrote:
Modern systems have a complex life, parameters need to be changed at any point of time, not only during 'initialisation'.
This does not make asking for these parameters explicitly at the time the system comes up first a bad idea, doesn't it?
If you provide a good tool to change them afterwards you do not need such "in the face" advertising. Just select good defaults like for everything else.
Regards,
On 6/8/05, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
If you provide a good tool to change them afterwards you do not need such "in the face" advertising. Just select good defaults like for everything
Ah.. but how do you make sure people are aware of the new good tool? and sadly i think this is one of those system-wide features that can benefit from install-time or firstboot configuration depending on the role the machine is playing.
As long as good defaults.. mean safe defaults I'm happier. If the data corruption situations that david mentioned can be prevented my important concerns over the question of defaults disappears. Shaking out the lingering data corruption situations should be something targetted for the early fc5 test releases if this feature is implemented and turned on by default in the test releases.
Everything else is murky trade-offs about defaults versus feature discovery, a category of questions we don't have a general answer for.
-jef
-
Alan Cox -
Colin Charles -
David Zeuthen -
Jef Spaleta -
Nicolas Mailhot -
Prasad H.L. -
Rahul Sundaram -
Ralf Ertzinger