Re: pfctl: anchor names must not be empty, unify sanity checks

2019-02-08 Thread Alexandr Nedvedicky
Hello,


On Wed, Feb 06, 2019 at 10:20:35PM +0100, Klemens Nanni wrote:
> When using anchors, they ought to have a non-empty name or none at all.
> 
> By accident, I discovered the following:
> 
>   $ printf 'anchor ""\n' | pfctl -vnf-
>   pass all no state
> 
> No errors and it parses in a potentially harmful way.  Other use cases
> behave badly as well:
> 
>   $ printf 'anchor "" {\n}\n' | pfctl -vnf-
>   pfctl: anchorrule: unable to create ruleset: Permission denied
> 
>   $ printf 'load anchor "" from "/dev/null"\n' | pfctl -vnf-
>   Loading anchor  from /dev/null
> 
> None of them make sense, so I propose to error out on empty anchor names
> as early as possible.  Given that typos happen and folks generate their
> pf.conf automatically, such errors do not seem entirely out of scope.

makes sense to me. and change also looks good to me.

Also it looks like tables are suffering from the same problem:

puffy# echo "table <''> const { 10/8, 172.16/12, 192.168/16 }" |pfctl -nf - 
puffy# echo $?
0
puffy# echo "table <''> const { 10/8, 172.16/12, 192.168/16 }" |pfctl -f -
stdin:1: cannot define table : Invalid argument
pfctl: Syntax error in config file: pf rules not loaded

We parse.y can be also taught to fail on empty name for table, but it can be
fixed in yet another patch.

OK sashan@



Re: httpd.conf(5) man page

2019-02-08 Thread Florian Obser
On Sat, Feb 02, 2019 at 12:20:03PM +0100, Daniel Gracia wrote:
> Hi there!
> 
> httpdd FastCGI interface can connect seamlessly to a local TCP port,
> but this is not documented on the man page.

Thanks for pointing this out. I worked with jmc on rewording the
fastcgi socket description a bit.

> 
> Went to the source and found the syntax to be a little awkward (maybe
> a quick fix?). Anyway, allowed me running flask/flup/bottle pretty
> straightforward.
> 
> Regards!
> 
> Index: usr.sbin/httpd/httpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
> retrieving revision 1.101
> diff -u -p -u -p -r1.101 httpd.conf.5
> --- usr.sbin/httpd/httpd.conf.5 20 Jun 2018 16:43:05 -  1.101
> +++ usr.sbin/httpd/httpd.conf.5 2 Feb 2019 11:03:48 -
> @@ -278,12 +278,16 @@ will neither display nor generate a dire
>  Enable FastCGI instead of serving files.
>  The
>  .Ar socket
> -is a local path name within the
> +can be a local path name within the
>  .Xr chroot 2
>  root directory of
>  .Xr httpd 8
> -and defaults to
> -.Pa /run/slowcgi.sock .
> +(defaults to
> +.Pa /run/slowcgi.sock
> +). Starting with colon,
> +.Ar socket
> +can specify a port number that will connect to INADDR_LOOPBACK
> +address.
>  .Pp
>  The FastCGI handler will be given the following variables:
>  .Pp
> 

-- 
I'm not entirely sure you are real.



Update pf.os with newer OS fingerprints

2019-02-08 Thread Fernando Fernandez Mancera
Hi,

I have been updating the pf.os signatures with more recent OS
fingerprints. I have checked out new Linux, FreeBSD and OpenBSD but only
Linux and FreeBSD needed new ones. I have been doing this because it is
related with my work during the last Google Summer of Code. In addition,
Michal Zalewski is aware of the new fingerprints too.

Thanks.

P.S: Keep me on Cc. I'm not subscribed to the list.

diff --git etc/pf.os etc/pf.os
index 41c1bc6a482..8f235876799 100644
--- etc/pf.os
+++ etc/pf.os
@@ -232,6 +232,11 @@ S4:64:1:60:M*,S,T,N,W7:Linux:2.6::Linux 2.6
(newer, 3)
 T4:64:1:60:M*,S,T,N,W7:Linux:2.6::Linux 2.6 (newer, 4)

 S10:64:1:60:M*,S,T,N,W4:   Linux:3.0::Linux 3.0
+S10:64:1:60:M*,S,T,N,W6:   Linux:3.1::Linux 3.1
+S10:64:1:60:M*,S,T,N,W7:   Linux:3.4-3.10::Linux 3.4 - 3.10
+S20:64:1:60:M*,S,T,N,W7:   Linux:3.11-3.19::Linux 3.11 - 3.19
+S20:64:1:60:M*,S,T,N,W7:   Linux:4.0-4.19::Linux 4.0 - 4.19
+S44:64:1:60:M*,S,T,N,W7:   Linux:4.20::Linux 4.20

 S3:64:1:60:M*,S,T,N,W1:Linux:2.5::Linux 2.5 (sometimes 2.4)
 S4:64:1:60:M*,S,T,N,W1:Linux:2.5-2.6::Linux 2.5/2.6
@@ -283,6 +288,8 @@ S22:64:1:52:M*,N,N,S,N,W0:  Linux:2.2:ts:Linux 2.2
w/o timestamps
 65535:64:1:60:M*,N,W1,N,N,T:   FreeBSD:4.7-4.11::FreeBSD 4.7-5.2
 65535:64:1:60:M*,N,W1,N,N,T:   FreeBSD:5.0-5.2::FreeBSD 4.7-5.2

+65535:64:1:60:M*,N,W6,S,T: FreeBSD:9.0-12.0::FreeBSD 9.0 - 12.0
+
 # XXX need quirks support
 # 65535:64:1:60:M*,N,W0,N,N,T:Z:FreeBSD:5.1-5.4::5.1-current (1)
 # 65535:64:1:60:M*,N,W1,N,N,T:Z:FreeBSD:5.1-5.4::5.1-current (2)



Re: install(1) could fail due to race

2019-02-08 Thread Ingo Schwarze
Ted Unangst wrote on Sun, Jan 27, 2019 at 10:37:52AM -0500:
> Ingo Schwarze wrote:

>> If people here agree with the general direction of making -S the
>> default and removing the fragile non-S mode (see the patch below),
>> i'll run a full make build and make release and then ask for OKs.

> Just checking we didn't forget about this. Seems the right thing to do.

Committed now, hoping that it will *not* cause fireworks in deraadt@'s
NFS-based build infrastructure.

Yours,
  Ingo



diff: add missing bit description for pkthdr_pf.flags

2019-02-08 Thread Jan Klemkow
Hi,

The following diff adds the description of the second bit of the struct
pkthdr_pf field flags.

bye,
Jan

Index: sys/sys/mbuf.h
===
RCS file: /cvs/src/sys/sys/mbuf.h,v
retrieving revision 1.241
diff -u -p -r1.241 mbuf.h
--- sys/sys/mbuf.h  7 Dec 2018 08:37:24 -   1.241
+++ sys/sys/mbuf.h  8 Feb 2019 16:25:12 -
@@ -119,8 +119,8 @@ struct pkthdr_pf {
 
 #ifdef _KERNEL
 #define MPF_BITS \
-("\20\1GENERATED\3TRANSLATE_LOCALHOST\4DIVERTED\5DIVERTED_PACKET" \
-"\6REROUTE\7REFRAGMENTED\10PROCESSED")
+("\20\1GENERATED\2SYNCOOKIE_RECREATED\3TRANSLATE_LOCALHOST\4DIVERTED" \
+"\5DIVERTED_PACKET\6REROUTE\7REFRAGMENTED\10PROCESSED")
 #endif
 
 /* record/packet header in first mbuf of chain; valid if M_PKTHDR set */



Re: Update pf.os with newer OS fingerprints

2019-02-08 Thread Pablo Neira Ayuso
On Fri, Feb 08, 2019 at 05:25:38PM +0100, Fernando Fernandez Mancera wrote:
[...]
> On 2/8/19 5:07 PM, Pablo Neira Ayuso wrote:
[...]
> > On Fri, Feb 08, 2019 at 03:06:00PM +0100, Fernando Fernandez Mancera wrote:
[...]
> >> +S20:64:1:60:M*,S,T,N,W7:  Linux:3.11-3.19::Linux 3.11 - 3.19
> >> +S20:64:1:60:M*,S,T,N,W7:  Linux:4.0-4.19::Linux 4.0 - 4.19
> > 
> > Probably merge these two lines above? ie.
> > > S20:64:1:60:M*,S,T,N,W7:  Linux:3.11-4.19::Linux 3.11 - 4.19
> > 
> 
> I split this one by following the pattern of similar situations for
> other fingerprints. eg.
> 
> 16384:64:1:44:M*: FreeBSD:2.0-2.2::FreeBSD 2.0-4.2
> 16384:64:1:44:M*: FreeBSD:3.0-3.5::FreeBSD 2.0-4.2
> 16384:64:1:44:M*: FreeBSD:4.0-4.2::FreeBSD 2.0-4.2
> 
> 65535:64:1:60:M*,N,W1,N,N,T:  FreeBSD:4.7-4.11::FreeBSD 4.7-5.2
> 65535:64:1:60:M*,N,W1,N,N,T:  FreeBSD:5.0-5.2::FreeBSD 4.7-5.2
> 
> In my opinion I would make no changes to these two lines. Do you agree?

That's fine. Thanks for explaining.



Re: Update pf.os with newer OS fingerprints

2019-02-08 Thread Pablo Neira Ayuso
Hi Fernando,

On Fri, Feb 08, 2019 at 03:06:00PM +0100, Fernando Fernandez Mancera wrote:
> Hi,
> 
> I have been updating the pf.os signatures with more recent OS
> fingerprints. I have checked out new Linux, FreeBSD and OpenBSD but only
> Linux and FreeBSD needed new ones. I have been doing this because it is
> related with my work during the last Google Summer of Code. In addition,
> Michal Zalewski is aware of the new fingerprints too.
> 
> Thanks.
> 
> P.S: Keep me on Cc. I'm not subscribed to the list.
> 
> diff --git etc/pf.os etc/pf.os
> index 41c1bc6a482..8f235876799 100644
> --- etc/pf.os
> +++ etc/pf.os
> @@ -232,6 +232,11 @@ S4:64:1:60:M*,S,T,N,W7:  Linux:2.6::Linux 2.6
> (newer, 3)
>  T4:64:1:60:M*,S,T,N,W7:  Linux:2.6::Linux 2.6 (newer, 4)
> 
>  S10:64:1:60:M*,S,T,N,W4: Linux:3.0::Linux 3.0
> +S10:64:1:60:M*,S,T,N,W6: Linux:3.1::Linux 3.1
> +S10:64:1:60:M*,S,T,N,W7: Linux:3.4-3.10::Linux 3.4 - 3.10
> +S20:64:1:60:M*,S,T,N,W7: Linux:3.11-3.19::Linux 3.11 - 3.19
> +S20:64:1:60:M*,S,T,N,W7: Linux:4.0-4.19::Linux 4.0 - 4.19

Probably merge these two lines above? ie.

S20:64:1:60:M*,S,T,N,W7:Linux:3.11-4.19::Linux 3.11 - 4.19

> +S44:64:1:60:M*,S,T,N,W7: Linux:4.20::Linux 4.20
> 
>  S3:64:1:60:M*,S,T,N,W1:  Linux:2.5::Linux 2.5 (sometimes 2.4)
>  S4:64:1:60:M*,S,T,N,W1:  Linux:2.5-2.6::Linux 2.5/2.6
> @@ -283,6 +288,8 @@ S22:64:1:52:M*,N,N,S,N,W0:Linux:2.2:ts:Linux 2.2
> w/o timestamps
>  65535:64:1:60:M*,N,W1,N,N,T: FreeBSD:4.7-4.11::FreeBSD 4.7-5.2
>  65535:64:1:60:M*,N,W1,N,N,T: FreeBSD:5.0-5.2::FreeBSD 4.7-5.2
> 
> +65535:64:1:60:M*,N,W6,S,T:   FreeBSD:9.0-12.0::FreeBSD 9.0 - 12.0
> +
>  # XXX need quirks support
>  # 65535:64:1:60:M*,N,W0,N,N,T:Z:FreeBSD:5.1-5.4::5.1-current (1)
>  # 65535:64:1:60:M*,N,W1,N,N,T:Z:FreeBSD:5.1-5.4::5.1-current (2)



Re: Update pf.os with newer OS fingerprints

2019-02-08 Thread Fernando Fernandez Mancera
Hi Pablo,

On 2/8/19 5:07 PM, Pablo Neira Ayuso wrote:
> Hi Fernando,
> 
> On Fri, Feb 08, 2019 at 03:06:00PM +0100, Fernando Fernandez Mancera wrote:
>> Hi,
>>
>> I have been updating the pf.os signatures with more recent OS
>> fingerprints. I have checked out new Linux, FreeBSD and OpenBSD but only
>> Linux and FreeBSD needed new ones. I have been doing this because it is
>> related with my work during the last Google Summer of Code. In addition,
>> Michal Zalewski is aware of the new fingerprints too.
>>
>> Thanks.
>>
>> P.S: Keep me on Cc. I'm not subscribed to the list.
>>
>> diff --git etc/pf.os etc/pf.os
>> index 41c1bc6a482..8f235876799 100644
>> --- etc/pf.os
>> +++ etc/pf.os
>> @@ -232,6 +232,11 @@ S4:64:1:60:M*,S,T,N,W7: Linux:2.6::Linux 2.6
>> (newer, 3)
>>  T4:64:1:60:M*,S,T,N,W7: Linux:2.6::Linux 2.6 (newer, 4)
>>
>>  S10:64:1:60:M*,S,T,N,W4:Linux:3.0::Linux 3.0
>> +S10:64:1:60:M*,S,T,N,W6:Linux:3.1::Linux 3.1
>> +S10:64:1:60:M*,S,T,N,W7:Linux:3.4-3.10::Linux 3.4 - 3.10
>> +S20:64:1:60:M*,S,T,N,W7:Linux:3.11-3.19::Linux 3.11 - 3.19
>> +S20:64:1:60:M*,S,T,N,W7:Linux:4.0-4.19::Linux 4.0 - 4.19
> 
> Probably merge these two lines above? ie.
> > S20:64:1:60:M*,S,T,N,W7:Linux:3.11-4.19::Linux 3.11 - 4.19
> 

I split this one by following the pattern of similar situations for
other fingerprints. eg.

16384:64:1:44:M*:   FreeBSD:2.0-2.2::FreeBSD 2.0-4.2
16384:64:1:44:M*:   FreeBSD:3.0-3.5::FreeBSD 2.0-4.2
16384:64:1:44:M*:   FreeBSD:4.0-4.2::FreeBSD 2.0-4.2

65535:64:1:60:M*,N,W1,N,N,T:FreeBSD:4.7-4.11::FreeBSD 4.7-5.2
65535:64:1:60:M*,N,W1,N,N,T:FreeBSD:5.0-5.2::FreeBSD 4.7-5.2

In my opinion I would make no changes to these two lines. Do you agree?

>> +S44:64:1:60:M*,S,T,N,W7:Linux:4.20::Linux 4.20
>>
>>  S3:64:1:60:M*,S,T,N,W1: Linux:2.5::Linux 2.5 (sometimes 2.4)
>>  S4:64:1:60:M*,S,T,N,W1: Linux:2.5-2.6::Linux 2.5/2.6
>> @@ -283,6 +288,8 @@ S22:64:1:52:M*,N,N,S,N,W0:   Linux:2.2:ts:Linux 2.2
>> w/o timestamps
>>  65535:64:1:60:M*,N,W1,N,N,T:FreeBSD:4.7-4.11::FreeBSD 4.7-5.2
>>  65535:64:1:60:M*,N,W1,N,N,T:FreeBSD:5.0-5.2::FreeBSD 4.7-5.2
>>
>> +65535:64:1:60:M*,N,W6,S,T:  FreeBSD:9.0-12.0::FreeBSD 9.0 - 12.0
>> +
>>  # XXX need quirks support
>>  # 65535:64:1:60:M*,N,W0,N,N,T:Z:FreeBSD:5.1-5.4::5.1-current (1)
>>  # 65535:64:1:60:M*,N,W1,N,N,T:Z:FreeBSD:5.1-5.4::5.1-current (2)



Re: scan_ffs(8) and FFS2 filesystems

2019-02-08 Thread Jason McIntyre
On Fri, Feb 08, 2019 at 09:35:35PM +0100, Jeremie Courreges-Anglas wrote:
> 
> 
> I think it's fair to give the user a chance to understand why
> scan_ffs(8) won't help in this case.
> 
> ok?
> 

hi.

i'm not sure if it's a bug, but it sure seems relevant. i would be
tempted to be much more upfront about this (DESCRIPTION), way before you
start tearing hair out...

like just say upfront, scan_ffs does not support ffs2 filesystems.

jmc

> 
> --- scan_ffs.8.~1.16.~Mon Mar 24 00:28:46 2008
> +++ scan_ffs.8Fri Feb  8 21:31:10 2019
> @@ -136,6 +136,7 @@ you out of a jam when they happen.
>  .Sh SEE ALSO
>  .Xr disklabel 8
>  .Sh BUGS
> -It is not perfect, and could do a lot more things with date/time information
> +It is not perfect, does not support FFS2 filesystems,
> +and could do a lot more things with date/time information
>  in the superblocks it finds, but this program has saved more than one butt,
>  more than once.
> 
> -- 
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
> 



scan_ffs(8) and FFS2 filesystems

2019-02-08 Thread Jeremie Courreges-Anglas



I think it's fair to give the user a chance to understand why
scan_ffs(8) won't help in this case.

ok?


--- scan_ffs.8.~1.16.~  Mon Mar 24 00:28:46 2008
+++ scan_ffs.8  Fri Feb  8 21:31:10 2019
@@ -136,6 +136,7 @@ you out of a jam when they happen.
 .Sh SEE ALSO
 .Xr disklabel 8
 .Sh BUGS
-It is not perfect, and could do a lot more things with date/time information
+It is not perfect, does not support FFS2 filesystems,
+and could do a lot more things with date/time information
 in the superblocks it finds, but this program has saved more than one butt,
 more than once.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: scan_ffs(8) and FFS2 filesystems

2019-02-08 Thread Jason McIntyre
On Fri, Feb 08, 2019 at 11:11:31PM +0100, Jeremie Courreges-Anglas wrote:
> On Fri, Feb 08 2019, "Theo de Raadt"  wrote:
> > Jason McIntyre  wrote:
> >
> >> On Fri, Feb 08, 2019 at 09:35:35PM +0100, Jeremie Courreges-Anglas wrote:
> >> > 
> >> > 
> >> > I think it's fair to give the user a chance to understand why
> >> > scan_ffs(8) won't help in this case.
> >> > 
> >> > ok?
> >> > 
> >> 
> >> hi.
> >> 
> >> i'm not sure if it's a bug, but it sure seems relevant. i would be
> >> tempted to be much more upfront about this (DESCRIPTION), way before you
> >> start tearing hair out...
> >> 
> >> like just say upfront, scan_ffs does not support ffs2 filesystems.
> >
> > true.  it should be stated in a formal way.
> 
> Looks like a better approach indeed.
> 
> > "It is not perfect"
> >
> > Yuck...
> >
> > "one butt"?
> >
> > This is below our standard.
> 
> yep
> 
> So here's a three parts diff
> 1. kill useless .TH line present since rev. 1.1

yep

> 2. document the lack of FFS2 support in DESCRIPTION

yep, though i'd skip the "note that" blurb.

why not

.Pp
.Nm
works only on FFS file systems,
not FFS2 file systems.

> 3. remove BUGS
> 

i'm less sure here. i'd leave it to the author's discretion, but if it
really is useless (i can't judge), fair enough.

jmc

> Rationale for 3: after trimming the fluff from BUGS, you end up with:
> 
>   .Nm
>   could do a lot more things with date/time information in the
>   superblocks it finds.
> 
> The FFS superblock contains three "time" fields:
> - fs_ffs1_time "last time written"
> - fs_time "last time written"
> - fs_fscktime "last time fsck(8)ed"
> 
> Printing fs_fscktime doesn't look useful to me.  fs_ffs1_time and
> fs_time are supposed to contain the same value, if I read ffs_vfsops.c
> correctly.  The difference is that fs_ffs1_time is an int32_t and
> fs_time is an int64_t.  While this may need care regarding Y2038,
> this is a problem with FFS, not scan_ffs(8).
> 
> Thoughts/oks?
> 
> 
> --- scan_ffs.8.~1.16.~Fri Feb  8 21:56:34 2019
> +++ scan_ffs.8Fri Feb  8 23:08:00 2019
> @@ -23,7 +23,6 @@
>  .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
>  .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>  .\"
> -.\" .TH scan_ffs 8
>  .Dd $Mdocdate: March 23 2008 $
>  .Dt SCAN_FFS 8
>  .Os
> @@ -48,6 +47,10 @@ on the disk.
>  It has various options to make it go faster, and to print out
>  information to help in the reconstruction of the disklabel.
>  .Pp
> +Note that
> +.Nm
> +does not recognize FFS2 partitions.
> +.Pp
>  The options are as follows:
>  .Bl -tag -width Ds
>  .It Fl b Ar begin
> @@ -135,7 +138,3 @@ If you can't have backups, at least have funky tools t
>  you out of a jam when they happen.
>  .Sh SEE ALSO
>  .Xr disklabel 8
> -.Sh BUGS
> -It is not perfect, and could do a lot more things with date/time information
> -in the superblocks it finds, but this program has saved more than one butt,
> -more than once.
> 
> -- 
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
> 



Re: scan_ffs(8) and FFS2 filesystems

2019-02-08 Thread Theo de Raadt
Jason McIntyre  wrote:

> On Fri, Feb 08, 2019 at 09:35:35PM +0100, Jeremie Courreges-Anglas wrote:
> > 
> > 
> > I think it's fair to give the user a chance to understand why
> > scan_ffs(8) won't help in this case.
> > 
> > ok?
> > 
> 
> hi.
> 
> i'm not sure if it's a bug, but it sure seems relevant. i would be
> tempted to be much more upfront about this (DESCRIPTION), way before you
> start tearing hair out...
> 
> like just say upfront, scan_ffs does not support ffs2 filesystems.

true.  it should be stated in a formal way.

"It is not perfect"

Yuck...

"one butt"?

This is below our standard.


> > --- scan_ffs.8.~1.16.~  Mon Mar 24 00:28:46 2008
> > +++ scan_ffs.8  Fri Feb  8 21:31:10 2019
> > @@ -136,6 +136,7 @@ you out of a jam when they happen.
> >  .Sh SEE ALSO
> >  .Xr disklabel 8
> >  .Sh BUGS
> > -It is not perfect, and could do a lot more things with date/time 
> > information
> > +It is not perfect, does not support FFS2 filesystems,
> > +and could do a lot more things with date/time information
> >  in the superblocks it finds, but this program has saved more than one butt,
> >  more than once.
> > 
> > -- 
> > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
> > 
> 



Re: scan_ffs(8) and FFS2 filesystems

2019-02-08 Thread Jeremie Courreges-Anglas
On Fri, Feb 08 2019, "Theo de Raadt"  wrote:
> Jason McIntyre  wrote:
>
>> On Fri, Feb 08, 2019 at 09:35:35PM +0100, Jeremie Courreges-Anglas wrote:
>> > 
>> > 
>> > I think it's fair to give the user a chance to understand why
>> > scan_ffs(8) won't help in this case.
>> > 
>> > ok?
>> > 
>> 
>> hi.
>> 
>> i'm not sure if it's a bug, but it sure seems relevant. i would be
>> tempted to be much more upfront about this (DESCRIPTION), way before you
>> start tearing hair out...
>> 
>> like just say upfront, scan_ffs does not support ffs2 filesystems.
>
> true.  it should be stated in a formal way.

Looks like a better approach indeed.

> "It is not perfect"
>
> Yuck...
>
> "one butt"?
>
> This is below our standard.

yep

So here's a three parts diff
1. kill useless .TH line present since rev. 1.1
2. document the lack of FFS2 support in DESCRIPTION
3. remove BUGS

Rationale for 3: after trimming the fluff from BUGS, you end up with:

  .Nm
  could do a lot more things with date/time information in the
  superblocks it finds.

The FFS superblock contains three "time" fields:
- fs_ffs1_time "last time written"
- fs_time "last time written"
- fs_fscktime "last time fsck(8)ed"

Printing fs_fscktime doesn't look useful to me.  fs_ffs1_time and
fs_time are supposed to contain the same value, if I read ffs_vfsops.c
correctly.  The difference is that fs_ffs1_time is an int32_t and
fs_time is an int64_t.  While this may need care regarding Y2038,
this is a problem with FFS, not scan_ffs(8).

Thoughts/oks?


--- scan_ffs.8.~1.16.~  Fri Feb  8 21:56:34 2019
+++ scan_ffs.8  Fri Feb  8 23:08:00 2019
@@ -23,7 +23,6 @@
 .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
 .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 .\"
-.\" .TH scan_ffs 8
 .Dd $Mdocdate: March 23 2008 $
 .Dt SCAN_FFS 8
 .Os
@@ -48,6 +47,10 @@ on the disk.
 It has various options to make it go faster, and to print out
 information to help in the reconstruction of the disklabel.
 .Pp
+Note that
+.Nm
+does not recognize FFS2 partitions.
+.Pp
 The options are as follows:
 .Bl -tag -width Ds
 .It Fl b Ar begin
@@ -135,7 +138,3 @@ If you can't have backups, at least have funky tools t
 you out of a jam when they happen.
 .Sh SEE ALSO
 .Xr disklabel 8
-.Sh BUGS
-It is not perfect, and could do a lot more things with date/time information
-in the superblocks it finds, but this program has saved more than one butt,
-more than once.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



switch to am335x_evm U-Boot target

2019-02-08 Thread Jonathan Gray
The am335x_evm U-Boot target outputs a FIT image including device trees
for multiple am335x boards including the BeagleBone Black.

The am335x_boneblack target has been removed in the U-Boot repository
and will not be in the next major release.

This requires u-boot-arm >= 2019.01p2

Index: miniroot/am335x/Makefile
===
RCS file: /cvs/src/distrib/armv7/miniroot/am335x/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- miniroot/am335x/Makefile21 Sep 2018 02:21:53 -  1.6
+++ miniroot/am335x/Makefile9 Feb 2019 01:05:58 -
@@ -1,6 +1,6 @@
 BOARD= am335x
 PLATFORM=OMAP
-UBOOT= am335x_boneblack
+UBOOT= am335x_evm
 DTBS=\
am335x-bone.dtb \
am335x-boneblack.dtb \
Index: ramdisk/list
===
RCS file: /cvs/src/distrib/armv7/ramdisk/list,v
retrieving revision 1.37
diff -u -p -r1.37 list
--- ramdisk/list21 Sep 2018 02:21:53 -  1.37
+++ ramdisk/list9 Feb 2019 01:05:58 -
@@ -120,8 +120,8 @@ SYMLINK install.sub install
 SYMLINKinstall.sub upgrade
 
 # u-boot and dtbs
-COPY   /usr/local/share/u-boot/am335x_boneblack/MLOusr/mdec/am335x/MLO
-COPY   /usr/local/share/u-boot/am335x_boneblack/u-boot.img 
usr/mdec/am335x/u-boot.img
+COPY   /usr/local/share/u-boot/am335x_evm/MLO  usr/mdec/am335x/MLO
+COPY   /usr/local/share/u-boot/am335x_evm/u-boot.img   
usr/mdec/am335x/u-boot.img
 COPY   /usr/local/share/dtb/arm/am335x-bone.dtb
usr/mdec/am335x/am335x-bone.dtb
 COPY   /usr/local/share/dtb/arm/am335x-boneblack.dtb   
usr/mdec/am335x/am335x-boneblack.dtb
 COPY   /usr/local/share/dtb/arm/am335x-pocketbeagle.dtb
usr/mdec/am335x/am335x-pocketbeagle.dtb



Re: scan_ffs(8) and FFS2 filesystems

2019-02-08 Thread gwes




On 02/08/19 15:35, Jeremie Courreges-Anglas wrote:


I think it's fair to give the user a chance to understand why
scan_ffs(8) won't help in this case.

ok?


--- scan_ffs.8.~1.16.~  Mon Mar 24 00:28:46 2008
+++ scan_ffs.8  Fri Feb  8 21:31:10 2019
@@ -136,6 +136,7 @@ you out of a jam when they happen.
  .Sh SEE ALSO
  .Xr disklabel 8
  .Sh BUGS
-It is not perfect, and could do a lot more things with date/time information
+It is not perfect, does not support FFS2 filesystems,
+and could do a lot more things with date/time information
  in the superblocks it finds, but this program has saved more than one butt,
  more than once.


Scan_ffs checks for the the magic number of the superblock.


--- scan_ffs.c  23 Nov 2015 19:19:30 -  1.21
+++ scan_ffs.c  9 Feb 2019 02:13:48 -
@@ -67,7 +67,8 @@ ufsscan(int fd, daddr_t beg, daddr_t end

    for (n = 0; n < (SBSIZE * SBCOUNT); n += 512){
    sb = (struct fs*)([n]);
-   if (sb->fs_magic == FS_MAGIC) {
+   if (sb->fs_magic == FS_UFS1_MAGIC ||
+   sb->fs_magic == FS_UFS2_MAGIC) {
    if (flags & FLAG_VERBOSE)
    printf("block %lld id %x,%x 
size %d\n",

    (long long)(blk + (n/512)),
   sb->fs_magic == FS_UFS2_MAGIC) {
fixes it.