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.
>
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 http://www.t
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 http://www.theregis
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 http://www.theregister.co
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 http://www.theregis
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% |*
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 moment.
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
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
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 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 p
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 /.
>
>
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 make.co
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
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 tha
> 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
FWI
>[ 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 t
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
>> >
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 (
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 d
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 repai
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 /.
I
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
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 a
* 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 t
> > 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 t
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
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 sy
On Mon, Nov 24, 2003 at 11:46:54AM -0500, Garrett Wollman wrote:
> < 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.
Why wasn't it enough of a
[ 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
< 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
___
[EMAIL PROTECTED] mailing list
http://li
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
> >
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 o
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
--
Dag
> 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.
Wr
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.
>>
>>
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
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
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 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
http://lists.freebsd.org/mai
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 fu
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.
>
> Pl
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 ca
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
> 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
_
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 ne
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]"
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 is
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.smal
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 term
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:
: >
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 have
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
>
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
> > > w
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 buil
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. L
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 y
--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 req
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
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 e
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 t
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
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
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) i
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 month
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, w
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 th
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 user
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:
> > O
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 bef
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 w
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
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 nee
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 /bi
"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 dyn
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 la
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 th
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 recover
* 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
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 thing
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 (ha
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 y
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
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
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 corrupted.
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
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 e
On Sun, Nov 16, 2003 at 11:37:47PM -0500, 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.
You are aware of /rescue, right?
> On a non-FreeBSD system I had t
> --
> 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]>
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 quest
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 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 behavio
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),
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
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 an
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
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, Nov 16, 2003 at 09:46:47AM -0500, Robert M.Zigweid 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, now
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
100 matches
Mail list logo
