On Fri, Nov 28, 2003 at 10:01:05PM +0100, Michael Nottebrock wrote:
Content-Description: signed data
On Friday 28 November 2003 21:03, Tim Kientzle wrote:
David O'Brien wrote:
On Wed, Nov 26, 2003 at 10:37:48AM -0800, Tim Kientzle wrote:
and [/usr/bin/ftp] doesn't support HTTP.
$
David O'Brien wrote:
On Wed, Nov 26, 2003 at 10:37:48AM -0800, Tim Kientzle wrote:
and [/usr/bin/ftp] doesn't support HTTP.
$ /usr/bin/ftp http://www.theregister.co.uk/content/6/32524.html
Requesting http://www.theregister.co.uk/content/6/32524.html
100%
On Friday 28 November 2003 21:03, Tim Kientzle wrote:
David O'Brien wrote:
On Wed, Nov 26, 2003 at 10:37:48AM -0800, Tim Kientzle wrote:
and [/usr/bin/ftp] doesn't support HTTP.
$ /usr/bin/ftp http://www.theregister.co.uk/content/6/32524.html
Requesting
In message [EMAIL PROTECTED], Tim Kientzle writes:
David O'Brien wrote:
On Wed, Nov 26, 2003 at 10:37:48AM -0800, Tim Kientzle wrote:
and [/usr/bin/ftp] doesn't support HTTP.
$ /usr/bin/ftp http://www.theregister.co.uk/content/6/32524.html
Requesting
On Fri, Nov 28, 2003 at 09:17:39PM +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Tim Kientzle writes:
David O'Brien wrote:
On Wed, Nov 26, 2003 at 10:37:48AM -0800, Tim Kientzle wrote:
and [/usr/bin/ftp] doesn't support HTTP.
$ /usr/bin/ftp
On Tue, Nov 25, 2003 at 01:41:53PM -0500 I heard the voice of
Garance A Drosihn, and lo! it spake thus:
It is a bit more complicated than that, because programs may
include embedded references to other files. So, I think
some developer would *have* to do a little up-front work for
any
On Tue, Nov 25, 2003 at 02:17:02PM -0500 I heard the voice of
slave-mike, and lo! it spake thus:
Would it be possible to get a copy of this script?
Please! :)
Oh, it's pretty simplistic. It's actually on a box that's in the closet
right now, but I think this is an older working version:
---
On Wed, Nov 26, 2003 at 10:16:37AM -0600, Matthew D. Fuller wrote:
The advantage of this method is it's simple, cheap, automatic, and lets
us say You can try setting ADDITIONAL_RESCUE=usr.sbin/foo in make.conf
and it may work,
Please send a tested patch for this. :-)
If ADDITIONAL_RESCUE will
Matthew D. Fuller wrote:
On Tue, Nov 25, 2003 at 01:41:53PM -0500 I heard the voice of
Garance A Drosihn, and lo! it spake thus:
It is a bit more complicated than that, because programs may
include embedded references to other files. So, I think
some developer would *have* to do a little up-front
David O'Brien wrote:
... lets agree that the FTP client will be
the last thing added to /rescue that is outside the original charter.
I sincerely hope it will be. Mostly because I have a large chunk
of new code to contribute that's broken and sitting in pieces all over
my hard disk at the
On Mon, Nov 24, 2003 at 02:41:44PM -0800 I heard the voice of
David O'Brien, and lo! it spake thus:
On Mon, Nov 24, 2003 at 04:07:49PM -0500, Michael Edenfield wrote:
Would it be possible, through some make.conf magic, for the end-user to
set extra programs to be put into /rescue that are
At 10:09 AM -0600 11/25/03, Matthew D. Fuller wrote:
On Mon, Nov 24, 2003, I heard the voice of
David O'Brien, and lo! it spake thus:
On Mon, Nov 24, 2003, Michael Edenfield wrote:
Would it be possible, through some make.conf magic, for
the end-user to set extra programs to be put
Would it be possible to get a copy of this script?
Please! :)
Matthew D. Fuller wrote:
On Mon, Nov 24, 2003 at 02:41:44PM -0800 I heard the voice of
David O'Brien, and lo! it spake thus:
On Mon, Nov 24, 2003 at 04:07:49PM -0500, Michael Edenfield wrote:
Would it be possible, through some
On Mon, Nov 24, 2003 at 03:48:57PM -0800, Tim Kientzle wrote:
... I think [/rescue] only needs to support those
recovery actions necessary to repair /bin and /sbin if they break.
My stance is that no failure mode needs to
be repairable that wasn't repairable with a static /.
I'm willing
On Sun, 23 Nov 2003, Bruce M Simpson wrote:
On Sun, Nov 23, 2003 at 02:42:58AM +0100, Brad Knowles wrote:
At 5:22 PM -0800 2003/11/22, David O'Brien wrote:
Please, NO. There wasn't an FTP client available for this type of
recovery pre-/rescue, there shouldn't be one now.
Why? Why
If you want access to fetch early on in this way, you could make a local
branch and maintain the change for your own site, or you could boot from
a FreeBSD live CD, or use sysinstall from the installation CD to install
a package. I don't see fetch as a requirement for diskless clients.
Bruce M Simpson [EMAIL PROTECTED] writes:
I think David has valid concerns here about feeping creaturism. fetch
has a whole load of library dependencies which go with it, making it
unsuitable for inclusion in /rescue in the base system.
Not if you build it without SSL support.
DES
--
On Sun, Nov 23, 2003 at 06:00:36PM -0800, Tim Kientzle wrote:
Scenarios that require /rescue are ones in which /bin and /sbin
are unusable, which is almost always going to imply a trashed file
in /bin, /sbin, or /lib. Thus, most /rescue scenarios are going to
involve locating a good copy of a
David O'Brien wrote:
On Sun, Nov 23, 2003 at 06:00:36PM -0800, Tim Kientzle wrote:
Scenarios that require /rescue are ones in which /bin and /sbin
are unusable, which is almost always going to imply a trashed file
in /bin, /sbin, or /lib. Thus, most /rescue scenarios are going to
involve
On Mon, 24 Nov 2003 03:40:06 -0800, David O'Brien [EMAIL PROTECTED] said:
We have made the assumption for the first three options since day one.
Why should we change the assumptions just because we now have a dynamic
/?
Because we are not all masochists.
-GAWollman
[ From: set to /dev/null as too many can't follow the Reply-To: ]
On Mon, Nov 24, 2003 at 11:00:24AM -0500, Rahul Siddharthan wrote:
NO. /rescue was allowed in the system to handle the case of a trashed
file in /lib[exec]. To allow a sysadmin to recover a system from the
same type of
On Mon, Nov 24, 2003 at 11:46:54AM -0500, Garrett Wollman wrote:
On Mon, 24 Nov 2003 03:40:06 -0800, David O'Brien [EMAIL PROTECTED] said:
We have made the assumption for the first three options since day one.
Why should we change the assumptions just because we now have a dynamic
/?
At 3:40 AM -0800 11/24/03, David O'Brien wrote:
NO. /rescue was allowed in the system to handle the case
of a trashed file in /lib[exec]. To allow a sysadmin to
recover a system from the same type of mishaps they could
before we went to a dynamic /. Not to continue to add
to /rescue until the
Garance A Drosihn wrote:
Another issue with adding more-and-more to /rescue ...
I am certainly not suggesting adding more-and-more to /rescue.
The dynamic root is a new feature with as-yet-unknown failure
modes. As we understand those failure modes, we can fine-tune
the contents of /rescue. I'm
For a *lot* of people today (like home users), an up-to-date FreeBSD
CD or floppy or a second machine to create the disk on may not be
handy (and forget about NFS), but a network connection may still be
available.
That network connection would most likely be a M$-Win box in that case,
* Garance A Drosihn [EMAIL PROTECTED] [031124 14:11]:
I doubt there is any perfect answer which will satisfy
everyone, but perhaps we can recognize that and figure out
some flexible middle ground.
Would it be possible, through some make.conf magic, for the end-user to
set extra programs to be
On Mon, Nov 24, 2003 at 12:08:58PM -0800, Tim Kientzle wrote:
Contrary to what David claims, I don't think /rescue does need
to support all of the recovery actions that a static /s?bin
would support. Rather, I think it only needs to support those
recovery actions necessary to repair /bin and
On Mon, Nov 24, 2003 at 04:07:49PM -0500, Michael Edenfield wrote:
I doubt there is any perfect answer which will satisfy
everyone, but perhaps we can recognize that and figure out
some flexible middle ground.
Would it be possible, through some make.conf magic, for the end-user to
set
David O'Brien wrote:
On Mon, Nov 24, 2003 at 12:08:58PM -0800, Tim Kientzle wrote:
... I think [/rescue] only needs to support those
recovery actions necessary to repair /bin and /sbin if they break.
My stance is that no failure mode needs to
be repairable that wasn't repairable with a static /.
Tim Kientzle wrote:
David O'Brien wrote:
On Mon, Nov 24, 2003 at 12:08:58PM -0800, Tim Kientzle wrote:
... I think [/rescue] only needs to support those
recovery actions necessary to repair /bin and /sbin if they break.
My stance is that no failure mode needs to
be repairable that wasn't
Richard Coleman wrote:
I think a better compromise is to add the make.conf option so that extra
utilities may be added to /rescue.
As David already pointed out, this is not entirely trivial.
Adding the programs isn't difficult, but it requires adjusting
library includes, which would be tricky to
On Mon, Nov 24, 2003 at 06:27:13PM -0800, Tim Kientzle wrote:
The debate right now is over what programs from /usr/bin and
/usr/sbin should be included. Right now, that includes
tar, gzip, bzip2, and vi/ex.
All but vi(ex) were built statically, but installed into /usr/bin.
--
-- David
On Mon, Nov 24, 2003 at 11:00:24AM -0500, Rahul Siddharthan wrote:
David O'Brien wrote:
On Sun, Nov 23, 2003 at 06:00:36PM -0800, Tim Kientzle wrote:
Scenarios that require /rescue are ones in which /bin and /sbin
are unusable, which is almost always going to imply a trashed file
in /bin,
[ From: set to /dev/null as too many can't follow the Reply-To: ]
On Mon, Nov 24, 2003 at 11:00:24AM -0500, Rahul Siddharthan wrote:
NO. /rescue was allowed in the system to handle the case of a trashed
file in /lib[exec]. To allow a sysadmin to recover a system from the
same type of
need it or not. :-) So, FTP server is not concern. /rescue/fetch MAY help
to recover RUINED FreeBSD from ashes... As /rescue/mount_cd9660, or
mount_msdosfs... In other words we can drom mount_msdosfs from /rescue
just because almost everybody can burn CD... We will save a few KBytes of
FWIW,
On Sat, Nov 22, 2003 a.d., M. Warner Losh wrote:
Grepping seems unsatisfying to find out which keys are used. Do you
have a list?
Believe it or not, vi only needs 'cm' :-)
Regards,
Adi
___
[EMAIL PROTECTED] mailing list
M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Bruce M Simpson [EMAIL PROTECTED] writes:
: On Thu, Nov 20, 2003 at 04:31:10PM -0800, Tim Kientzle wrote:
: * /rescue/vi is currently unusable if /usr is missing because
: the termcap database is in /usr. One possibility
:
On Sun, Nov 23, 2003 at 02:42:58AM +0100, Brad Knowles wrote:
At 5:22 PM -0800 2003/11/22, David O'Brien wrote:
Please, NO. There wasn't an FTP client available for this type of
recovery pre-/rescue, there shouldn't be one now.
Why? Why cut your nose off to spite your face? Even
At 5:22 PM -0800 2003/11/22, David O'Brien wrote:
Please, NO. There wasn't an FTP client available for this type of
recovery pre-/rescue, there shouldn't be one now.
This type of recovery (repairing a system with a trashed /bin)
wasn't possible at all pre-/rescue. Had it been possible, /rescue
On Sun, Nov 23, 2003 at 02:42:58AM +0100, Brad Knowles wrote:
At 5:22 PM -0800 2003/11/22, David O'Brien wrote:
Please, NO. There wasn't an FTP client available for this type of
recovery pre-/rescue, there shouldn't be one now.
Why? Why cut your nose off to spite your face? Even
In message: [EMAIL PROTECTED]
Bruce M Simpson [EMAIL PROTECTED] writes:
: On Thu, Nov 20, 2003 at 04:31:10PM -0800, Tim Kientzle wrote:
: * /rescue/vi is currently unusable if /usr is missing because
: the termcap database is in /usr. One possibility
: would be to build a
On Fri, Nov 21, 2003 at 03:33:51PM -0600, Guy Helmer wrote:
Tim Kientzle wrote:
Guy Helmer wrote:
Thanks to /rescue and the live filesystem archives on
current.freebsd.org, I was able to recover a machine
that I hosed after the statfs change by trying to installworld
without
On Fri, Nov 21, 2003 at 02:11:30PM -0800, Tim Kientzle wrote:
Thanks to /rescue and the live filesystem archives on
current.freebsd.org, I was able to recover
... I could have used the ftp client (or fetch) in /rescue :-)
Yes, fetch would be useful. I imagine a lot of people
in
At 5:22 PM -0800 2003/11/22, David O'Brien wrote:
Please, NO. There wasn't an FTP client available for this type of
recovery pre-/rescue, there shouldn't be one now.
Why? Why cut your nose off to spite your face? Even though this
capability may not have existed before, why shouldn't we
In message: [EMAIL PROTECTED]
Bruce Evans [EMAIL PROTECTED] writes:
: On Sat, 22 Nov 2003, M. Warner Losh wrote:
:
: In message: [EMAIL PROTECTED]
: Bruce M Simpson [EMAIL PROTECTED] writes:
: : On Thu, Nov 20, 2003 at 04:31:10PM -0800, Tim Kientzle wrote:
: : *
On Sat, 22 Nov 2003, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Bruce Evans [EMAIL PROTECTED] writes:
: On Sat, 22 Nov 2003, M. Warner Losh wrote:
: Timing Solutions uses the following minimal termcap for its embedded
: applications. It has a number of terminals that
In message: [EMAIL PROTECTED]
Bruce Evans [EMAIL PROTECTED] writes:
: Mine is better because it has a more representative slice of currently
: used terminal types. Maybe we should replace termcap.small with mine
: (maybe with the copyright notice).
:
: I agree. termcap.small is
M. Warner Losh wrote:
: I agree. termcap.small is amazingly uncurrent. However, perhaps some
: merging and reducing is in order. Why is a full cons25 or vt2xx needed?
: vi only needs a few capabilities. I think we mostly use copies of large
: termcap entries because copying the whole things
how about no copy of vi, or termcap and one copy of ed?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
boyd, rounin wrote:
how about no copy of vi, or termcap and one copy of ed?
Is this where we start swapping stories about when I was a young
sysadmin, we didn't need no stinkin vi. We used ed and liked it!. :-)
Actually, as a sysadmin who's grown old, fat, and lazy, I would prefer
to not
Is this where we start swapping stories about when I was a young
sysadmin, we didn't need no stinkin vi. We used ed and liked it!. :-)
No, this is where we, out of respect for the mbox size of our fellow
readers of -current, take this thread to -chat.
Please.
mcl
From: Richard Coleman [EMAIL PROTECTED]
Is this where we start swapping stories about when I was a young
sysadmin, we didn't need no stinkin vi. We used ed and liked it!. :-)
the point is that when you really want your valuable data back
(without resorting to backups) a small, simple toolkit
In message: [EMAIL PROTECTED]
Richard Coleman [EMAIL PROTECTED] writes:
: M. Warner Losh wrote:
:
: : I agree. termcap.small is amazingly uncurrent. However, perhaps some
: : merging and reducing is in order. Why is a full cons25 or vt2xx needed?
: : vi only needs a few
Mark Linimon wrote:
Is this where we start swapping stories about when I was a young
sysadmin, we didn't need no stinkin vi. We used ed and liked it!. :-)
No, this is where we, out of respect for the mbox size of our fellow
readers of -current, take this thread to -chat.
Please.
You
On Sat, 22 Nov 2003, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Richard Coleman [EMAIL PROTECTED] writes:
: M. Warner Losh wrote:
:
: : I agree. termcap.small is amazingly uncurrent. However, perhaps some
: : merging and reducing is in order. Why is a full cons25
Tim Kientzle wrote on Thursday, November 20, 2003 6:31 PM
Garance A Drosihn wrote:
At 6:26 PM +0100 11/17/03, Julian Stacey wrote:
Seconded ! Better commit an improved switch with
default = Off.
The time for voting was months ago.
...
I'm pretty comfortable with the failsafes
Guy Helmer wrote:
Thanks to /rescue and the live filesystem archives on
current.freebsd.org, I was able to recover a machine
that I hosed after the statfs change by trying to installworld
without building booting a new kernel first.
Great! Any changes you could suggest
to /rescue based on that
On Thu, Nov 20, 2003 at 04:31:10PM -0800, Tim Kientzle wrote:
* /rescue/vi is currently unusable if /usr is missing because
the termcap database is in /usr. One possibility
would be to build a couple of default termcap entries
into ncurses or into vi.
My suggested candidates are
--On Thursday, November 20, 2003 9:40 PM -0500 Richard Coleman
[EMAIL PROTECTED] wrote:
ust put a tiny termcap file in /rescue (i.e. termcap.rescue) that
contains 5 or 6 of the most common terminal types (cons25, vt102,
etc), and have /rescue/vi default to cons25.
If you are hosed enough to
Tim Kientzle wrote:
Guy Helmer wrote:
Thanks to /rescue and the live filesystem archives on
current.freebsd.org, I was able to recover a machine
that I hosed after the statfs change by trying to installworld
without building booting a new kernel first.
Great! Any changes you could
Thanks to /rescue and the live filesystem archives on
current.freebsd.org, I was able to recover
... I could have used the ftp client (or fetch) in /rescue :-)
Yes, fetch would be useful. I imagine a lot of people
in emergency situations will need to pull things over
a network connection.
Garance A Drosihn wrote:
At 6:26 PM +0100 11/17/03, Julian Stacey wrote:
Seconded ! Better commit an improved switch with
default = Off.
The time for voting was months ago.
Actually, the discussion started almost a year ago now.
That's when the new PAM/NSS libraries were first being
announced,
On Thu, Nov 20, 2003 at 16:31 , while impersonating an expert on
the internet, Tim Kientzle sent this to stdout:
Garance A Drosihn wrote:
At 6:26 PM +0100 11/17/03, Julian Stacey wrote:
Seconded ! Better commit an improved switch with
default = Off.
The time for voting was months ago.
From: Tim Kientzle [EMAIL PROTECTED]
Many of us here have been hamstrung by systems that didn't
provide a static fallback. I've personally been bitten by
unrecoverable Linux and Solaris systems due to hosed shared
libraries.
bingo. a small set of tools will usually save you. vi(1) is out
Hi Garance
cc current,
Thanks for your well explained posting. I won't distract from new thread
Unfortunate dynamic linking for everything
except to note:
It is not fair to pretend
that this was some kind of back-room, closed-door decision.
Sorry, I didn't mean to imply that. I
Tim Kientzle wrote:
I'm pretty comfortable with the failsafes that we
have in place:
* /sbin/init is static
* If /bin/sh fails, /rescue/sh can be run
* /rescue provides a complete set of statically-linked
sysadmin utilities that should be sufficient
for recovering a damaged system.
There
On Sun, Nov 16, 2003 at 09:51:30PM -0800, Kris Kennaway wrote:
On Mon, Nov 17, 2003 at 12:51:49AM -0500, Anthony Schneider wrote:
This isn't *totally* the case. :)
My problem is that in upgrading from 5.1-RELEASE to -CURRENT today,
installworld fails at installing test with (hand
Erik Trulsson [EMAIL PROTECTED] wrote:
On Sun, Nov 16, 2003 at 07:24:00PM -0700, Brent Jones wrote:
This is just a case of OS evolution. /sbin used to be the place where
the statically linked recovery things would be placed, in case the
shared libraries got hosed. The only things that
* Erik Trulsson [EMAIL PROTECTED] [031116 23:21]:
On Sun, Nov 16, 2003 at 07:24:00PM -0700, Brent Jones wrote:
This is just a case of OS evolution. /sbin used to be the place where
the statically linked recovery things would be placed, in case the
shared libraries got hosed. The only
On Mon, Nov 17, 2003 at 09:00:20AM -0500, Michael Edenfield wrote:
* Erik Trulsson [EMAIL PROTECTED] [031116 23:21]:
On Sun, Nov 16, 2003 at 07:24:00PM -0700, Brent Jones wrote:
This is just a case of OS evolution. /sbin used to be the place where
the statically linked recovery things
Bill Vermillion wrote:
I would think that instead of NO_DYNAMICROOT root in make.conf,
a varialbe of DYNAMICROOT be used with the default of building
static, and having the option of building dynamic for those
who need to save those few MB of space. IOW don't change one of
the things that
On Mon, 17 Nov 2003, Julian Stacey wrote:
Richard Coleman wrote:
But I think the time for these discussions is passed.
current@ is only a concensus of /usr/src developers. /usr/src
/usr/ports/ users on hackers@ ports@ isp@ may not have seen current@'s
change ? that may make later net
Robert M.Zigweid wrote:
I'll admit to being mostly a lurker here, but isn't the point of /sbin
to be statically linked. That's what the 's' stands for?
Second question. This seems to imply that /sbin and /bin both have to
have the same behavior? I have no problem with /bin being
Terry Lambert wrote:
Robert M.Zigweid wrote:
I'll admit to being mostly a lurker here, but isn't the point of /sbin
to be statically linked. That's what the 's' stands for?
Second question. This seems to imply that /sbin and /bin both have to
have the same behavior? I have no problem with /bin
On Mon, Nov 17, 2003 at 06:26:00PM +0100, Julian Stacey wrote:
Bill Vermillion wrote:
I would think that instead of NO_DYNAMICROOT root in make.conf,
a varialbe of DYNAMICROOT be used with the default of building
static, and having the option of building dynamic for those
who need to
walt wrote:
Terry Lambert wrote:
Robert M.Zigweid wrote:
I'll admit to being mostly a lurker here, but isn't the point of /sbin
to be statically linked. That's what the 's' stands for?
Second question. This seems to imply that /sbin and /bin both have to
have the same behavior? I
On Mon, Nov 17, 2003 at 12:59:47PM -0800, Peter Wemm wrote:
It is 'system' binaries. The distinction between bin and sbin (and /usr/
bin and /usr/sbin) is that the binaries in */sbin are only really supposed
to be useful for administrators or other priviliged users.
Yup, this distinction was
At 6:26 PM +0100 11/17/03, Julian Stacey wrote:
Seconded ! Better commit an improved switch with
default = Off.
The time for voting was months ago. In fact, we have
been running with what-you-call an improved switch for
the past few months, to give people a chance to work out
all the issues
well, it did compile, install and (mostly) boot with NO_DYNAMICROOT.
However,i'm back to another problem (see my next email).
Thanks for the responses.
-Anthony.
On Mon, Nov 17, 2003 at 12:06:11PM +0200, Ruslan Ermilov wrote:
On Sun, Nov 16, 2003 at 09:51:30PM -0800, Kris Kennaway wrote:
On
Ken Smith wrote:
On Mon, Nov 17, 2003 at 12:59:47PM -0800, Peter Wemm wrote:
It is 'system' binaries. The distinction between bin and sbin (and /usr/
bin and /usr/sbin) is that the binaries in */sbin are only really supposed
to be useful for administrators or other priviliged users.
On Sun, Nov 16, 2003 at 11:37:47PM -0500, Bill Vermillion wrote:
For those who don't build the OS but install from binaries, this
makes the system potentially less rugged.
One of the things I disliked about the Linux systems I've been on
is libraries that change and break things - for things
On Nov 16, 2003, at 12:10 AM, Gordon Tetlow wrote:
I just committed a patch to change /bin and /sbin from statically to
dynamically linked. If you don't like the idea of using a dynamically
linked /bin and /sbin, now is the time to define NO_DYNAMICROOT in your
make.conf.
The reasons for doing so
Robert M.Zigweid wrote:
I'll admit to being mostly a lurker here, but isn't the point of /sbin
to be statically linked. That's what the 's' stands for?
Second question. This seems to imply that /sbin and /bin both have to
have the same behavior? I have no problem with /bin being dynamically
On Sun, 16 Nov 2003, Richard Coleman wrote:
Robert M.Zigweid wrote:
I'll admit to being mostly a lurker here, but isn't the point of /sbin
to be statically linked. That's what the 's' stands for?
Second question. This seems to imply that /sbin and /bin both have to
have the same
On 2003.11.16 09:46:47 -0500, Robert M.Zigweid [EMAIL PROTECTED]
wrote:
On Nov 16, 2003, at 12:10 AM, Gordon Tetlow wrote:
I just committed a patch to change /bin and /sbin from statically to
dynamically linked. If you don't like the idea of using a
dynamically linked /bin and /sbin,
On Sun, Nov 16, 2003 at 02:50:24PM -0800, Darren Pilgrim wrote:
On 2003.11.16 09:46:47 -0500, Robert M.Zigweid [EMAIL PROTECTED]
wrote:
On Nov 16, 2003, at 12:10 AM, Gordon Tetlow wrote:
I just committed a patch to change /bin and /sbin from statically to
dynamically linked. If you
Hi
Darren Pilgrim wrote:
What was done to programs like /bin/sh, /sbin/init and /sbin/fsck to
make them work without access to /usr/lib?
All the libs required for /bin or /sbin have moved to /lib. Like this:
cd /bin
file sh
sh: ELF 64-bit MSB executable, SPARC V9, version 1 (FreeBSD), for
On Nov 16, 2003, at 9:22 AM, Richard Coleman wrote:
Robert M.Zigweid wrote:
I'll admit to being mostly a lurker here, but isn't the point of
/sbin to be statically linked. That's what the 's' stands for?
Second question. This seems to imply that /sbin and /bin both have
to have the same
At Sat, 15 Nov 2003 21:10:28 -0800,
Gordon Tetlow [EMAIL PROTECTED] wrote:
I just committed a patch to change /bin and /sbin from statically to
dynamically linked. If you don't like the idea of using a dynamically
linked /bin and /sbin, now is the time to define NO_DYNAMICROOT in your
On Sun, Nov 16, 2003 at 07:24:00PM -0700, Brent Jones wrote:
On Nov 16, 2003, at 9:22 AM, Richard Coleman wrote:
Robert M.Zigweid wrote:
I'll admit to being mostly a lurker here, but isn't the point of
/sbin to be statically linked. That's what the 's' stands for?
Second question. This
--
Message: 10
Date: Sun, 16 Nov 2003 14:50:24 -0800
From: Darren Pilgrim [EMAIL PROTECTED]
Subject: Re: HEADS UP: /bin and /sbin are now dynamically linked
On 2003.11.16 09:46:47 -0500, Robert M.Zigweid [EMAIL PROTECTED]
wrote:
On Nov 16, 2003, at 12:10
On Sun, Nov 16, 2003 at 11:37:47PM -0500, Bill Vermillion wrote:
1) Much smaller /bin and /sbin. On i386, /bin and /sbin are 33 MB
static.
Dynamically linked, they are only 4 MB.
I don't think saving that little space on the / partition is as
important as having everthing in
If memory serves me right, Bill Vermillion wrote:
I don't think saving that little space on the / partition is as
important as having everthing in sbin being able to stand alone no
matter what is corrupted.
man 8 rescue
Bruce.
pgp0.pgp
Description: PGP signature
Bill Vermillion wrote:
1) Much smaller /bin and /sbin. On i386, /bin and /sbin are 33 MB
static.
Dynamically linked, they are only 4 MB.
I don't think saving that little space on the / partition is as
important as having everthing in sbin being able to stand alone no
matter what is
On Sun, Nov 16, 2003 at 11:37:47PM -0500, Bill Vermillion wrote:
One thing I always liked of the FBSD approach as opposed to others
is to make ever tool that might possible be needed in a system
recovery static so if it was there it would work.
How about you take a look at what is actually
This isn't *totally* the case. :)
My problem is that in upgrading from 5.1-RELEASE to -CURRENT today,
installworld fails at installing test with (hand copied):
---8---8---
=== bin/test
install -s -o root -g wheel -m 555 test /bin
install -o root -g wheel -m 444 test.1.gz /usr/share/man/man1
ELF
On Mon, Nov 17, 2003 at 12:51:49AM -0500, Anthony Schneider wrote:
This isn't *totally* the case. :)
My problem is that in upgrading from 5.1-RELEASE to -CURRENT today,
installworld fails at installing test with (hand copied):
Except we weren't talking about buildworld - sorry to hear you're
97 matches
Mail list logo
