Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
0 views
Skip to first unread message
Josh Triplett
Dec 15, 2011, 4:00:01 PM12/15/11
to
Package: partman-auto
Severity: normal
In all of the recent discussions about separate /usr partitions, most
people seem to acknowledge them as unusual, special-purpose
configurations, even those who use them. To the extent they have a use
at all, they primarily have a use for people who have very specific
reasons for wanting them, and all of those people will know how to
handle partitioning. To a lesser extent, that holds true for having
separate partitions for /var, /tmp, or other top-level directories. It
seems likely that any such setup will have custom requirements.
Meanwhile, we don't want to steer any new users towards a setup with a
pile of different partitions, which makes their system more complex with
more potential failure modes.
In the most recent thread, I noticed that someone mentioned they
primarily chose a setup with a separate /usr partition because the
installer offered such a setup as one of the standard guided
partitioning options.
Please consider removing the option in the guided partitioner for
separate /usr, /var, and /tmp partitions; that would leave only the "All
files in one partition" and "Separate /home partition" setups, both of
which potentially make sense for users of the guided partitioner.
Anyone desiring a setup with more separate partitions should have no
trouble using the manual partitioner to create whatever custom
configuration they desire.
- Josh Triplett
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Severity: normal
In all of the recent discussions about separate /usr partitions, most
people seem to acknowledge them as unusual, special-purpose
configurations, even those who use them. To the extent they have a use
at all, they primarily have a use for people who have very specific
reasons for wanting them, and all of those people will know how to
handle partitioning. To a lesser extent, that holds true for having
separate partitions for /var, /tmp, or other top-level directories. It
seems likely that any such setup will have custom requirements.
Meanwhile, we don't want to steer any new users towards a setup with a
pile of different partitions, which makes their system more complex with
more potential failure modes.
In the most recent thread, I noticed that someone mentioned they
primarily chose a setup with a separate /usr partition because the
installer offered such a setup as one of the standard guided
partitioning options.
Please consider removing the option in the guided partitioner for
separate /usr, /var, and /tmp partitions; that would leave only the "All
files in one partition" and "Separate /home partition" setups, both of
which potentially make sense for users of the guided partitioner.
Anyone desiring a setup with more separate partitions should have no
trouble using the manual partitioner to create whatever custom
configuration they desire.
- Josh Triplett
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russ Allbery
Dec 15, 2011, 6:10:02 PM12/15/11
to
Josh Triplett <jo...@joshtriplett.org> writes:
> In all of the recent discussions about separate /usr partitions, most
> people seem to acknowledge them as unusual, special-purpose
> configurations, even those who use them. To the extent they have a use
> at all, they primarily have a use for people who have very specific
> reasons for wanting them, and all of those people will know how to
> handle partitioning. To a lesser extent, that holds true for having
> separate partitions for /var, /tmp, or other top-level directories. It
> seems likely that any such setup will have custom requirements.
I don't think these things are alike. Separating /var and /tmp from the
> In all of the recent discussions about separate /usr partitions, most
> people seem to acknowledge them as unusual, special-purpose
> configurations, even those who use them. To the extent they have a use
> at all, they primarily have a use for people who have very specific
> reasons for wanting them, and all of those people will know how to
> handle partitioning. To a lesser extent, that holds true for having
> separate partitions for /var, /tmp, or other top-level directories. It
> seems likely that any such setup will have custom requirements.
rest of the file systems is done because those partitions contain varying
amounts of data and often fill if something goes wrong, but can fill
without impacting the rest of the system and allowing easy recovery if
they're not on the same partition as everything else.
Separating /var continues to be good and recommended practice if you're
running anything that's likely to produce a lot of output, IMO. (/tmp
should probalby just be tmpfs, but that's another discussion.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Christian PERRIER
Dec 16, 2011, 1:40:02 AM12/16/11
to
(reducing CC as I guess that most are subscribed to -devel)
Quoting Russ Allbery (r...@debian.org):
> I don't think these things are alike. Separating /var and /tmp from the
> rest of the file systems is done because those partitions contain varying
> amounts of data and often fill if something goes wrong, but can fill
> without impacting the rest of the system and allowing easy recovery if
> they're not on the same partition as everything else.
>
> Separating /var continues to be good and recommended practice if you're
> running anything that's likely to produce a lot of output, IMO. (/tmp
> should probalby just be tmpfs, but that's another discussion.)
I'm inclined to follow this advice and would indeed propose that the
"atomic" partman-auto recipe is kept, however without a separate /usr
partition (discussions on -devel and the current practice convinced me
that a separate /usr is seomthing that probably belongs to the former
century..:-)
So, would it be OK for participants in this discussion is we, in the
installer, just drop separate /usr but keep the atomic recipe (which
is not the default choice, by the way)?
Quoting Russ Allbery (r...@debian.org):
> I don't think these things are alike. Separating /var and /tmp from the
> rest of the file systems is done because those partitions contain varying
> amounts of data and often fill if something goes wrong, but can fill
> without impacting the rest of the system and allowing easy recovery if
> they're not on the same partition as everything else.
>
> Separating /var continues to be good and recommended practice if you're
> running anything that's likely to produce a lot of output, IMO. (/tmp
> should probalby just be tmpfs, but that's another discussion.)
"atomic" partman-auto recipe is kept, however without a separate /usr
partition (discussions on -devel and the current practice convinced me
that a separate /usr is seomthing that probably belongs to the former
century..:-)
So, would it be OK for participants in this discussion is we, in the
installer, just drop separate /usr but keep the atomic recipe (which
is not the default choice, by the way)?
Roger Leigh
Dec 16, 2011, 5:40:01 AM12/16/11
to
separate would also be sensible.
Regarding /tmp, we're now defaulting to a tmpfs for new installs, so
I'm not certain if having a separate /tmp by default is a good idea
or not. I would certainly like for /tmp in particular (and tmpfses
in general) to become configurable through the partitioner, which
would then also check that sufficient swap is also allocated at the
same time.
Once we have /etc/fstab.d fully supported by mount (with the next
util-linux release, probably in early January), I will be looking
at making all the initscripts mountpoints currently hardcoded in
the init scripts like mountkernfs etc. into conffiles in fstab.d.
It would then be possible for the installer to edit these files
quite simply to change the defaults, perhaps using the partitioner
as a frontend.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Thomas Goirand
Dec 16, 2011, 8:20:02 AM12/16/11
to
On 12/16/2011 04:46 AM, Josh Triplett wrote:
> In all of the recent discussions about separate /usr partitions, most
> people seem to acknowledge them as unusual, special-purpose
> configurations, even those who use them.
I do *not* agree that there's such a consensus.
> In all of the recent discussions about separate /usr partitions, most
> people seem to acknowledge them as unusual, special-purpose
> configurations, even those who use them.
On 12/16/2011 04:46 AM, Josh Triplett wrote:
> Meanwhile, we don't want to steer any new users towards a setup with a
> pile of different partitions, which makes their system more complex with
> more potential failure modes.
>
and that we don't want to force anyone to do anything.
If I want to use many partitions, this is *my* call, and
not everyone's business. Please don't try to force your
view on partitioning to anyone.
> In the most recent thread, I noticed that someone mentioned they
> primarily chose a setup with a separate /usr partition because the
> installer offered such a setup as one of the standard guided
> partitioning options.
>
> Please consider removing the option in the guided partitioner for
> separate /usr, /var, and /tmp partitions; that would leave only the "All
> files in one partition" and "Separate /home partition" setups, both of
> which potentially make sense for users of the guided partitioner.
>
don't see why it needs to be removed just because
you Josh (and maybe others) don't like/use it.
You feel like a separate partition for /home is useful.
Good for you, and your desktop. But when it comes
to servers, the /home separate partition is useless,
and having a separate /var makes things faster.
Also, having a separate /tmp avoids that the rootfs
gets full, and I consider it quite important especially
on servers. I would recommend using it for absolutely
*every* setup (desktop or servers) as a security measure,
especially considering any application can fill up the
temp space.
> Anyone desiring a setup with more separate partitions should have no
> trouble using the manual partitioner to create whatever custom
> configuration they desire.
>
also it's a way faster than doing it manually. Please don't
remove it.
Again, the way *I* and *others* use my/their computers
is their choice. Please do not remove this choice from
me/them.
Thomas Goirand (zigo)
Joey Hess
Dec 16, 2011, 1:20:02 PM12/16/11
to
Christian PERRIER wrote:
> I'm inclined to follow this advice and would indeed propose that the
> "atomic" partman-auto recipe is kept, however without a separate /usr
> partition (discussions on -devel and the current practice convinced me
> that a separate /usr is seomthing that probably belongs to the former
> century..:-)
I don't think that d-i should be on the leading edge of this discussion.
> I'm inclined to follow this advice and would indeed propose that the
> "atomic" partman-auto recipe is kept, however without a separate /usr
> partition (discussions on -devel and the current practice convinced me
> that a separate /usr is seomthing that probably belongs to the former
> century..:-)
Once Debian has made up its mind, d-i can be updated to follow the
consensus.
--
see shy jo
Michael Biebl
Dec 16, 2011, 1:40:01 PM12/16/11
to
partition should be considered deprecated and this option removed from
the installer.
If that means dropping the multi-partition option altogether or just
removing /usr from the "atomic" partman-auto recipe is something I'd
leave up to the d-i team to decide. Personally I'd be fine with either
solution.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Steve Langasek
Dec 16, 2011, 1:50:02 PM12/16/11
to
On Fri, Dec 16, 2011 at 07:32:35PM +0100, Michael Biebl wrote:
> On 16.12.2011 18:38, Joey Hess wrote:
> > Christian PERRIER wrote:
> >> I'm inclined to follow this advice and would indeed propose that the
> >> "atomic" partman-auto recipe is kept, however without a separate /usr
> >> partition (discussions on -devel and the current practice convinced me
> >> that a separate /usr is seomthing that probably belongs to the former
> >> century..:-)
> > I don't think that d-i should be on the leading edge of this discussion.
> > Once Debian has made up its mind, d-i can be updated to follow the
> > consensus.
> To me it looks like there is broad consensus that a separate /usr
> partition should be considered deprecated and this option removed from
> the installer.
There isn't. There's just a broad consensus among those who are talking
> On 16.12.2011 18:38, Joey Hess wrote:
> > Christian PERRIER wrote:
> >> I'm inclined to follow this advice and would indeed propose that the
> >> "atomic" partman-auto recipe is kept, however without a separate /usr
> >> partition (discussions on -devel and the current practice convinced me
> >> that a separate /usr is seomthing that probably belongs to the former
> >> century..:-)
> > I don't think that d-i should be on the leading edge of this discussion.
> > Once Debian has made up its mind, d-i can be updated to follow the
> > consensus.
> To me it looks like there is broad consensus that a separate /usr
> partition should be considered deprecated and this option removed from
> the installer.
about changing things.
Some of us think this is completely bogus and are really sick of the same
already-rebutted arguments being repeated over and over on the list as if
that makes them true.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Christian PERRIER
Dec 16, 2011, 1:50:01 PM12/16/11
to
Quoting Michael Biebl (bi...@debian.org):
> > I don't think that d-i should be on the leading edge of this discussion.
> > Once Debian has made up its mind, d-i can be updated to follow the
> > consensus.
>
> To me it looks like there is broad consensus that a separate /usr
> partition should be considered deprecated and this option removed from
> the installer.
That was my feeling too (consensus about dropping a strong support for
> > I don't think that d-i should be on the leading edge of this discussion.
> > Once Debian has made up its mind, d-i can be updated to follow the
> > consensus.
>
> To me it looks like there is broad consensus that a separate /usr
> partition should be considered deprecated and this option removed from
> the installer.
a separate /usr by keeping it in the atomic recipe). Which is why I
think we can do it now. As of now, I have seen Thomas Goirand strongly
advocating *for* the *possibility* of a separate /usr....which will
still be possible (just less convenient if we drop it from the atomic
recipe).
After all, by dropping the separate /usr in the atomic recipe, we
don't make it impossible, we make it less easy to do.
Josh Triplett
Dec 16, 2011, 2:00:02 PM12/16/11
to
On Fri, Dec 16, 2011 at 09:11:22PM +0800, Thomas Goirand wrote:
> On 12/16/2011 04:46 AM, Josh Triplett wrote:
> > In all of the recent discussions about separate /usr partitions, most
> > people seem to acknowledge them as unusual, special-purpose
> > configurations, even those who use them.
>
> I do *not* agree that there's such a consensus.
Hence why I said "most people" (because I didn't want to imply
> On 12/16/2011 04:46 AM, Josh Triplett wrote:
> > In all of the recent discussions about separate /usr partitions, most
> > people seem to acknowledge them as unusual, special-purpose
> > configurations, even those who use them.
>
> I do *not* agree that there's such a consensus.
unanimity), but there's a difference between "consensus" and "complete
lack of dissent". In any case, note that I specifically mentioned
separate /usr as a special-purpose configuration, not other separate
partitions. I don't want to argue here that no possible reason exists
for separate /usr (that seems like another argument entirely, and a
mostly orthogonal one); I simply suggested that it represents an
uncommon configuration. Do you really disagree with the statement
that separate /usr represents an uncommon configuration?
> On 12/16/2011 04:46 AM, Josh Triplett wrote:
> > Meanwhile, we don't want to steer any new users towards a setup with a
> > pile of different partitions, which makes their system more complex with
> > more potential failure modes.
>
> I hope that we are still the universal operating system,
> and that we don't want to force anyone to do anything.
> If I want to use many partitions, this is *my* call, and
> not everyone's business. Please don't try to force your
> view on partitioning to anyone.
suggested a change to the guided partitioner, which exists to make the
most common partition configurations easy, and to steer new Debian users
in the direction of configurations which will work well for them and not
give them too much trouble.
A configuration with everything in one partition needs no extra
configuration; anyone who wants such a configuration will like what the
guided partitioner comes up with. A configuration with five separate
partitions seems almost impossible to provide sensible proportions for
that work for everyone without editing. And getting the proportions
wrong means people have to deal with strange and annoying cases like
/var filling up when /home has tons of room, or / filling up when /usr
has tons of room.
> > In the most recent thread, I noticed that someone mentioned they
> > primarily chose a setup with a separate /usr partition because the
> > installer offered such a setup as one of the standard guided
> > partitioning options.
> >
> > Please consider removing the option in the guided partitioner for
> > separate /usr, /var, and /tmp partitions; that would leave only the "All
> > files in one partition" and "Separate /home partition" setups, both of
> > which potentially make sense for users of the guided partitioner.
>
> Please don't remove the above option, I like it, and I
> don't see why it needs to be removed just because
> you Josh (and maybe others) don't like/use it.
Sometimes it makes sense to optimize for the common and recommended
case, as long as the uncommon case remains *possible*, which it does
here. (And sometimes it even makes sense to optimize for the common and
recommended case by making the uncommon case impossible, but note that I
didn't suggest that in this case.)
> You feel like a separate partition for /home is useful.
> Good for you, and your desktop. But when it comes
> to servers, the /home separate partition is useless,
> and having a separate /var makes things faster.
makes /home, /usr, /var, and /tmp all separate partitions. You just
said you don't want a separate /home, and you do want a separate /var.
Thus, you have custom requirements that don't fit the guided option, and
you'd need to use the manual partitioner instead. I argue that the same
holds true for almost anyone who might want something similar to that
guided option: they don't actually want what the guided option provides.
> Also, having a separate /tmp avoids that the rootfs
> gets full, and I consider it quite important especially
> on servers. I would recommend using it for absolutely
> *every* setup (desktop or servers) as a security measure,
> especially considering any application can fill up the
> temp space.
Also, it really doesn't matter for single-user systems, only for
multi-user systems with untrusted users.
> > Anyone desiring a setup with more separate partitions should have no
> > trouble using the manual partitioner to create whatever custom
> > configuration they desire.
>
> And we have even less trouble using the automated option,
> also it's a way faster than doing it manually. Please don't
> remove it.
>
> Again, the way *I* and *others* use my/their computers
> is their choice. Please do not remove this choice from
> me/them.
care about. From the configure --enable-foo options of every random
package to the default set of installed packages, Debian makes it so you
don't have to answer 69105 questions before getting any work done.
Linux is not about choice.
https://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html
Keep in mind that the installer used to ask several times as many
questions as it does now. Debian has managed to improve it drastically,
and in doing so removed some choices that I'd bet a non-zero number of
people in the universe cared about. As a net result, the installer now
proves simpler and easier to deal with for everyone.
- Josh Triplett
Russ Allbery
Dec 16, 2011, 2:10:02 PM12/16/11
to
Michael Biebl <bi...@debian.org> writes:
> On 16.12.2011 18:38, Joey Hess wrote:
>> Christian PERRIER wrote:
>>> I'm inclined to follow this advice and would indeed propose that the
>>> "atomic" partman-auto recipe is kept, however without a separate /usr
>>> partition (discussions on -devel and the current practice convinced me
>>> that a separate /usr is seomthing that probably belongs to the former
>>> century..:-)
>> I don't think that d-i should be on the leading edge of this
>> discussion. Once Debian has made up its mind, d-i can be updated to
>> follow the consensus.
> To me it looks like there is broad consensus that a separate /usr
> partition should be considered deprecated and this option removed from
> the installer.
There's a bit of disagreement over the deprecation part still, but I think
> On 16.12.2011 18:38, Joey Hess wrote:
>> Christian PERRIER wrote:
>>> I'm inclined to follow this advice and would indeed propose that the
>>> "atomic" partman-auto recipe is kept, however without a separate /usr
>>> partition (discussions on -devel and the current practice convinced me
>>> that a separate /usr is seomthing that probably belongs to the former
>>> century..:-)
>> I don't think that d-i should be on the leading edge of this
>> discussion. Once Debian has made up its mind, d-i can be updated to
>> follow the consensus.
> To me it looks like there is broad consensus that a separate /usr
> partition should be considered deprecated and this option removed from
> the installer.
there's a pretty good consensus that people with a separate /usr from /
are doing so for fairly edge-case situations, such as wanting a partially
encrypted file system, and hence are not the target audience for the
pre-constructed partitioning choices in d-i.
Marco d'Itri
Dec 16, 2011, 2:40:01 PM12/16/11
to
On Dec 16, Josh Triplett <jo...@joshtriplett.org> wrote:
> A configuration with everything in one partition needs no extra
> configuration; anyone who wants such a configuration will like what the
> guided partitioner comes up with. A configuration with five separate
> partitions seems almost impossible to provide sensible proportions for
> that work for everyone without editing. And getting the proportions
> wrong means people have to deal with strange and annoying cases like
> /var filling up when /home has tons of room, or / filling up when /usr
> has tons of room.
+1
> A configuration with everything in one partition needs no extra
> configuration; anyone who wants such a configuration will like what the
> guided partitioner comes up with. A configuration with five separate
> partitions seems almost impossible to provide sensible proportions for
> that work for everyone without editing. And getting the proportions
> wrong means people have to deal with strange and annoying cases like
> /var filling up when /home has tons of room, or / filling up when /usr
> has tons of room.
> That line of reasoning would never let Debian remove *anything*, ever.
Debian.
--
ciao,
Marco
Joey Hess
Dec 16, 2011, 2:40:01 PM12/16/11
to
Josh Triplett wrote:
> Exactly my point, then. The guided partitioning option I mentioned
> makes /home, /usr, /var, and /tmp all separate partitions. You just
> said you don't want a separate /home, and you do want a separate /var.
> Thus, you have custom requirements that don't fit the guided option, and
> you'd need to use the manual partitioner instead. I argue that the same
> holds true for almost anyone who might want something similar to that
> guided option: they don't actually want what the guided option provides.
That's not how d-i's partitioner works. You can select a recipe and
> Exactly my point, then. The guided partitioning option I mentioned
> makes /home, /usr, /var, and /tmp all separate partitions. You just
> said you don't want a separate /home, and you do want a separate /var.
> Thus, you have custom requirements that don't fit the guided option, and
> you'd need to use the manual partitioner instead. I argue that the same
> holds true for almost anyone who might want something similar to that
> guided option: they don't actually want what the guided option provides.
then modify the partition scheme it generates to meet your exact needs.
> Keep in mind that the installer used to ask several times as many
> questions as it does now. Debian has managed to improve it drastically,
> and in doing so removed some choices that I'd bet a non-zero number of
> people in the universe cared about. As a net result, the installer now
> proves simpler and easier to deal with for everyone.
current list where the user choses from some common recipes, or chooses
to fully manually partition. Since we *have* to ask a question that
provides that last option, providing the other options is free from a
number of questions POV.
--
see shy jo
Thomas Goirand
Dec 16, 2011, 3:20:02 PM12/16/11
to
Hi Josh,
Seems you're as much passionate about this topic as I am! :)
At this point, I don't remotely hope to convince you, but perhaps you
will find some of my points valid.
On 12/17/2011 02:46 AM, Josh Triplett wrote:
> Hence why I said "most people" (because I didn't want to imply
> unanimity), but there's a difference between "consensus" and "complete
> lack of dissent". In any case, note that I specifically mentioned
> separate /usr as a special-purpose configuration, not other separate
> partitions. I don't want to argue here that no possible reason exists
> for separate /usr (that seems like another argument entirely, and a
> mostly orthogonal one); I simply suggested that it represents an
> uncommon configuration. Do you really disagree with the statement
> that separate /usr represents an uncommon configuration?
>
>> On 12/16/2011 04:46 AM, Josh Triplett wrote:
>>> Meanwhile, we don't want to steer any new users towards a setup with a
>>> pile of different partitions, which makes their system more complex with
>>> more potential failure modes.
>>
>> I hope that we are still the universal operating system,
>> and that we don't want to force anyone to do anything.
>> If I want to use many partitions, this is *my* call, and
>> not everyone's business. Please don't try to force your
>> view on partitioning to anyone.
>
> Nobody stops you from using as many partitions as you like. I've
> suggested a change to the guided partitioner, which exists to make the
> most common partition configurations easy, and to steer new Debian users
> in the direction of configurations which will work well for them and not
> give them too much trouble.
But I do not agree with your steering, just for the sake of making it
more easy. We shouldn't only target "most common partition
configurations easy", there's isn't a "one solution fits all", but
really some choice depending on your needs. Showing to our users that
separate /usr, /var, /tmp and /home can be a good choice is also
important to me.
Pushing users to do encryption would also be great. The Debian installer
shouldn't only aim to be easy: it should do the job and do it well.
I'd be happy if we had a partionner which could do as much as we can
with right now with partman (which is: a lot!), just more efficiently.
In other words: I'd like to do more complicated things faster.
> A configuration with everything in one partition needs no extra
> configuration; anyone who wants such a configuration will like what the
> guided partitioner comes up with.
Of course, anyone who wants X will like X... What if I like Y?
> A configuration with five separate
> partitions seems almost impossible to provide sensible proportions for
> that work for everyone without editing. And getting the proportions
> wrong means people have to deal with strange and annoying cases like
> /var filling up when /home has tons of room, or / filling up when /usr
> has tons of room.
Sometimes, you just don't care about partition sizes, you just want them
to be there automatically (as long as there's a separate /var and /tmp...).
But well anyway, that's a valid reason for giving *more* template
choices and control in partman not less! :) Indeed, I'd be cool to
select such layout, then just quickly just enter sizes on the LVM,
without having to define types and mount points manually (which takes
soooooo muuuuuuch time).
I have tried multiple times to convince Otavio at the last Debconf11
that I believed partman should also be providing templates with RAID1 /
RAID10 setups, since a lot of people are using it in the server room. I
had a hard time, and I think he stand in your side for less choices,
since his answer was that I should make a custom ISO for myself (which
doesn't satisfy me, really).
>>> Please consider removing the option in the guided partitioner for
>>> separate /usr, /var, and /tmp partitions; that would leave only the "All
>>> files in one partition" and "Separate /home partition" setups, both of
>>> which potentially make sense for users of the guided partitioner.
>>
>> Please don't remove the above option, I like it, and I
>> don't see why it needs to be removed just because
>> you Josh (and maybe others) don't like/use it.
>
> That line of reasoning would never let Debian remove *anything*, ever.
We have debconf priority and the expert install mode for a reason. If
you said you want to remove some templates from the non-expert
installer, then I'd say it's a good idea. But not for the expert mode.
>> You feel like a separate partition for /home is useful.
>
> Actually, I don't, but I didn't advocate that today. :)
>
>> Good for you, and your desktop. But when it comes
>> to servers, the /home separate partition is useless,
>> and having a separate /var makes things faster.
>
> Exactly my point, then. The guided partitioning option I mentioned
> makes /home, /usr, /var, and /tmp all separate partitions. You just
> said you don't want a separate /home, and you do want a separate /var.
> Thus, you have custom requirements that don't fit the guided option, and
> you'd need to use the manual partitioner instead. I argue that the same
> holds true for almost anyone who might want something similar to that
> guided option: they don't actually want what the guided option provides.
If your point is to say that partman can do everything BUT it's GUI
isn't convenient, then would agree. I'd really love to have more
predefined templates, and only change sizes only, and there really,
partman missed the point of templates. On an average server install, I
spend like half of my time in it. Ideally, it'd be really a cool feature
to be able to scp/ftp an HDD template directly from the installer (both
ways: load and save).
>> Also, having a separate /tmp avoids that the rootfs
>> gets full, and I consider it quite important especially
>> on servers. I would recommend using it for absolutely
>> *every* setup (desktop or servers) as a security measure,
>> especially considering any application can fill up the
>> temp space.
>
> Note that newly installed Debian systems have /tmp on tmpfs by default.
I'm not so sure I will like the "improvement" of eating my RAM when a
program is explicitly asking to write on a storage medium, but we'll see
if I like it. :)
> Also, it really doesn't matter for single-user systems, only for
> multi-user systems with untrusted users.
With untrusted users, I think I'd implement quotas for writing in /tmp
(it was like that under OSF1 10/15 years ago...). But when you have
separate /usr and /var, your rootfs can be very small, so you don't want
any random program, for a valid or an invalid reason, fills your rootfs
with anything until it's full. I've seen MySQL doing that for example,
and was very happy that my dedicated /tmp showed it to me (and that's
only *one* example of what can happen in a normal usage of a computer
running Debian).
> Distributions *exist* to make choices for you, most of which you don't
> care about.
One of the reason I like Debian is that it gives me the choice to have
the choice (eg: debconf priority is configurable).
Cheers,
Thomas
Seems you're as much passionate about this topic as I am! :)
At this point, I don't remotely hope to convince you, but perhaps you
will find some of my points valid.
On 12/17/2011 02:46 AM, Josh Triplett wrote:
> Hence why I said "most people" (because I didn't want to imply
> unanimity), but there's a difference between "consensus" and "complete
> lack of dissent". In any case, note that I specifically mentioned
> separate /usr as a special-purpose configuration, not other separate
> partitions. I don't want to argue here that no possible reason exists
> for separate /usr (that seems like another argument entirely, and a
> mostly orthogonal one); I simply suggested that it represents an
> uncommon configuration. Do you really disagree with the statement
> that separate /usr represents an uncommon configuration?
>
>> On 12/16/2011 04:46 AM, Josh Triplett wrote:
>>> Meanwhile, we don't want to steer any new users towards a setup with a
>>> pile of different partitions, which makes their system more complex with
>>> more potential failure modes.
>>
>> I hope that we are still the universal operating system,
>> and that we don't want to force anyone to do anything.
>> If I want to use many partitions, this is *my* call, and
>> not everyone's business. Please don't try to force your
>> view on partitioning to anyone.
>
> Nobody stops you from using as many partitions as you like. I've
> suggested a change to the guided partitioner, which exists to make the
> most common partition configurations easy, and to steer new Debian users
> in the direction of configurations which will work well for them and not
> give them too much trouble.
more easy. We shouldn't only target "most common partition
configurations easy", there's isn't a "one solution fits all", but
really some choice depending on your needs. Showing to our users that
separate /usr, /var, /tmp and /home can be a good choice is also
important to me.
Pushing users to do encryption would also be great. The Debian installer
shouldn't only aim to be easy: it should do the job and do it well.
I'd be happy if we had a partionner which could do as much as we can
with right now with partman (which is: a lot!), just more efficiently.
In other words: I'd like to do more complicated things faster.
> A configuration with everything in one partition needs no extra
> configuration; anyone who wants such a configuration will like what the
> guided partitioner comes up with.
> A configuration with five separate
> partitions seems almost impossible to provide sensible proportions for
> that work for everyone without editing. And getting the proportions
> wrong means people have to deal with strange and annoying cases like
> /var filling up when /home has tons of room, or / filling up when /usr
> has tons of room.
to be there automatically (as long as there's a separate /var and /tmp...).
But well anyway, that's a valid reason for giving *more* template
choices and control in partman not less! :) Indeed, I'd be cool to
select such layout, then just quickly just enter sizes on the LVM,
without having to define types and mount points manually (which takes
soooooo muuuuuuch time).
I have tried multiple times to convince Otavio at the last Debconf11
that I believed partman should also be providing templates with RAID1 /
RAID10 setups, since a lot of people are using it in the server room. I
had a hard time, and I think he stand in your side for less choices,
since his answer was that I should make a custom ISO for myself (which
doesn't satisfy me, really).
>>> Please consider removing the option in the guided partitioner for
>>> separate /usr, /var, and /tmp partitions; that would leave only the "All
>>> files in one partition" and "Separate /home partition" setups, both of
>>> which potentially make sense for users of the guided partitioner.
>>
>> Please don't remove the above option, I like it, and I
>> don't see why it needs to be removed just because
>> you Josh (and maybe others) don't like/use it.
>
> That line of reasoning would never let Debian remove *anything*, ever.
you said you want to remove some templates from the non-expert
installer, then I'd say it's a good idea. But not for the expert mode.
>> You feel like a separate partition for /home is useful.
>
> Actually, I don't, but I didn't advocate that today. :)
>
>> Good for you, and your desktop. But when it comes
>> to servers, the /home separate partition is useless,
>> and having a separate /var makes things faster.
>
> Exactly my point, then. The guided partitioning option I mentioned
> makes /home, /usr, /var, and /tmp all separate partitions. You just
> said you don't want a separate /home, and you do want a separate /var.
> Thus, you have custom requirements that don't fit the guided option, and
> you'd need to use the manual partitioner instead. I argue that the same
> holds true for almost anyone who might want something similar to that
> guided option: they don't actually want what the guided option provides.
isn't convenient, then would agree. I'd really love to have more
predefined templates, and only change sizes only, and there really,
partman missed the point of templates. On an average server install, I
spend like half of my time in it. Ideally, it'd be really a cool feature
to be able to scp/ftp an HDD template directly from the installer (both
ways: load and save).
>> Also, having a separate /tmp avoids that the rootfs
>> gets full, and I consider it quite important especially
>> on servers. I would recommend using it for absolutely
>> *every* setup (desktop or servers) as a security measure,
>> especially considering any application can fill up the
>> temp space.
>
> Note that newly installed Debian systems have /tmp on tmpfs by default.
program is explicitly asking to write on a storage medium, but we'll see
if I like it. :)
> Also, it really doesn't matter for single-user systems, only for
> multi-user systems with untrusted users.
(it was like that under OSF1 10/15 years ago...). But when you have
separate /usr and /var, your rootfs can be very small, so you don't want
any random program, for a valid or an invalid reason, fills your rootfs
with anything until it's full. I've seen MySQL doing that for example,
and was very happy that my dedicated /tmp showed it to me (and that's
only *one* example of what can happen in a normal usage of a computer
running Debian).
> Distributions *exist* to make choices for you, most of which you don't
> care about.
the choice (eg: debconf priority is configurable).
Cheers,
Thomas
Josh Triplett
Dec 16, 2011, 4:20:02 PM12/16/11
to
On Sat, Dec 17, 2011 at 04:13:50AM +0800, Thomas Goirand wrote:
> Seems you're as much passionate about this topic as I am! :)
> At this point, I don't remotely hope to convince you, but perhaps you
> will find some of my points valid.
Likewise. :)
> Seems you're as much passionate about this topic as I am! :)
> At this point, I don't remotely hope to convince you, but perhaps you
> will find some of my points valid.
your preferred partitioning scheme, even though it doesn't represent a
common configuration.
The guided partitioner exists in large part to say "If you don't have
custom needs, we recommend this configuration". And while we might
debate the usefulness of a separate /usr back and forth, I think I can
safely say that it won't become a *recommended* configuration anytime
soon. :)
That represents the primary reason I filed this bug: to ensure that
people only end up with a separate /usr if they actively want one, not
because they saw the option in the installer and didn't know any better.
> Pushing users to do encryption would also be great. The Debian installer
> shouldn't only aim to be easy: it should do the job and do it well.
of making it the default (and while I wish we could do that, I can see
a number of good reasons why we can't, not least of which systems that
need to boot unattended).
For the installer, "easy" represents a significant component of "do the
job and do it well". I still remember doing installs via boot-floppies.
It certainly offered quite a lot more choices. :)
> I'd be happy if we had a partionner which could do as much as we can
> with right now with partman (which is: a lot!), just more efficiently.
> In other words: I'd like to do more complicated things faster.
However, I also don't think that should stop us from optimizing for the
common case.
> > A configuration with everything in one partition needs no extra
> > configuration; anyone who wants such a configuration will like what the
> > guided partitioner comes up with.
>
> Of course, anyone who wants X will like X... What if I like Y?
option that gives you X. If you prefer Y, it doesn't necessarily help
you to have an option for Z, any more than it helps you to have an
option for X.
> > A configuration with five separate
> > partitions seems almost impossible to provide sensible proportions for
> > that work for everyone without editing. And getting the proportions
> > wrong means people have to deal with strange and annoying cases like
> > /var filling up when /home has tons of room, or / filling up when /usr
> > has tons of room.
>
> Sometimes, you just don't care about partition sizes, you just want them
> to be there automatically (as long as there's a separate /var and /tmp...).
waste a pile of space with mostly empty partitions. Personally, when I
have a 1TB disk, I'd still like to have the ability to use 99% of that
for the contents of /home, and at the same time as long as I haven't
done so yet I'd like to have that space available for use in / or /usr
or /var or /tmp or /srv.
> But well anyway, that's a valid reason for giving *more* template
> choices and control in partman not less! :) Indeed, I'd be cool to
> select such layout, then just quickly just enter sizes on the LVM,
> without having to define types and mount points manually (which takes
> soooooo muuuuuuch time).
partition", I find that it takes more time to clean up after the guided
partitioner than to just create what I want from scratch.
I would actually advocate having a pile of convenient templates, but not
offered as part of the guided partitioner, just as an option from within
the manual partitioner. In other words, I'd love to see a menu
structure that looks like this (structure, not necessarily exact
wording):
Partition layout: [all in one] [all in one with encryption]
[custom/manual] For the first two options, just confirm the result and
proceed. For "custom/manual", open the manual partitioner, and have a
prominent option to apply a template. The template, rather than
offering a linear list of some subset of 2^N options, could actually ask
"what do you want as a separate partition: [ ] /home [ ] /tmp [ ] /var
...", and make it easy to configure the individual sizes.
That makes the most straightforward options simpler (one less question),
and makes the complex options simpler as well. However, it also
represents a significantly larger change, and I don't want to see small
improvements put on hold waiting for a massive overhaul like that.
> I have tried multiple times to convince Otavio at the last Debconf11
> that I believed partman should also be providing templates with RAID1 /
> RAID10 setups, since a lot of people are using it in the server room. I
> had a hard time, and I think he stand in your side for less choices,
> since his answer was that I should make a custom ISO for myself (which
> doesn't satisfy me, really).
we come up with a template that will actually work for many people
without requiring manual editing afterward?
I suspect the right solution for that would involve a friendly RAID
configuration option which let you first pick the RAID you want, and
then mark areas of free space that you want included, rather than having
to create partitions, mark them as RAID components, and then create a
RAID device containing them. In any case, that seems less like a
template and more like a custom partitioner option.
> >>> Please consider removing the option in the guided partitioner for
> >>> separate /usr, /var, and /tmp partitions; that would leave only the "All
> >>> files in one partition" and "Separate /home partition" setups, both of
> >>> which potentially make sense for users of the guided partitioner.
> >>
> >> Please don't remove the above option, I like it, and I
> >> don't see why it needs to be removed just because
> >> you Josh (and maybe others) don't like/use it.
> >
> > That line of reasoning would never let Debian remove *anything*, ever.
>
> We have debconf priority and the expert install mode for a reason. If
> you said you want to remove some templates from the non-expert
> installer, then I'd say it's a good idea. But not for the expert mode.
questions. But yes, if I can't successfully argue that this particular
template in the guided partitioner should go away, I plan to suggest
that it should not appear when not in expert mode. That would certainly
satisfy my original goal: ensuring that people don't accidentally end up
with a "pile of partitions" configuration without actively wanting one.
> >> You feel like a separate partition for /home is useful.
> >
> > Actually, I don't, but I didn't advocate that today. :)
> >
> >> Good for you, and your desktop. But when it comes
> >> to servers, the /home separate partition is useless,
> >> and having a separate /var makes things faster.
> >
> > Exactly my point, then. The guided partitioning option I mentioned
> > makes /home, /usr, /var, and /tmp all separate partitions. You just
> > said you don't want a separate /home, and you do want a separate /var.
> > Thus, you have custom requirements that don't fit the guided option, and
> > you'd need to use the manual partitioner instead. I argue that the same
> > holds true for almost anyone who might want something similar to that
> > guided option: they don't actually want what the guided option provides.
>
> If your point is to say that partman can do everything BUT it's GUI
> isn't convenient, then would agree.
recipe I've advocated the removal of doesn't actually do what you want
anyway.
> I'd really love to have more
> predefined templates, and only change sizes only, and there really,
> partman missed the point of templates. On an average server install, I
> spend like half of my time in it.
templates in partman, with more pluggable parameters such as partition
sizes. In the meantime, I think the existing "pile of partitions"
template does more harm than good, not least of which because it doesn't
have a giant "don't use if you don't know what you're doing" warning
attached to it. How do you expect a novice Debian user to deal with
obscure problems like "d-i created a tiny / partition and it filled up"?
> Ideally, it'd be really a cool feature
> to be able to scp/ftp an HDD template directly from the installer (both
> ways: load and save).
great idea; if nothing else, perhaps the installer could save a sample
recipe next to the install log on the installed system. As for loading
one, I'd suggest loading a d-i preseed file. You can boot the installer
with url=http://example.org/d-i to load an arbitrary preseed file and
pre-answer a pile of questions to save yourself time. That preseed file
can include an arbitrarily complex partman-auto recipe. And you don't
have to make a custom CD, though you may want to if you install enough
systems that typing the boot parameter gets annoying.
Tell you what: if you can describe the partitioning setup you actually
want with sufficient precision, I'll help you write a partman recipe and
explain how to put it somewhere that d-i preseeding can find. :)
> >> Also, having a separate /tmp avoids that the rootfs
> >> gets full, and I consider it quite important especially
> >> on servers. I would recommend using it for absolutely
> >> *every* setup (desktop or servers) as a security measure,
> >> especially considering any application can fill up the
> >> temp space.
> >
> > Note that newly installed Debian systems have /tmp on tmpfs by default.
>
> I'm not so sure I will like the "improvement" of eating my RAM when a
> program is explicitly asking to write on a storage medium, but we'll see
> if I like it. :)
personally. I have a (probably bad) habit of storing things there. One
of these days I'll break that habit, at which point I'll probably like
having /tmp as a tmpfs, but for now I always edit /etc/default/rcS on
every new system and set TMPTIME=infinite. I also recognize that as the
uncommon case. :)
> > Also, it really doesn't matter for single-user systems, only for
> > multi-user systems with untrusted users.
>
> With untrusted users, I think I'd implement quotas for writing in /tmp
> (it was like that under OSF1 10/15 years ago...). But when you have
> separate /usr and /var, your rootfs can be very small, so you don't want
> any random program, for a valid or an invalid reason, fills your rootfs
> with anything until it's full. I've seen MySQL doing that for example,
> and was very happy that my dedicated /tmp showed it to me (and that's
> only *one* example of what can happen in a normal usage of a computer
> running Debian).
:)
Modern systems seem to cope just fine with near-full disks, and provide
appropriate warnings to users to help them clean things up. And
applications which spew unbounded amounts of data to /tmp need fixing.
> > Distributions *exist* to make choices for you, most of which you don't
> > care about.
>
> One of the reason I like Debian is that it gives me the choice to have
> the choice (eg: debconf priority is configurable).
and the hard things possible". In this case, I'd like to make the easy
things easier, while continuing to leave the hard things possible.
- Josh Triplett
Thomas Goirand
Dec 17, 2011, 4:50:02 AM12/17/11
to
On 12/17/2011 05:12 AM, Josh Triplett wrote:
> And while we might
> debate the usefulness of a separate /usr back and forth, I think I can
> safely say that it won't become a *recommended* configuration anytime
> soon. :)
I do recommend a separate /usr to anyone. It's *not* safe to say that,
> And while we might
> debate the usefulness of a separate /usr back and forth, I think I can
> safely say that it won't become a *recommended* configuration anytime
> soon. :)
and I know many people that agree with me. To me, it has, and still is,
the best choice. You have no rights to arbitrary decide what should
be/was/will be the recommended configuration. Your choice is not more
valid than mine, and (computer) science isn't about majorities anyway.
On 12/17/2011 05:12 AM, Josh Triplett wrote:
> For the installer, "easy" represents a significant component of
> "do the job and do it well".
> Sure; see below for a more detailed suggestion along these lines.
> However, I also don't think that should stop us from optimizing
> for the common case.
Well, commonly, for a desktop computer, I recommend separated /usr,
> However, I also don't think that should stop us from optimizing
> for the common case.
/var, /tmp and /home. Reasonably, if you put enough space for it (for
example, 16GB for usr, 8GB for var, 1GB for tmp) then you can set the
rest for /home. Today's HDD are really big, and in most cases, this
setup will work very well for a desktop, and you'll be able to install a
really insane amount of software without filling up /usr or /var. If you
then lack space, LVM is there.
Doing this has many advantage. Like, if your laptop has to unexpectedly
reboot (like when you inadvertently removed power cord when batteries
were not plugged, which happens often in real life), having separated
partitions usually makes the fsck faster. Only some of the partitions
may have dirty bits to clean, and there's a very good chance your /usr
(which holds a lot of files and is long to check) doesn't even need a
check. That alone is a cool feature that justifies having a separate
/usr for me.
When it comes to *real* newbies (here, I'm thinking about people like my
father in law or my wife who really, don't want to know what is
partitionning), they wont go to hit corner cases and fill any of the
partitions of their HDD anyway. For them, I see no issue "wasting" a bit
of space on multiple hundreds of GB space that will anyway never be used.
> Only in the case where you have such a big disk that you can afford to
In most general cases nowadays, we *do* have huge disks. Just have a
look into what's available in the marketplace. If you lack space in one
of the default partitions, you can resize using LVM anyway.
Thomas
Otavio Salvador
Dec 17, 2011, 3:50:01 PM12/17/11
to
On Sat, Dec 17, 2011 at 07:42, Thomas Goirand <zi...@debian.org> wrote:
On 12/17/2011 05:12 AM, Josh Triplett wrote:I do recommend a separate /usr to anyone. It's *not* safe to say that,
> And while we might
> debate the usefulness of a separate /usr back and forth, I think I can
> safely say that it won't become a *recommended* configuration anytime
> soon. :)
and I know many people that agree with me. To me, it has, and still is,
the best choice. You have no rights to arbitrary decide what should
be/was/will be the recommended configuration. Your choice is not more
valid than mine, and (computer) science isn't about majorities anyway.
Sure but Debian Installer defaults are. End point.
...In most general cases nowadays, we *do* have huge disks. Just have a
look into what's available in the marketplace. If you lack space in one
of the default partitions, you can resize using LVM anyway.
New users will think LVM is something to eat with bread or similar. This is mostly as if I starting to try to convince to use Awesome WM as default desktop install because I think it is more user-friendly (and it is, for my type of use, but not for general use).
I do think you ought to stop to try to push your personal opinion too hard... it is clear on this thread that most people do not agree with you so lets go ahead and move topic.
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Josh Triplett
Dec 17, 2011, 4:00:02 PM12/17/11
to
On Sat, Dec 17, 2011 at 05:42:59PM +0800, Thomas Goirand wrote:
> On 12/17/2011 05:12 AM, Josh Triplett wrote:
> > And while we might
> > debate the usefulness of a separate /usr back and forth, I think I can
> > safely say that it won't become a *recommended* configuration anytime
> > soon. :)
>
> I do recommend a separate /usr to anyone. It's *not* safe to say that,
> and I know many people that agree with me. To me, it has, and still is,
> the best choice. You have no rights to arbitrary decide what should
> be/was/will be the recommended configuration. Your choice is not more
> valid than mine, and (computer) science isn't about majorities anyway.
Let me clarify: I can safely say it won't become *Debian's* recommended
> On 12/17/2011 05:12 AM, Josh Triplett wrote:
> > And while we might
> > debate the usefulness of a separate /usr back and forth, I think I can
> > safely say that it won't become a *recommended* configuration anytime
> > soon. :)
>
> I do recommend a separate /usr to anyone. It's *not* safe to say that,
> and I know many people that agree with me. To me, it has, and still is,
> the best choice. You have no rights to arbitrary decide what should
> be/was/will be the recommended configuration. Your choice is not more
> valid than mine, and (computer) science isn't about majorities anyway.
configuration anytime soon. It has strong enough arguments against it
that while a vocal minority might manage to keep it around, I doubt
it will become the default. The discussion would have to change quite
drastically for that to occur.
> On 12/17/2011 05:12 AM, Josh Triplett wrote:
> > For the installer, "easy" represents a significant component of
> > "do the job and do it well".
> > Sure; see below for a more detailed suggestion along these lines.
> > However, I also don't think that should stop us from optimizing
> > for the common case.
>
> Well, commonly, for a desktop computer, I recommend separated /usr,
> /var, /tmp and /home. Reasonably, if you put enough space for it (for
> example, 16GB for usr, 8GB for var, 1GB for tmp) then you can set the
> rest for /home. Today's HDD are really big, and in most cases, this
> setup will work very well for a desktop, and you'll be able to install a
> really insane amount of software without filling up /usr or /var. If you
> then lack space, LVM is there.
SSDs. Netbooks often have even less than that. Wasting ~20GB of that
seems excessive.
And do you seriously expect the average user to go through the process
of an LVM resize? "Possible" doesn't mean "easy".
> Doing this has many advantage. Like, if your laptop has to unexpectedly
> reboot (like when you inadvertently removed power cord when batteries
> were not plugged, which happens often in real life), having separated
> partitions usually makes the fsck faster. Only some of the partitions
> may have dirty bits to clean, and there's a very good chance your /usr
> (which holds a lot of files and is long to check) doesn't even need a
> check. That alone is a cool feature that justifies having a separate
> /usr for me.
the filesystem). Also, unless you've mounted some of those partitions
read-only, they'll all always need fsck when not cleanly shut down.
> When it comes to *real* newbies (here, I'm thinking about people like my
> father in law or my wife who really, don't want to know what is
> partitionning), they wont go to hit corner cases and fill any of the
> partitions of their HDD anyway. For them, I see no issue "wasting" a bit
> of space on multiple hundreds of GB space that will anyway never be used.
don't want to think about advanced concepts like partitioning and the
set of users quite capable of filling a disk and installing piles of
software. If you really don't want to know about partitioning, you
don't want to deal with situations where you have plenty of free space
but not on the partitions where you need it.
> > Only in the case where you have such a big disk that you can afford to
> > waste a pile of space with mostly empty partitions. Personally [...]
>
> In most general cases nowadays, we *do* have huge disks. Just have a
> look into what's available in the marketplace. If you lack space in one
> of the default partitions, you can resize using LVM anyway.
that the non-/home partitions will never fill up, and we don't want to
inflict partition resizes on most users unnecessarily.
- Josh Triplett
Goswin von Brederlow
Dec 21, 2011, 8:30:02 AM12/21/11
to
Steve Langasek <vor...@debian.org> writes:
> On Fri, Dec 16, 2011 at 07:32:35PM +0100, Michael Biebl wrote:
>> On 16.12.2011 18:38, Joey Hess wrote:
>> > Christian PERRIER wrote:
>> >> I'm inclined to follow this advice and would indeed propose that the
>> >> "atomic" partman-auto recipe is kept, however without a separate /usr
>> >> partition (discussions on -devel and the current practice convinced me
>> >> that a separate /usr is seomthing that probably belongs to the former
>> >> century..:-)
>
>> > I don't think that d-i should be on the leading edge of this discussion.
>> > Once Debian has made up its mind, d-i can be updated to follow the
>> > consensus.
>
>> To me it looks like there is broad consensus that a separate /usr
>> partition should be considered deprecated and this option removed from
>> the installer.
>
> There isn't. There's just a broad consensus among those who are talking
> about changing things.
>
> Some of us think this is completely bogus and are really sick of the same
> already-rebutted arguments being repeated over and over on the list as if
> that makes them true.
Then please once more for the record speak up and tell us why / and /usr
> On Fri, Dec 16, 2011 at 07:32:35PM +0100, Michael Biebl wrote:
>> On 16.12.2011 18:38, Joey Hess wrote:
>> > Christian PERRIER wrote:
>> >> I'm inclined to follow this advice and would indeed propose that the
>> >> "atomic" partman-auto recipe is kept, however without a separate /usr
>> >> partition (discussions on -devel and the current practice convinced me
>> >> that a separate /usr is seomthing that probably belongs to the former
>> >> century..:-)
>
>> > I don't think that d-i should be on the leading edge of this discussion.
>> > Once Debian has made up its mind, d-i can be updated to follow the
>> > consensus.
>
>> To me it looks like there is broad consensus that a separate /usr
>> partition should be considered deprecated and this option removed from
>> the installer.
>
> There isn't. There's just a broad consensus among those who are talking
> about changing things.
>
> Some of us think this is completely bogus and are really sick of the same
> already-rebutted arguments being repeated over and over on the list as if
> that makes them true.
must be seperate partitions?
We are not talking about dropping support for having a seperate /usr
here. Just about D-I not creating / and /usr as seperate partition in
the "make more than one partition" automatic partitioning choice.
It is obvious that Debian still needs to support /usr being
seperate. But that isn't the issue. That is also why I don't agree with
Joey. D-I is the only one that makes the choice for the user and as such
is the one that can change the recepie.
MfG
Goswin
PS: I myself like a seperate /usr but I wouldn't use it for my parents.
I do want a seperate /var and /home for them though so they can't DOS
the system by filling up their home.
Raphael Geissert
Dec 25, 2011, 11:30:02 PM12/25/11
to
Russell Coker wrote:
> On Thu, 22 Dec 2011, Goswin von Brederlow <goswi...@web.de> wrote:
>> PS: I myself like a seperate /usr but I wouldn't use it for my parents.
>> I do want a seperate /var and /home for them though so they can't DOS
>> the system by filling up their home.
>
> How would filling up /home DOS the system?
At least a couple of years ago if you left /home with no free space, kdm (or
something under the hood) would be unable to create ~/.Xauthority-* files,
making it impossible to log into a graphical session.
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
> On Thu, 22 Dec 2011, Goswin von Brederlow <goswi...@web.de> wrote:
>> PS: I myself like a seperate /usr but I wouldn't use it for my parents.
>> I do want a seperate /var and /home for them though so they can't DOS
>> the system by filling up their home.
>
At least a couple of years ago if you left /home with no free space, kdm (or
something under the hood) would be unable to create ~/.Xauthority-* files,
making it impossible to log into a graphical session.
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Debian Bug Tracking System
Sep 25, 2014, 1:30:02 AM9/25/14
to
Your message dated Thu, 25 Sep 2014 05:03:46 +0000
with message-id <E1XX1DW-...@franck.debian.org>
and subject line Bug#652275: fixed in partman-auto 123
has caused the Debian Bug report #652275,
regarding Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
652275: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652275
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
with message-id <E1XX1DW-...@franck.debian.org>
and subject line Bug#652275: fixed in partman-auto 123
has caused the Debian Bug report #652275,
regarding Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
652275: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652275
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
0 new messages