Re: HEADS UP: /bin and /sbin are now dynamically linked
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. $ /usr/bin/ftp http://www.theregister.co.uk/content/6/32524.html Requesting http://www.theregister.co.uk/content/6/32524.html 100% |*| 22559 35.32 KB/s 00:00 ETA 22559 bytes retrieved in 00:00 (35.28 KB/s) Wow! Learn something new every day around here. Well, it's a rather new ftp(1), this feature came with lukemftp replacing the former ftp. I believe Microsoft Windows still ships the old ftp client thought. The version of ftp in 4.9-R also supports this feature and is documented in the man page. :-) In fact, it looks like it was added my Mike Smith back in June of 1997 (source was Luke Mewburn/NetBSD). Bob -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -- Bob Willcox First Law of Procrastination: [EMAIL PROTECTED] Procrastination shortens the job and places the Austin, TX responsibility for its termination on someone else (i.e., the authority who imposed the deadline). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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% |*| 22559 35.32 KB/s 00:00 ETA 22559 bytes retrieved in 00:00 (35.28 KB/s) Wow! Learn something new every day around here. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
OT [was: Re: HEADS UP: /bin and /sbin are now dynamically linked]
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.theregister.co.uk/content/6/32524.html 100% |*| 22559 35.32 KB/s 00:00 ETA 22559 bytes retrieved in 00:00 (35.28 KB/s) Wow! Learn something new every day around here. Well that's bizarre IMHO. I never had guessed a tool called ftp would unterstand http! Just my 2¢ -Harry Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] pgp0.pgp Description: signature
Re: HEADS UP: /bin and /sbin are now dynamically linked
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.uk/content/6/32524.html 100% |*| 22559 35.32 KB/s 00:00 ETA 22559 bytes retrieved in 00:00 (35.28 KB/s) Wow! Learn something new every day around here. For consistency, we should link ftp(1) to http(1) I guess... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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.theregister.co.uk/content/6/32524.html Requesting http://www.theregister.co.uk/content/6/32524.html 100% |*| 22559 35.32 KB/s 00:00 ETA 22559 bytes retrieved in 00:00 (35.28 KB/s) Wow! Learn something new every day around here. For consistency, we should link ftp(1) to http(1) I guess... Good idea. I'll ask RE. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 program that would be optionally-added to /rescue. Oh, sure; nothing's ever as easy as it should be :) 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, without putting extra burden on developers or people who don't wanna. It may only be a fifth of a loaf, but... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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:
---
liblist:
@echo '== Getting needed libraries'
-@(cd ${SRCBASE}/bin ldd ${BINFILES}) liblist.raw
-@(cd ${SRCBASE}/sbin ldd ${SBINFILES}) liblist.raw
[ ... similar stuff for other dirs ... ]
[EMAIL PROTECTED] -v '^[a-z]' liblist.raw | awk '{print $$3}' | sort | uniq \
| sed 's,^${SRCBASE},,' | sed 's,^/,,' liblist.cooked
[EMAIL PROTECTED] liblist.cooked
@tar -cf - -C ${SRCBASE} `cat liblist.cooked` \
| tar -xvpf - -C ${DSTBASE}
-@(cd ${SRCBASE}/usr/lib install -c -m 444 pam_* ${DSTBASE}/usr/lib)
@echo '== Done libraries'
---
You'll note that I already manually slipped in the pam_* .so's, which is
one of those additional non-obvious extra files things that Garance
mentioned in the other message. I could probably replace the whole
transformation pipeline with a few lines of actual scripted awk(1); I
just did it all inline in the Makefile because I was lazy.
${SRCBASE} is somewhere I DESTDIR='d an installworld previously, and
${DSTBASE} becomes (as a result of a bunch of other make targets, of
which this is one of the later ones) a dir I can tar up and untar
somewhere as /.
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 end the thread I'm all for it. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 work for any program that would be optionally-added to /rescue. Oh, sure; nothing's ever as easy as it should be :) 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, without putting extra burden on developers or people who don't wanna. It may only be a fifth of a loaf, but... ... but a /rescue that doesn't work is useless. The one critical property of /rescue is that it MUST WORK when /bin and /sbin are both hosed. Your technique here cannot gaurantee this. Testing /rescue is not a simple exercise. You must first break both /bin and /sbin and unmount /usr. You must then test EVERY part of /rescue, since adding or removing one program can potentially break other programs (whose hard-coded references to that program may need to be adjusted). There are (fortunately) a few shortcuts (I spent a long time poring over the output of 'strings /rescue/rescue' to check for hard-coded references), but it's still not pretty. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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. (Working out APIs for new libraries is not a simple task. sigh) I don't have a lot of time for FreeBSD hacking, and this thread has consumed a rather sizable percentage of it. If we're going to add an FTP client, lets pick the one with the best functionality for the job -- /usr/bin/ftp. I may not know the complete URL to the bits I need, and if so with fetch you're still screwed. On the other hand, /usr/bin/ftp also has drawbacks: It requires ncurses (one reason I am interested in dropping vi is to shed the ncurses library and the need for a termcap file), it's considerably larger than fetch, and it doesn't support HTTP. But you are right that if you need to get a file from somewhere, you probably don't already know the exact location of that file, and ftp's browsing ability would be very useful then. Harumph It's a very good suggestion; I'll have to get back to you on it. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 not typically there? RESCUE_EXTRAPRGS= usr.bin/vi usr.bin/fetch This list could easily need things added to librescue. If you can delay building the rescue stuff until after everything else, you can use ldd(1) on the built binaries for everything else and hash up the list from that. I do something similar in a set of scripts I have to generate filesystems for small systems (i.e., I create a variable in a Makefile listing all the programs, and it automatically includes all the libraries the programs need) with a little sed/awk. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 into /rescue that are not typically there? RESCUE_EXTRAPRGS= usr.bin/vi usr.bin/fetch This list could easily need things added to librescue. If you can delay building the rescue stuff until after everything else, you can use ldd(1) on the built binaries for everything else and hash up the list from that. 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 program that would be optionally-added to /rescue. Also, if you completely automate it, then a year from now someone will make a change to 'vi' which drags in a few extra libraries, and people will be blind-sided with a much larger /rescue. If someone is watching what happens, they could #ifdef-out that extra code for the /rescue version. I do like the idea, but to do it right *will* involve extra work for each optional program. I would gladly do that extra work for any programs that I cared to have in /rescue -- but personally I set up dual-boot systems, so I don't really care about any of them... :-) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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.conf magic, for the end-user to set extra programs to be put into /rescue that are not typically there? RESCUE_EXTRAPRGS= usr.bin/vi usr.bin/fetch This list could easily need things added to librescue. If you can delay building the rescue stuff until after everything else, you can use ldd(1) on the built binaries for everything else and hash up the list from that. I do something similar in a set of scripts I have to generate filesystems for small systems (i.e., I create a variable in a Makefile listing all the programs, and it automatically includes all the libraries the programs need) with a little sed/awk. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 to compromise, David. Here's what I suggest: * I could support removing vi/ex from /rescue. Either way -- keep it or not. But lets agree that the FTP client will be the last thing added to /rescue that is outside the original charter. * In exchange for this concession, would you be willing to support adding fetch? If we're going to add an FTP client, lets pick the one with the best functionality for the job -- /usr/bin/ftp. I may not know the complete URL to the bits I need, and if so with fetch you're still screwed. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 cut your nose off to spite your face? Even though this capability may not have existed before, why shouldn't we have it now? 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. 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. Not diskless clients, but ruined FreeBSD installation. IMHO /rescue is created for it. We shouldn't put fetch into /bin, but placing fetch into crunched executable may be helpful in case of system restore. Sincerely, Maxim M. Kazachek mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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. Wrong. Not diskless. Simple w/o CD, DVD, FDC. Only HDD. -- Slawa Olhovchenkov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 trashed file to replace a damaged local copy. 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 sysadmin could recover from every conceivable way of trashing a system. /rescue was not to become the all-in-compassing Swiss Army recover tool. We provide the Live-FS CD (disc 2) for that. I can only think of a few places where that good copy can come from: * CDROM: requires a CD-ROM drive, and a suitable CD. * floppy: requires a floppy drive * NFS: requires a local network and an NFS server * An HTTP or FTP server: requires a network connection and 'fetch.' I don't think we can safely assume that everyone has access to one of the first three options here. 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 /? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 locating a good copy of a trashed file to replace a damaged local copy. 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 /. Ie, let's do things the same way we did in 1994? Other things have changed since then, hard drives and typical root partitions are much bigger, and Tim estimated the total bloat from this as 64k. Maybe earlier, pre-/rescue, you couldn't recover from damaged files in the root partition without a CD/floppy/NFS, it doesn't mean you should not have that capability in /rescue. 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. This applies equally if the trashed file is in /lib[exec]. I don't understand this argument of we have never been able to do this, therefore we shouldn't do this now even if we are able to. Rahul ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
[ 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 mishaps they could before we went to a dynamic /.
Ie, let's do things the same way we did in 1994? Other things have
changed since then, hard drives and typical root partitions are much
bigger, and Tim estimated the total bloat from this as 64k. Maybe
earlier, pre-/rescue, you couldn't recover from damaged files in the
root partition without a CD/floppy/NFS, it doesn't mean you should not
have that capability in /rescue.
Lets have /rescue/{[s]bin,usr/[s]bin}. Install static copies of every
thing in /[s]bin and /usr/[s]bin today. That will let you recover in
even more ways.
Where does it end if we don't go full-out and install a 2nd copy of every
binary?
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,
which doesn't have an FTP server. Samba, not an FTP client should be in
/rescue then.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 /? Because we are not all masochists. Why wasn't it enough of a problem to bring up until we went to a dynamic /? Not having a usable FTP client if your libs are FUBAR'ed isn't new with dynamic. Now that it is brought up, where does it end what goes into /rescue? Having what goes into /rescue bounded only by what is in /[s]bin, /usr/[s]bin is what worries some of us. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 sysadmin could recover from every conceivable way of trashing a system. /rescue was not to become the all-in-compassing Swiss Army recover tool. We provide the Live-FS CD (disc 2) for that. Another issue with adding more-and-more to /rescue is that every thing added to /rescue is compiled for it. Which is to say, the time it takes for a buildworld keeps increasing. I just bought one hardware upgrade to get back the time lost from going to GCC 3.x, and I find that the buildworld times are now increasing again due to compiling everything twice for /rescue. I kind of like the idea of having 'vi' available, but I will also admit that I don't need it. All my hardware has CD-ROM drives, and I set up all my systems with multiple (multi-boot) installs of freebsd. If something goes wrong, I like having vi around, but then I also like having bash and ruby (among other things). So, I have dual-boot systems. No matter what you put in /rescue, there are *possible* disaster scenarios where you won't have something you need. For some reason, I manage to hit those every few months. From my experience I have found that it's much better to have multiple separate installs, and that way I can usually fix one install from the other one. Other people will have other hardware, and thus other needs. We should probably make sure it's easy to add some of these programs to /rescue, but I don't think that all of us should have to build all the programs that any one of us feel they might need. I doubt there is any perfect answer which will satisfy everyone, but perhaps we can recognize that and figure out some flexible middle ground. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 trying to understand what those failure modes are and what that implies about the contents of /rescue. I do want /rescue to be small and I want it to compile quickly. But I mostly want it to be useful to the people who need it. I kind of like the idea of having 'vi' available, ... I'm personally tempted to remove vi/ex from /rescue. I originally put it in based on my experience recovering systems where I needed to edit configure files. But, I've not managed to come up with a scenario where a broken config file would break /bin. If that's the case, then vi isn't needed in /rescue, since the purpose of /rescue is to repair a broken /bin, /sbin, /lib. Once those are working, you can mount /usr and have access to /usr/bin/vi. 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 /sbin if they break. That could be a very small set of tools. It is not necessarily a subset of /bin and /sbin, however. Unfortunately (or fortunately, I suppose), few people seem to have actually needed /rescue, so we as a community don't yet have enough experience to really tailor that toolkit. disaster scenarios where you won't have something you need. For some reason, I manage to hit those every few months. The only way to find out what's truly necessary in /rescue is to pay attention to people who actually use it. If someone knows they'll never use it, NO_RESCUE has been shown to measurably reduce buildworld times. I doubt there is any perfect answer which will satisfy everyone, but perhaps we can recognize that and figure out some flexible middle ground. That's exactly what I'm trying to do. Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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, which doesn't have an FTP server. Samba, not an FTP client should be in /rescue then. # ftp ftp.freebsd.org get blah/blah/blah/release/bin.tgz # tar xzvf seems like a damn easy fix for killing /bin and /sbin i like the idea of having a tiny (re: non-ssl) fetch availble for when i shoot myself in the foot. would be incredibly helpful. And while in my current configurations, live cd or NFS are also options, sometimes fetch is going to be faster, and if it's a production machine, time is money. In a perfect world, I'd never hose a production machine, but... ~j ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] = Yesterday upon the stair I saw a man who wasn't there, he wasn't there again today, oh how i wish he'd go away Rev. Jonathan T. Sage - Lighting / Set Designer [HTTP://www.wisefreebsd.org] [HTTP://jonsage.wisefreebsd.org] [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
* 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 put into /rescue that are not typically there? RESCUE_EXTRAPRGS= usr.bin/vi usr.bin/fetch ?? --Mike pgp0.pgp Description: PGP signature
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 /sbin if they break. No, you're missing my stance. My stance is that no failure mode needs to be repairable that wasn't repairable with a static /. With a static / last month, if I needed to get a file onto the machine, I had to use a floppy, CDROM, or mount another file system (NFS counts in this). The argument flowing in this thread is about adding additional ways to repair a trashed machine. Those of us that agreed to the /rescue bloat didn't agree to that. We agreed to the claim that /rescue would hold those bits needed to repair a trashed system in the SAME ways one did with a static /. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 extra programs to be put into /rescue that are not typically there? RESCUE_EXTRAPRGS= usr.bin/vi usr.bin/fetch This list could easily need things added to librescue. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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'm willing to compromise, David. Here's what I suggest: * I could support removing vi/ex from /rescue. * In exchange for this concession, would you be willing to support adding fetch? I expect this exchange would result in a net 150-200 kB savings in /rescue. How about it? Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 repairable with a static /. I'm willing to compromise, David. Here's what I suggest: * I could support removing vi/ex from /rescue. * In exchange for this concession, would you be willing to support adding fetch? I expect this exchange would result in a net 150-200 kB savings in /rescue. How about it? Tim I think a better compromise is to add the make.conf option so that extra utilities may be added to /rescue. Then leave both vi and fetch out of the default. With the size of disk drives these days, (for my own setup) I'm tempted to just add a complete copy of /bin and /sbin into /rescue. The extra 100 meg doesn't take much out of a 80 gig hard drive. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 do automatically. In addition, a surprising number of programs require minor source edits to function correctly in /rescue. In particular, many programs have hard-coded references to specific programs in /bin and /sbin. I spent a long time tracking down such references and replacing them with references to /rescue where appropriate. Without those changes, /rescue will work correctly only if /bin and /sbin are functional. There is a real potential for landmines here. With the size of disk drives these days, (for my own setup) I'm tempted to just add a complete copy of /bin and /sbin into /rescue. There's surprisingly little of /bin and /sbin that isn't already in /rescue. Most of what's omitted was left out for very straightforward reasons (e.g., tcsh is clearly redundant, devd is incompatible with crunchgen, etc.) 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. Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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, /sbin, or /lib. Thus, most /rescue scenarios are going to involve locating a good copy of a trashed file to replace a damaged local copy. 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 /. Ie, let's do things the same way we did in 1994? To put it another way. FreeBSD has never had the ability to recover from a hosed root or /usr using FTP, though you can use rrestore or rcp to recover /usr. There has never been a great groundswell of complaints about this (offhand, I can't recall any). Why does this suddenly become a major issue once / is dynamically linked? Other things have changed since then, hard drives and typical root partitions are much bigger, Pre-existing harddrives and root partitions do not magically expand over time. A new installation and/or a new harddrive might have a much bigger root partition but an existing one won't. and Tim estimated the total bloat from this as 64k. And then someone else wants their favourite tool which is only another 64K and so on. Pretty soon you have a 200MB /rescue. Maybe earlier, pre-/rescue, you couldn't recover from damaged files in the root partition without a CD/floppy/NFS, it doesn't mean you should not have that capability in /rescue. If no-one's missed it in the past, why would they suddenly need it now? Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
[ 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 mishaps they could before we went to a dynamic /.
Ie, let's do things the same way we did in 1994? Other things have
changed since then, hard drives and typical root partitions are much
bigger, and Tim estimated the total bloat from this as 64k. Maybe
earlier, pre-/rescue, you couldn't recover from damaged files in the
root partition without a CD/floppy/NFS, it doesn't mean you should not
have that capability in /rescue.
Lets have /rescue/{[s]bin,usr/[s]bin}. Install static copies of every
thing in /[s]bin and /usr/[s]bin today. That will let you recover in
even more ways.
Where does it end if we don't go full-out and install a 2nd copy of every
binary?
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,
which doesn't have an FTP server. Samba, not an FTP client should be in
/rescue then.
There are a lot of FTP servers for M$ Windows... At least
IIS/PWS... :-) IMHO, Microsoft gives it to all, neglecting whether they
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
space (that isn't really needed on modern disks), but we will loose
functionality... For me, having /rescue/fetch is a good thing, just
because it can REALLY help me to recover fallen system.
Sincerely, Maxim M. Kazachek
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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, *large* installations, don't bother with buying floppies and cdroms. (By large I mean 1000 machines.) Then again, places with large installations, probably don't use the freebsd installer, *or* have the clue to not be (too) hurt by these changes. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 : would be to build a couple of default termcap entries : into ncurses or into vi. : : My suggested candidates are vt100 and cons25. The comconsole port installs : an /etc/ttys entry using vt100. This is also the default terminal type for : most dialup entries. Timing Solutions uses the following minimal termcap for its embedded applications. It has a number of terminals that it supports, while still being tiny. it is 3.5k in size, which was the goal ( 4k block size we were using). One could SED this down by another 140 bytes or so. Removing the comments and the verbose names would net another 300 odd bytes. The terminals supported are vt220, vt102, vt100, xterm, xterms, cons25w, cons25 and ansi. This seems a reasonable number: neither too few, nor too many. It lets people connect 'normal' terminals to the serial port (most PCs have vt100/vt220 emulation), as well as PC to PC connection on the console or xterm. I'd be happy to commit this as /etc/termcap.tiny. vi could then look for both termcap and termcap.tiny and things would just work. Comments? Sounds like a good idea to me. I only wonder if it makes sense to commit it as /rescue/termcap.tiny to make the purpose clear? I see no point in trying to prune any smaller. As you point out, it's already smaller than a typical block size. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 though this capability may not have existed before, why shouldn't we have it now? Lets build all of /bin, /sbin, /usr/bin, /usr/sbin static then. You would have all kinds of capability you didn't before. /rescue is the consession made between those that want a dynamic / and those that want a static /. Its purpose is only to allow one to do the things they could before with a static /. It is not to become a can or worms that ends up being a duplicate of 50% of the system. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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
wouldn't be needed.
Bruce M Simpson wrote:
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.
Fetch requires libfetch (45k). I've not tested, but I expect
it adds less than 64k to /rescue.
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 trashed file to replace a damaged
local copy.
I can only think of a few places where that good copy
can come from:
* CDROM: requires a CD-ROM drive, and a suitable CD.
* floppy: requires a floppy drive
* NFS: requires a local network and an NFS server
* An HTTP or FTP server: requires a network connection and 'fetch.'
I don't think we can safely assume that everyone has access to
one of the first three options here.
Given the choice between 'vi' and 'fetch,' I'd definitely
choose the latter. ('vi' is useful for repairing config files;
errors in config files are not generally going to break /bin.)
I don't see fetch as a requirement for diskless clients.
This is a red herring: diskless clients don't need /rescue since
any recovery necessary can be done on the server. Whether or
not diskless clients require fetch has therefore no bearing at
all on the question of whether fetch should be in /rescue.
Tim Kientzle
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 though this capability may not have existed before, why shouldn't we have it now? 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. 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. Regards, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 couple of default termcap entries : into ncurses or into vi. : : My suggested candidates are vt100 and cons25. The comconsole port installs : an /etc/ttys entry using vt100. This is also the default terminal type for : most dialup entries. Timing Solutions uses the following minimal termcap for its embedded applications. It has a number of terminals that it supports, while still being tiny. it is 3.5k in size, which was the goal ( 4k block size we were using). One could SED this down by another 140 bytes or so. Removing the comments and the verbose names would net another 300 odd bytes. The terminals supported are vt220, vt102, vt100, xterm, xterms, cons25w, cons25 and ansi. This seems a reasonable number: neither too few, nor too many. It lets people connect 'normal' terminals to the serial port (most PCs have vt100/vt220 emulation), as well as PC to PC connection on the console or xterm. I'd be happy to commit this as /etc/termcap.tiny. vi could then look for both termcap and termcap.tiny and things would just work. Comments? Warner vt200|vt220|vt220am|vt200am|dec-vt220|dec-vt200|dec vt200 series with jump scroll:\ :@7=\E[4~:kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kh=\E[1~:\ :k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:\ :k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:\ :ve=\E[?25h:vi=\E[?25l:k0@:im@:ei@:\ :F1=\E[23~:F2=\E[24~:ic=\E[@:IC=\E[%d@:ec=\E[%dX:tc=vt102: vt100|dec-vt100|vt100-am|vt100am|dec vt100:\ :do=2\E[B:co#80:li#24:cl=50\E[H\E[J:sf=2*\ED:\ :le=^H:bs:am:cm=5\E[%i%d;%dH:nd=2\E[C:up=2\E[A:\ :ce=3\E[K:cd=50\E[J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:\ :md=2\E[1m:mr=2\E[7m:mb=2\E[5m:me=2\E[m:\ :is=\E\E[?1;3;4;5l\E[?7;8h\E[1;24r\E[24;1H:\ :if=/usr/share/tabset/vt100:nw=2\EE:ho=\E[H:\ :as=2\E(0:ae=2\E(B:ac=llmmkkjjuuttvvwwqqxxnnpprr``aa:\ :rs=\E\E[?1;3;4;5l\E[?7;8h:ks=\E[?1h\E=:ke=\E[?1l\E:\ :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=\177:\ :k0=\EOy:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\EOt:\ :k6=\EOu:k7=\EOv:k8=\EOl:k9=\EOw:k;=\EOx:@8=\EOM:\ :K1=\EOq:K2=\EOr:K3=\EOs:K4=\EOp:K5=\EOn:pt:sr=2*\EM:vt#3:xn:\ :sc=2\E7:rc=2\E8:cs=5\E[%i%d;%dr:UP=2\E[%dA:DO=2\E[%dB:RI=2\E[%dC:\ :LE=2\E[%dD:ct=2\E[3g:st=2\EH:ta=^I:ms:bl=^G:cr=^M:eo:it#8:ut:\ :RA=\E[?7l:SA=\E[?7h: vt102|dec-vt102-am|vt102am|vt100 w/adv. video:\ :al=\E[L:dl=\E[M:im=\E[4h:ei=\E[4l:mi:dc=\E[P:\ :AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:tc=vt100-np: vt100-np|dec-vt100-np|vt100 with no padding (for psl games):\ :do=\E[B:cl=\E[H\E[J:sf=\ED:as=\E(0:ae=\E(B:\ :cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:nw=\EE:\ :ce=\E[K:cd=\E[J:so=\E[7m:se=\E[m:us=\E[4m:ue=\E[m:\ :md=\E[1m:mr=\E[7m:mb=\E[5m:me=\E[m:sr=\EM:\ :sc=\E7:rc=\E8:cs=\E[%i%d;%dr:UP=\E[%dA:DO=\E[%dB:RI=\E[%dC:\ :LE=\E[%dD:ct=\E[3g:st=\EH:tc=vt100-am: xterm|vs100|xterm terminal emulator (X window system):\ :li#65:\ :kh=\EOH:@7=\EOF:kb=^H:kD=^?:\ :k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:km:\ :is=\E\E[?1;3;4;5l\E[?7;8h\E[1;65r\E[65;1H:\ :rs=\E\E[?1;3;4;5l\E[?7;8h:\ :tc=vt220: xterms|vs100s|xterm terminal emulator (small)(X window system):\ :is=\E\E[?1;3;4;5l\E[?7;8h\E[1;24r\E[24;1H:\ :li#24:tc=xterm: # for syscons # common entry without semigraphics cons25w|ansiw|ansi80x25-raw:\ :al=\E[L:am:bs:NP:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:co#80:\ :dc=\E[P:dl=\E[M:do=\E[B:bt=\E[Z:ho=\E[H:ic=\E[@:li#25:cb=\E[1K:\ :ms:nd=\E[C:pt:rs=\E[x\E[m\Ec:so=\E[7m:se=\E[m:up=\E[A:\ :pa#64:Co#8:AF=\E[3%dm:AB=\E[4%dm:op=\E[x:sc=\E7:rc=\E8:\ :k1=\E[M:k2=\E[N:k3=\E[O:k4=\E[P:k5=\E[Q:k6=\E[R:k7=\E[S:k8=\E[T:\ :k9=\E[U:k;=\E[V:F1=\E[W:F2=\E[X:K2=\E[E:nw=\E[E:ec=\E[%dX:\ :kb=^H:kh=\E[H:ku=\E[A:kd=\E[B:kl=\E[D:kr=\E[C:le=^H:eo:sf=\E[S:sr=\E[T:\ :kN=\E[G:kP=\E[I:@7=\E[F:kI=\E[L:kD=\177:kB=\E[Z:\ :IC=\E[%d@:DC=\E[%dP:SF=\E[%dS:SR=\E[%dT:AL=\E[%dL:DL=\E[%dM:\ :DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:cv=\E[%i%dd:ch=\E[%i%d`:bw:\ :mb=\E[5m:md=\E[1m:mh=\E[30;1m:mr=\E[7m:me=\E[m:bl=^G:ut:it#8:km: cons25|ansis|ansi80x25:\ :ac=l\332m\300k\277j\331u\264t\303v\301w\302q\304x\263n\305`^Da\260f\370g\361~\371.^Y-^Xh\261I^U0\333y\363z\362:\ :tc=cons25w: dosansi|ANSI.SYS standard crt:\ :am:bs:ce=\E[K:cl=\E[2J:cm=\E[%i%d;%dH:co#80:\ :do=\E[B:li#25:mi:nd=\E[C:\ :se=\E[m:so=\E[7m:up=\E[A:us=\E[4m:ue=\E[m:\ :md=\E[1m:mh=\E[m:mb=\E[5m:me=\E[m:\ :kh=\EG:kb=^h:ku=\EH:kd=\EP:kl=\EK:kr=\EM:\ :k1=\E;:k2=\E:k3=\E=:k4=\E:k5=\E?:\
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 building booting a new kernel first. Great! Any changes you could suggest to /rescue based on that experience? Sure -- I could have used the ftp client (or fetch) in /rescue :-) (/me ducks) You wouldn't have had it pre-dynamic /: fetch is /usr/bin/fetch ftp is /usr/bin/ftp ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 emergency situations will need to pull things over a network connection. Looks like it would only add about 65k (20k for fetch, another 45k for libfetch which isn't already in the crunched /rescue binary). Submit a PR on this Please, NO. There wasn't an FTP client available for this type of recovery pre-/rescue, there shouldn't be one now. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 it now? -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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: : : * /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 vt100 and cons25. The comconsole port installs : : an /etc/ttys entry using vt100. This is also the default terminal type for : : most dialup entries. : : Timing Solutions uses the following minimal termcap for its embedded : applications. It has a number of terminals that it supports, while : still being tiny. it is 3.5k in size, which was the goal ( 4k block : size we were using). One could SED this down by another 140 bytes or : so. Removing the comments and the verbose names would net another 300 : odd bytes. : : What's wrong with FreeBSD's /usr/src/etc/termcap.small, except it is : twice as large and has a weird selection of entries (zillions of : variants of cons25, dosansi and pc3). 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). Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 it supports, while : still being tiny. it is 3.5k in size, which was the goal ( 4k block : size we were using). One could SED this down by another 140 bytes or : so. Removing the comments and the verbose names would net another 300 : odd bytes. : : What's wrong with FreeBSD's /usr/src/etc/termcap.small, except it is : twice as large and has a weird selection of entries (zillions of : variants of cons25, dosansi and pc3). 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 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 easier. Bruce Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 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 easier. You have a good point. My termcap was done so that we could run a number of applications... Grepping seems unsatisfying to find out which keys are used. Do you have a list? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 easier. You have a good point. My termcap was done so that we could run a number of applications... Grepping seems unsatisfying to find out which keys are used. Do you have a list? Warner Is the extra maintenance worth it to save a few hundred bytes? It might even make sense to dynamically generate termcap.tiny at build time by pulling out the entries in /etc/termcap for a selected list of terminal types. Then, no extra maintenance would be needed. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 need to use ed ever again. There's no need to be masochistic. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 is superior to abitrary and gratuitous complexity. or you could goto fonfon; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 capabilities. I think we mostly use copies of large : : termcap entries because copying the whole things is easier. : : You have a good point. My termcap was done so that we could run a : number of applications... : : Grepping seems unsatisfying to find out which keys are used. Do you : have a list? : : Warner : : Is the extra maintenance worth it to save a few hundred bytes? Generating them automatically can be kind of difficult. termcap doesn't change that often. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 know, its never been done on our mailing lists that I can remember, but this thread is certainly one that I'm seriously thinking of killing at the mailing list gateway for the first time. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 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 easier. : : You have a good point. My termcap was done so that we could run a : number of applications... : : Grepping seems unsatisfying to find out which keys are used. Do you : have a list? nvi/cl/cl_bsd.c has a possibly complete enough list in its terminfo translation table. : Is the extra maintenance worth it to save a few hundred bytes? Probably not, if this is mainly for use by rescue on larger (multi-megabyte) disks. I used an 8K termcap on 1200MB floppy rescue disks many years ago, Generating them automatically can be kind of difficult. termcap doesn't change that often. As someone pointed out, ed is sufficient. It's all we had on the root partition. I remember how to use it mainly from using it there. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: HEADS UP: /bin and /sbin are now dynamically linked
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 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. 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. Regarding the performance loss due to the dynamic /bin and /sbin, wouldn't prebinding help? Guy Helmer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 experience? Regarding the performance loss due to the dynamic /bin and /sbin, wouldn't prebinding help? Probably. Profiling the dynamic-link code would probably also help. NetBSD made this change a long time ago, and Luke Mewburn observed that switching /bin to dynamic linking prompted a lot of people to study and optimize the dynamic linking code, with big wins for programs like Mozilla and OpenOffice that rely heavily on shared libraries. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 vt100 and cons25. The comconsole port installs an /etc/ttys entry using vt100. This is also the default terminal type for most dialup entries. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
--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 require /rescue/sh then you are pretty much by definition running in single user mode. Your console options at this point are local (cons25) or the serial port (most likely vt100 or xterm), so those three will cover 99% of the cases. Anyone with a Hazeltine 1500 or adm3a serial console will already know how to use ed(1). --lyndon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: HEADS UP: /bin and /sbin are now dynamically linked
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 suggest to /rescue based on that experience? Sure -- I could have used the ftp client (or fetch) in /rescue :-) (/me ducks) As it was, I downloaded /lib/libc.so.5 from the Nov 10 live filesys on another machine, copied it to a DOS floppy, mounted the floppy on the hosed machine using /rescue/mount_msdos, and used /rescue/cp to copy libc into place. Then I was able to config rebuild the kernel, reboot, and bring the machine back to life with the statfs changes. Regarding the performance loss due to the dynamic /bin and /sbin, wouldn't prebinding help? Probably. Profiling the dynamic-link code would probably also help. NetBSD made this change a long time ago, and Luke Mewburn observed that switching /bin to dynamic linking prompted a lot of people to study and optimize the dynamic linking code, with big wins for programs like Mozilla and OpenOffice that rely heavily on shared libraries. Hmm, sounds like a good challenge. Guy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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. Looks like it would only add about 65k (20k for fetch, another 45k for libfetch which isn't already in the crunched /rescue binary). Submit a PR on this Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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, which was a big driving factor for all-dynamic linking. I recall quite a bit of that discussion happening right here on [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. That's why I volunteered to build /rescue in the first place, so that I'd never be faced with an unrecoverable FreeBSD machine. 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 are a few things I'd like to see: * It would be nice if the kernel noticed that /sbin/init failed too quickly and prompted the user for an alternate init. That would open the door to a dynamic or just more ambitious /sbin/init, since you could always fall back to /rescue/init for recovery. * /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. If there are still rough edges on some of this well, that is what -CURRENT is all about, after all. ;-) Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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. Actually, the discussion started almost a year ago now. That's when the new PAM/NSS libraries were first being announced, which was a big driving factor for all-dynamic linking. I recall quite a bit of that discussion happening right here on [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. That's why I volunteered to build /rescue in the first place, so that I'd never be faced with an unrecoverable FreeBSD machine. Happened to me in the past too. 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 are a few things I'd like to see: * It would be nice if the kernel noticed that /sbin/init failed too quickly and prompted the user for an alternate init. That would open the door to a dynamic or just more ambitious /sbin/init, since you could always fall back to /rescue/init for recovery. * /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. Considering that rescue mode will most often be run from a console login or a serial console, I would thing the default console name termcap [cons25] and something ubuiquitous such as vt102 would do quite well - as you could cover almost all with just those two. That surely beats older systems where all I had in recovery attempts was echo to see what was there, and ed for editing. I like your idea. Bill -- Bill Vermillion - bv @ wjv . com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 of the question because it is too complex. init, sh, echo, cat, ed, sed, fsck (and 'once upon a time' fsdb) should do it. remove dynamic linking and you remove Yet Another Band-Aid. the kernel should be able to page stuff right which should eliminate the need for this folly. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 meant: - Current@ readers (that decide things), may have different skill levels preference of balance between risk function, compared with other user groups EG perhaps on hackers@ /or isp@ etc. - Some admins don't read @freebsd.org lists, to comment on the fully dynamic decision, but will later install default systems `out of the box', with later subsequent remote upgrades. - Any extra later danger / limitation to them could affect FreeBSD reputation. If you personally are worried about the new setup, then just use the switch which gives you the previous setup. Did it immediately, Thanks. Julian - Julian Stacey. Munich Unix Net Consultancy available. http://berklix.com Ihr Rauchen = mein allergischer Kopfschmerz ! Schnupftabak probieren. All HTML mail automaticaly deleted unread as Spam. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 are a few things I'd like to see: * It would be nice if the kernel noticed that /sbin/init failed too quickly and prompted the user for an alternate init. That would open the door to a dynamic or just more ambitious /sbin/init, since you could always fall back to /rescue/init for recovery. * /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. Just 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. That is cleaner than hard coding them into /rescue/vi. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 copied): Except we weren't talking about buildworld - sorry to hear you're having problems though. Perhaps this upgrade path needs to be tested to confirm your problem. Unless someone has hosed the change from src/Makefile.inc1,v 1.392, this should not be a problem. Oh, I now see there was a small 16-hour window where this was broken, before the initial commit to make the dynamic root default, and the follow-up Makefile.inc1,v 1.397 commit that took care of that. Anyway, this should not be a problem anymore, and it isn't even worth of an entry in src/UPDATING. ;) Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 needed to be statically linked though, were system utilities, which is why people probably started to associate the s with system, rather than static. Do you have any references for this? Every single place that I can find explains /sbin as system binaries. I have also never heard of there ever being duplicates in /bin of the files in /sbin. That's the way things work in Solaris. It's more a difference between System V and BSD, rather than one scheme evolving into another. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ ARDNAMURCHAN POINT TO CAPE WRATH INCLUDING THE OUTER HEBRIDES: WEST 5 OR 6 BACKING SOUTH 4 OR 5, VEERING SOUTHWEST LATER, AND INCREASING 6 LATER IN THE SOUTH. OCCASIONAL RAIN. MODERATE OR GOOD. MODERATE OR ROUGH, OCCASIONALLY SLIGHT IN SHELTERED EASTERN WATERS. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
* 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 things that needed to be statically linked though, were system utilities, which is why people probably started to associate the s with system, rather than static. When this happened, you started to see the duplicates that used to exist in /bin (or /usr/bin) and /sbin disappear. Since you still need a place to have statically linked recovery utilities, /rescue was created. Now you see the duplicates in /bin (or /usr/bin) and /rescue instead. Do you have any references for this? Every single place that I can find explains /sbin as system binaries. I have also never heard of there ever being duplicates in /bin of the files in /sbin. Also, wouldn't the names 'bin' and 'sbin' pre-date the existiance of dynamically linked binaries? AFAIK the primary difference between the two was the /bin was typically in a user's PATH and /sbin was not. --Mike pgp0.pgp Description: PGP signature
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 would be placed, in case the shared libraries got hosed. The only things that needed to be statically linked though, were system utilities, which is why people probably started to associate the s with system, rather than static. When this happened, you started to see the duplicates that used to exist in /bin (or /usr/bin) and /sbin disappear. Since you still need a place to have statically linked recovery utilities, /rescue was created. Now you see the duplicates in /bin (or /usr/bin) and /rescue instead. Do you have any references for this? Every single place that I can find explains /sbin as system binaries. I have also never heard of there ever being duplicates in /bin of the files in /sbin. Also, wouldn't the names 'bin' and 'sbin' pre-date the existiance of dynamically linked binaries? Yeah, that is what I thought too, but it does not seem to to be the case. As far as I can tell (after using Google for quite a bit) shared libraries were first introduced in Unix with SysVR3, with the model currently in use first appearing in SunOS 4 (I have no idea what they looked like in SysVR3.) /sbin seems to have first appeared in SysVR4, which postdates both of the above. /sbin seems to have been introduced to BSD sometime between 4.3BSD and 4.4BSD. (And SysVR4-derived systems seem to have /bin just as a symlink to /usr/bin, with /sbin containing only what is needed to boot the system far enough to mount /usr, with system binaries otherwise appearing in /usr/sbin and normal user binaries in /usr/bin. Solaris does appear to have dynamically linked duplicates in /usr/sbin of the statically linked programs appearing in /sbin.) AFAIK the primary difference between the two was the /bin was typically in a user's PATH and /sbin was not. This is apparently one of things that differ between SysV- and BSD- derived systems. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 has made the BSD so rugged and reliable for so many years. Seconded ! Better commit an improved switch with default = Off. 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 upgrades more problematic / dangerous. FreeBSD (non current) can be net upgraded to new releases without any /usr/src /usr/obj on either remote target or local (keyboard) system, using merely an ftp'd new binary tree + `mv'. Will a safe new `ftp + mv' procedure be documented ? - Julian Stacey Freelance Systems Engineer, Unix Net Consultant, Munich. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 upgrades more problematic / dangerous. FreeBSD (non current) can be net upgraded to new releases without any /usr/src /usr/obj on either remote target or local (keyboard) system, using merely an ftp'd new binary tree + `mv'. Will a safe new `ftp + mv' procedure be documented ? Is /rescue/mv adequate for this purpose? A slightly more fragile approach would be to make sure that /lib is unpacked before /bin and /sbin. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 linked, but what if I want /bin to be dynamic and /sbin static? Since sbin on System V predated shared libraries on System V, I think maybe this is a reverse assignment of a meaning to the 's'. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 being dynamically linked, but what if I want /bin to be dynamic and /sbin static? Since sbin on System V predated shared libraries on System V, I think maybe this is a reverse assignment of a meaning to the 's'. I was taught by an older fart than Terry that the 's' stands for (S)ingle-user, which is reflected even today in the 'boot -s' switch. Since the single-user is usually the Sysadmin, the association with 'system' is inevitable. The association with 'static' is also inevitable when I think of Sysadmins-I-Have-Known ;0) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 save those few MB of space. IOW don't change one of the things that has made the BSD so rugged and reliable for so many years. Seconded ! Better commit an improved switch with default = Off. This change has been announced and discussed for months - it's too bad you missed your chance to voice your opinion when it was time to do so. Kris pgp0.pgp Description: PGP signature
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 have no problem with /bin being dynamically linked, but what if I want /bin to be dynamic and /sbin static? Since sbin on System V predated shared libraries on System V, I think maybe this is a reverse assignment of a meaning to the 's'. I was taught by an older fart than Terry that the 's' stands for (S)ingle-user, which is reflected even today in the 'boot -s' switch. Since the single-user is usually the Sysadmin, the association with 'system' is inevitable. The association with 'static' is also inevitable when I think of Sysadmins-I-Have-Known ;0) 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. eg: ps, netstat, ls, id, etc are in */bin because they dont require privs and are generally useful. meanwhile, fsck, dhclient, fdisk, cron, rmuser, usbdevs etc do require priviliges or are not of general use. Why seperate them? Consider your shell and searching $PATH at execve time. It was more efficient to keep the amount of work that each step in processing $PATH to a minimum. Doubling the size of the directories means double the work searching directories looking for the foo binary. Remember that we dont have hashed directory lookups, its a linear search. For all your shell scripts etc, this search happens over and over and over again. So, having /bin:/usr/bin:/usr/local/bin as your $PATH as a normal user is a win. Of course, the nami cache which does negative caching does skew things a bit, but it still helps. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 in place long before shared libraries came along but not in its current form. You can only consider yourself a true UNIX dinosaur if at some point you changed your path to replace /usr/etc /etc with /usr/sbin /sbin. /etc was where they lived at first. -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 before we made this final switch. 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 ? Well, /usr/src developers do include people who are quite aware of the other parts of the system. There are very few developers who have worked more on /usr/ports than Kris Kennaway, for instance. All the objections being voiced now were brought up back in the original debate, and since that time the /usr/src developers have done their best to address all those issues. Also note that this debate was open to everyone tracking freebsd-current (the mailing list), not just /usr/src developers. I think it came up on freebsd-hackers or freebsd-arch, too. The discussion went on for multiple weeks, if not multiple months. It is not fair to pretend that this was some kind of back-room, closed-door decision. Not only that, but NetBSD has been living for awhile now with a similar change. Check the comments at http://www.bsdnewsletter.com/2002/08/News34.html for instance. That was more than a year ago, and they seemed to have survived the change. It will not be surprising if there are a few things we want to add to /rescue as we get more experience with this, but we do have good reason for making the change. If you personally are worried about the new setup, then just use the switch which gives you the previous setup. That's what the switch is for, after all. We did realize that some situations will have good reasons to use the previous setup. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 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 having problems though. Perhaps this upgrade path needs to be tested to confirm your problem. Unless someone has hosed the change from src/Makefile.inc1,v 1.392, this should not be a problem. Oh, I now see there was a small 16-hour window where this was broken, before the initial commit to make the dynamic root default, and the follow-up Makefile.inc1,v 1.397 commit that took care of that. Anyway, this should not be a problem anymore, and it isn't even worth of an entry in src/UPDATING. ;) Cheers, -- Ruslan ErmilovSysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: HEADS UP: /bin and /sbin are now dynamically linked
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. Yup, this distinction was in place long before shared libraries came along but not in its current form. You can only consider yourself a true UNIX dinosaur if at some point you changed your path to replace /usr/etc /etc with /usr/sbin /sbin. /etc was where they lived at first. *Everbody* knows that ifconfig belongs in /etc/ifconfig :-) On my SVR4 system (past life), /bin was a symlink to /usr/bin and /sbin was a symlink to /usr/sbin. /usr was on /. Things were simpler. I say we ditch this silly /usr thing and put it all in /bin + /lib and be done with it. :-) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 which I felt should have been static in the first place We've always been more frugal with library bumps and ABI changes than the other projects so I don't see any immediate danger of that happening. I certainly shared your concerns until I learned about /rescue; speaking as a long time abuser of Solaris and Linux who has experienced the problems you mention. But I don't feel the same possibility exists for catastrophic failure without recovery here. For just about everything, dynamic linking is a win. There are some scenarios where it isn't. I for one understand your concerns; if static linking is appropriate for your environment, then by all means, rebuild the components you need with static linking. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 have been hashed over lots of times. But the short of it: 1) Much smaller /bin and /sbin. On i386, /bin and /sbin are 33 MB static. Dynamically linked, they are only 4 MB. 2) Proper support for NSS. This will finally allow you to use NSS modules and get things like usernames in ls -l working for modules that are dynamically loaded. -gordon 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 linked, but what if I want /bin to be dynamic and /sbin static? Regards, Robert M. Zigweid PGP.sig Description: PGP signature
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 linked, but what if I want /bin to be dynamic and /sbin static? Regards, Robert M. Zigweid I'm not sure what that would accomplish. If a system was broken such that the dynamically linked binaries in /bin didn't work, the utilities in /sbin wouldn't be enough to fix the system. For instance, you wouldn't have a shell or ls. Statically linked binaries to fix a hosed system are now in /rescue. Check man hier. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 behavior? I have no problem with /bin being dynamically linked, but what if I want /bin to be dynamic and /sbin static? I'm not sure what that would accomplish. If a system was broken such that the dynamically linked binaries in /bin didn't work, the utilities in /sbin wouldn't be enough to fix the system. For instance, you wouldn't have a shell or ls. And these problems are best fixed through the new /rescue tree. I was pleasantly surprised to find that the net space consumed by 5.0-CURRENT in / for /stand, /sbin, and /bin was substantially larger in the statically linked world than the space required for / with /rescue, /sbin, and /bin in the dynamically linked world. I.e., I can now update boxes installed with smaller root file systems from earlier 4.x releases without running out of space, whereas before I would run out of space. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
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 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 have been hashed over lots of times. But the short of it: 1) Much smaller /bin and /sbin. On i386, /bin and /sbin are 33 MB static. Dynamically linked, they are only 4 MB. 2) Proper support for NSS. This will finally allow you to use NSS modules and get things like usernames in ls -l working for modules that are dynamically loaded. What was done to programs like /bin/sh, /sbin/init and /sbin/fsck to make them work without access to /usr/lib? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 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 have been hashed over lots of times. But the short of it: 1) Much smaller /bin and /sbin. On i386, /bin and /sbin are 33 MB static. Dynamically linked, they are only 4 MB. 2) Proper support for NSS. This will finally allow you to use NSS modules and get things like usernames in ls -l working for modules that are dynamically loaded. What was done to programs like /bin/sh, /sbin/init and /sbin/fsck to make them work without access to /usr/lib? /lib and /libexec. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 FreeBSD 5.0.1, dynamically linked (uses shared libs), stripped ldd sh sh: libedit.so.4 = /lib/libedit.so.4 (0x40348000) libncurses.so.5 = /lib/libncurses.so.5 (0x40462000) libc.so.5 = /lib/libc.so.5 (0x405c4000) Notice that sh is dynamicly linked to stuff in /lib. __ __ _ | \/ | __ _ ___| |_ __ _ | |\/| |/ _` / __| __/ _` | | | | | (_| \__ \ || (_| | |_| |_|\__,_|___/\__\__,_| unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep [EMAIL PROTECTED] http://wifibsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 behavior? I have no problem with /bin being dynamically linked, but what if I want /bin to be dynamic and /sbin static? Regards, Robert M. Zigweid I'm not sure what that would accomplish. If a system was broken such that the dynamically linked binaries in /bin didn't work, the utilities in /sbin wouldn't be enough to fix the system. For instance, you wouldn't have a shell or ls. 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 needed to be statically linked though, were system utilities, which is why people probably started to associate the s with system, rather than static. When this happened, you started to see the duplicates that used to exist in /bin (or /usr/bin) and /sbin disappear. Since you still need a place to have statically linked recovery utilities, /rescue was created. Now you see the duplicates in /bin (or /usr/bin) and /rescue instead. Brent ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 make.conf. Why are some programs in /usr/bin and /usr/sbin still linked statically? -- fuyuki ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 seems to imply that /sbin and /bin both have to have the same behavior? I have no problem with /bin being dynamically linked, but what if I want /bin to be dynamic and /sbin static? Regards, Robert M. Zigweid I'm not sure what that would accomplish. If a system was broken such that the dynamically linked binaries in /bin didn't work, the utilities in /sbin wouldn't be enough to fix the system. For instance, you wouldn't have a shell or ls. 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 needed to be statically linked though, were system utilities, which is why people probably started to associate the s with system, rather than static. When this happened, you started to see the duplicates that used to exist in /bin (or /usr/bin) and /sbin disappear. Since you still need a place to have statically linked recovery utilities, /rescue was created. Now you see the duplicates in /bin (or /usr/bin) and /rescue instead. Do you have any references for this? Every single place that I can find explains /sbin as system binaries. I have also never heard of there ever being duplicates in /bin of the files in /sbin. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
-- 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 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 have been hashed over lots of times. But the short of it: 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. On a non-FreeBSD system I had to recover, I had to physically take the server from the colo to a place where I could pull the drive to be able to run the recovery utitlities - as none of the dynamic binariies worked. 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. 2) Proper support for NSS. This will finally allow you to use NSS modules and get things like usernames in ls -l working for modules that are dynamically loaded. What was done to programs like /bin/sh, /sbin/init and /sbin/fsck to make them work without access to /usr/lib? And even if they are accessible IF the libraries become corrupted then nothing will work. That's certainly not a 'fail-safe' environment. 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 has made the BSD so rugged and reliable for so many years. 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 which I felt should have been static in the first place End of freebsd-current Digest, Vol 34, Issue 26 Bill -- Bill Vermillion - bv @ wjv . com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 sbin being able to stand alone no matter what is corrupted. You seem to be late comming to this discussion. #2 in the original email was also a huge reason for this change. On a non-FreeBSD system I had to recover, I had to physically take the server from the colo to a place where I could pull the drive to be able to run the recovery utitlities - as none of the dynamic binariies worked. /rescue What was done to programs like /bin/sh, /sbin/init and /sbin/fsck to make them work without access to /usr/lib? And even if they are accessible IF the libraries become corrupted then nothing will work. That's certainly not a 'fail-safe' environment. Again you are late coming to this discussion -- /resuce. For those who don't build the OS but install from binaries, this makes the system potentially less rugged. /rescue ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 you need to recover from a corrupted system, why is it so important to use /bin or /sbin, when /rescue is there for that exact purpose? I think it is much more important that nsswitch.conf work properly. But I think the time for these discussions is passed. I think at this stage the important thing is to make it work correctly. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 implemented before complaining. The ability to recover from broken dynamic linking has not been lost. Kris pgp0.pgp Description: PGP signature
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 interpreter /libexec/ld-elf.so.1 not found *** Signal 6 ... # echo /rescue/* echo: No match. ---8---8--- this is from a freshest-of-fresh-from-the-cd 5.1-RELEASE install (only zsh and cvsup added and network configured) to -CURRENT. this system is very much hosed from here on. i have tried sneaky ways of moving /usr/obj/usr/src/libexec/rtld-elf/ld-elf.so.1 to libexec, but none seem to succeed, even gzip -c ld-elf.so.1 | gzip -dc /libexec/ld-elf.so.1 LD_LIBRARY_PATH at this point has also lost its magic. /stand has no cp and no ln (or install, even). i will try again now with NO_DYNAMICROOT set in /etc/make.conf. -Anthony. On Sun, Nov 16, 2003 at 09:17:24PM -0800, Kris Kennaway wrote: 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 implemented before complaining. The ability to recover from broken dynamic linking has not been lost. Kris pgp0.pgp Description: PGP signature
Re: HEADS UP: /bin and /sbin are now dynamically linked
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 having problems though. Perhaps this upgrade path needs to be tested to confirm your problem. Kris pgp0.pgp Description: PGP signature
