Re: Useful tools missing from /rescue
On Thu, Nov 01, 2007 at 08:53:39AM -0700, David O'Brien wrote: On Thu, Oct 18, 2007 at 02:04:21AM +0400, Yar Tikhiy wrote: On Mon, Oct 15, 2007 at 10:38:26AM -0700, David O'Brien wrote: I guess I'm not creative enough in the ways I've screwed up my systems and needed tools from /rescue. 8-) Just try to installworld FreeBSD/amd64 over a running FreeBSD/i386. ;-) I strongly feel that shouldn't be supported on a live system. So to me We already got that possibility for free along with src/Makefile.inc1#1.590, so no particular efforts are needed to support it. it shouldn't be an excuse to put a duplicated copy of /usr/[s]bin into /rescue. It's an exaggeration. The most of /usr/[s]bin aren't in /rescue yet. :-) It is a delicate thing to get right - and there are easy ways to do it today: Boot from disc1; mount / and /usr; mv /mnt/etc /mnt/etc.hold; rm -rf the bits in bin,sbin,libexec; then run the install.sh from the disc1; mv /mnt/etc /mnt/etc.new ; mv /mnt/etc.hold /mnt/etc One of the things I love FreeBSD for is being able to do things in different ways and to choose such a way depending on the case. :-) E.g., one may want to go from CURRENT/arch1 to CURRENT/arch2 without having to install a binary release or snapshot for arch2 first. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Thu, Oct 18, 2007 at 02:04:21AM +0400, Yar Tikhiy wrote: On Mon, Oct 15, 2007 at 10:38:26AM -0700, David O'Brien wrote: I guess I'm not creative enough in the ways I've screwed up my systems and needed tools from /rescue. 8-) Just try to installworld FreeBSD/amd64 over a running FreeBSD/i386. ;-) I strongly feel that shouldn't be supported on a live system. So to me it shouldn't be an excuse to put a duplicated copy of /usr/[s]bin into /rescue. It is a delicate thing to get right - and there are easy ways to do it today: Boot from disc1; mount / and /usr; mv /mnt/etc /mnt/etc.hold; rm -rf the bits in bin,sbin,libexec; then run the install.sh from the disc1; mv /mnt/etc /mnt/etc.new ; mv /mnt/etc.hold /mnt/etc -- -- David ([EMAIL PROTECTED]) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Mon, Oct 15, 2007 at 10:38:26AM -0700, David O'Brien wrote: On Sat, Oct 13, 2007 at 10:01:39AM +0400, Yar Tikhiy wrote: On Wed, Oct 03, 2007 at 07:23:44PM -0700, David O'Brien wrote: I also don't see the need for pgrep - I think needing that says your system is running multiuser pretty well. First of all, I'd like to point out that /rescue doesn't need to be as minimal as /stand used to. Now, /rescue is a compact yet versatile set of essential tools that can help in any difficult situation when /*bin:/usr/*bin are unusable for some reason, not only in restoring a broken system while in single-user mode. A .. As for pgrep+pkill, it can come handy if one has screwed up his live system and wants to recover it without dropping the system to single-user. But if we take this just a little bit farther then why don't we go back to a static /[s]bin except for the few things one might need LDAP, etc.. for? That is, what's the purpose in continuing to duplicate /[s]bin into /rescue? /rescue should be just enough to reasonably get a system who's shared libs are messed up working again. Note that /rescue includes the most essential tools from /usr/[s]bin, too. Irrespective of its initial purpose, I regard /rescue as an emergency toolset left aside. In particular, it's good to know it's there when you experiment with a live remote system. A valid objection to this point is that pgrep's job can be done with a combination of ps(1) and sed(1), so it's just a matter of convenience. I guess I'm still having trouble understanding why one would need 'ps' to fix a shared libs issue. Now is a reason to keep adding stuff to IMHO it isn't only shared libs issues that /rescue can help with. /rescue. Also why one would be running 'ps -aux', which is the only way I can think of to get more than one screen of output if a system is in trouble. Imagine that you've rm'ed /usr by accident in a remote shell session. With enough tools in /rescue (which doesn't take lots of tools,) you can stop sensitive daemons, find the backup, restore from it, and get a functional system again without a reboot. No doubt, some tools just make the task easier by providing typical command-line idioms. I don't mean I'm so reckless that I need to restore my /usr often, but the 3-4 megabytes occupied by /rescue are a terribly low price today for being able to shoot different parts of one's foot without necessarily hitting the bone. The price for it in terms of disk space is next to nothing, and there are quite useless space hogs in /rescue already (see below on /rescue/vi.) Considering how few people are skilled in ed(1) these days, we have little choice but include vi. Of course, there should be /rescue/vi, and I have an idea on how to remove its dependence on /usr in a more or less elegant way. I mentioned the not-so-functional /rescue/vi here just to show that we can tolerate certain space waste in /rescue. I won't speak for everyone, but I really like to use fancy shell commands, particularly during hard times: loops, pipelines, etc. So I don't have to enter many commands for a single task or browse I guess I'm not creative enough in the ways I've screwed up my systems and needed tools from /rescue. 8-) Just try to installworld FreeBSD/amd64 over a running FreeBSD/i386. ;-) I don't see the purpose of chown - if you have to fall back to /rescue you're user 'root' - and you're trying to fix enough so you can use standard /*lib /*bin .. Having /rescue/chown is just a matter of completeness of the ch* subset of /rescue tools because chown's job can't be done by any other stock tools. If /rescue is complete enough, one can find more applications for it. E.g., the loader, a kernel, and /rescue /rescue wasn't intended to be well orthogonal. /rescue was part of he corner stone of the deal to switch to shared /[s]bin. But it doesn't confine us to the corner forever. Having an emergency toolset independent of the rest of the system is good in any case. I bet people will experiment and have fun with their systems more eagerly if they know they still can recover quickly with ready tools in case of a serious error. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Sat, Oct 13, 2007 at 10:01:39AM +0400, Yar Tikhiy wrote: On Wed, Oct 03, 2007 at 07:23:44PM -0700, David O'Brien wrote: I also don't see the need for pgrep - I think needing that says your system is running multiuser pretty well. First of all, I'd like to point out that /rescue doesn't need to be as minimal as /stand used to. Now, /rescue is a compact yet versatile set of essential tools that can help in any difficult situation when /*bin:/usr/*bin are unusable for some reason, not only in restoring a broken system while in single-user mode. A .. As for pgrep+pkill, it can come handy if one has screwed up his live system and wants to recover it without dropping the system to single-user. But if we take this just a little bit farther then why don't we go back to a static /[s]bin except for the few things one might need LDAP, etc.. for? That is, what's the purpose in continuing to duplicate /[s]bin into /rescue? /rescue should be just enough to reasonably get a system who's shared libs are messed up working again. /stand was a left-over from installation and not intended to be a sysadmins' savor - it just happened to be because we didn't clean up / after the bits were laid down. A valid objection to this point is that pgrep's job can be done with a combination of ps(1) and sed(1), so it's just a matter of convenience. I guess I'm still having trouble understanding why one would need 'ps' to fix a shared libs issue. Now is a reason to keep adding stuff to /rescue. Also why one would be running 'ps -aux', which is the only way I can think of to get more than one screen of output if a system is in trouble. The price for it in terms of disk space is next to nothing, and there are quite useless space hogs in /rescue already (see below on /rescue/vi.) Considering how few people are skilled in ed(1) these days, we have little choice but include vi. I won't speak for everyone, but I really like to use fancy shell commands, particularly during hard times: loops, pipelines, etc. So I don't have to enter many commands for a single task or browse I guess I'm not creative enough in the ways I've screwed up my systems and needed tools from /rescue. 8-) I don't see the purpose of chown - if you have to fall back to /rescue you're user 'root' - and you're trying to fix enough so you can use standard /*lib /*bin .. Having /rescue/chown is just a matter of completeness of the ch* subset of /rescue tools because chown's job can't be done by any other stock tools. If /rescue is complete enough, one can find more applications for it. E.g., the loader, a kernel, and /rescue /rescue wasn't intended to be well orthogonal. /rescue was part of he corner stone of the deal to switch to shared /[s]bin. -- -- David ([EMAIL PROTECTED]) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Wed, Oct 03, 2007 at 07:23:44PM -0700, David O'Brien wrote: Yar Tikhiy wrote: I've had to use /rescue recently and felt lack of a few basic tools in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter, e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1), tail(1), and even tee(1) can be emulated if one has sed(1), but the tools are so tiny and convenient that it's a pity not to have them all handy during hard times. I also don't see the need for pgrep - I think needing that says your system is running multiuser pretty well. First of all, I'd like to point out that /rescue doesn't need to be as minimal as /stand used to. Now, /rescue is a compact yet versatile set of essential tools that can help in any difficult situation when /*bin:/usr/*bin are unusable for some reason, not only in restoring a broken system while in single-user mode. A skillful admin needs a rather limited number of tools, but some of them still are missing from /rescue. As for pgrep+pkill, it can come handy if one has screwed up his live system and wants to recover it without dropping the system to single-user. A valid objection to this point is that pgrep's job can be done with a combination of ps(1) and sed(1), so it's just a matter of convenience. The price for it in terms of disk space is next to nothing, and there are quite useless space hogs in /rescue already (see below on /rescue/vi.) Also head and tail - why not just add 'more' as that would give more functionality if you're trying to read a file in /etc to fix something. I won't speak for everyone, but I really like to use fancy shell commands, particularly during hard times: loops, pipelines, etc. So I don't have to enter many commands for a single task or browse through voluminous output for relevant parts. And it's hard to use pipelines w/o basic filters. Again, head(1) and tail(1) can be substituted by sed(1), but my fingers are just used to type head or tail in certain cases. I suspect that I'm not the only one of this kind out there. As for more(1), there is a reason not to include it in /rescue now, besides its rather large size. Namely it uses ncurses and thus depends on /etc/termcap to work well; but in a really tough case when you can mount only /, /etc/termcap is unavailable because it's a symlink to under /usr. This problem plagues /rescue/vi already (see PR bin/80256.) I think we should postpone adding more(1) to /rescue to after the problem has been fixed. And, of course, more(1) is no substitute for head(1) or tail(1) when it comes to pipelines. In addition, there are chflags and chmod in /rescue, but there's no chown in it, so the toolset is a bit incomplete. I don't see the purpose of chown - if you have to fall back to /rescue you're user 'root' - and you're trying to fix enough so you can use standard /*lib /*bin chflags is needed so you can overwrite a file and chmod is needed so you can chmod +x something - those needs are clear. Please don't pestimize the build - unless there is a clear benefit. Having /rescue/chown is just a matter of completeness of the ch* subset of /rescue tools because chown's job can't be done by any other stock tools. If /rescue is complete enough, one can find more applications for it. E.g., the loader, a kernel, and /rescue are enough to run single-user and do basic things. (Note that there is /rescue/init.) Of course, what I've just told is my own view of /rescue's role, but it seems to be supported by some other folks. Thank you for your comments! I think this discussion can let us understand better what we need from /rescue. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
Yar Tikhiy wrote: I've had to use /rescue recently and felt lack of a few basic tools in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter, e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1), tail(1), and even tee(1) can be emulated if one has sed(1), but the tools are so tiny and convenient that it's a pity not to have them all handy during hard times. I also don't see the need for pgrep - I think needing that says your system is running multiuser pretty well. Also head and tail - why not just add 'more' as that would give more functionality if you're trying to read a file in /etc to fix something. In addition, there are chflags and chmod in /rescue, but there's no chown in it, so the toolset is a bit incomplete. I don't see the purpose of chown - if you have to fall back to /rescue you're user 'root' - and you're trying to fix enough so you can use standard /*lib /*bin chflags is needed so you can overwrite a file and chmod is needed so you can chmod +x something - those needs are clear. Please don't pestimize the build - unless there is a clear benefit. -- -- David ([EMAIL PROTECTED]) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play Jeopardy-style quoting ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Monday 03 September 2007 08:03:53 am Yar Tikhiy wrote: On Sun, Sep 02, 2007 at 11:18:04AM -0700, Tim Kientzle wrote: Yar Tikhiy wrote: Hi all, I've had to use /rescue recently and felt lack of a few basic tools in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter, e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1), tail(1), and even tee(1) can be emulated if one has sed(1), but the tools are so tiny and convenient that it's a pity not to have them all handy during hard times. In addition, there are chflags and chmod in /rescue, but there's no chown in it, so the toolset is a bit incomplete. Oh, my. chown was definitely an oversight. That should have been in there. My opinions: * head, tail, and tee are no-brainers; just do it. * sed would be a nice addition. (I atttempted to fit 'vi' in there, but curses is rather finicky; 'sed' would be more useful.) Thank you for supporting my idea! I would go for all of these as well as 'chown'. Are you still planning on doing this? -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Sun, Sep 02, 2007 at 09:00:04PM +0200, Simon 'corecode' Schubert wrote: Tim Kientzle wrote: I atttempted to fit 'vi' in there, but curses is rather finicky; 'sed' would be more useful. Mined is a nice editor for this, running without curses. A statically linked, stripped binary is about 100k in size, so if crunched it would have a very small impact. It even used to be in our src tree under release/picobsd. However, if we revive it, we'll have to support as many as 4 text editors in the base system, which can be a bit too many. The main problem with /rescue/vi is its being totally useless without the termcap file from /usr, as discussed under PR bin/80256. The solutions suggested there are more or less based on introducing additional trimmed down termcap files in the src tree, which is no better than having 4 editors to support. I'd rather write a small script to extract a subset of terminal types from the main termcap file, and install it as /rescue/termcap. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Sun, Sep 02, 2007 at 11:18:04AM -0700, Tim Kientzle wrote: Yar Tikhiy wrote: Hi all, I've had to use /rescue recently and felt lack of a few basic tools in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter, e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1), tail(1), and even tee(1) can be emulated if one has sed(1), but the tools are so tiny and convenient that it's a pity not to have them all handy during hard times. In addition, there are chflags and chmod in /rescue, but there's no chown in it, so the toolset is a bit incomplete. Oh, my. chown was definitely an oversight. That should have been in there. My opinions: * head, tail, and tee are no-brainers; just do it. * sed would be a nice addition. (I atttempted to fit 'vi' in there, but curses is rather finicky; 'sed' would be more useful.) Thank you for supporting my idea! * I personally would not add pgrep/pkill because I never use them. They can be handy if you find yourself with a botched system still in multi-user mode and want to fix the things w/o dropping to single-user mode. Now there are ps(1) and kill(1) in rescue, which together with sed(1) can do the same job, but pgrep/pkill is much more convenient. Another option can be killall(1), but pkill(1) has almost superseded it because it is more widely adopted and has richer features without code bloat. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Mon, 3 Sep 2007, Yar Tikhiy wrote: On Sun, Sep 02, 2007 at 11:18:04AM -0700, Tim Kientzle wrote: Yar Tikhiy wrote: Hi all, I've had to use /rescue recently and felt lack of a few basic tools in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter, e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1), tail(1), and even tee(1) can be emulated if one has sed(1), but the tools are so tiny and convenient that it's a pity not to have them all handy during hard times. In addition, there are chflags and chmod in /rescue, but there's no chown in it, so the toolset is a bit incomplete. Oh, my. chown was definitely an oversight. That should have been in there. My opinions: * head, tail, and tee are no-brainers; just do it. * sed would be a nice addition. (I atttempted to fit 'vi' in there, but curses is rather finicky; 'sed' would be more useful.) Thank you for supporting my idea! I'm surprised no one has mentioned ftp or fetch. I don't know how large they would be if static, but if you have to grab some files over the network, it can be quite convenient. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Mon, Sep 03, 2007 at 08:36:58AM -0400, Daniel Eischen wrote: On Mon, 3 Sep 2007, Yar Tikhiy wrote: On Sun, Sep 02, 2007 at 11:18:04AM -0700, Tim Kientzle wrote: Yar Tikhiy wrote: Hi all, I've had to use /rescue recently and felt lack of a few basic tools in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter, e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1), tail(1), and even tee(1) can be emulated if one has sed(1), but the tools are so tiny and convenient that it's a pity not to have them all handy during hard times. In addition, there are chflags and chmod in /rescue, but there's no chown in it, so the toolset is a bit incomplete. Oh, my. chown was definitely an oversight. That should have been in there. My opinions: * head, tail, and tee are no-brainers; just do it. * sed would be a nice addition. (I atttempted to fit 'vi' in there, but curses is rather finicky; 'sed' would be more useful.) Thank you for supporting my idea! I'm surprised no one has mentioned ftp or fetch. I don't know how large they would be if static, but if you have to grab some files over the network, it can be quite convenient. It's just a matter of Someone(tm) building the new rescue with ftp or fetch, testing it, and reporting the size change. ;-) With network setup tools already in /rescue, it sounds as a good idea to consider, at least. The needed code pieces aren't giant: -r-xr-xr-x 1 root wheel 18956 26 авг 03:31 /usr/bin/fetch -r--r--r-- 1 root wheel 54750 26 авг 03:27 /usr/lib/libfetch.a But the crypto bits may need to be disabled: # ldd /usr/bin/fetch /usr/bin/fetch: libfetch.so.5 = /usr/lib/libfetch.so.5 (0x2808) libssl.so.5 = /usr/lib/libssl.so.5 (0x2808d000) libcrypto.so.5 = /lib/libcrypto.so.5 (0x280ce000) libc.so.7 = /lib/libc.so.7 (0x28225000) Another option is tftp(1). :-) -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Mon, Sep 03, 2007 at 03:18:03AM +0300, Giorgos Keramidas wrote:
On 2007-09-02 11:18, Tim Kientzle [EMAIL PROTECTED] wrote:
Yar Tikhiy wrote:
In addition, there are chflags and chmod in /rescue, but there's no
chown in it, so the toolset is a bit incomplete.
Oh, my. chown was definitely an oversight. That
should have been in there.
Probably because chown is a relatively big binary. If build as a static
binary here, it ends up being:
$ pwd
/home/keramida/bsd/src/usr.sbin/chown
$ make DEBUG_FLAGS='' NO_SHARED=yes all
[...]
$ ls -ld chown
-rwxrwxr-x1 keramida users - 2297013 Sep 3 03:06 chown
$ strip -s chown
$ ls -ld chown
-rwxrwxr-x1 keramida users - 550624 Sep 3 03:06 chown
$
This will get smaller when crunched, but it's still almost 4x the size
of chmod:
$ pwd
/home/keramida/bsd/src/bin/chmod
$ make DEBUG_FLAGS='' NO_SHARED=yes all
[...]
$ ls -ld chmod
-rwxrwxr-x 1 keramida users - 662678 Sep 3 03:08 chmod
$ strip -s chmod
$ ls -ld chmod
-rwxrwxr-x 1 keramida users - 165884 Sep 3 03:08 chmod
$
Running nm(1) on the binaries, I see that they have the same symbols
though:
$ nm -S chmod | awk '{print $2,$3,$4}' | sort /tmp/symbols.chmod
$ nm -S chown | awk '{print $2,$3,$4}' | sort /tmp/symbols.chown
$ diff -u /tmp/symbols.chmod /tmp/symbols.chown
$
Does this mean that adding chown to the already crunched binary will not
cause a lot of bloat because of symbols/functions private to chown?
The difference in the static binary sizes is weird, but I don't
have time now to dig the issue deeper, sorry. The rescue binary
grows just slightly when chown is added to it:
-r-xr-xr-x 121 root wheel 3715096 1 сен 10:22 /rescue.old/rescue
-r-xr-xr-x 122 root wheel 3718192 3 сен 17:17 /rescue/rescue
--
Yar
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On 2007-09-03 17:20, Yar Tikhiy [EMAIL PROTECTED] wrote:
On Mon, Sep 03, 2007 at 03:18:03AM +0300, Giorgos Keramidas wrote:
Running nm(1) on the binaries, I see that they have the same symbols
though:
$ nm -S chmod | awk '{print $2,$3,$4}' | sort /tmp/symbols.chmod
$ nm -S chown | awk '{print $2,$3,$4}' | sort /tmp/symbols.chown
$ diff -u /tmp/symbols.chmod /tmp/symbols.chown
$
Does this mean that adding chown to the already crunched binary will not
cause a lot of bloat because of symbols/functions private to chown?
The difference in the static binary sizes is weird, but I don't
have time now to dig the issue deeper, sorry. The rescue binary
grows just slightly when chown is added to it:
-r-xr-xr-x 121 root wheel 3715096 1 ??? 10:22 /rescue.old/rescue
-r-xr-xr-x 122 root wheel 3718192 3 ??? 17:17 /rescue/rescue
It's probably a side-effect of the fact my userland was built with
DEBUG_FLAGS='-g' and this was compiled without a full buildworld.
Thus the binaries I compiled used debugging versions of the libs
from /usr/lib but their own source was built with DEBUG_FLAGS=''.
Nevermind about the binary difference in sizes; it's probably a local
build-related issue. It's good to know that rescue doesn't grow a
lot anyway :)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Sat, 1 Sep 2007, Julian Stacey wrote:
JS I've had to use /rescue recently and felt lack of a few basic tools
JS in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter,
JS e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1),
JS tail(1), and even tee(1) can be emulated if one has sed(1), but the
JS tools are so tiny and convenient that it's a pity not to have them
JS all handy during hard times.
JS
JS In addition, there are chflags and chmod in /rescue, but there's
JS no chown in it, so the toolset is a bit incomplete.
JS
JS Would anyone mind if I add those tools to /rescue? The size growth
JS will be rather small:
JS
JS -r-xr-xr-x 121 root wheel 3715096 1 сен 10:22 /mnt2/rescue.old/rescue
JS -r-xr-xr-x 129 root wheel 3761828 1 сен 11:22 /mnt2/rescue/rescue
JS
JS Don't do it without approval of re@ (who might be too busy just now
JS anyway) It might blow the limit on the tight packed rescue floppy.
JS ( though desk workstations have CDs, lost of small boxes still
JS just have floppies for rescue) Best try to build a rescue floppy
JS yourself before adding bloat.
JS
JS BTW I've never used pgrep thus superfluous to rescue. Others also
JS not really needed, merely nice. True rescue is just to fix FS at
JS which point you can mount other FS or CDROM or NFS etc for more
JS tools.
What about adding support for zfs then (see below)? I found it especially
useful when you have zfs-on-root and copy /rescue to /bootdisk and symlink bin
and sbin to rescue - this allows emergency management of zfs when booting with
/bootdisk as root.
Trick with -lm seems to be needed because libzfs itself refers to pow(3) - or
did I miss something trivial to resolve this?
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: [EMAIL PROTECTED] ]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
Index: Makefile
===
RCS file: /home/ncvs/src/rescue/rescue/Makefile,v
retrieving revision 1.56
diff -u -r1.56 Makefile
--- Makefile14 Jul 2007 21:49:22 - 1.56
+++ Makefile31 Aug 2007 11:24:34 -
@@ -71,7 +71,7 @@
CRUNCH_PROGS_bin= cat chflags chio chmod cp date dd df echo\
ed expr getfacl hostname kenv kill ln ls mkdir mv pax ps pwd \
realpath rm rmdir setfacl sh stty sync test
-CRUNCH_LIBS+= -lcrypt -ledit -lkvm -ll -lm -ltermcap -lutil
+CRUNCH_LIBS+= -lcrypt -ledit -lkvm -ll -ltermcap -lutil
.if ${MK_OPENSSL} != no
CRUNCH_LIBS+= -lcrypto
.endif
@@ -185,5 +185,17 @@
CRUNCH_PROGS_sbin+= dhclient
CRUNCH_BUILDOPTS_dhclient= -DRELEASE_CRUNCH -Dlint
+# zfs-related: zpool and zfs
+.if ${MK_CDDL} != no ${MK_ZFS} != no
+CRUNCH_PROGS_sbin+= zfs zpool
+CRUNCH_SRCDIR_zfs= $(.CURDIR)/../../cddl/sbin/zfs
+CRUNCH_SRCDIR_zpool= $(.CURDIR)/../../cddl/sbin/zpool
+CRUNCH_LIBS+= -lzfs -lavl -lnvpair -luutil
+.endif
+
+# XXX libzfs needs pow()
+CRUNCH_LIBS+= -lm
+
##
# Programs from stock /usr/bin
#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
Giorgos Keramidas wrote: ... [chown] is still almost 4x the size of chmod: $ ls -ld chown -rwxrwxr-x1 keramida users - 550624 Sep 3 03:06 chown $ ls -ld chmod -rwxrwxr-x 1 keramida users - 165884 Sep 3 03:08 chmod getpwuid() pulls in DNS, NIS, and a bunch of other network routines, which are quite large. chmod doesn't need to look up user or group names. Tim Kientzle P.S. Interesting experiment: for every function in libc, create a statically linked and stripped binary that references that one function and look at the sizes. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
Yar Tikhiy wrote: Hi all, I've had to use /rescue recently and felt lack of a few basic tools in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter, e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1), tail(1), and even tee(1) can be emulated if one has sed(1), but the tools are so tiny and convenient that it's a pity not to have them all handy during hard times. In addition, there are chflags and chmod in /rescue, but there's no chown in it, so the toolset is a bit incomplete. Oh, my. chown was definitely an oversight. That should have been in there. My opinions: * head, tail, and tee are no-brainers; just do it. * sed would be a nice addition. (I atttempted to fit 'vi' in there, but curses is rather finicky; 'sed' would be more useful.) * I personally would not add pgrep/pkill because I never use them. Of course, it's hard to get worked up about 45k, so feel free to ignore the above. Cheers, Tim Kientzle ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
Tim Kientzle wrote: I atttempted to fit 'vi' in there, but curses is rather finicky; 'sed' would be more useful. Mined is a nice editor for this, running without curses. A statically linked, stripped binary is about 100k in size, so if crunched it would have a very small impact. cheers simon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On 2007-09-02 11:18, Tim Kientzle [EMAIL PROTECTED] wrote:
Yar Tikhiy wrote:
In addition, there are chflags and chmod in /rescue, but there's no
chown in it, so the toolset is a bit incomplete.
Oh, my. chown was definitely an oversight. That
should have been in there.
Probably because chown is a relatively big binary. If build as a static
binary here, it ends up being:
$ pwd
/home/keramida/bsd/src/usr.sbin/chown
$ make DEBUG_FLAGS='' NO_SHARED=yes all
[...]
$ ls -ld chown
-rwxrwxr-x1 keramida users - 2297013 Sep 3 03:06 chown
$ strip -s chown
$ ls -ld chown
-rwxrwxr-x1 keramida users - 550624 Sep 3 03:06 chown
$
This will get smaller when crunched, but it's still almost 4x the size
of chmod:
$ pwd
/home/keramida/bsd/src/bin/chmod
$ make DEBUG_FLAGS='' NO_SHARED=yes all
[...]
$ ls -ld chmod
-rwxrwxr-x 1 keramida users - 662678 Sep 3 03:08 chmod
$ strip -s chmod
$ ls -ld chmod
-rwxrwxr-x 1 keramida users - 165884 Sep 3 03:08 chmod
$
Running nm(1) on the binaries, I see that they have the same symbols
though:
$ nm -S chmod | awk '{print $2,$3,$4}' | sort /tmp/symbols.chmod
$ nm -S chown | awk '{print $2,$3,$4}' | sort /tmp/symbols.chown
$ diff -u /tmp/symbols.chmod /tmp/symbols.chown
$
Does this mean that adding chown to the already crunched binary will not
cause a lot of bloat because of symbols/functions private to chown?
- Giorgos
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
Reference:
From: Yar Tikhiy [EMAIL PROTECTED]
Date: Sat, 1 Sep 2007 11:34:40 +0400
Message-id: [EMAIL PROTECTED]
Yar Tikhiy wrote:
Hi all,
I've had to use /rescue recently and felt lack of a few basic tools
in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter,
e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1),
tail(1), and even tee(1) can be emulated if one has sed(1), but the
tools are so tiny and convenient that it's a pity not to have them
all handy during hard times.
In addition, there are chflags and chmod in /rescue, but there's
no chown in it, so the toolset is a bit incomplete.
Would anyone mind if I add those tools to /rescue? The size growth
will be rather small:
-r-xr-xr-x 121 root wheel 3715096 1 ÓÅÎ 10:22 /mnt2/rescue.old/rescue
-r-xr-xr-x 129 root wheel 3761828 1 ÓÅÎ 11:22 /mnt2/rescue/rescue
Don't do it without approval of re@ (who might be too busy just now
anyway) It might blow the limit on the tight packed rescue floppy.
( though desk workstations have CDs, lost of small boxes still
just have floppies for rescue) Best try to build a rescue floppy
yourself before adding bloat.
BTW I've never used pgrep thus superfluous to rescue. Others also
not really needed, merely nice. True rescue is just to fix FS at
which point you can mount other FS or CDROM or NFS etc for more
tools.
Before anyone else might discuss which tools might be nice, I'd
suggest build yourself a FIXIT floppy, see what space is left,
what you'd have to chuck out to make space for what you want to
add.
The patch is attached.
Thanks!
--
Yar
--- //depot/vendor/freebsd/src/rescue/rescue/Makefile 2007/07/14 22:47:42
+++ //depot/user/yar/hack/rescue/rescue/Makefile 2007/09/01 07:28:25
@@ -85,6 +85,10 @@
CRUNCH_ALIAS_rm= unlink
CRUNCH_ALIAS_ed= red
+CRUNCH_PROGS_bin+= pkill
+CRUNCH_SRCDIR_pkill= ${.CURDIR}/../../usr.bin/pkill
+CRUNCH_ALIAS_pkill= pgrep
+
.if ${MK_RCMDS} != no
CRUNCH_PROGS_bin+= rcp
.endif
@@ -190,6 +194,8 @@
#
CRUNCH_SRCDIRS+= usr.bin
+CRUNCH_PROGS_usr.bin= head sed tail tee
+
CRUNCH_PROGS_usr.bin+= gzip
CRUNCH_ALIAS_gzip= gunzip gzcat zcat
@@ -211,7 +217,10 @@
#
CRUNCH_SRCDIRS+= usr.sbin
-CRUNCH_PROGS_usr.sbin+= chroot
+CRUNCH_PROGS_usr.sbin= chroot
+
+CRUNCH_PROGS_usr.sbin+= chown
+CRUNCH_ALIAS_chown= chgrp
##
# The following is pretty nearly a generic crunchgen-handling makefile
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com
Ihr Rauch=mein allergischer Kopfschmerz. Dump cigs 4 snuff.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Sat, Sep 01, 2007 at 02:40:29PM +0200, Julian Stacey wrote:
Reference:
From: Yar Tikhiy [EMAIL PROTECTED]
Date: Sat, 1 Sep 2007 11:34:40 +0400
Message-id: [EMAIL PROTECTED]
Yar Tikhiy wrote:
Hi all,
I've had to use /rescue recently and felt lack of a few basic tools
in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter,
e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1),
tail(1), and even tee(1) can be emulated if one has sed(1), but the
tools are so tiny and convenient that it's a pity not to have them
all handy during hard times.
In addition, there are chflags and chmod in /rescue, but there's
no chown in it, so the toolset is a bit incomplete.
Would anyone mind if I add those tools to /rescue? The size growth
will be rather small:
-r-xr-xr-x 121 root wheel 3715096 1 сен 10:22 /mnt2/rescue.old/rescue
-r-xr-xr-x 129 root wheel 3761828 1 сен 11:22 /mnt2/rescue/rescue
Don't do it without approval of re@ (who might be too busy just now
Thanks for the reminder. ;-)
anyway) It might blow the limit on the tight packed rescue floppy.
( though desk workstations have CDs, lost of small boxes still
just have floppies for rescue) Best try to build a rescue floppy
yourself before adding bloat.
If you meant the fixit floppy, it is built separately. The rescue(8)
binary is already bigger than a floppy and it isn't supposed to fit
on that media.
BTW I've never used pgrep thus superfluous to rescue. Others also
not really needed, merely nice. True rescue is just to fix FS at
which point you can mount other FS or CDROM or NFS etc for more
tools.
Unlike a fixit floppy, rescue(8) was introduced mostly to help when
shared libraries were damaged badly. In that case, to prevent
system malfunction, you may want to kill daemons starting other
binaries, e.g., cron(8) and sendmail(8), if you don't want to, or
just cannot, drop into single-user mode immediately. Of course,
rescue(8) is also of use in other recovery tasks if one is lucky
enough to be able to mount / and too lazy to reach for a fixit CD.
Before anyone else might discuss which tools might be nice, I'd
suggest build yourself a FIXIT floppy, see what space is left,
what you'd have to chuck out to make space for what you want to
add.
Again, fixit is built using a different configuration file, please
see src/release/${TARGET_ARCH}/fixit_crunch.conf.
--
Yar
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
