rtld breakage still in -stable, or is it me?
Hi A few days ago I upgraded by system to -stable from 3.2-RELEASE and several programs which use dlopen stopped working, most notably mod_perl. For example: # apachectl start [Wed Mar 8 10:19:35 2000] [error] Can't load '/usr/local/lib/perl5/site_perl/5.005/i386-freebsd/auto/Time/HiRes/HiRes.so' for module Time::HiRes: /usr/local/lib/perl5/site_perl/5.005/i386-freebsd/auto/Time/HiRes/HiRes.so: Undefined symbol "PL_stack_max" at /usr/libdata/perl/5.00503/DynaLoader.pm line 169. at /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Interp.pm line 25 BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/5.005/HTML/Mason.pm line 9. BEGIN failed--compilation aborted at /usr/local/web/mason/handler.pl line 3. Syntax error on line 1204 of /usr/local/apache-1.3/conf/httpd.conf: Can't load '/usr/local/lib/perl5/site_perl/5.005/i386-freebsd/auto/Time/HiRes/HiRes.so' for module Time::HiRes: /usr/local/lib/perl5/site_perl/5.005/i386-freebsd/auto/Time/HiRes/HiRes.so: Undefined symbol "PL_stack_max" at /usr/libdata/perl/5.00503/DynaLoader.pm line 169. at /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Interp.pm line 25 BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/5.005/HTML/Mason.pm line 9. BEGIN failed--compilation aborted at /usr/local/web/mason/handler.pl line 3. /usr/local/apache-1.3/bin/apachectl start: httpd could not be started Furthermore: niall% nm /usr/lib/libperl.so | grep PL_stack_max 00090630 B PL_stack_max The Time::HiRes module loads fine when I invoke perl from the command line. It appears I amn't the only one having this problem: http://x42.deja.com/getdoc.xp?AN=582680524 http://x30.deja.com/getdoc.xp?AN=591070824 http://x31.deja.com/getdoc.xp?AN=573655265 http://x31.deja.com/getdoc.xp?AN=565253105 A recompile of apache etc did not solve the problem, neither did a make world yesterday Any hints? Regards, Niall -- Niall Smart email: [EMAIL PROTECTED] phone: (087) 8052390 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Various Questions
-- snip --
if (pswitch) {
/*
* If the device is not configured up, we cannot put it
in
* promiscuous mode.
*/
if ((ifp-if_flags IFF_UP) == 0)
return (ENETDOWN);
if (ifp-if_pcount++ != 0)
return (0);
ifp-if_flags |= IFF_PROMISC;
log(LOG_INFO, "%s%d: promiscuous mode enabled\n",
ifp-if_name, ifp-if_unit);
} else {
if (--ifp-if_pcount 0)
return (0);
ifp-if_flags = ~IFF_PROMISC;
---log(LOG_INFO, "%s%d: promiscuous mode disabled\n",
---ifp-if_name, ifp-if_unit);
Shouldn't this be:
if (ipf-if_flags IFF_PROMISC) {
ipf-if_flags = ~IFF_PROMISC;
log(LOG_INFO, "%s%d: promiscuous mode disabled\n", ifp-if_name,
ifp-if_unit);
}
Or is the test for IFF_PROMISC made earlier in the code? You
should only print a disabled message when it has previously
been enabled so that log file watchers can always match up
the up/down pairs.
Regards,
Niall
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Various Questions
Sheldon Hearn wrote: On Thu, 12 Aug 1999 11:29:47 GMT, Niall Smart wrote: Or is the test for IFF_PROMISC made earlier in the code? You should only print a disabled message when it has previously been enabled so that log file watchers can always match up the up/down pairs. I've been using if.c modified exactly as suggested for a few months now and have experienced the intended results without apparent problems. But what happens if you write a program which does whatever ioctl is required to unpromiscify an interface and run it on an unpromiscuous interface, does it print a message to syslog even though promiscuous mode was never enabled in the first place? Time to start reading some code methinks Niall + To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Various Questions
-- snip --
if (pswitch) {
/*
* If the device is not configured up, we cannot put it
in
* promiscuous mode.
*/
if ((ifp-if_flags IFF_UP) == 0)
return (ENETDOWN);
if (ifp-if_pcount++ != 0)
return (0);
ifp-if_flags |= IFF_PROMISC;
log(LOG_INFO, %s%d: promiscuous mode enabled\n,
ifp-if_name, ifp-if_unit);
} else {
if (--ifp-if_pcount 0)
return (0);
ifp-if_flags = ~IFF_PROMISC;
---log(LOG_INFO, %s%d: promiscuous mode disabled\n,
---ifp-if_name, ifp-if_unit);
Shouldn't this be:
if (ipf-if_flags IFF_PROMISC) {
ipf-if_flags = ~IFF_PROMISC;
log(LOG_INFO, %s%d: promiscuous mode disabled\n, ifp-if_name,
ifp-if_unit);
}
Or is the test for IFF_PROMISC made earlier in the code? You
should only print a disabled message when it has previously
been enabled so that log file watchers can always match up
the up/down pairs.
Regards,
Niall
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Various Questions
Sheldon Hearn wrote: On Thu, 12 Aug 1999 11:29:47 GMT, Niall Smart wrote: Or is the test for IFF_PROMISC made earlier in the code? You should only print a disabled message when it has previously been enabled so that log file watchers can always match up the up/down pairs. I've been using if.c modified exactly as suggested for a few months now and have experienced the intended results without apparent problems. But what happens if you write a program which does whatever ioctl is required to unpromiscify an interface and run it on an unpromiscuous interface, does it print a message to syslog even though promiscuous mode was never enabled in the first place? Time to start reading some code methinks Niall + To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
[Fwd: Please support FreeBSD 3.x as host OS]
Olivia Cheriton wrote: Niall, VMware will support FreeBSD as a guest operating system, but unfortunately we currently do not have plans to support FreeBSD as a host operating system. I have noted your request of FreeBSD host support in case we review this in the future. Best regards, Olivia Cheriton VMware, Inc. - Original Message - From: Niall Smart ni...@pobox.com To: feature-requ...@vmware.com Cc: sa...@vmware.com Sent: Saturday, July 24, 1999 11:09 AM Subject: Please support FreeBSD 3.x as host OS Hi. I'd like to see FreeBSD 3.x supported as a host OS, I'll certainly be buying a copy of VMware if this happens. Regards, Niall Smart Senior Software Developer Trinity Commerce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD
[ CC list nuked ] Ok, here goes my understanding of how things should be, please correct me if i'm wrong. There are three parts to the problem: 1. Where do we get the databases from? I mean, where do we get passwd, group, hosts, ethers, etc from. This should be handled by a name service switch a la solaris. Basically we want to be able to tell the system for each individual database where to get the stuff from. We can add entries for each database in the system. Not so much as "where do we get the databases from" as "which databases hold data for this particular service". For example DNS can store information for the hosts service (i.e. nameserver service) but could also store crytographic keys which could be used for as host keys for ssh for example. The service has a standard API (gethostbyname() for example, or getpwnam()) which can search through multiple disparate database types. (I may be mixing my terminology up here, it may be more conventional to say "which services support this database", where the database might be a load of struct pw for example, but hopefully its clear I mean) Each particular database type might have its own configuration file. Taking the "hosts" service for example, the configuration file for the DNS database is /etc/resolv.conf and there is no configuration for the files database (which uses /etc/hosts) 2. How to authorize the user? I mean, what sort of authentication should we use to decide if the user should be allowed in. This should be handled by PAM. Yes, although login programs would require that a) getpwnam returns non-NULL and b) pam_authenticate returns PAM_SUCCESS. 3. What password hash should we use when we have the username and the password hash? This should be handled by the new modularized crypt. This is a function of the pam_unix module, a PAM module can use smartcards, retina scanners, body odour detectors etc etc, so it may not use password hashes at all. Each PAM module may have its own configuration file to tell it which serial port the smartcard reader is on for example. Regards, Niall To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal for new syscall to close files
3) Close all FDs except the ones you explicitly want to keep. This is normally something like: for (i = getdtablesize(); --i 2; ) close(i); The advantage is that you are sure you don't miss any. The disadvantage is that it requires a system call for each potentially open FD - 600 on my system - whereas maybe only 4 or 5 are actually open. How many daemons suffer from performance problems because of this? None that I know of. I'm sorry, but this syscall seems like clutter to me. Regards, Niall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD
[ CC list nuked ] Ok, here goes my understanding of how things should be, please correct me if i'm wrong. There are three parts to the problem: 1. Where do we get the databases from? I mean, where do we get passwd, group, hosts, ethers, etc from. This should be handled by a name service switch a la solaris. Basically we want to be able to tell the system for each individual database where to get the stuff from. We can add entries for each database in the system. Not so much as where do we get the databases from as which databases hold data for this particular service. For example DNS can store information for the hosts service (i.e. nameserver service) but could also store crytographic keys which could be used for as host keys for ssh for example. The service has a standard API (gethostbyname() for example, or getpwnam()) which can search through multiple disparate database types. (I may be mixing my terminology up here, it may be more conventional to say which services support this database, where the database might be a load of struct pw for example, but hopefully its clear I mean) Each particular database type might have its own configuration file. Taking the hosts service for example, the configuration file for the DNS database is /etc/resolv.conf and there is no configuration for the files database (which uses /etc/hosts) 2. How to authorize the user? I mean, what sort of authentication should we use to decide if the user should be allowed in. This should be handled by PAM. Yes, although login programs would require that a) getpwnam returns non-NULL and b) pam_authenticate returns PAM_SUCCESS. 3. What password hash should we use when we have the username and the password hash? This should be handled by the new modularized crypt. This is a function of the pam_unix module, a PAM module can use smartcards, retina scanners, body odour detectors etc etc, so it may not use password hashes at all. Each PAM module may have its own configuration file to tell it which serial port the smartcard reader is on for example. Regards, Niall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
And pidentd will still be supported. Eventually, I'd like to have those huge majority who do not use DES tokens with pidentd move to the inetd identd (when committed)... How about a standalone identd with DES `tokens' and any other nice to haves that it doesn't make sense to implement in a built-in identd? Regards, Niall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Maybe if I call the sysctl "vm.crashmenow". No, that will just make more people actually try it. It might be doable as a compile-time option, since you wouldn't be able to run anything approaching standard on such a system anyway. I don't see much use for it myself. As I said before, there are easier ways to manage memory that are not quite as arbitrary as simply refusing a potential overcommit. Perhaps it could be an additional flag to mmap, in this way people wishing to run an overcommited system could do so but those writing programs which must not overcommit for certain memory allocations could ensure they did not do so. Regards, Niall To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/12578: `` subshell taints PWD
I'm not sure if XPG4v2 requires command substitution to behave like that. At least, both Solaris' and DEC UNIX... oops... True64 UNIX do execute all command substitutions in a subshell (`pwd` does not affect the surrounding shell), and both claim XPG4 compliance. They only execute a subshell when they need to: $ echo $$ `echo $$` 14405 14405 $ uname -a SunOS molotov.boi.ie 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra-5_10 Regards, Niall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Maybe if I call the sysctl vm.crashmenow. No, that will just make more people actually try it. It might be doable as a compile-time option, since you wouldn't be able to run anything approaching standard on such a system anyway. I don't see much use for it myself. As I said before, there are easier ways to manage memory that are not quite as arbitrary as simply refusing a potential overcommit. Perhaps it could be an additional flag to mmap, in this way people wishing to run an overcommited system could do so but those writing programs which must not overcommit for certain memory allocations could ensure they did not do so. Regards, Niall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Off Topic] ODBC and yahoo
David Miller wrote: Couple of questions which are pretty much off topic 1) Does anyone know of a way to talk to a remote oracle server via odbc or oci? Access is required specifically under apache and mod_perl or php, but we've spent a couple of man-days looking for straightforward answers and found none:( I know of at least two ways to access Oracle from FreeBSD: use the JDBC type IV driver, or use linux emulated binaries with Oracle for Linux. Regards, Niall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: bin/12578: `` subshell taints PWD
Sheldon Hearn wrote: On Mon, 12 Jul 1999 18:37:13 GMT, Niall Smart wrote: The patch appended seems to fix this, I'd like someone familiar with sh to review it though, since this may be symptomatic of a general problem with command substitution. As I understand your patch, you're saying "we should fork off a child process when the command in question is cd"? This is what I missed when I tried ``echo .`sleep 600`.'' and assumed that the result was proof that we always spawn a subprocess for backtick evaluation. :-( As I understand it most builtins will not spawn a new shell when they are used in command substitution: niall% echo `echo $$` $$ 20354 20354 niall% Niall To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
"Brian F. Feldman" wrote: On Mon, 12 Jul 1999, Sheldon Hearn wrote: On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. [snip] It's "out with the bad, in with the good." Pidentd code is pretty terrible. Agreed, nobody wants a monstrosity of an ident daemon in the base system. The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) Your code is still insecure, I can still obtain 16 characters of the first line of any file in the system just by symlinking to it. I don't see how you expect your checks to defeat that. What you should do is setgid setuid to the user returned by net.inet.tcp.getcred immediately after doing the sysctl. Or even better take out this FAKEID stuff. If anyone wants to audit my code for security, I invite them to. But frankly, I highly doubt anyone will find anything to exploit. Heh, famous last words. And, why would bugtraq advisories against other identds apply to my ident_stream service? This is an entirely different code base. That doesn't matter, different programmers make the same mistakes and assumptions when solving the same problem (there is research into the effectiveness of N-way programming which shows this) and many attacks are against subtle implementation mistakes which you may also make. Regards, Niall To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/12578: `` subshell taints PWD
Sheldon Hearn wrote: On Mon, 12 Jul 1999 18:37:13 GMT, Niall Smart wrote: The patch appended seems to fix this, I'd like someone familiar with sh to review it though, since this may be symptomatic of a general problem with command substitution. As I understand your patch, you're saying we should fork off a child process when the command in question is cd? This is what I missed when I tried ``echo .`sleep 600`.'' and assumed that the result was proof that we always spawn a subprocess for backtick evaluation. :-( As I understand it most builtins will not spawn a new shell when they are used in command substitution: niall% echo `echo $$` $$ 20354 20354 niall% Niall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
Brian F. Feldman wrote: On Mon, 12 Jul 1999, Sheldon Hearn wrote: On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. [snip] It's out with the bad, in with the good. Pidentd code is pretty terrible. Agreed, nobody wants a monstrosity of an ident daemon in the base system. The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) Your code is still insecure, I can still obtain 16 characters of the first line of any file in the system just by symlinking to it. I don't see how you expect your checks to defeat that. What you should do is setgid setuid to the user returned by net.inet.tcp.getcred immediately after doing the sysctl. Or even better take out this FAKEID stuff. If anyone wants to audit my code for security, I invite them to. But frankly, I highly doubt anyone will find anything to exploit. Heh, famous last words. And, why would bugtraq advisories against other identds apply to my ident_stream service? This is an entirely different code base. That doesn't matter, different programmers make the same mistakes and assumptions when solving the same problem (there is research into the effectiveness of N-way programming which shows this) and many attacks are against subtle implementation mistakes which you may also make. Regards, Niall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: bin/12578: `` subshell taints PWD
Sheldon Hearn wrote:
cd /tmp
echo .`cd /`.
pwd
Any takers?
The patch appended seems to fix this, I'd like someone familiar
with sh to review it though, since this may be symptomatic of
a general problem with command substitution.
PS: And no, this is not an invitation to chat about the default shell
for the base system. :-)
You're hinting it should be /bin/sh for root, right?
Regards,
Niall
*** eval.c~ Mon May 10 16:10:16 1999
--- eval.c Mon Jul 12 18:27:44 1999
***
*** 710,715
--- 710,716
((flags EV_EXIT) == 0 || Tflag))
|| ((flags EV_BACKCMD) != 0
(cmdentry.cmdtype != CMDBUILTIN
+|| cmdentry.u.index == CDCMD
|| cmdentry.u.index == DOTCMD
|| cmdentry.u.index == EVALCMD))) {
jp = makejob(cmd, 1);
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
I don't see a point to that. However, I am finished. Please go to
http://www.FreeBSD.org/~green/ and get getcred.patch and inetd_ident.patch.
Hmm,
+#ifdef FAKEID
+ snprintf(fakeid_path, sizeof(fakeid_path), "%s/.fakeid",
pw-pw_dir);
+ fakeid = fopen(fakeid_path, "r");
+ if (fakeid) {
$ ln -s /etc/master.passwd ~/.fakeid
Ouch. (One possible saving grace here is that you truncate
after 16 characters).
+ if (!*cp || getpwnam(cp)) {
+ pw = getpwuid(uc.cr_uid);
+ cp = pw-pw_name;
+ goto printit;
+ }
What is this code trying to do? If the ~/.fakeid file is invalid
or the user is attempting to impersonate another then revert? A
comment would be nice. You forget to check for pw == NULL here
(but you don't earlier ;) and I don't think the goto is necessary.
Regards,
Niall
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
I don't see a point to that. However, I am finished. Please go to
http://www.FreeBSD.org/~green/ and get getcred.patch and inetd_ident.patch.
Hmm,
+#ifdef FAKEID
+ snprintf(fakeid_path, sizeof(fakeid_path), %s/.fakeid,
pw-pw_dir);
+ fakeid = fopen(fakeid_path, r);
+ if (fakeid) {
$ ln -s /etc/master.passwd ~/.fakeid
Ouch. (One possible saving grace here is that you truncate
after 16 characters).
+ if (!*cp || getpwnam(cp)) {
+ pw = getpwuid(uc.cr_uid);
+ cp = pw-pw_name;
+ goto printit;
+ }
What is this code trying to do? If the ~/.fakeid file is invalid
or the user is attempting to impersonate another then revert? A
comment would be nice. You forget to check for pw == NULL here
(but you don't earlier ;) and I don't think the goto is necessary.
Regards,
Niall
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: poll() scalability
could buffer siginfo's in user space, although this introduces complexity if you want the ability to cancel queued signals... yes, that is the hard part :) Well, how about the kernel passes siginfo and siginfo_cancel events up to userland, siginfo will remove any siginfo's from its buffer that it sees a siginfo_cancel event for -- naturally we need a flag to tell siginfo when to poll for events, this flag would be set by the function which cancels siginfo's. Would this work? Is it worth the complexity? Regards, Niall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poll() scalability
Also, you really want to return more than one event at at time in order to amortize the cost of the system call over several events, this doesn't seem possible with callbacks (or upcalls). yes, that would be a nice behaviour, but I haven't seen it become a real issue yet. the sigwaitinfo() syscall is just so much lighter than all the other things going on in the situation where you actually use this system. How about a modified sigwaitinfo that will return a number of waiting siginfo -- of course this introduces the problem of deciding how long to wait for new additions to the queue before returning. This is something similar to the Nagle algorithm.. Or perhaps sigwaitinfo could buffer siginfo's in user space, although this introduces complexity if you want the ability to cancel queued signals... Regards, Niall To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poll() scalability
Also, you really want to return more than one event at at time in order to amortize the cost of the system call over several events, this doesn't seem possible with callbacks (or upcalls). yes, that would be a nice behaviour, but I haven't seen it become a real issue yet. the sigwaitinfo() syscall is just so much lighter than all the other things going on in the situation where you actually use this system. How about a modified sigwaitinfo that will return a number of waiting siginfo -- of course this introduces the problem of deciding how long to wait for new additions to the queue before returning. This is something similar to the Nagle algorithm.. Or perhaps sigwaitinfo could buffer siginfo's in user space, although this introduces complexity if you want the ability to cancel queued signals... Regards, Niall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 'rtfm script'
At that point the converstaion turned to talking about Irish soap carving and the fact that www.OpenBSD.org doesn't run OpenBSD. I guess I was wrong about IRC being positive. Well, you can blame the first bit of surrealism on jkh, the poor fella has some awful ideas about what the Irish do in their spare time. God bless him. Niall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [DISKLABEL FRAGGED] Clues requested... ;)
Josef Karthauser wrote:
Guess what... I've got a disk where the partition table and the disklabel has
mysteriously disappeared! Oops.
I've reconstructed the partition table, and now need to partition the
disklabel.
Wow, you're probably the first person ever to do that, unlucky you. Out
of sympathy I've written you this findsb program which of course I've
never had to use myself. Its not the most efficiently written program
ever
and since FreeBSD swap partitions don't have magic numbers it may be
slow,
but it seems to work, however I draw your attention to the disclaimer
in the C file. ;)
Regards,
Niall
niall% disklabel wd0s2 | sed -n '/fstype/,$p'
#size offsetfstype [fsize bsize bps/cpg]
a: 13107204.2BSD0 0 0 # (Cyl.0 -
8*)
b: 262144 131072 swap# (Cyl.8*-
24*)
c: 41929650unused0 0 # (Cyl.0 -
260)
e: 819200 3932164.2BSD0 0 0 # (Cyl. 24*-
75*)
f: 2980549 12124164.2BSD0 0 0 # (Cyl. 75*-
260*)
niall% ./findsb /dev/wd0s2 0
found superblock: offset=16384, fs_size=65536, fs_fsmnt=/
suggested disklabel entry:
size offsetfstype
13107204.2BSD
found superblock: offset=24576, fs_size=65536, fs_fsmnt=
suggested disklabel entry:
size offsetfstype
131072 164.2BSD
^C
niall% ./findsb /dev/wd0s2 $[393216 * 512 - 8192 * 10]
skipping 201244672 bytes
found superblock: offset=201342976, fs_size=409600, fs_fsmnt=/home
suggested disklabel entry:
size offsetfstype
819200 3932164.2BSD
found superblock: offset=201351168, fs_size=409600, fs_fsmnt=
suggested disklabel entry:
size offsetfstype
819200 3932324.2BSD
^CPROG= findsb
CFLAGS = -aout -static -W -Wall -Wmissing-prototypes -Wstrict-prototypes
MAN1=
.include bsd.prog.mk
/*
* Copyright (c) 1999 Niall Smart. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
*must display the following acknowledgement:
* This product includes software developed by Niall Smart,
ni...@pobox.com.
*
* THIS SOFTWARE IS PROVIDED BY NIALL SMART ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL NIALL SMART BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
#include sys/types.h
#include sys/param.h
#include ufs/ffs/fs.h
#include stdio.h
#include unistd.h
#include fcntl.h
#include stddef.h
#include stdlib.h
#include limits.h
int
main(int argc, char** argv)
{
int fd;
int ret;
off_t offset;
u_quad_tskip;
char* ptr;
charbuf[SBSIZE];
struct fs* fs = (struct fs*)buf;
if (argc != 3) {
fprintf(stderr, usage: %s device skip\n, argv[0]);
exit(1);
}
if ( (fd = open(argv[1], O_RDONLY)) 0) {
perror(open);
exit(1);
}
if ( (skip = strtouq(argv[2], ptr, 0)) == QUAD_MAX || *ptr != '\0') {
fprintf(stderr, bad seek value: %s\n, argv[2]);
exit(1);
}
if ( (skip % SBOFF) != 0)
fprintf(stderr, warning: %qu is not a multiple of SBOFF
(%d)\n, skip, (int)SBOFF);;
if (skip 0) {
fprintf(stderr, skipping %qu bytes\n, skip);
lseek(fd, skip, SEEK_SET);
}
while (1) {
ret = read(fd, buf, sizeof(buf));
if (ret 0) {
perror(read);
exit(1);
}
/*
* based on checks in /sys/ufs/ffs/ffs_vfsops.c, line 478
*/
if (fs-fs_magic
