On 07/01/16 08:36, Paul Wise wrote:
> $something should
> automatically manage the contents of /bin /sbin /lib (/boot?) based on
> the tools needed to mount /usr (perhaps plus some more recovery
> tools)
I really don't think that's a good approach, particularly as a default.
We already have tools
Marc Haber writes:
> Unfortunately, it's emotions that take vendor decisions. Your attitude
> is driving big users towards the paid-for Enterprise Linuxes, be it
> logical or not, be it good engineering or not.
...the ones that have already merged /usr and /?
I'm not sur
Marc Haber writes:
> On Tue, 5 Jan 2016 19:37:03 +0100, Marco d'Itri wrote:
>>On Jan 05, Ian Jackson wrote:
>>
>>> People who have been using a configuration for many years naturally
>>> become upset when they are told that it has been `unsupported' for all
>>> of this time and that, implicitly
On Tue, 5 Jan 2016 19:37:03 +0100, Marco d'Itri wrote:
>On Jan 05, Ian Jackson wrote:
>
>> People who have been using a configuration for many years naturally
>> become upset when they are told that it has been `unsupported' for all
>> of this time and that, implicitly, changes are going to be ma
I am using overlayFS in Limba[1], and it works well (and is really
fast!) for read-only filesystems, read-write sometimes has issues if
you are using multiple OverlayFS layers (which made me adjust the code
so this doesn't happen anymore).
2016-01-06 17:29 GMT+01:00 Jonathan Dowland :
> I wish I c
On Wed, 6 Jan 2016 09:57:26 +, Jonathan Dowland
wrote:
>On Fri, Jan 01, 2016 at 06:20:42PM +0800, Paul Wise wrote:
>> On Thu, Dec 31, 2015 at 8:51 AM, Marco d'Itri wrote:
>>
>> > https://wiki.debian.org/UsrMerge
>>
>> Now that we have union mounts in Linux
>
>Do you mean overlayfs? If so can
While reading the LWN article about this, I had a thought that might
be interesting.
The packages should all install to /usr and $something should
automatically manage the contents of /bin /sbin /lib (/boot?) based on
the tools needed to mount /usr (perhaps plus some more recovery
tools), just lik
On Wed, Jan 06, 2016 at 01:35:13PM +0100, Marco d'Itri wrote:
> On Jan 06, Jonathan Dowland wrote:
>
> > Do you mean overlayfs? If so can you or anyone vouch for its quality?
> > I had been trying it as a docker storage back end and generally found
> > that it was not ready yet.
> Can you be more
On Jan 06 2016, Ian Jackson wrote:
> Nikolaus Rath writes ("Re: support for merged /usr in Debian"):
>> On Jan 05 2016, Ian Jackson wrote:
>> > People who have been using a configuration for many years naturally
>> > become upset when they are told that it h
On Sun, Jan 03, 2016 at 11:55:08PM +0100, Eric Valette wrote:
> Red hat is mainly for servers nowadays with paying support.
As with many Red Hat features, it was first trialled and proven in Fedora, which
is very much used on Desktops:
https://fedoraproject.org/wiki/Features/UsrMove
On 01/06/2016 10:40 AM, Simon McVittie wrote:
On 05/01/16 15:55, Ian Jackson wrote:
Abolishing the distinction between /usr and /
"Merged /usr" is not about removing the distinction between /usr and /,
it's about removing the distinction between subdirectories of /usr and
th
r using / rather than
>> initramfs, or some such.
> Which actually was never proposed. There were some "what if" type
> posts, but noone was mandating a merged /usr anywhere.
What is the advantage of having a optional-merged-/usr?
>From what I understand the main argument fo
On Jan 06, Jonathan Dowland wrote:
> Do you mean overlayfs? If so can you or anyone vouch for its quality?
> I had been trying it as a docker storage back end and generally found
> that it was not ready yet.
Can you be more specific? I only use it to test new packages and it
works for me.
e.g. w
Simon McVittie debian.org> writes:
> I personally think those factors undermine the "/ as recovery" use-case
> so far that the advantages of a merged /usr far outweigh it.
User side note: If people would like to help the recovery use case,
grml-rescueboot is already packa
On Sun, Jan 03, 2016 at 06:39:36AM -0200, Martinx - ジェームズ wrote:
> No ugly symlinks on root file system, no Bash at /usr/bin/bash!
Aesthetically, I find symlinks for /bin etc., in combination with all
binaries in /usr/bin, to be prettier than the current situation. (I'd
find all binaries in /bin t
On Wed, Jan 06, 2016 at 02:56:24AM +0100, Christian Seiler wrote:
> I've backported the two upstream patches that fix this (which amount to
> the same change that your patch does) and have added them with the
> proper metadata attached to them to the git packaging of the policykit
> package.
Thank
On 05/01/16 09:49, Paul Wise wrote:
> On Mon, Jan 4, 2016 at 2:14 AM, Russ Allbery wrote:
>
>> And yet, it works, and it means that we don't have to try to harass a
>> thousand package maintainers into doing essentially untestable busy-work
>> to try to move things around between /usr, /bin, and /
On Fri, Jan 01, 2016 at 06:20:42PM +0800, Paul Wise wrote:
> On Thu, Dec 31, 2015 at 8:51 AM, Marco d'Itri wrote:
>
> > https://wiki.debian.org/UsrMerge
>
> Now that we have union mounts in Linux
Do you mean overlayfs? If so can you or anyone vouch for its quality?
I had been trying it as a dock
On 05/01/16 15:55, Ian Jackson wrote:
> Abolishing the distinction between /usr and /
This seems to be a somewhat frequent point of confusion so, at the risk
of beating a dead horse:
"Merged /usr" is not about removing the distinction between /usr and /,
it's about removi
On 01/06/2016 02:55 AM, Ian Jackson wrote:
> Nikolaus Rath writes ("Re: support for merged /usr in Debian"):
>> On Jan 05 2016, Ian Jackson wrote:
>>> People who have been using a configuration for many years naturally
>>> become upset when they are told t
On Wed, Jan 6, 2016 at 2:42 AM, Tollef Fog Heen wrote:
> The check doesn't seem to be complete, it's not complaining about PAM
> modules needing libcurl or libkrb5 for instance.
Could you file a bug?
--
bye,
pabs
https://wiki.debian.org/PaulWise
On Wed, Jan 6, 2016 at 2:27 AM, Sune Vuorela wrote:
> Does it also catch when for example a udev configuration file wants to
> run an executable living under /usr ?
Doesn't look like it, could you file a bug?
--
bye,
pabs
https://wiki.debian.org/PaulWise
On 01/06/2016 12:54 AM, Adam Borowski wrote:
> For example, policykit-1 FTBFSes on non-systemd architectures
> (#798769)
I'd also like to note that while you provided a patch, you didn't
really provide much context for this - and left a lot of work to the
maintainers when it comes to integrating t
Nikolaus Rath writes ("Re: support for merged /usr in Debian"):
> On Jan 05 2016, Ian Jackson wrote:
> > People who have been using a configuration for many years naturally
> > become upset when they are told that it has been `unsupported' for all
> > of this t
On 01/06/2016 12:54 AM, Adam Borowski wrote:
> On Tue, Jan 05, 2016 at 08:10:00PM +0100, Simon Richter wrote:
>> On 05.01.2016 19:37, Marco d'Itri wrote:
>>
>>> There is a significant difference between concepts like:
>>> - something works for me
>>> - something works
>>
>>> and:
>>> - I want somet
On Tue, Jan 05, 2016 at 08:10:00PM +0100, Simon Richter wrote:
> On 05.01.2016 19:37, Marco d'Itri wrote:
>
> > There is a significant difference between concepts like:
> > - something works for me
> > - something works
>
> > and:
> > - I want something to be supported
> > - the people actually w
On 2016-01-04 11:30, Marc Haber wrote:
On Sun, 3 Jan 2016 22:30:24 +0100, Eric Valette
wrote:
System admins do like using absolute path
for security reasons...
Please also notice that this is the only option for ExecStart in
systemd units. Well played, Lennart.
Similarly skeleton-based init
On Jan 05 2016, Ian Jackson wrote:
> Marco d'Itri writes ("Re: support for merged /usr in Debian"):
>> On Jan 05, Ian Jackson wrote:
>> > or which do mount /usr using / rather than initramfs, or some such.
>>
>> And this has already not been supported
itramfs, or some such.
Which actually was never proposed. There were some "what if" type
posts, but noone was mandating a merged /usr anywhere.
> It seems to me that enough people want Debian to retain the
> flexibility which is gained by the /usr vs / division, that we as a
> p
On 01/03/2016 09:35 PM, Christian Seiler wrote:
> Well, just for the heck of it I wrote a braindead-simple initrd
> implementation in just 300 LOC:
>
> https://gist.github.com/chris-se/e0fbc073fcbd9ac2d7ae
>
> [...]
>
> This is just a proof of concept, [...]
Well, in case anyone's interested:
Hi,
On 05.01.2016 19:37, Marco d'Itri wrote:
> There is a significant difference between concepts like:
> - something works for me
> - something works
> and:
> - I want something to be supported
> - the people actually working on something want to support it
What is the recourse for people who
]] Ian Jackson
> This thread contains a fair few assertions that certain configurations
> are `broken' or `unsupported'; but these assertions sit alongside
> reports from actual users that these configurations do work for them,
> and expressions of the wish that they should continue to do so.
A l
]] Paul Wise
> On Mon, Jan 4, 2016 at 2:14 AM, Russ Allbery wrote:
>
> > And yet, it works, and it means that we don't have to try to harass a
> > thousand package maintainers into doing essentially untestable busy-work
> > to try to move things around between /usr, /bin, and /lib to support a
>
On Jan 05, Ian Jackson wrote:
> People who have been using a configuration for many years naturally
> become upset when they are told that it has been `unsupported' for all
> of this time and that, implicitly, changes are going to be made which
> will break it.
I think that your summary is correc
On 2016-01-05, Paul Wise wrote:
> On Mon, Jan 4, 2016 at 2:14 AM, Russ Allbery wrote:
>
>> And yet, it works, and it means that we don't have to try to harass a
>> thousand package maintainers into doing essentially untestable busy-work
>> to try to move things around between /usr, /bin, and /lib
Marco d'Itri writes ("Re: support for merged /usr in Debian"):
> On Jan 05, Ian Jackson wrote:
> > or which do mount /usr using / rather than initramfs, or some such.
>
> And this has already not been supported for many years, even if it works
> in some cases, so
.
>
> Abolishing the distinction between /usr and / will break systems that
> have been set up that way.
I think that you are a bit confused, because on a merged /usr system you
can continue having a read only /usr and a read write /.
If your goal is to have read only system binaries then a merg
Marco d'Itri writes ("Re: support for merged /usr in Debian"):
> On Jan 05, Ian Jackson wrote:
> > /etc contains files which are modified during normal operation.
>
> Depending on the operation involved, we consider this to be a bug:
> https://wiki.debian.org
who you are referring to, but I am quite interested
in excellent Debian support for embedded devices, servers and
containers, and a merged /usr scheme would be extremely useful for many
of these use cases.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Jan 05, Ian Jackson wrote:
> /etc contains files which are modified during normal operation.
Depending on the operation involved, we consider this to be a bug:
https://wiki.debian.org/ReadonlyRoot
--
ciao,
Marco
signature.asc
Description: PGP signature
On Tue, 5 Jan 2016 12:49:25 +
Ian Jackson wrote:
> Simon Richter writes ("Re: support for merged /usr in Debian"):
> > However, we do have a huge installation base outside of that. In
> > most of my embedded systems projects, Debian has been the starting
>
* Paul Wise , 2016-01-05, 17:49:
And yet, it works, and it means that we don't have to try to harass a
thousand package maintainers into doing essentially untestable
busy-work to try to move things around between /usr, /bin, and /lib to
support a tiny handful of systems for which other approach
Simon Richter writes ("Re: support for merged /usr in Debian"):
> However, we do have a huge installation base outside of that. In most of
> my embedded systems projects, Debian has been the starting point for the
> customized installation, simply because before jessie, you
Marco d'Itri writes ("Re: support for merged /usr in Debian"):
> On Jan 02, Joerg Jaspert wrote:
> > No, /etc can be nicely ro. That is, /, /usr, /etc, ... can be. The log
> > storage and the user homes, as well as a tmp filesystem rw, rest ro.
> > Works nice
On Mon, Jan 4, 2016 at 2:14 AM, Russ Allbery wrote:
> And yet, it works, and it means that we don't have to try to harass a
> thousand package maintainers into doing essentially untestable busy-work
> to try to move things around between /usr, /bin, and /lib to support a
> tiny handful of systems
Hello all.
On Tue, Jan 05, 2016 at 01:23:06AM +0100, Michael Biebl wrote:
> Am 05.01.2016 um 01:17 schrieb Adam Borowski:
> > On Mon, Jan 04, 2016 at 08:43:02PM +0100, Michael Biebl wrote:
> >> Am 04.01.2016 um 19:12 schrieb Eric Valette:
> Remember that / and /usr don't have to reside on the
On Jan 05 2016, Marc Haber wrote:
> On Mon, 4 Jan 2016 22:21:06 +0100, Iustin Pop
> wrote:
>>On 2016-01-04 12:03:07, Marc Haber wrote:
>>> On Sun, 3 Jan 2016 19:15:18 +0100, m...@linux.it (Marco d'Itri) wrote:
>>> >Anyway, if you think that the merged /usr
On 01/05/2016 01:34 AM, Marc Haber wrote:
> On Mon, 4 Jan 2016 22:21:06 +0100, Iustin Pop
> wrote:
>> On 2016-01-04 12:03:07, Marc Haber wrote:
>>> On Sun, 3 Jan 2016 19:15:18 +0100, m...@linux.it (Marco d'Itri) wrote:
>>>> Anyway, if you think that the me
On 01/05/2016 01:17 AM, Adam Borowski wrote:
> On Mon, Jan 04, 2016 at 08:43:02PM +0100, Michael Biebl wrote:
>> Am 04.01.2016 um 19:12 schrieb Eric Valette:
Remember that / and /usr don't have to reside on the same partition with
the usrmerge proposal: they only have to be both available
On Mon, 4 Jan 2016 22:21:06 +0100, Iustin Pop
wrote:
>On 2016-01-04 12:03:07, Marc Haber wrote:
>> On Sun, 3 Jan 2016 19:15:18 +0100, m...@linux.it (Marco d'Itri) wrote:
>> >Anyway, if you think that the merged /usr scheme is about systemd then
>> >you are automa
Am 05.01.2016 um 01:17 schrieb Adam Borowski:
> On Mon, Jan 04, 2016 at 08:43:02PM +0100, Michael Biebl wrote:
>> Am 04.01.2016 um 19:12 schrieb Eric Valette:
Remember that / and /usr don't have to reside on the same partition with
the usrmerge proposal: they only have to be both availabl
On Mon, Jan 04, 2016 at 08:43:02PM +0100, Michael Biebl wrote:
> Am 04.01.2016 um 19:12 schrieb Eric Valette:
> >> Remember that / and /usr don't have to reside on the same partition with
> >> the usrmerge proposal: they only have to be both available
> >> post-initramfs. The initramfs already tak
On 2016-01-04 23:41:40, Eric Valette wrote:
> On 04/01/2016 20:43, Michael Biebl wrote:
>
> >an initramfs is not mandatory as long as you don't have /usr on a
> >separate partition.
> >No initramfs + split /usr is not supported and has been broken for a while.
>
> Did you actually test it? It wor
On 04/01/2016 20:43, Michael Biebl wrote:
an initramfs is not mandatory as long as you don't have /usr on a
separate partition.
No initramfs + split /usr is not supported and has been broken for a while.
Did you actually test it? It works for me TM on fairly simple setup...
-- eric
On 2016-01-04 12:03:07, Marc Haber wrote:
> On Sun, 3 Jan 2016 19:15:18 +0100, m...@linux.it (Marco d'Itri) wrote:
> >Anyway, if you think that the merged /usr scheme is about systemd then
> >you are automatically disqualified from taking part in this discussion
&g
Am 04.01.2016 um 19:12 schrieb Eric Valette:
>> Remember that / and /usr don't have to reside on the same partition with
>> the usrmerge proposal: they only have to be both available
>> post-initramfs. The initramfs already takes care to mount /usr (for the
>> systemd case as initscripts needs upd
Remember that / and /usr don't have to reside on the same partition with
the usrmerge proposal: they only have to be both available
post-initramfs. The initramfs already takes care to mount /usr (for the
systemd case as initscripts needs updates for sysvinit as was said
elsewhere). So no reparti
Remember that / and /usr don't have to reside on the same partition with
the usrmerge proposal: they only have to be both available
post-initramfs. The initramfs already takes care to mount /usr (for the
systemd case as initscripts needs updates for sysvinit as was said
elsewhere
On 01/04/2016 11:44 AM, Marc Haber wrote:
> On Sun, 3 Jan 2016 21:35:39 +0100, Christian Seiler
> wrote:
>> So that was the state in February of 2011, when the warning was added
>> to systemd and the systemd developers recommended the use of the
>> initrd: mounting /usr from a running system is br
On 01/04/2016 12:15 PM, Marc Haber wrote:
> On Mon, 04 Jan 2016 12:01:46 +0100, Ansgar Burchardt
>> Remember that / and /usr don't have to reside on the same partition with
>> the usrmerge proposal: they only have to be both available
>> post-initramfs. The initramfs already takes care to mount /u
sary for
> new systems, and it is really a horror vision to have to do this for
> existing systems during upgrades.
You will always have to adapt things to upgrades, because lots of small
details can change. Also I don't see how putting things in /usr will
have a large impact on this:
- bac
On Mon, 04 Jan 2016 12:01:46 +0100, Ansgar Burchardt
wrote:
>Marc Haber writes:
>> On Sun, 03 Jan 2016 13:28:14 -0800, Russ Allbery
>> wrote:
>>>But I don't get why people who are using non-embedded UNIX systems
>>>particularly care.
>>
>> I, for example, am afraid of having to merge /usr in exi
On Sun, 3 Jan 2016 19:15:18 +0100, m...@linux.it (Marco d'Itri) wrote:
>Anyway, if you think that the merged /usr scheme is about systemd then
>you are automatically disqualified from taking part in this discussion
>because you are not understanding the basic underlying issues.
Marc Haber writes:
> On Sun, 03 Jan 2016 13:28:14 -0800, Russ Allbery
> wrote:
>>But I don't get why people who are using non-embedded UNIX systems
>>particularly care.
>
> I, for example, am afraid of having to merge /usr in existing systems
> during upgrades, causing repartitions to be necessar
On Sun, 3 Jan 2016 21:35:39 +0100, Christian Seiler
wrote:
>So that was the state in February of 2011, when the warning was added
>to systemd and the systemd developers recommended the use of the
>initrd: mounting /usr from a running system is broken. Either it is
>already completely broken in som
On Sun, 03 Jan 2016 13:28:14 -0800, Russ Allbery
wrote:
>I do understand why people working in the embedded space care about some
>unusual mount orderings, file system separations, and very light cores,
>and I hope that we can accomodate and support all of their use cases
>inside Debian. I think
On Sun, 3 Jan 2016 22:06:32 +0100, Florian Lohoff wrote:
>From my 25 year Unix experience i dont like the usr merge.
Agreed.
> As you sum
>up very nicely and i agree on is that Debian has given up on being
>slim at this point. There is no such thing as a single user mode boot
>with only the root
On Sun, 3 Jan 2016 23:55:08 +0100, Eric Valette
wrote:
>cannot really accommodate the /etc/defaut/pkg
>configurable options...
This will get worse, btw, since the systemd community ponders removing
the EnvironmentFile option since "all distributions are using it
wrong", especially looking upon D
On Sun, 3 Jan 2016 22:30:24 +0100, Eric Valette
wrote:
>System admins do like using absolute path
>for security reasons...
Please also notice that this is the only option for ExecStart in
systemd units. Well played, Lennart.
Greetings
Marc
--
-- !! No courte
On Sun, 03 Jan 2016 10:14:14 -0800, Russ Allbery
wrote:
>Note that mounting /usr early, something we *already do*, is separate from
>actually merging /usr with /bin and /lib. Once you mount /usr early, it's
>rather less important whether you actually merge the file systems. While
>it does let yo
On Mon, 2016-01-04 at 00:55 +0100, Christian Seiler wrote:
[...]
> Btw. initramfs-tools (via switch_root from util-linux) recursively
> deletes the files in the initramfs in a forked-off process right
> before exec()ing init. Is that really necessary? Shouldn't the
> kernel loose the data of the in
On 01/04/2016 12:39 AM, Ben Hutchings wrote:
> On Sun, 2016-01-03 at 21:35 +0100, Christian Seiler wrote:
> [...]
>>
>> Well, just for the heck of it I wrote a braindead-simple initrd
>> implementation in just 300 LOC:
>>
>> https://gist.github.com/chris-se/e0fbc073fcbd9ac2d7ae
> [...]
>
> Neat.
On Sun, 2016-01-03 at 21:35 +0100, Christian Seiler wrote:
[...]
>
> Well, just for the heck of it I wrote a braindead-simple initrd
> implementation in just 300 LOC:
>
> https://gist.github.com/chris-se/e0fbc073fcbd9ac2d7ae
[...]
Neat. It should probably implement 'ro', 'rw' and 'rootdelay', t
On Sun, 2016-01-03 at 19:43 +0100, Marco d'Itri wrote:
> On Jan 03, Andreas Henriksson wrote:
>
> > First, it would be nice to have a preinst check if the system has any
> > running services that uses ProtectSystem and offer a choice to stop
> > (and restart) them in case having them running is r
On Sun, 2016-01-03 at 18:10 +0100, Iustin Pop wrote:
> On 2016-01-03 17:03:02, Simon McVittie wrote:
> > […] For
> > instance, /bin -> /usr/bin is needed because otherwise #!/bin/sh would
> > stop working, […]
>
> This brings to mind—I wonder if the performance impact of having /bin/sh
> be read t
On Sun, 2016-01-03 at 23:42 +0100, Simon Richter wrote:
> Hi,
>
> On 03.01.2016 23:32, Ben Hutchings wrote:
>
> > An initramfs is mandatory if using the standard kernel packages, as I
> > think most people do.
>
> Not on embedded systems.
Sure.
> While we do have the advantage there that the
>
I'm confused why you think anything will break. There would obviously be
symlinks, so anything that's currently in /bin will continue to work if
invoked with an absolute /bin path.
I consider linking across file system a very bad practice because if
/usr gets errors all the symlinks may be bro
On 01/03/2016 04:23 AM, Martinx - ジェームズ wrote:
> This "UseMerge" just brings more insanity into Debian. What is wrong
> with you guys?! For God's sake...
Even if you disagree with something, please don't call it insanity.
> It violates the FHS 2.3 standards.
Sure, if you mean the sentence that "
On Sun, 2016-01-03 at 13:10 -0800, Russ Allbery wrote:
> Eric Valette writes:
>
> > But could you elaborate a bit on "mounting /usr early, something we
> > *already do*" if you do not implicitly refer to initramfs solution.
>
> There are other people who know a lot more about the machinery here
Hi,
On 03.01.2016 23:32, Ben Hutchings wrote:
> An initramfs is mandatory if using the standard kernel packages, as I
> think most people do.
Not on embedded systems. While we do have the advantage there that the
people putting the system together are generally clueful, it should
still remain po
On Sun, 2016-01-03 at 21:21 +0100, Simon Richter wrote:
> Hi,
>
> On 03.01.2016 19:15, Marco d'Itri wrote:
[...]
> > Anyway, if you think that the merged /usr scheme is about systemd then
> > you are automatically disqualified from taking part in this discussio
On Sun, 2016-01-03 at 21:34 +0100, Eric Valette wrote:
> > > > This is not true: you just need to use an initramfs.
> > > Ok, so it should warn that this setup will soon require to use an
> > > initramfs.
> > It is the Debian default, there is no need to do this.
>
> Being debian installer defaul
On 01/02/2016 06:42 PM, Geert Stappers wrote:
> To me is this "TheUsrMerge" something like among
> * "it is hard too to explain to have /sbin/fsck and not /usr/sbin/fsck"
> * "there was a question about /bin/kill and /usr/bin/killall being
> inconsequent"
> * "we could not agree if p{erl,ython,hp
On 01/03/2016 11:06 PM, Henrique de Moraes Holschuh wrote:
> On Sun, Jan 3, 2016, at 19:59, Christian Seiler wrote:
>> On 01/03/2016 10:53 PM, Henrique de Moraes Holschuh wrote:
>>> On Sun, Jan 3, 2016, at 18:35, Christian Seiler wrote:
My question would be: would those people here who have se
On Sun, Jan 3, 2016, at 19:59, Christian Seiler wrote:
> On 01/03/2016 10:53 PM, Henrique de Moraes Holschuh wrote:
> > On Sun, Jan 3, 2016, at 18:35, Christian Seiler wrote:
> >> My question would be: would those people here who have separate /usr
> >> and aren't using initrd be willing to put up
On 01/03/2016 10:53 PM, Henrique de Moraes Holschuh wrote:
> On Sun, Jan 3, 2016, at 18:35, Christian Seiler wrote:
>> My question would be: would those people here who have separate /usr
>> and aren't using initrd be willing to put up with something like that?
>
> I don't know if they will, but t
On Sun, Jan 3, 2016, at 18:35, Christian Seiler wrote:
> Well, just for the heck of it I wrote a braindead-simple initrd
> implementation in just 300 LOC:
>
> https://gist.github.com/chris-se/e0fbc073fcbd9ac2d7ae
Oho! Cool!
> My question would be: would those people here who have separate /usr
❦ 3 janvier 2016 22:30 +0100, Eric Valette :
>> The problem of getting /usr mounted before things start using it is mostly
>> separate from the question of whether we want to merge it with /bin and
>> /lib. This thread is more about the latter than the former. (Obviously,
>> mounting /usr ear
On Sun, Jan 3, 2016, at 16:43, Marco d'Itri wrote:
> I just have not found yet how to determine if the system was booted
> using an initramfs or not. Does anybody have any hint?
I don't think there is any source for that information that one can
really trust ATM, AFAIK.
We could add it in usersp
Eric Valette writes:
> If it is just to close once for all the right location philosophical
> debate, I would say it will be over priced: changing executable PATH
> will just breaks million scripts people have written themselves on top
> of original debian install to maintain their system or do w
On 2016-01-03 22:22:16, Tom H wrote:
> On Sun, Jan 3, 2016 at 6:17 PM, Iustin Pop wrote:
> > On 2016-01-03 12:59:01, Tom H wrote:
> >>
> >> I don't like usr-merge because it goes against my historical
> >> expectation that "/{,s}bin" be separate from their /usr namesakes and
> >> contain binaries
On 03/01/2016 22:10, Russ Allbery wrote:
Eric Valette writes:
The problem of getting /usr mounted before things start using it is mostly
separate from the question of whether we want to merge it with /bin and
/lib. This thread is more about the latter than the former. (Obviously,
mounting
Florian Lohoff writes:
> On Sun, Jan 03, 2016 at 10:14:14AM -0800, Russ Allbery wrote:
>> No. Debian has basically given up on this; there are way too many
>> packages and way too much stuff that would have to be moved to /bin and
>> /lib in order to preserve the traditional semantics that allow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/03/2016 07:15 PM, Marco d'Itri wrote:
> On Jan 03, Simon Richter wrote:
>
>>> "I have always done this in a different way" is not a valid use
>>> case, sorry.
>> "Compatibility" is a very valid use case. Debian is famous for
>> backwards co
On Sun, Jan 3, 2016 at 6:17 PM, Iustin Pop wrote:
> On 2016-01-03 12:59:01, Tom H wrote:
>>
>> I don't like usr-merge because it goes against my historical
>> expectation that "/{,s}bin" be separate from their /usr namesakes and
>> contain binaries required for boot.
>
> OK, so adjust your histori
On Sun, Jan 03, 2016 at 10:14:14AM -0800, Russ Allbery wrote:
> Daniel Reurich writes:
>
> > Ah, so it's actually packages that don't separate device configuration
> > logic from the application or daemons properly that has caused the
> > brokenness. Can we identify and fix the packages that cau
Eric Valette writes:
> But could you elaborate a bit on "mounting /usr early, something we
> *already do*" if you do not implicitly refer to initramfs solution.
There are other people who know a lot more about the machinery here than I
do, but my understanding is that we currently use a variety
uch a mechanism provided it is not imposed,
2) no separate partition for / and /usr being another one. I will
probably end up changing the way I install new debian system to this one
now that even SSD disks are so huge compared to system requirements,
3) merged /usr proposal being a kind o
On 01/03/2016 12:03 PM, Daniel Reurich wrote:
> On 03/01/16 23:18, Ben Hutchings wrote:
>
>>> Then why is it that since the introduction of systemd is having /usr on
>>> a separate partition suddenly considered evil and systemd complains
>>> loudly about it. It always has worked and does work fin
>This is not true: you just need to use an initramfs.
Ok, so it should warn that this setup will soon require to use an initramfs.
It is the Debian default, there is no need to do this.
Being debian installer default does not mean any debian users
1) really has any benefit of using it a
501 - 600 of 677 matches
Mail list logo
