Christoph Anton Mitterer writes:
> On Wed, 2010-08-25 at 11:05 +0200, Goswin von Brederlow wrote:
>> We already have the logic in there to mount anything as /.
> Well. at least if it's a very plain setup... (see
> http://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices)
>
>
On Wed, 2010-08-25 at 11:05 +0200, Goswin von Brederlow wrote:
> We already have the logic in there to mount anything as /.
Well. at least if it's a very plain setup... (see
http://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices)
> /usr can't be
> any harder so that isn't
The Fungi writes:
> On Fri, Aug 20, 2010 at 10:45:04PM +0200, Christoph Anton Mitterer wrote:
>> Of course,.. but only because your /usr is on the root-fs.
>>
>> And there are many good reasons to put it on its own fs, as already
>> outlayed here...
> [...]
>
> No disagreement there... I'm much
On Fri, Aug 20, 2010 at 10:45:04PM +0200, Christoph Anton Mitterer wrote:
> Of course,.. but only because your /usr is on the root-fs.
>
> And there are many good reasons to put it on its own fs, as already
> outlayed here...
[...]
No disagreement there... I'm much in favor of continuing to suppo
On Fri, 2010-08-20 at 15:10 +, The Fungi wrote:
> This argument is somewhat circular, in that the machine from which
> I'm typing this message has /usr as part of the / filesystem, all of
> which is LUKS encrypted, and the generic Debian initrd is handling
> it just fine. Some built-in logic to
On Fri, Aug 20, 2010 at 04:47:04PM +0200, Christoph Anton Mitterer wrote:
> Yes, because the initr makes only the root-fs available,... and
> perhaps resume devices. But not things like encrpyted /usr, etc.
> pp.
This argument is somewhat circular, in that the machine from which
I'm typing this me
On Thu, 2010-08-19 at 18:48 +0200, Stéphane Glondu wrote:
> Is this still relevant, now that we have initrd?
Yes, because the initr makes only the root-fs available,... and perhaps resume
devices.
But not things like encrpyted /usr, etc. pp.
Cheers,
Chris.
--
To UNSUBSCRIBE, email to debian-d
Le 10/08/2010 12:18, Stanislav Maslovski a écrit :
> Not just to repair. First of all, / must have enough tools to
> bring the system up to the point where the other file systems can be
> mounted (i.g., over the network).
Is this still relevant, now that we have initrd?
> This is an unfortunate c
Ted Ts'o writes:
> On Mon, Aug 16, 2010 at 09:01:42PM +0200, Bernhard R. Link wrote:
>> * Perry E. Metzger [100816 20:21]:
>> > The most reasonable argument against altering such things is that
>> > after decades, people are used to the whole /usr thing and the fight
>> > to change it isn't wort
On Mon, Aug 16, 2010 at 09:01:42PM +0200, Bernhard R. Link wrote:
> * Perry E. Metzger [100816 20:21]:
> > The most reasonable argument against altering such things is that
> > after decades, people are used to the whole /usr thing and the fight
> > to change it isn't worthwhile. That I will agree
Sven Mueller writes:
> Am 10.08.2010 17:54, schrieb Russ Allbery:
>> Unfortunately, there isn't any way to check this in Lintian since
>> Lintian has no idea whether a given library will be found in /lib or in
>> /usr/lib. It's one of those things that needs to be done in a
>> cross-archive chec
Am 10.08.2010 17:54, schrieb Russ Allbery:
> Simon McVittie writes:
>
>> It might be worth having a Lintian check for the situation you describe,
>> since missing libraries will generally prevent the executable from
>> starting up at all, whereas missing bits of /usr/share or /var might not
>> be
* Perry E. Metzger [100816 20:21]:
> The most reasonable argument against altering such things is that
> after decades, people are used to the whole /usr thing and the fight
> to change it isn't worthwhile. That I will agree with -- see the
> emotional reactions people get when you suggest their p
I want to make it clear, btw, that I don't think that getting rid of
/usr is something worth fighting for. I just think that there is no
reason to keep it other than the fact that years of experience say
people will irrationally fight for it endlessly, and the minimal
benefits of getting rid of it
On Mon, Aug 16, 2010 at 02:47:56PM +0200, Yves-Alexis Perez wrote:
> On 16/08/2010 14:00, Tollef Fog Heen wrote:
> > ]] "Perry E. Metzger"
> > | In the embedded space, which I know a lot about, it is true that the
> > | root FS is on flash or other expensive media -- but it isn't like /usr
> > |
On Mon, Aug 16, 2010 at 02:43:04PM +0200, Giacomo A. Catenazzi wrote:
[...]
> And Debian still don't have a live distribution to be used for
> rescue,
Well, there's this, which I've had great experiences with so far
(though the automatic reassembly of md devices and activation of
volume groups was
Le lundi 16 août 2010 à 14:43 +0200, Giacomo A. Catenazzi a écrit :
> As you can easily check, there is a lot of Debian installation
> who use networked disks. Usually not embedded devices, but usual
> desktop installations (e.g. using huge number of desktops as in
> schools or corporate environmen
On August 15, 2010 04:30:04 pm Perry E. Metzger wrote:
> On Tue, 10 Aug 2010 03:15:35 -0600 Bruce Sass wrote:
> > /sbin and /usr/sbin, /lib and /usr/lib directories?
> >
> > AFAICT, the reason is so that a minimal but functional system is
> > guaranteed to exist so long as a local HDD with a root
On 16/08/2010 14:00, Tollef Fog Heen wrote:
> ]] "Perry E. Metzger"
>
> | In the embedded space, which I know a lot about, it is true that the
> | root FS is on flash or other expensive media -- but it isn't like /usr
> | is on cheaper media in such an environment, it is always part of the
> | ro
On 16.08.2010 01:22, Perry E. Metzger wrote:
On Sun, 15 Aug 2010 16:00:23 -0700 Steve Langasek
wrote:
On Sun, Aug 15, 2010 at 06:30:04PM -0400, Perry E. Metzger wrote:
By the early 1990s this was long since unneeded but people
continued to do it anyway, and in fact started to think it was
done
]] "Perry E. Metzger"
| In the embedded space, which I know a lot about, it is true that the
| root FS is on flash or other expensive media -- but it isn't like /usr
| is on cheaper media in such an environment, it is always part of the
| root fs anyway, so it makes no difference.
Take a look at
On Sun, 15 Aug 2010 18:30:04 -0400, "Perry E. Metzger"
wrote:
>The true reason is that back in ancient days, hard drives were too
>small to put everything in one place, so ancient Unix machines at Bell
>Labs in the 1970s ended up with some programs on the root disk and
>some on the same supplement
On Sun, 15 Aug 2010 16:00:23 -0700 Steve Langasek
wrote:
> On Sun, Aug 15, 2010 at 06:30:04PM -0400, Perry E. Metzger wrote:
> > By the early 1990s this was long since unneeded but people
> > continued to do it anyway, and in fact started to think it was
> > done for technical reasons rather than
On Sun, Aug 15, 2010 at 06:30:04PM -0400, Perry E. Metzger wrote:
> By the early 1990s this was long since unneeded but people continued
> to do it anyway, and in fact started to think it was done for
> technical reasons rather than because of a simple lack of space in an
> earlier era. At this poi
On Tue, 10 Aug 2010 03:15:35 -0600 Bruce Sass wrote:
> /sbin and /usr/sbin, /lib and /usr/lib directories?
>
> AFAICT, the reason is so that a minimal but functional system is
> guaranteed to exist so long as a local HDD with a root filesystem
> is available (which doesn't necessarily include /u
> A better test might be to do this without /usr mounted.
>
> MfG
> Goswin
Could we do automated testing using:
- creating a new mount namespace
- a bind mount of /usr on a empty directory ?
A second option will be to modify fakeroot in order to avoid the
/usr/binding and run some test lik
On Tue, 2010-08-10 at 03:15 -0600, Bruce Sass wrote:
> I was curious so...
> $ for f in /bin/* /sbin/*; do if [ "`file $f | grep ELF`" != "" ] ; then
> /lib/ld-linux.so.2 (0x46bad000)
> libpcre.so.3 => /lib/libpcre.so.3 (0xb7856000)
>
> Are these bugs just waiting to bite, or
Steve Langasek writes:
> On Tue, Aug 10, 2010 at 11:53:10PM +0200, Goswin von Brederlow wrote:
>> Bruce Sass writes:
>
>> Note that there is /lib/libcrypt* (at least here). This is just the more
>> optimized flavour the ld.so picks when the cpu supports it.
>
> libcrypt != libcrypto.
Ups, sorry
On Tue, Aug 10, 2010 at 03:15:35AM -0600, Bruce Sass wrote:
> iputils-ping: /bin/ping6
> linux-gate.so.1 => (0xb770d000)
> libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0x472dc000)
> libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8
> (0x4882b000)
> li
On August 10, 2010 03:53:10 pm Goswin von Brederlow wrote:
> Bruce Sass writes:
> > I was curious so...
> > $ for f in /bin/* /sbin/*; do if [ "`file $f | grep ELF`" != "" ] ;
> > then if [ "`ldd $f | grep /usr`" != "" ] ; then echo `dpkg -S $f`;
> > ldd $f; fi; fi; done
> > iputils-ping: /bin/pin
On Tue, Aug 10, 2010 at 11:53:10PM +0200, Goswin von Brederlow wrote:
> Bruce Sass writes:
>
> > I was curious so...
> > $ for f in /bin/* /sbin/*; do if [ "`file $f | grep ELF`" != "" ] ; then
> > if [ "`ldd $f | grep /usr`" != "" ] ; then echo `dpkg -S $f`; ldd $f;
> > fi; fi; done
> > iputil
On Tue, Aug 10, 2010 at 11:53:10PM +0200, Goswin von Brederlow wrote:
> Bruce Sass writes:
> Note that there is /lib/libcrypt* (at least here). This is just the more
> optimized flavour the ld.so picks when the cpu supports it.
libcrypt != libcrypto.
--
Steve Langasek Give me
Bruce Sass writes:
> I was curious so...
> $ for f in /bin/* /sbin/*; do if [ "`file $f | grep ELF`" != "" ] ; then
> if [ "`ldd $f | grep /usr`" != "" ] ; then echo `dpkg -S $f`; ldd $f;
> fi; fi; done
> iputils-ping: /bin/ping6
> linux-gate.so.1 => (0xb770d000)
> libresolv.so
Simon McVittie writes:
> It might be worth having a Lintian check for the situation you describe,
> since missing libraries will generally prevent the executable from
> starting up at all, whereas missing bits of /usr/share or /var might not
> be so important.
Unfortunately, there isn't any way
On August 10, 2010 04:25:07 am Simon McVittie wrote:
> On Tue, 10 Aug 2010 at 03:15:35 -0600, Bruce Sass wrote:
> > AFAICT, the reason is so that a minimal but functional system is
> > guaranteed to exist so long as a local HDD with a root filesystem
> > is available
>
> The fact that you can use i
On August 10, 2010 04:18:10 am Stanislav Maslovski wrote:
> On Tue, Aug 10, 2010 at 03:15:35AM -0600, Bruce Sass wrote:
> > /sbin and /usr/sbin, /lib and /usr/lib directories?
> >
> > AFAICT, the reason is so that a minimal but functional system is
> > guaranteed to exist so long as a local HDD wit
Simon McVittie wrote:
> The FHS says mkfs.* have to be on the root filesystem. I'm not entirely clear
> why this is.
Well, I personally believe this holds for at least two of the purposes
listed in FHS Chapter 3:
* To enable recovery and/or repair of a system
* To restore a system
To recover a d
On Tue, 10 Aug 2010 at 03:15:35 -0600, Bruce Sass wrote:
> AFAICT, the reason is so that a minimal but functional system is
> guaranteed to exist so long as a local HDD with a root filesystem is
> available
The fact that you can use it for troubleshooting/repairs is a nice (and
desirable) side-e
On Tue, Aug 10, 2010 at 03:15:35AM -0600, Bruce Sass wrote:
> /sbin and /usr/sbin, /lib and /usr/lib directories?
>
> AFAICT, the reason is so that a minimal but functional system is
> guaranteed to exist so long as a local HDD with a root filesystem is
> available (which doesn't necessarily inc
/sbin and /usr/sbin, /lib and /usr/lib directories?
AFAICT, the reason is so that a minimal but functional system is
guaranteed to exist so long as a local HDD with a root filesystem is
available (which doesn't necessarily include /usr); and that is a good
thing to have because it gives develop
40 matches
Mail list logo
