The Fungi fu...@yuggoth.org 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
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 an
Christoph Anton Mitterer cales...@scientia.net 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
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 support
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
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
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
Ted Ts'o ty...@mit.edu writes:
On Mon, Aug 16, 2010 at 09:01:42PM +0200, Bernhard R. Link wrote:
* Perry E. Metzger pe...@piermont.com [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
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
On Mon, Aug 16, 2010 at 09:01:42PM +0200, Bernhard R. Link wrote:
* Perry E. Metzger pe...@piermont.com [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
Am 10.08.2010 17:54, schrieb Russ Allbery:
Simon McVittie s...@debian.org 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
Sven Mueller s...@incase.de 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
On Sun, 15 Aug 2010 18:30:04 -0400, Perry E. Metzger
pe...@piermont.com 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
]] 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 16.08.2010 01:22, Perry E. Metzger wrote:
On Sun, 15 Aug 2010 16:00:23 -0700 Steve Langasekvor...@debian.org
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
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
| root fs
On August 15, 2010 04:30:04 pm Perry E. Metzger wrote:
On Tue, 10 Aug 2010 03:15:35 -0600 Bruce Sass bms...@shaw.ca 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
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
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
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
| is on
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
* Perry E. Metzger pe...@piermont.com [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
On Tue, 10 Aug 2010 03:15:35 -0600 Bruce Sass bms...@shaw.ca 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
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 point
On Sun, 15 Aug 2010 16:00:23 -0700 Steve Langasek vor...@debian.org
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
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 like
Steve Langasek vor...@debian.org writes:
On Tue, Aug 10, 2010 at 11:53:10PM +0200, Goswin von Brederlow wrote:
Bruce Sass bms...@shaw.ca 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 !=
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 frustrate
/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
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 include
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)
Simon McVittie s...@debian.org 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
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 with a root
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 it for
Simon McVittie s...@debian.org 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
Bruce Sass bms...@shaw.ca 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)
On Tue, Aug 10, 2010 at 11:53:10PM +0200, Goswin von Brederlow wrote:
Bruce Sass bms...@shaw.ca 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
On Tue, Aug 10, 2010 at 11:53:10PM +0200, Goswin von Brederlow wrote:
Bruce Sass bms...@shaw.ca 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
On August 10, 2010 03:53:10 pm Goswin von Brederlow wrote:
Bruce Sass bms...@shaw.ca 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
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)
libc.so.6
40 matches
Mail list logo
