Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

> Am 26.01.24 um 17:09 schrieb Rodney W. Grimes:
> >> Am 25.01.24 um 16:38 schrieb Ed Maste:
> >>> On Wed, 24 Jan 2024 at 12:30, Warner Losh  wrote:
> >>> sbin/growfs/tests/legacy_test.pl
> >>> tools/regression/msdosfs/msdosfstest-2.sh
> >>> tools/regression/tmpfs/t_vnd
> >>> tools/tools/nanobsd/legacy.sh
> 
> All these scripts that currently depend on bsdlabel could
> easily be converted to exclusively use gpart instead.
> 
> Other scripts that had been identified to use bsdlabel or
> disklabel are unused / not relevant for FreeBSD.
> 
> [...]
> >> The bsdlabel/disklabel/fdisk programs could be rewritten using
> >> gpart without too much effort, at least for the use cases that
> 
> After looking at the source code it appears that there is
> no need to rewrite any of the bsdlabel/disklabel code, since
> it already uses geom calls to access the partition data and
> only uses direct disk writes to write out the partition table
> (as does gpart, AFAICT).
> 
> So, I do not see any dependencies on deprecated kernel features.
> 
> I have not compared the bsdlabel code and gpart_write_partcode()
> in detail, but I do not see much of a difference at first glance.
> 
> Therefore, bsdlabel and disklabel could be kept in the base
> system, IMHO. (But fdisk should go ...)

I still have not seen anything compelling that says fdisk
must go, other than someone says there is a PR and I am
not sure how a bug fix effects the position of fdisk in
or out of base as the bug needs fixed regardless.

> 
> > That would be wonderful.  Even just getting it to spit out
> > the FULL MBR values that are in a protective 0x238 MBR
> > would go along way to diagnose some corrupt GPT disks.
> 
> If you need access to the protective MBR of a GPT partition,
> this feature should be added to gpart instead, IMHO.

I am fine with that too, probalby 99% of my use case
is just a sanity check that the MBR/PMBR is not messed
up, but that 1% case when it is one needs a way to
deal with it very carefully.
> 
> But what's wrong with using "file -s" for this purpose:
> 
> # file -s /dev/nda0
> /dev/nda0: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), 
 ^sic
> end-CHS (0x3ff,255,63), startsector 1, 1953525167 sectors, extended partition 
^sic
> table (last)

Other than the sick mixing of hex and decimal output I suppose that
does infact get the :reading: of the MBR/PMBR to validate
there isnt an issue.  Its the repair work when those values are
nonsince I do not seeing file(1) fixing.

> 
> Do you need more information from the protective MBR?

I think that is all the information, same as output
by fdisk, just in a different and very hard to read
format.
> 
> This will not work on mounted file systems, though. But if
> you got the disk mounted, I'd expect you do not really need
> this information ...

Correct
> 
> >> have not become obsolete (e.g. CHS specifications) and only for
> >> use in scripts (i.e. no fdisk interactive edit mode).
> > 
> > You are fooling yourself if you think an MBR and CHS values
> > are obsolete.  GPT *IS* a type 0x238 MBR and see how many
> > BIOSes you can crash by writting garbage (Especially 0x0)
> > to the CHS values.  That MBR must have proper values, and
> > you cant just ignore that they exist.
> 
> Again something that gpart should be able to diagnose and fix.
> 
> Doesn't "gpart recover" already fix such protective MBRs?

I do not know for certain, but I think mainly "gpart recover"
is about fixing the 2 copies of the GPT to be consistant, can
it actually reconstuct a toasted PMBR?  It would be making
assumptions so I would expect to have to use some options
to force it to do this.

> >> Even parsing of the disktab format and a conversion to gpart
> >> backup format for use by gpart restore should not be too hard.
> >>
> >> That would keep the commands available for those that use them
> >> in scripts outside the FreeBSD sources, but would also allow to
> >> remove the kernel interfaces used by those legacy tools.
> >>
> >> I'd be willing to write those emulations of legacy tools, if
> >> there is interest in going that way ...
> > 
> > I would be interested in seeing these.
> > For me gpart does do a lot of things, but it is missing
> > some very low level stuff that is probably should have.
> 
> I read that to mean that gpart is useful for standard setup
> operations, but it lacks commands that might be useful to
> diagnose inconsistent parameters?

Yes, like a disk with a zapped PMBR

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

> On Fri, Jan 26, 2024 at 9:17?AM Rodney W. Grimes <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
> 
> > [ Charset UTF-8 unsupported, converting... ]
> > > On Thu, Jan 25, 2024, 10:49?AM Rodney W. Grimes <
> > > freebsd-...@gndrsh.dnsmgr.net> wrote:
> > >
> > > > > On Thu, Jan 25, 2024, 9:11?AM Ed Maste  wrote:
> > > > >
> > > > > > On Thu, 25 Jan 2024 at 11:00, Rodney W. Grimes
> > > > > >  wrote:
> > > > > > >
> > > > > > > > These will need to be addressed before actually removing any of
> > > > these
> > > > > > > > binaries, of course.
> > > > > > >
> > > > > > > You seem to have missed /rescue.  Now think about that long
> > > > > > > and hard, these tools classified as so important that they
> > > > > > > are part of /rescue.  Again I can not stress enough how often
> > > > > > > I turn to these tools in a repair mode situation.
> > > > > >
> > > > > > I haven't missed rescue, it is included in the work in progress I
> > > > > > mentioned. Note that rescue has included gpart since 2007.
> > > > > >
> > > > >
> > > > > What can fdisk and/or disklabel repair that gpart can't?
> > > >
> > > > As far as I know there is no way in gpart to get to the
> > > > MBR cyl/hd/sec values, you can only get to the LBA start
> > > > and end values:
> > > >
> > >
> > > In the last 20 years when have you needed this?
> >
> > Last week, and probably about every other month for the last
> > 30 years.
> >
> 
> What. specifically did you need to change, for what hardware, etc?

I needed to manually recraft the MBR that had been destroyed,
and doing so with tools I knew would not touch anything but
the MBR.  I know that fdisk well do exactly what I tell it
to and without any fight about the values I put in.  I do
not have that confidence in GPT or any other tool, I suspect
if you tell gpart to write a GPT setup to what appears to
be an empty disk you shall end up with that, an empty
disk as it is going to clear out more than just the MBR/PMBR.

> > >
> > > LBA start/end is all that's relevant these days. The CHS values are
> > > completely ignored
> > > by FreeBSD. We use packet mode in the boot loader since about Pentium
> > 150MHz
> > > or so.
> >
> > WORLD != FreeBSD, please STOP trying to assume that the users OF FreeBSD
> > are ONLY using FreeBSD
> >
> 
> Yes. And the world stopped using them too around that time, give or take 5
> years.

That response doesnt even fit with the assertion.
Or are you saying the world stopped using other OS's?  As that
is about the only thing that seems to fit your assertion.
 
> > > I did have to change these back in the day when we inferred what the CHS
> > > geometry
> > > was from the drive by looking at the MBR's partitions that you knew
> > > (assumed really)
> > > started on a cylinder value. This hasn't mattered in FreeBSD since sos
> > > rewrote ata
> > > the second time. DOS had to do these things because old-school MFM, RLL,
> > etc
> > > disks couldn't return their CHS, so DOS had to enshrine them in the MBR
> > to
> > > get
> > > a hint (or have the drive type BIOS to just know). Since we use LBA
> > > exclusively,
> > > none of this matter to FreeBSD.
> >
> > WORLD != FreeBSD, and weither you like it or not your BIOS and CSM
> > and UEFI are PROPBABLY reading those values and might even do a
> > nice divide by zero for you should you write 0 in them.
> >
> 
> Maybe rather than using all caps you could give a specific example. I've
> not had to help anybody with CHS values in maybe 15 years, and even
> then it was rare. In the prior 10 years to that I went from shipping product
> where CHS had to be right, to shipping product where it didn't matter at
> all on a set of SBCs that were lagging the industry by 5 years.

I have given specifics, you seem to read right pass them, and since
I already see commits falling in I am assuming at this point it has
zero point in confersing with what is a Brick wall.

> 
> Also, UEFI doesn't care: It has no CHS APIs. It's all LBA. The only places
> in the
> standard where 'Cylinder' is mentioned is the (now obsolete) name for
> fields in
> a ATA packet that now mean different parts of the LBA for modern commands.

You yet again seem to ignore what it was I said, U

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

> 
> 
> > On 26. Jan 2024, at 18:02, Rodney W. Grimes  
> > wrote:
> > 
> > -- Start of PGP signed section.
> >> Am 2024-01-25 18:49, schrieb Rodney W. Grimes:
> >>>> On Thu, Jan 25, 2024, 9:11?AM Ed Maste  wrote:
> >>>> 
> >>>>> On Thu, 25 Jan 2024 at 11:00, Rodney W. Grimes
> >>>>>  wrote:
> >>>>>> 
> >>>>>>> These will need to be addressed before actually removing any of these
> >>>>>>> binaries, of course.
> >>>>>> 
> >>>>>> You seem to have missed /rescue.  Now think about that long
> >>>>>> and hard, these tools classified as so important that they
> >>>>>> are part of /rescue.  Again I can not stress enough how often
> >>>>>> I turn to these tools in a repair mode situation.
> >>>>> 
> >>>>> I haven't missed rescue, it is included in the work in progress I
> >>>>> mentioned. Note that rescue has included gpart since 2007.
> >>>>> 
> >>>> 
> >>>> What can fdisk and/or disklabel repair that gpart can't?
> >>> 
> >>> As far as I know there is no way in gpart to get to the
> >>> MBR cyl/hd/sec values, you can only get to the LBA start
> >>> and end values:
> >>> sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
> >>>start 63, size 8388513 (4095 Meg), flag 80 (active)
> >>>beg: cyl 0/ head 1/ sector 1;
> >>>end: cyl 1023/ head 15/ sector 63
> >>> 
> >>> gpart show ada0
> >>> => 63  8388545  ada0  MBR  (4.0G)
> >>>   63  8388513 1  freebsd  [active]  (4.0G)
> >>>  8388576   32- free -  (16K)
> >> 
> >> What are you using cyl/hd/sec values for on a system which runs FreeBSD 
> >> current or on which you would have to use FreeBSD-current in case of a 
> >> repair need? What is the disk hardware on those systems that you still 
> >> need cyl/hd/sec and LBA doesn't work? Serious questions out of 
> >> curiosity.
> > 
> > Your making way to many assuptions, I deal with all sorts of operating
> > systems, not just FreeBSD, and I often many drives from many systems
> > connected to a FreeBSD box doing work to repair various anomolyies.
> > FreeBSD is my swiss army knife of choice for fixing things.
> > 
> > UEFI CMS and BIOS emplemntations can get very confused about a
> > disk if these values are not properly set.  Also make a big
> > mental note that GPT is really just a BIOS type 0x238 MBR
> > entry and if that entry is messed up you are screwed.  I am
> > not sure gpart has anyway to fix the protective MBR other
> > than to rewrite it, probably destroying access to the whole
> > contents of the disk.
> > 
> 
> That does not make too much sense because PMBR is just fake partition 
> covering whole disk (within the data type size limit), with the hope that MBR 
> only tool will see all the space is allocated and will not attempt anything 
> silly. Right after sector 0, in sector 1 there is GPT, followed by GPT table 
> array ? that is, if anything will attempt to write anything other into 
> sectors 1-33 (or depending on how large is your table array), you are in 
> trouble as the primary GPT is destroyed.

*SIGH* Seriously if you think it is so fake NUKE it and see how good your 
system works.

dd if=/dev/zero of=/dev/FOO count=1
GOOD LUCK!

> rgds,
> toomas
> > I am getting rather tired of hearing from people who just simply
> > do not use these tools or can not phantom there are legitamate
> > uses for them.  But it is evident the project has decided to
> > remote them to ports no matter what, so be it, yet another
> > reason for me to use less FreeBSD and more of someone elses
> > product.
> > 
> >> 
> >> Bye,
> >> Alexander.
> >> 
> >> -- 
> >> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> >> http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF
> > -- End of PGP section, PGP failed!
> > 
> > -- 
> > Rod Grimes 
> > rgri...@freebsd.org
-- 
Rod Grimes rgri...@freebsd.org

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On Thu, Jan 25, 2024, 10:49?AM Rodney W. Grimes <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
> 
> > > On Thu, Jan 25, 2024, 9:11?AM Ed Maste  wrote:
> > >
> > > > On Thu, 25 Jan 2024 at 11:00, Rodney W. Grimes
> > > >  wrote:
> > > > >
> > > > > > These will need to be addressed before actually removing any of
> > these
> > > > > > binaries, of course.
> > > > >
> > > > > You seem to have missed /rescue.  Now think about that long
> > > > > and hard, these tools classified as so important that they
> > > > > are part of /rescue.  Again I can not stress enough how often
> > > > > I turn to these tools in a repair mode situation.
> > > >
> > > > I haven't missed rescue, it is included in the work in progress I
> > > > mentioned. Note that rescue has included gpart since 2007.
> > > >
> > >
> > > What can fdisk and/or disklabel repair that gpart can't?
> >
> > As far as I know there is no way in gpart to get to the
> > MBR cyl/hd/sec values, you can only get to the LBA start
> > and end values:
> >
> 
> In the last 20 years when have you needed this?

Last week, and probably about every other month for the last
30 years.

> 
> LBA start/end is all that's relevant these days. The CHS values are
> completely ignored
> by FreeBSD. We use packet mode in the boot loader since about Pentium 150MHz
> or so.

WORLD != FreeBSD, please STOP trying to assume that the users OF FreeBSD
are ONLY using FreeBSD
> 
> I did have to change these back in the day when we inferred what the CHS
> geometry
> was from the drive by looking at the MBR's partitions that you knew
> (assumed really)
> started on a cylinder value. This hasn't mattered in FreeBSD since sos
> rewrote ata
> the second time. DOS had to do these things because old-school MFM, RLL, etc
> disks couldn't return their CHS, so DOS had to enshrine them in the MBR to
> get
> a hint (or have the drive type BIOS to just know). Since we use LBA
> exclusively,
> none of this matter to FreeBSD.

WORLD != FreeBSD, and weither you like it or not your BIOS and CSM
and UEFI are PROPBABLY reading those values and might even do a
nice divide by zero for you should you write 0 in them.

> 
> I've certainly never needed to tweak these in single user mode on an
> emergency
> basis. Why? Because you can't get to single user mode because the kernel
> won't
> even load if you have these wrong. So either you are booting some rescue
> disk
> to fix that (in which case you can craft it for your special environment).,
> or you are

rescue disk == any FreeBSD install media from the last 20 years.
your REALLY stuck in a small box Warner, please think outside
that box.   You keep repeating FreeBSD FreeBSD FreeBSD, I have to
inform you many of us who USE FreeBSD also USE other stuff, but
we prefer to have FreeBSD be our goto system for this type of work.

> creating a special thing in multi-user, so you can install  For all these
> use cases, fdisk
> as a port is fine.

I really do not want to have to maintain my own distribution.

> 
> sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
> > start 63, size 8388513 (4095 Meg), flag 80 (active)
> > beg: cyl 0/ head 1/ sector 1;
> > end: cyl 1023/ head 15/ sector 63
> >
> > gpart show ada0
> > => 63  8388545  ada0  MBR  (4.0G)
> >63  8388513 1  freebsd  [active]  (4.0G)
> >   8388576   32- free -  (16K)
> >
> > Now I have learned that gpart backup/restore CAN get me
> > at least basic bsdlabel -e function, but again it has
> > no access to all the stuff stored that showsup with
> > bsdlabel -A.  Which this is now the third time I have
> > asked "how do I do bsdlabel -A -e with gpart"?  One
> > person at least answered that with:
> > gpart backup GEOM >backup
> > vi backup
> > gpart restore GEOM
> >
> 
> OK Let's look at these extra fields:
> 
> # /dev/md0:
> type: unknown
> disk: amnesiac
> label:
> flags:
> bytes/sector: 512
> sectors/track: 63
> tracks/cylinder: 255
> sectors/cylinder: 16065
> cylinders: 130
> sectors/unit: 2097152
> rpm: 3600
> interleave: 1
> trackskew: 0
> cylinderskew: 0
> headswitch: 0 # milliseconds
> track-to-track seek: 0 # milliseconds
> drivedata: 0
> 
> type isn't used at all in FreeBSD.
> disk is for /etc/disktab, something we've not really needed since FreeBSD 3
> or so.
> label can be set with gpart add/modify -l.
> I've never used flags

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

> Am 25.01.24 um 16:38 schrieb Ed Maste:
> > On Wed, 24 Jan 2024 at 12:30, Warner Losh  wrote:
> >>
> >> Those are the only users in the tree, but not for long :)
> > 
> > I have some reviews open to remove some old fdisk / diskabel /
> > bsdlabel invocations from the tree.
> > 
> > With those applied, for fdisk I see the following references
> > (excluding sbin/fdisk/* and comments, old examples, etc.):
> > 
> > contrib/netbsd-tests/sbin/gpt/t_gpt.sh
> 
> This test contains NetBSD specific details and will not run
> on FreeBSD.
> 
> > tests/sys/cddl/zfs/bin/zpool_smi.ksh
> 
> More than 99% of the tests in tests/sys/cddl/zfs are skipped,
> including this one, which relies on commands that do not exist
> on FreeBSD.
> 
> > For bsdlabel / disklabel:
> > 
> > sbin/growfs/tests/legacy_test.pl
> 
> This test could easily be changed to use gpart.
> 
> > tools/regression/msdosfs/msdosfstest-2.sh
> 
> Trivially fixed.
> 
> > tools/regression/tmpfs/t_vnd
> 
> Trivially fixed.
> 
> > tools/tools/nanobsd/legacy.sh
> 
> Does already use gpart and could easily be fixed.
> 
> > contrib/netbsd-tests/kernel/t_umount.sh
> > contrib/netbsd-tests/kernel/t_umountstress.sh
> > contrib/netbsd-tests/sbin/gpt/t_gpt.sh
> 
> These are unused and won't run without modification.
> 
> > sbin/newfs/runtest00.sh
> > sbin/newfs/runtest01.sh
> 
> Unused and do not run on a current version of FreeBSD.
> 
> > These will need to be addressed before actually removing any of these
> > binaries, of course.
> 
> I could fix those that are actually usable and installed on
> a current FreeBSD system within at most 1 hour.
> 
> >> I wouldn't object to making these ports, but both these programs use 
> >> 'sekret'
> >> bits from the kernel that might not remain exposed as we clean things up.
> >> Though the IOCTLs they do (or used to do) may no longer be relevant. It's
> >> been so long that I've forgotten
> > 
> > If we eventually stop exporting those kernel interfaces the tools
> > would fail anyway, so IMO we can keep providing the kernel interfaces
> > along with the headers etc, and keep building from source until/unless
> > we drop support altogether.
> 
> The bsdlabel/disklabel/fdisk programs could be rewritten using
> gpart without too much effort, at least for the use cases that

That would be wonderful.  Even just getting it to spit out
the FULL MBR values that are in a protective 0x238 MBR
would go along way to diagnose some corrupt GPT disks.

> have not become obsolete (e.g. CHS specifications) and only for
> use in scripts (i.e. no fdisk interactive edit mode).

You are fooling yourself if you think an MBR and CHS values
are obsolete.  GPT *IS* a type 0x238 MBR and see how many
BIOSes you can crash by writting garbage (Especially 0x0)
to the CHS values.  That MBR must have proper values, and
you cant just ignore that they exist.

> 
> Even parsing of the disktab format and a conversion to gpart
> backup format for use by gpart restore should not be too hard.
> 
> That would keep the commands available for those that use them
> in scripts outside the FreeBSD sources, but would also allow to
> remove the kernel interfaces used by those legacy tools.
> 
> I'd be willing to write those emulations of legacy tools, if
> there is interest in going that way ...

I would be interested in seeing these.
For me gpart does do a lot of things, but it is missing
some very low level stuff that is probably should have.

> Regards, STefan
-- 
Rod Grimes rgri...@freebsd.org

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

-- Start of PGP signed section.
> Am 2024-01-25 18:49, schrieb Rodney W. Grimes:
> >> On Thu, Jan 25, 2024, 9:11?AM Ed Maste  wrote:
> >> 
> >> > On Thu, 25 Jan 2024 at 11:00, Rodney W. Grimes
> >> >  wrote:
> >> > >
> >> > > > These will need to be addressed before actually removing any of these
> >> > > > binaries, of course.
> >> > >
> >> > > You seem to have missed /rescue.  Now think about that long
> >> > > and hard, these tools classified as so important that they
> >> > > are part of /rescue.  Again I can not stress enough how often
> >> > > I turn to these tools in a repair mode situation.
> >> >
> >> > I haven't missed rescue, it is included in the work in progress I
> >> > mentioned. Note that rescue has included gpart since 2007.
> >> >
> >> 
> >> What can fdisk and/or disklabel repair that gpart can't?
> > 
> > As far as I know there is no way in gpart to get to the
> > MBR cyl/hd/sec values, you can only get to the LBA start
> > and end values:
> > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
> > start 63, size 8388513 (4095 Meg), flag 80 (active)
> > beg: cyl 0/ head 1/ sector 1;
> > end: cyl 1023/ head 15/ sector 63
> > 
> > gpart show ada0
> > => 63  8388545  ada0  MBR  (4.0G)
> >63  8388513 1  freebsd  [active]  (4.0G)
> >   8388576   32- free -  (16K)
> 
> What are you using cyl/hd/sec values for on a system which runs FreeBSD 
> current or on which you would have to use FreeBSD-current in case of a 
> repair need? What is the disk hardware on those systems that you still 
> need cyl/hd/sec and LBA doesn't work? Serious questions out of 
> curiosity.

Your making way to many assuptions, I deal with all sorts of operating
systems, not just FreeBSD, and I often many drives from many systems
connected to a FreeBSD box doing work to repair various anomolyies.
FreeBSD is my swiss army knife of choice for fixing things.

UEFI CMS and BIOS emplemntations can get very confused about a
disk if these values are not properly set.  Also make a big
mental note that GPT is really just a BIOS type 0x238 MBR
entry and if that entry is messed up you are screwed.  I am
not sure gpart has anyway to fix the protective MBR other
than to rewrite it, probably destroying access to the whole
contents of the disk.

I am getting rather tired of hearing from people who just simply
do not use these tools or can not phantom there are legitamate
uses for them.  But it is evident the project has decided to
remote them to ports no matter what, so be it, yet another
reason for me to use less FreeBSD and more of someone elses
product.

> 
> Bye,
> Alexander.
> 
> -- 
> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF
-- End of PGP section, PGP failed!

-- 
Rod Grimes rgri...@freebsd.org

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

> On Thu, Jan 25, 2024, 9:11?AM Ed Maste  wrote:
> 
> > On Thu, 25 Jan 2024 at 11:00, Rodney W. Grimes
> >  wrote:
> > >
> > > > These will need to be addressed before actually removing any of these
> > > > binaries, of course.
> > >
> > > You seem to have missed /rescue.  Now think about that long
> > > and hard, these tools classified as so important that they
> > > are part of /rescue.  Again I can not stress enough how often
> > > I turn to these tools in a repair mode situation.
> >
> > I haven't missed rescue, it is included in the work in progress I
> > mentioned. Note that rescue has included gpart since 2007.
> >
> 
> What can fdisk and/or disklabel repair that gpart can't?

As far as I know there is no way in gpart to get to the
MBR cyl/hd/sec values, you can only get to the LBA start
and end values:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 63, size 8388513 (4095 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 1023/ head 15/ sector 63

gpart show ada0
=> 63  8388545  ada0  MBR  (4.0G)
   63  8388513 1  freebsd  [active]  (4.0G)
  8388576   32- free -  (16K)

Now I have learned that gpart backup/restore CAN get me
at least basic bsdlabel -e function, but again it has
no access to all the stuff stored that showsup with
bsdlabel -A.  Which this is now the third time I have
asked "how do I do bsdlabel -A -e with gpart"?  One
person at least answered that with:
gpart backup GEOM >backup
vi backup
gpart restore GEOM

Now I just have to rewrite my bsdlabel GEOM >backup
files to be be gpart GEOM >backup files (I have precanned
sets of bsdlabel files I use to do bsdlabel -w GEOM with.

> Warner
-- 
Rod Grimes rgri...@freebsd.org

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

> On Wed, 24 Jan 2024 at 12:30, Warner Losh  wrote:
> >
> > Those are the only users in the tree, but not for long :)
> 
> I have some reviews open to remove some old fdisk / diskabel /
> bsdlabel invocations from the tree.
> 
> With those applied, for fdisk I see the following references
> (excluding sbin/fdisk/* and comments, old examples, etc.):
> 
> contrib/netbsd-tests/sbin/gpt/t_gpt.sh
> tests/sys/cddl/zfs/bin/zpool_smi.ksh
> 
> For bsdlabel / disklabel:
> 
> sbin/growfs/tests/legacy_test.pl
> tools/regression/msdosfs/msdosfstest-2.sh
> tools/regression/tmpfs/t_vnd
> tools/tools/nanobsd/legacy.sh
> contrib/netbsd-tests/kernel/t_umount.sh
> contrib/netbsd-tests/kernel/t_umountstress.sh
> contrib/netbsd-tests/sbin/gpt/t_gpt.sh
> sbin/newfs/runtest00.sh
> sbin/newfs/runtest01.sh
> 
> These will need to be addressed before actually removing any of these
> binaries, of course.

You seem to have missed /rescue.  Now think about that long
and hard, these tools classified as so important that they
are part of /rescue.  Again I can not stress enough how often
I turn to these tools in a repair mode situation.  

> > I wouldn't object to making these ports, but both these programs use 
> > 'sekret'
> > bits from the kernel that might not remain exposed as we clean things up.
> > Though the IOCTLs they do (or used to do) may no longer be relevant. It's
> > been so long that I've forgotten
> 
> If we eventually stop exporting those kernel interfaces the tools
> would fail anyway, so IMO we can keep providing the kernel interfaces
> along with the headers etc, and keep building from source until/unless
> we drop support altogether.
> 
> 

-- 
Rod Grimes rgri...@freebsd.org

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

> I would agree personally, to moving to ports (eg ports/sysutils) with
> a DEPRECATED in the DESCR or something, or better yet a Make
> invokation event to say "superceded, here is how to proceed against
> advice") or something.

They are totally useless as ports when your booted from install
media and working from a standalone shell.  These are the exact
times you want things like fdisk and bsdlabel so you can figure
out wtf is going on, and bsdinstall is NOT gona help you.

I know there are a boat load of people that have built there
own installers for VM's and stuff, running UFS and I bet you
they are using MBR disks too.  PLEASE do not kick these tiny
little and very usable and pretty univeral (as far as I know
ALL BSD's have fdisk and bsdlabel/disklabel) tools out of
the base system. 

The world is NOT 2TB nvme drives with GPT, EFI and ZFS,
yours might not be, but I am pretty certain I am not
alone in this other world.

> -G
> 
> On Thu, Jan 25, 2024 at 3:30?AM Warner Losh  wrote:
> >
> > On Wed, Jan 24, 2024 at 8:45?AM Ed Maste  wrote:
> >>
> >> MBR (PC BIOS) partition tables were historically maintained with
> >> fdisk(8), but gpart(8) has long been the preferred method for working
> >> with partition tables of all types. fdisk has been declared as
> >> obsolete in the man page since 2015. Similarly BSD disklabels were
> >> historically maintained with bsdlabel. It does not yet have a
> >> deprecation notice - I have proposed a man page addition in
> >> https://reviews.freebsd.org/D43563.
> >>
> >> I would like to disconnect these from the build, and subsequently
> >> remove them. This is prompted by a recent bsdlabel bug report which
> >> uncovered a longstanding buffer overflow in that tool. Effort is much
> >> better focused on contemporary, maintained tools rather than
> >> investigating issues in deprecated ones. Removing these tools would
> >> happen in FreeBSD 15 only (no change in 14 or 13).
> >>
> >> Code review to disconnect fdisk: https://reviews.freebsd.org/D43575
> >>
> >> Note that this effort is limited to these maintenance tools only -
> >> there is no change to kernel or gpart support for MBR or BSD
> >> disklablel partitioning. That said, MBR partitioning and BSD
> >> disklabels are best considered legacy formats and should be avoided
> >> for new installations, if possible.
> >>
> >> If anyone is using fdisk and/or bsdlabel rather than gpart I would
> >> appreciate knowing what is preventing you from using the contemporary
> >> tools.
> >
> >
> > nanobsd's legacy.sh still is using disklabel in two spots.
> >
> > But one is to just do gpart create -s bsd and the other is to display it. 
> > Easy
> > to fix, but even easier to delete legacy.sh entirely. It's not really 
> > needed any
> > more and was a product of CHS addressing... Now that we use LBA, it's
> > better to use the new embedded ones. Even at $WORK where we kinda
> > use legacy, we replace the partitioning stuff with our own custom thing...
> >
> > Those are the only users in the tree, but not for long :)
> >
> > fdisk was good, but somewhere around the CHS -> LBA transition things
> > got weird with it, and for really big disks there were reports of issues 
> > that
> > I could never encounter when I set out to fix them... Most likely due to a
> > mismatch in the CHS data and the LBA data being recorded in the MBR.
> > The in-kernel gpart copes so much better.
> >
> > I wouldn't object to making these ports, but both these programs use 
> > 'sekret'
> > bits from the kernel that might not remain exposed as we clean things up.
> > Though the IOCTLs they do (or used to do) may no longer be relevant. It's
> > been so long that I've forgotten
> >
> > Warner
-- 
Rod Grimes rgri...@freebsd.org

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

> On Wed, Jan 24, 2024 at 8:45?AM Ed Maste  wrote:
> 
> > MBR (PC BIOS) partition tables were historically maintained with
> > fdisk(8), but gpart(8) has long been the preferred method for working
> > with partition tables of all types. fdisk has been declared as
> > obsolete in the man page since 2015. Similarly BSD disklabels were
> > historically maintained with bsdlabel. It does not yet have a
> > deprecation notice - I have proposed a man page addition in
> > https://reviews.freebsd.org/D43563.

man page additions are not going to reach the people who may be
using this.  This should be a gonein(15) added to the binary.
I also suspect that all of the people doing ufs installs
are doing so via bsdlabel, not gpart.

> >
> > I would like to disconnect these from the build, and subsequently
> > remove them. This is prompted by a recent bsdlabel bug report which
> > uncovered a longstanding buffer overflow in that tool. Effort is much
> > better focused on contemporary, maintained tools rather than
> > investigating issues in deprecated ones. Removing these tools would
> > happen in FreeBSD 15 only (no change in 14 or 13).
> >
> > Code review to disconnect fdisk: https://reviews.freebsd.org/D43575

How can you do bsdlabel -A -e /dev/foo with gpart?  As far as I know
that functionality never made it to gpart, neither the -A or -e.

> >
> > Note that this effort is limited to these maintenance tools only -
> > there is no change to kernel or gpart support for MBR or BSD
> > disklablel partitioning. That said, MBR partitioning and BSD
> > disklabels are best considered legacy formats and should be avoided
> > for new installations, if possible.
> >
> > If anyone is using fdisk and/or bsdlabel rather than gpart I would
> > appreciate knowing what is preventing you from using the contemporary
> > tools.

My prototype files that are read by bsdlabel -R as far as I know
can not be processed by gpart.
fdisk I can probably get away from, but thats a working binary
accross a lot of platforms which do not have gpart.

> >
> 
> nanobsd's legacy.sh still is using disklabel in two spots.
> 
> But one is to just do gpart create -s bsd and the other is to display it.
> Easy
> to fix, but even easier to delete legacy.sh entirely. It's not really
> needed any
> more and was a product of CHS addressing... Now that we use LBA, it's
> better to use the new embedded ones. Even at $WORK where we kinda
> use legacy, we replace the partitioning stuff with our own custom thing...
> 
> Those are the only users in the tree, but not for long :)
> 
> fdisk was good, but somewhere around the CHS -> LBA transition things
> got weird with it, and for really big disks there were reports of issues
> that
> I could never encounter when I set out to fix them... Most likely due to a
> mismatch in the CHS data and the LBA data being recorded in the MBR.
> The in-kernel gpart copes so much better.
> 
> I wouldn't object to making these ports, but both these programs use
> 'sekret'
> bits from the kernel that might not remain exposed as we clean things up.
> Though the IOCTLs they do (or used to do) may no longer be relevant. It's
> been so long that I've forgotten
> 
> Warner

-- 
Rod Grimes rgri...@freebsd.org

Re: noatime on ufs2

[Rodney W. Grimes]

> Am 2024-01-10 22:49, schrieb Mark Millard:
> 
> > I never use atime, always noatime, for UFS. That said, I'd never 
> > propose
> > changing the long standing defaults for commands and calls. I'd avoid:
> 
> [good points I fully agree on]
> 
> There's one possibility which nobody talked about yet... changing the 
> default to noatime at install time in fstab / zfs set.

Perhaps you should take a closer look at what bsdinstall does
when it creates a zfs install pool and boot environment, you
might just find that noatime is already set everywhere but
on /var/mail:

/usr/libexec/bsdinstall/zfsboot:: ${ZFSBOOT_POOL_CREATE_OPTIONS:=-O 
compress=lz4 -O atime=off}
/usr/libexec/bsdinstall/zfsboot:/var/mail   atime=on

> 
> I fully agree to not violate POLA by changing the default to noatime in 
> any FS. I always set noatime everywhere on systems I take care about, no 
> exceptions (any user visible mail is handled via maildir/IMAP, not 
> mbox). I haven't made up my mind if it would be a good idea to change 
> bsdinstall to set noatime (after asking the user about it, and later 
> maybe offer  the possibility to use relatime in case it gets 
> implemented). I think it is at least worthwile to discuss this 
> possibility (including what the default setting of bsdinstall should be 
> for this option).

Little late... iirc its been that way since day one of zfs support
in bsdinstall.

> -- 
> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF
-- 
Rod Grimes rgri...@freebsd.org

Re: noatime on ufs2

[Rodney W. Grimes]

> Olivier Certner  wrote on
> Date: Wed, 10 Jan 2024 10:01:48 UTC :
> 
> > What I'm saying is that, based on others' input so far, my own (long, even 
> > if not as long as yours) experience and some late reflection, is that 
> > "noatime" should be the default (everywhere, all mounts and all FSes), and 
> > that working on "relatime" won't make any real difference for most users 
> > (IOW, I think that developing "relatime" is a bad idea *in general*). And I 
> > think this is a sufficiently reasonable conclusion that anyone with the 
> > same inputs would conclude the same. So, if it's not the case, I would be 
> > interested in knowing why, ideally.
> 
> I never use atime, always noatime, for UFS. That said, I'd never propose
> changing the long standing defaults for commands and calls. I'd avoid:

.. Very well said Mark ...

Please folks stop tweaking defaults, especially long standing ones,
if you feel the need for noatime, set it, by all means, I have been
for 30 years

.. what Mark said very well removed for brevity ...

> Mark Millard
> marklmi at yahoo.com
-- 
Rod Grimes rgri...@freebsd.org

Re: Proposal: Disable compression of newsyslog by default

[Rodney W. Grimes]

> On 2023-12-23 10:17, Ceri Davies wrote:
> > I really don?t like the idea of adding flags that make the program ignore a 
> > config file.  I also think this is premature until ZFS installs are default 
> > on all architectures.
> > 
> > However, if you must (and I see you have) change this, please don?t call 
> > the option ?legacy? as we wish to deprecate other behaviour in the future 
> > or add additional compression algorithms.
> > Perhaps it could be called ?useconfig? or something that describes what it 
> > actually does.
> > 
> > Also, could you please update the manage commit to note the change in 15.0 
> > because not everyone reads commit logs and we may end up violating the PoLA 
> > twice otherwise.
> 
> Thank you for sharing your thoughts on the commit. I want to clarify 
> that my recent change does not alter the existing behavior of the code. 
> In fact, the current legacy test cases still pass successfully. The 
> modification I introduced primarily adds the option to override the 
> default compression setting.
> 
> Regarding your suggestion to rename the ?legacy? option, the term was 
> chosen to reflect its purpose ? to preserve historical behavior while 
> acknowledging that it may be phased out in the future. Adding new 
> letters to the configuration format isn't scalable and lacks 
> flexibility.

The words "new, old, legacy, etc" are poor adjectives as they are
time variant.  Use of "legacy" isn't scalable and lacks flexibility too,
what do I call the next legacy move?  Legacy-legacy?  Please try
to use time invariant nouns when picking option names.

> Especially, consider an application that install their own 
> newsyslog.conf.d configuration, in which case the configuration is 
> overwritten during upgrades, or has to have some way to solve merge 
> conflicts, should they decide to add new log files, etc.  There's no 
> practical reason for users to adhere to a specific compression method 
> that the application writer told them, because the administrator have 
> better idea about what compressor is more suitable for their situation.
> 
> I'll add a note to the release notes later, but rest assured that there 
> is no PoLA violation yet.

Actually I think there is.  When admin A comes along and turns on
this global "do not compress" flag in /etc/crontab's invokation of
newsyslog then some time later admin B comes along and tries to fix
a full /var/log problem by working on /etc/newsyslogd.conf he pulls
his few grey remaining hairs out before he finds this "tweak" to
ignore what the config file is saying!  This POLA shall long outlive
your entry in the release notes for 15 and exist for ever.

> Cheers,

-- 
Rod Grimes rgri...@freebsd.org

Re: Proposal: Disable compression of newsyslog by default

[Rodney W. Grimes]

> On 2023-12-23 06:52, Konstantin Belousov wrote:
> > On Fri, Dec 22, 2023 at 11:18:23PM -0800, Xin Li wrote:
> >> Hi,
> >>
> >> Inspired by D42961, I propose that we move forward with disabling the
> >> compression by default in newsyslog, as implemented in
> >> https://reviews.freebsd.org/D43169
> >>
> >> Historically, newsyslog has compressed rotated log files to save disk 
> >> space.
> >> This approach was valuable in the early days where storage space was
> >> limited.  However, the landscape has changed significantly.  Modern file
> >> systems, such as ZFS, now offer native compression capabilities.
> >> Additionally, the widespread availability of larger hard drives has
> >> diminished the necessity for additional compression.  Notably, the need to
> >> decompress log files for pattern searches poses a significant 
> >> inconvenience,
> >> further questioning the utility of this legacy feature.
> >>
> >> In commit 906748d208d3, flags J, X, Y, Z can now indicate that a log file 
> >> is
> >> eligible for compression rather than directly enforcing it. It allows for a
> >> more flexible approach, wherein the actual compression method can be set to
> >> "none" or specified as one among bzip2, gzip, xz, or zstd.
> >>
> >> Therefore I would propose that we change the default compression setting to
> >> "none" in FreeBSD 15.0.  This change reflects our adaptation to the 
> >> evolving
> >> technological environment and user needs.  It also aligns with the broader
> >> initiative to modernize our systems while maintaining flexibility and
> >> efficiency.
> >>
> >> I look forward to your thoughts and feedback on this proposal.
> > 
> > This is strange change at best.  I have no opinion about the disabling
> > of compression of the rotated logs by default, but we already have knobs
> > to do that.  Adding a knob that disables (or enables) other knobs to work
> > is weird.

And counter intuitive!

> > If you want to change the compression, update the default configuration 
> > file.
> 
> The primary issue with simply updating the default configuration file is 
> the increased workload it imposes during system upgrades. Since the 
> compression method flag is a part of newsyslog.conf, standard conflict 
> resolution tools like diff3 struggle to automatically resolve changes 
> involving these flags without manual intervention. This situation 
> necessitates that users manually reconcile their configuration with 
> every update to newsyslog.conf, even for minor alterations like 
> switching the default compression method.
> 
> Therefore, the proposal isn't about adding another knob within 
> newsyslog.conf. Rather, it's about introducing a command-line option for 
> newsyslog (to be used in /etc/crontab) that specifies the preferred 
> compression method, or the choice not to compress at all. This approach 
> is more self-contained compared to modifying each line in 
> newsyslog.conf. It offers a simpler, more straightforward solution for 
> administrators to manage their compression settings, reducing the 
> administrative burden during upgrades.

So now I edit /etc/crontab to change the behavior of newsyslog?
Thats VERY counter to how things "should be."  I am sorry, but
this change is just yet another "Oh my god, the defaults dont
work for me so I am gona force my idea of what the defaults should
be on everone else."

And you just pushed the merge conflict to another file, one that
is not even related to newsyslog, you do get your arguement doesnt
hold water?  A change in /etc/newsyslog.conf or /etc/crontab BOTH
lead to the fact people are going to have to merge things.

Now we are goning go crazy trying to figure out why my logs are
not compressed and finally gona end up finding this flag in
/etc/crontab that is causing newsyslog to ignore what I put
in its proper config file???  Again, very counter intuitive.

> 
> I hope this clarifies the rationale behind the proposed changes and 
> their potential benefits.

I see only change for the sake of change and no real benefit, just
another hack cause someone is to weak to deal with locally modifing
configurations and dealing with the maintenance.  Do understand
every single change to any of this configuration stuff creates
burden for someone, I now have to add yet another file to my
maintanance to undo this change to /etc/crontab.  And I have to
special case that as "only apply if version >= 15".


-- 
Rod Grimes rgri...@freebsd.org

Re: FreeBSD 14.0-BETA5 Now Available

[Rodney W. Grimes]

> On Mon, 23 Oct 2023 at 11:06, Rodney W. Grimes
>  wrote:
> >
> > This is a regression of forms... I have been using ventoy to boot FreeBSD
> > since 12 or so and this is the first I have heard of a failure to boot
> > FreeBSD with Ventoy, so my ask is, what changed in FreeBSD that broke
> > it booting in Ventoy?
> 
> At a minimum FreeBSD 14 has a different KBI and the 13.x kernel
> modules provided by older Ventoy won't work on 14.0.

How does the KBI even entery into the picture?

What "modules" are being provied by Ventoy, I do not know
of any FreeBSD modules being provided by Ventoy, it is an
EFI shim that loads the FreeBSD loader, and the loader
does all the work.

Again, perhaps I do not see this as I am only using ventoy
in EFI mode.


-- 
Rod Grimes rgri...@freebsd.org

Re: FreeBSD 14.0-BETA5 Now Available

[Rodney W. Grimes]

> On Mon, 16 Oct 2023 at 13:46, Gy?rgy P?sztor  
> wrote:
> >
> >> I am interested in looking for a way to make Ventoy support more
> >> reliable, but that will not happen for 14.0.
> >
> > Is it depending on Ventoy?
> 
> Yes, Ventoy needs to be updated for newer FreeBSD releases. For more info, 
> see:
> https://forums.ventoy.net/showthread.php?tid=1805
> https://github.com/ventoy/Ventoy/issues/7#issuecomment-1493237303

This is a regression of forms... I have been using ventoy to boot FreeBSD
since 12 or so and this is the first I have heard of a failure to boot
FreeBSD with Ventoy, so my ask is, what changed in FreeBSD that broke
it booting in Ventoy?   Note I do use Ventoy in EFI mode, perhaps that
is why I have no issues?

-- 
Rod Grimes rgri...@freebsd.org

Re: Surprise null root password

[Rodney W. Grimes]

> It turns out all seven hosts in my cluster report
> a null password for root in /usr/src/etc/master.passwd:
> root::0:0::0:0:Charlie &:/root:/bin/sh
> 
> Is that intentional?

No, but I suspect your build/update procedures are infact telling
the system to do this.  Someone else pointed out etcupdate, which
iirc you are using, with the update of "thiers all" infact would
overwrite /etc/master.passwd.  I do not know that etcupdate has
the smarts to know that if it overwrites /etc/master.passwd it
needs to run a pwd_mkdb -p /etc/master.passwd.  etcupdate infact
does have the smarts to run a pwd_mkdb.

Hum, it also has some special casing of PREWORLD_FILES, which 
is /etc/master.passwd and etc/group.  Perhaps something in that
process went wrong.

-- 
Rod Grimes rgri...@freebsd.org

Re: Surprise null root password

[Rodney W. Grimes]

> On 26 May 2023, at 12:35, bob prohaska wrote:
> 
> > While going through normal security email from a Pi2
> > running -current I was disturbed to find:
> >
> > Checking for passwordless accounts:
> > root::0:0::0:0:Charlie &:/root:/bin/sh
> >
> > The machine had locked up on a -j4 buildworld since
> > sending the mail, so it was taken off the net, power
> > cycled and started single-user.
> >
> > Sure enough, /etc/master.passwd contained a
> > null password for root, but the last modification
> > to the file was two weeks ago according to ls -l.
> >
> > Stranger still, when fsck'd and brought up multi-user,
> > the normal password was still honored and a null
> > password rejected for both regular and root account.
> >
> > AFAIK, /etc/master.passwd is _the_ password repository,
> > but clearly I'm wrong.
> 
> /etc/master.passwd is the source, but the operational database
> is /etc/spwd.db.  You should check the date on it as well.
> You can rebuild it with ?pwd_mkdb -p /etc/master.passwd?.

BUT if infact /etc/master.passwd has been clobbered, BUT
/etc/spwd.db still contains the correct data you would not
want to do the above, as that would put the null passwd
for root into /etc/*pwd.db, and/or possible other accounts.

I do not know of a utility that can dump /etc/*pwd.db and
recreate a master.passwd file, anyone?

>   Mike
> 
> > If somebody can tell me what's going on and what to
> > check for before placing the machine back on line
> > it would be much appreciated.
> >
> > Thanks for reading,
> >
> > bob prohaska
> 
> 

-- 
Rod Grimes rgri...@freebsd.org

Re: git: c16e08e5f324 - main - stand/efi: Retire i386 support

[Rodney W. Grimes]

> On Thu, 11 May 2023 23:08:30 +0200
> Yuri  wrote:
> 
> > Warner Losh wrote:
> > > 
> > > 
> > > On Thu, May 11, 2023, 2:50 PM Rodney W. Grimes
> > > mailto:freebsd-...@gndrsh.dnsmgr.net>>
> > > wrote:
> > > 
> > > > On Thu, May 11, 2023, 2:16 PM Yuri  > > <mailto:y...@aetern.org>> wrote:
> > > >
> > > > > Warner Losh wrote:
> > > > > > The branch main has been updated by imp:
> > > > > >
> > > > > > URL:
> > > > >
> > > 
> > > https://cgit.FreeBSD.org/src/commit/?id=c16e08e5f324aa119c85e10eaabacbd2abdb40e0
> > >  
> > > <https://cgit.FreeBSD.org/src/commit/?id=c16e08e5f324aa119c85e10eaabacbd2abdb40e0>
> > > > > >
> > > > > > commit c16e08e5f324aa119c85e10eaabacbd2abdb40e0
> > > > > > Author:? ? ?Warner Losh 
> > > > > > AuthorDate: 2023-05-11 20:04:12 +
> > > > > > Commit:? ? ?Warner Losh 
> > > > > > CommitDate: 2023-05-11 20:06:03 +
> > > > > >
> > > > > >? ? ?stand/efi: Retire i386 support
> > > > > >
> > > > > >? ? ?Remove the i386 ifdefs and files. It never worked.
> > > > > >
> > > > > >? ? ?Sponsored by:? ? ? ? ? ?Netflix
> > > > > >? ? ?Reviewed by:? ? ? ? ? ? manu, tsoome, kevans
> > > > > >? ? ?Differential Revision:? https://reviews.freebsd.org/D40012
> > > <https://reviews.freebsd.org/D40012>
> > > > >
> > > > > As this question seems to be asked a lot on the forums, does
> > > this mean
> > > > > we will never support the 32bit efi booting 64bit OS?
> > > > >
> > > >
> > > > Yes. It means we've given up on that. Such environments are rare 
> > > these
> > > > days, as far as I know, so unless someone shows up with something 
> > > that
> > > > works perfectly with a qemu testing recipe that we can roll it
> > > into out
> > > > test bed. Plus some kind of info on real hardware that does this
> > > that's
> > > > popular enough to justify inclusion.
> > > 
> > > I have only ever seen 1 implementation of x86 32bit efi, and it was
> > > such a pile of turds I just scrapped the machine.
> > > 
> > > 
> > > That was my experience as well, so I biased my action towards just
> > > removing it. If it turns out my experience was somehow atypical and
> > > these are popular and very much robust, I'm open to learning about it.
> > 
> > I just noticed that it was asked several times in the last few months
> > trying to use FreeBSD on not-so-modern and rather exotic hardware; I
> > don't think we really need that support, but I simply wasn't aware of
> > efi32 status before this commit, hence I asked :)
> 
> Just a FYI.
> 
> A subscriber (not me) tried ASUS EeeBook X205TA (manufactured "2015-04")
> through Mar.18, 2021 to Apr.13, 2021 without luck on freebsd-usrs-jp ML
> (in Japanese, started from [1], [2] for April).
> 
> Atom CPU Z3735F @1.33GHz, 2GB RAM

That is a 4 core 64 bit CPU, it most likely has a 64bit efi
implementation.

> Shipped with "Windows 8.1 with Bing (32bit)" installed.

Probably a good choice to use a 32 bit OS on a machine
with only 2GB as there is no need for a 64 bit pointer.
This pretty much applies to any machine with 4GB or
less of memory 

> 
> [1]
> https://lists.freebsd.org/pipermail/freebsd-users-jp/2021-March/001728.html
> 
> [2]
> https://lists.freebsd.org/pipermail/freebsd-users-jp/2021-April/001746.html
> 
> 
> -- 
> Tomoaki AOKI]
> 
> 

-- 
Rod Grimes rgri...@freebsd.org

Re: git: c16e08e5f324 - main - stand/efi: Retire i386 support

[Rodney W. Grimes]

> On Thu, May 11, 2023, 2:16 PM Yuri  wrote:
> 
> > Warner Losh wrote:
> > > The branch main has been updated by imp:
> > >
> > > URL:
> > https://cgit.FreeBSD.org/src/commit/?id=c16e08e5f324aa119c85e10eaabacbd2abdb40e0
> > >
> > > commit c16e08e5f324aa119c85e10eaabacbd2abdb40e0
> > > Author: Warner Losh 
> > > AuthorDate: 2023-05-11 20:04:12 +
> > > Commit: Warner Losh 
> > > CommitDate: 2023-05-11 20:06:03 +
> > >
> > > stand/efi: Retire i386 support
> > >
> > > Remove the i386 ifdefs and files. It never worked.
> > >
> > > Sponsored by:   Netflix
> > > Reviewed by:manu, tsoome, kevans
> > > Differential Revision:  https://reviews.freebsd.org/D40012
> >
> > As this question seems to be asked a lot on the forums, does this mean
> > we will never support the 32bit efi booting 64bit OS?
> >
> 
> Yes. It means we've given up on that. Such environments are rare these
> days, as far as I know, so unless someone shows up with something that
> works perfectly with a qemu testing recipe that we can roll it into out
> test bed. Plus some kind of info on real hardware that does this that's
> popular enough to justify inclusion.

I have only ever seen 1 implementation of x86 32bit efi, and it was
such a pile of turds I just scrapped the machine.

> Warner

-- 
Rod Grimes rgri...@freebsd.org

Re: textdumps are too slow

[Rodney W. Grimes]

> On Fri, Apr 7, 2023 at 12:08?PM Warner Losh  wrote:
> >
> >
> >
> > On Fri, Apr 7, 2023 at 6:20?AM Poul-Henning Kamp  
> > wrote:
> >>
> >> 
> >> Alan Somers writes:
> >> > On Fri, Apr 7, 2023 at 2:22=E2=80=AFAM Poul-Henning Kamp 
> >> >  wrote:
> >>
> >> > > I would expect them to be limited by the serial console speed before
> >> > > the video system speed ?
> >> >
> >> > That was my first guess, too.  But my serial console is 115200 baud,
> >> > which is faster than the low performance server grade video card.
> >>
> >> Ok, that must truly be sucky hardware...
> >
> >
> > That's 10x slower than 1990s era VGA cards then... 115200 is 11k characters 
> > a second,
> > and FreeBSD on 1990s era VGA cards was in excess of 1MB/s, faster if not a 
> > pure ISA
> > card... Video hardware that's slower than *THAT* likely indicates a big big 
> > problem in
> > our video stack.
> >
> > Warner
> 
> While I'm logged into the video terminal in a normal login session, I
> measure about 28M characters/second.  So maybe the slow speed is due
> to something inefficient in ddb(4).

Do you mean to a physically connected vga display and usb/ps2 connected
keyboard, or do you mean a serially connected video terminal, or something
else like a console created by a BMC?

One other thing that could be at issue is a console redirection via
serial port, that can make "VGA device" performance appear abismal.


-- 
Rod Grimes rgri...@freebsd.org

Re: Could not change brightness anymore with i915kms & acpi_video modules c 202211

[Rodney W. Grimes]

> 
> Emmanuel Vadot writes:
> > On Thu, 02 Feb 2023 20:58:58 +
> > "Poul-Henning Kamp"  wrote:
> >
> > > 
> > > parv/FreeBSD writes:
> > > 
> > > > > Does backlight(8) works for you?
> > > >
> > > > Thanks for the clue. It does! It does ...
> > > >
> > > > - I get the same number back via "backlight" without any arguments as
> > > >   what I gave it earlier. There was no reporting of value being
> > > >   subtracted by one;
> > > 
> > > Sorry for the delay in reporting back.
> > > 
> > > I consistently read one less back, except for 0 and 100.
> >
> >  Even 50 ?
> 
>   # backlight 
>   brightness: 0
>   # backlight 50
>   # backlight
>   brightness: 49
>   # backlight 25
>   # backlight
>   brightness: 24
>   # backlight 75
>   # backlight
>   brightness: 74
> 
> yes

This smells like a zero-bias byte rounding issue...
Ie, if the backlight intensity register is 8 bit,
having values 0 to 255, and we scale 50% to
256 * 50% == 128 or do we scale to 255 * 50% == 127,
and then reverse it as 127/255 == 49.

> 
> >  So if you have, let's say brightness at 50%, and you plug an external
> > monitor, brightness goes up to 100% ?
> 
> No, plugging and unplugging does not change the backlight.
> 
> But when the screen saver has kicked in, and I wake it up again, it comes
> back at 100, (and reads back as 100)
> 
> -- 
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> 
> 

-- 
Rod Grimes rgri...@freebsd.org

Re: CAM: extract HDD informations about failure/to fail?

[Rodney W. Grimes]

> On Sun, Nov 27, 2022 at 8:15 AM FreeBSD User  wrote:
> 
> > Hello,
> >
> > well, the aim of my post sounds strange, but I'm serious.
> > Background: I run at home a 14-CURRENT based server with a ZFS volume
> > (RAIDZ) comprised from
> > 4x 4 TB HDD. A couple of days I had to exchange the HGST NAS drives since
> > one got a permanent
> > SMART error. So all HDDs have been replaced by now with four times Seagte
> > IronWolfe Pro 4TB
> > drives. So far, so good.
> > Now I face a weird sound sourcing at one of the new HDDs. The box is
> > supposed to be a heavy
> > duty poudriere build facility, so the drives are up 24/7. It seems that
> > one (or even more)
> > drives emitt a weird sound like the spindle motor is loosing for a
> > fraction of a second power
> > and spiining up the the drive again. Searching the net reveals that at
> > least one Seagate
> > customer did have the same issue and he provided an audio file of that
> > very weird sound, to be
> > found here:
> >
> > Post at reddit:
> >
> > https://www.reddit.com/r/techsupport/comments/sca6al/seagate_ironwolf_pro_making_weird_noise/
> >
> > and herin the post of the audio file:
> >
> >  https://www.mediafire.com/file/x3le816qsakiff9/Hdd.mp4/file
> >
> > I checked S.M.A.R.T for any unusual data, but everything is fine. The
> > values for
> >
> > Power_Cycle_Count
> > Power-Off_Retract_Count
> > Start_Stop_Count
> >
> > seem all within a reasonable range compared to the life time in hours (did
> > some simple
> > statistsics ), nothing looks unusual.
> >
> > Also, the advanced view onto each drive via
> >
> > smartctl -x
> >
> > doesn't give me any hint of a power failure as a source for the noise.
> >
> > So, big question here is: the drives are attached to a HBA, LSI3008 based
> > SAS9300-8i. Is it
> > possible to retrieve via CAM more health paramteres than those gathered by
> > SMART/smartmontools
> > and if the answer is yes, how can this be achieved?
> >
> 
> >From SATA drives? No. smartctl with enough flags retrieves everything
> available. Seagate is mainstream enough that there's unlikely to be other
> data at least that Seagate documents.
> 
> 
> > It close to impossible to isolate the drive making the noise. My guts tell
> > me to RMA the
> > supposed to be faulty drive and not to wait until it dies from "spindle
> > motor desease" or
> > something that is the source for the noises.
> >
> 
> The only way you can do this is to just apply power to the drives one at a
> time, which in most setups requires pulling cables.
> 
> Warner

What about using camcontrol standby, that should spin the drive down.
It probably takes a camcontrol reset to spin it back up.

camcontrol standby ada0
camcontrol reset ada0

-- 
Rod Grimes rgri...@freebsd.org

Re: dmesg content lifetime

[Rodney W. Grimes]

> On 22 Nov 2022, at 9:34, Dan Mack wrote:
> 
> > It disappears a piece at a time - the oldest entries disappear first. 
> > However, it vanishes even when there are only 2-3 lines in it so I didn't 
> > think capacity was in play as I expected.
> >
> > So for example I might see a rate-limit entry from someone spamming the 
> > system and then it will usually be gone in a couple days and the buffer is 
> > completely empty.   Similarly if I do something like ifconfig em0 down; 
> > ifconfig em0 up ; it's logged but disappears after a day or so.
> >
> > I'm looking to see if this is just a cron job or something clearing it as 
> > it might be user-error on my part.   Also this is an older system so I'll 
> > probably look at it again after I update.
> 
> I noticed this too, but discovered with ?dmesg -a? that the buffer was full
> of syslog messages, so dmesg without -a showed nothing.
> 
> It seems unfortunate that syslog messages logged in the message buffer, at
> least once syslogd is running.  Apparently this happens because they are
> output to /dev/console.
> 
>   Mike

I very much dislike this behavior.  I though that the kernel dmesg buffer
was for kernel messages only and that I could always count on going there
for any kernel messages about a problem that has occurred, expecting to
see my boot time output if nothing had happened since boot.  Now instead
I am almost always greated with an empty buffer :-(.

Rod

> 
> > Thank you,
> >
> > Dan
> >
> >
> > On Tue, 22 Nov 2022, Warner Losh wrote:
> >
> >> On Tue, Nov 22, 2022 at 8:13 AM Dan Mack  wrote:
> >>
> >>> It seems like dmesg content ages out over time.   Is there a way to leave
> >>> the contents based on a fixed memory size instead?
> >>>
> >>
> >> It already is a fixed memory size. Do you see it all disappear at once, or
> >> over time?
> >>
> >> Warner
> >>
> 
> 
> 

-- 
Rod Grimes rgri...@freebsd.org

Re: psm0: unable to allocate IRQ

[Rodney W. Grimes]

> On 2022-10-02 17:45, Chris wrote:
> > I've spent the last 2 days attempting to get a fresh install of
> > stable/13-n252407-f42139db639 working on a Dell Inspiron 5755.
> 
> Just attempted it again with the
> 14.0-CURRENT-amd64-20220930-42dc8696df5-258315 image, with the
> same results. Yet Linux && Windows work as intended. Any thoughts
> on how I might track the problem down in FreeBSD?
> Thanks.
> 
> > The problem I struggled with was getting the trackpad (synaptics?)
> > to be recognized and function. As it is, it's only ever recognized
> > as a mouse, and then, only if i kldload(8) ums(4). I'm pretty
> > sure this is on a psm(4). But any attempts to use psm fail with
> > psm0: unable to allocate IRQ.
> > An error I found in dmesg(8) on a verbose boot. Anybody familiar
> > with this, or have any thoughts on how I might track this down?
> > 
> > To rule out hardware; I installed Slackware along side the
> > FreeBSD install, and it has no trouble creating a full featured
> > trackpad under the MATE DE.

And in Slackware did it show up as a psm device,
and if it did what IRQ is it using.

Or what I suspect, is it shows up as a USB device.

> > 
> > Thank you for all your time, and consideration.
> > 
> > --chris


-- 
Rod Grimes rgri...@freebsd.org

Re: MCE: Does this look possibly like a slot issue?

[Rodney W. Grimes]

> 
> 
> Swapped 2 DIMMS, now we wait for the ZFS ARC to fill and start using all 
> the memory.

Depending on the results of that one thing that is often overlooked
when trying to trouble shoot memory systems in modern Intel systems
is the fact that the DIMM now talks directly to the CPU chip that
has the memory controller built into it.  THUS these "slot" related
ECC/Parity/blowup errors can actually be the CPU and/or the CPU
socket and/or the seating of the CPU in the socket.  

So if the error sticks with the DIMM slot and not the DIMM
module the next thing I would try would be a CPU chip reseat,
including a good inspection of the socket for for a damaged
pin.  Also look at the lands on the CPU chip itself, and you
can even try swaping CPU chips to see if it follows the
CPU or the socket, much as you do with a DIMM.


> 
> On 06/20/2022 7:59 pm, Larry Rosenman wrote:
> 
> > SuperMicro X8DTN+
> > 
> > 2 Processors, 6-core/12-Thread. CPU: Intel(R) Xeon(R) CPU   
> > E5645  @ 2.40GHz (2400.20-MHz K8-class CPU)
> > 
> > I'll bring it down and swap DIMMS around
> > 
> > On 06/20/2022 7:57 pm, Ultima wrote:
> > 
> > Hey Larry,
> > 
> > One red flag I am seeing is that the error is being produced on
> > the same CPU/bank with each error you have provided so far.
> > 
> > Can you try and follow my original recommendation and swap
> > currently installed DIMM with the problem DIMM slot and see
> > if anything changes?
> > 
> > Can you also provide the motherboard model? Also, do you
> > have multiple CPUs installed in this system?
> > 
> > Best regards,
> > Richard Gallamore
> > 
> > On Mon, Jun 20, 2022 at 5:41 PM Larry Rosenman  wrote:
> > 
> > Yes and Yes.
> > 
> > On 06/20/2022 7:37 pm, Ultima wrote:
> > 
> > Are you sure that the module you replaced it with was good?
> > Are you sure you replaced the correct module?
> > 
> > Best regards,
> > Richard Gallamore
> > 
> > On Mon, Jun 20, 2022 at 5:23 PM Larry Rosenman  wrote:
> > 
> > I'm seeing them constantly:
> > 
> > root@freenas[~]# mcelog --dmi
> > Hardware event. This is not a software error.
> > MCE 0
> > CPU 22 BANK 8 TSC 20aab486464a
> > MISC ac29890200046444 ADDR ee2f6e800
> > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > MCG status:
> > Memory read ECC error
> > Memory corrected error count (CORE_ERR_CNT): 1
> > Memory transaction Tracker ID (RTId): 44
> > Memory DIMM ID of error: 0
> > Memory channel ID of error: 1
> > Memory ECC syndrome: ac298902
> > STATUS 8c41009f MCGSTATUS 0
> > MCGCAP 1c09 APICID 34 SOCKETID 0
> > CPUID Vendor Intel Family 6 Model 44 Step 2
> > WARNING: SMBIOS data is often unreliable. Take with a grain of salt!
> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > Device Locator: P2-DIMM2C
> > Bank Locator: BANK14
> > Manufacturer: Hyundai
> > Serial Number: 40F3C20F
> > Asset Tag:
> > Part Number: HMT151R7BFR4C-H9
> > Hardware event. This is not a software error.
> > MCE 1
> > CPU 22 BANK 8 TSC 296dfcc82582
> > MISC ac29890200041381 ADDR ee2f6e800
> > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > MCG status:
> > Memory read ECC error
> > Memory corrected error count (CORE_ERR_CNT): 1
> > Memory transaction Tracker ID (RTId): 81
> > Memory DIMM ID of error: 0
> > Memory channel ID of error: 1
> > Memory ECC syndrome: ac298902
> > STATUS 8c41009f MCGSTATUS 0
> > MCGCAP 1c09 APICID 34 SOCKETID 0
> > CPUID Vendor Intel Family 6 Model 44 Step 2
> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > Device Locator: P2-DIMM2C
> > Bank Locator: BANK14
> > Manufacturer: Hyundai
> > Serial Number: 40F3C20F
> > Asset Tag:
> > Part Number: HMT151R7BFR4C-H9
> > Hardware event. This is not a software error.
> > MCE 2
> > CPU 22 BANK 8 TSC 2a5604a6a070
> > MISC ac29890200044281
> > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > MCG status:
> > Memory ECC error occurred during scrub
> > Memory corrected error count (CORE_ERR_CNT): 1
> > Memory transaction Tracker ID (RTId): 81
> > Memory DIMM ID of error: 0
> > Memory channel ID of error: 1
> > Memory ECC syndrome: ac298902
> > STATUS 884200cf MCGSTATUS 0
> > MCGCAP 1c09 APICID 34 SOCKETID 0
> > CPUID Vendor Intel Family 6 Model 44 Step 2
> > Hardware event. This is not a software error.
> > MCE 3
> > CPU 22 BANK 8 TSC 31e141418eb8
> > MISC ac29890200046a4a ADDR ee2f6e800
> > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > MCG status:
> > Memory read ECC error
> > Memory corrected error count (CORE_ERR_CNT): 1
> > Memory transaction Tracker ID (RTId): 4a
> > Memory DIMM ID of error: 0
> > Memory channel ID of error: 1
> > Memory ECC syndrome: ac298902
> > STATUS 8c41009f MCGSTATUS 0
> > MCGCAP 1c09 APICID 34 SOCKETID 0
> > CPUID Vendor Intel Family 6 Model 44 Step 2
> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > Device Locator: P2-DIMM2C
> > Bank Locator: BANK14
> > Manufacturer: Hyundai
> > Serial Number: 40F3C20F
> > Asset Tag:
> > Part Number: HMT151R7BFR4C-H9
> > Hardware event. This is not a software error.
> > 

Re: CURRENT doesn't recognise synaptics touchpad

[Rodney W. Grimes]

> Hi all,
> 
> I have another issue with my recent re-installation to Current: touchpad
> support seems to have vanished. I know it works because the keyboard lights
> up when I touch it, it also works under linux (dual-boot), and it worked
> with the previous installation of FreeBSD, where I installed iichid (and
> others, I guess) from the sources.
> 
> I've been searching high and low for things to test or set, with no visible
> success:
> - create an /etc/X11/xorg.conf
> - add or remove various settings from /boot/loader.conf
> 
> I have libinput and xf86-input-libinput installed.
> 
> TIA for all and any advice/pointers/RTFMs.

I do recall someplace along not to distant past reading some
commits that indicated changes to defaults with respected to
the synaptic touch pad, some time in the last year or year
and a half, not sure how old your prior install was

> 
> cheers
> Michael
> -- 
> Michael Schuster
> http://recursiveramblings.wordpress.com/
> recursion, n: see 'recursion'

-- 
Rod Grimes rgri...@freebsd.org

Re: Future of ident(1)

[Rodney W. Grimes]

Has anyone considered that ident(1) works on all the binaries
produced by FreeBSD for the first 25 years it existed?

Ie, you can run ident on a FreeBSD 1.0 binary... 
I also believe it can be run on binaries from many other
systems.


So though we have lost the data in FreeBSD 14, the other
data still exists, and though some might call this obscure,
others of us find this data pricessless in figuring out
from which a binary was made.

Regards,
Rod
> Just in case someone thinks this is something useful, I've got a PR filed
> against git to implement custom $Id$. There are no technical issues with
> the change but Git developers are not very keen on merging it in, since
> they see this as an obscure feature, no one needs. :-/ So if anyone wants
> to chime in on GitHub or git mailing list please do so.
> 
> https://github.com/git/git/pull/1074
> 
> Thanks!
> 
> -Max
> 
> On Fri, Oct 22, 2021 at 2:30 PM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
> 
> > All,
> >
> > With the new world order, what is the future of ident(1)?
> > Should it be removed from base?  Given a compiled binary
> > in base, how does one find the equivalent git info that
> > ident(1) used to perform?
> >
> > Having a few minutes to dust off old patchs for libm, should
> > I remove $FreeBSD$ tags in files I touch?  For new files, is
> > it expected that useless $FreeBSD$ tags should be added?
> >
> > --
> > Steve
> >
> >

-- 
Rod Grimes rgri...@freebsd.org

Re: Building ZFS disk images

[Rodney W. Grimes]

> On Tue, Sep 28, 2021 at 9:48 AM Rodney W. Grimes
>  wrote:
> >
> > > On Mon, Sep 27, 2021 at 1:54 PM Mark Johnston  wrote:
> > > >
> > > > On Thu, Aug 05, 2021 at 10:54:19AM -0500, Alan Somers wrote:
> > > > > There's this:
> > > > > https://openzfs.github.io/openzfs-docs/man/8/zpool-reguid.8.html .  I
> > > > > haven't used it myself.
> > > >
> > > > Would it be useful to have an rc.d script that can run this, probably
> > > > just on the root pool?  It could be configured to run only upon the
> > > > first boot, like growfs already does.
> > >
> > > Absolutely!
> >
> > Eww!  :-)
> >
> > > >
> > > > > On Thu, Aug 5, 2021, 9:29 AM David Chisnall  
> > > > > wrote:
> > > > >
> > > > > > On 05/08/2021 13:53, Alan Somers wrote:
> > > > > > > I don't know of any way to do it using the official release 
> > > > > > > scripts
> > > > > > > either. One problem is that every ZFS pool and file system is 
> > > > > > > supposed
> > > > > > > to have a unique GUID.  So any kind of ZFS release builder would 
> > > > > > > need to
> >  ^^^
> > > > > > > re-guid the pool on first boot.
> >
> > Isnt the proper place to solve this lack of Unique UUID creation
> > in the tool(s) that are creating the zfs pool in the first place.
> >
> > Fixing it "post boot" seems to be a far to late hack and doesnt
> > fix any of the situations where one might import these pools
> > between creation and first boot.
> 
> No, because you might create a VM image once, then instantiate it
> dozens or thousands of times.  The firstboot solution is great because
> it lets you reuse the same image file.

I would continue to argue that the place to fix this is in the
"instantiate tool".  ESXI vmfs deals with this all the time
when you clone a disk.  And again the "fix at boot" does not
deal with the problem in that if I "instatiate" 10 copies of
a zpool for VM's and then try to mount 2 of them at once on
the host this problem rares it head.   Fix the problem as close
to point of creation as possible for minimal issues in all
operations for everyone.

> 
> >
> > > > > >
> > > > > > Is there a tool / command to do this?  I've hit this problem in the
> > > > > > past: I have multiple FreeBSD VMs that are all created from the same
> > > > > > template and if one dies I can't import its zpool into another 
> > > > > > because
> > > > > > they have the same UUID.
> > > > > >
> > > > > > It doesn't matter for modern deployments where the VM is stateless 
> > > > > > and
> > > > > > reimaged periodically but it's annoying for classic deployments 
> > > > > > where I
> > > > > > have things I care about on the VM.
> > > > > >
> > > > > > David
> > >
> > >
> >
> > --
> > Rod Grimes 
> > rgri...@freebsd.org
> 

-- 
Rod Grimes rgri...@freebsd.org

Re: Building ZFS disk images

[Rodney W. Grimes]

> On Mon, Sep 27, 2021 at 1:54 PM Mark Johnston  wrote:
> >
> > On Thu, Aug 05, 2021 at 10:54:19AM -0500, Alan Somers wrote:
> > > There's this:
> > > https://openzfs.github.io/openzfs-docs/man/8/zpool-reguid.8.html .  I
> > > haven't used it myself.
> >
> > Would it be useful to have an rc.d script that can run this, probably
> > just on the root pool?  It could be configured to run only upon the
> > first boot, like growfs already does.
> 
> Absolutely!

Eww!  :-)

> >
> > > On Thu, Aug 5, 2021, 9:29 AM David Chisnall  wrote:
> > >
> > > > On 05/08/2021 13:53, Alan Somers wrote:
> > > > > I don't know of any way to do it using the official release scripts
> > > > > either. One problem is that every ZFS pool and file system is supposed
> > > > > to have a unique GUID.  So any kind of ZFS release builder would need 
> > > > > to
 ^^^
> > > > > re-guid the pool on first boot.

Isnt the proper place to solve this lack of Unique UUID creation
in the tool(s) that are creating the zfs pool in the first place.

Fixing it "post boot" seems to be a far to late hack and doesnt
fix any of the situations where one might import these pools
between creation and first boot.

> > > >
> > > > Is there a tool / command to do this?  I've hit this problem in the
> > > > past: I have multiple FreeBSD VMs that are all created from the same
> > > > template and if one dies I can't import its zpool into another because
> > > > they have the same UUID.
> > > >
> > > > It doesn't matter for modern deployments where the VM is stateless and
> > > > reimaged periodically but it's annoying for classic deployments where I
> > > > have things I care about on the VM.
> > > >
> > > > David
> 
> 

-- 
Rod Grimes rgri...@freebsd.org

Re: [HEADSUP] making /bin/sh the default shell for root

[Rodney W. Grimes]

> On 9/22/21 10:36 AM, Baptiste Daroussin wrote:
> > Hello,
> > 
> > TL;DR: this is not a proposal to deorbit csh from base!!!
> > 
> > For years now, csh is the default root shell for FreeBSD, csh can be 
> > confusing
> > as a default shell for many as all other unix like settled on a bourne shell
> > compatible interactive shell: zsh, bash, or variant of ksh.
> > 
> > Recently our sh(1) has receive update to make it more user friendly in
> > interactive mode:
> > * command completion (thanks pstef@)
> > * improvement in the emacs mode, to make it behave by default like other 
> > shells
> > * improvement in the vi mode (in particular the vi edit to respect $EDITOR)
> > * support for history as described by POSIX.
> > 
> > This makes it a usable shell by default, which is why I would like to 
> > propose to
> > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed)
> > 
> > If no strong arguments has been raised until October 15th, I will make this
> > proposal happen.
> > 
> > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE!
> > 
> > Best regards,
> > Baptiste
> > 
> 
> Hello,
> 
> I applaud the proposal to change the default login shell of root to 
> /bin/sh. As you mention the rest of the Unix(-like) world has used a 
> Bourne-like root login shell forever. It is one of the first things I 
> change on a new FreeBSD install anyway.

So now you stop changing it, something you have grown use to doing,
and all of us who want the old behavior have to add a change item
to our list of post install stuff.  We BOTH end up with version
conditional tweaks to the base system.  Is that a good idea?

> While there, you could change "Charlie &" in the gecos field to 
> something more sensible, e.g. just "Superuser". I know Charlie is there 
> since 4.2BSD, but the reference to a long forgotten baseball player is 
> probably lost by now. Also, a lot of explanation is often needed when 
> users receive (automated) emails from Charlie Root.
> 
> Once the login shell of root has changed to /bin/sh, I do not see any 
> reason to keep toor around. It is there since 4.3BSD, but I don't know 
> anybody who uses it in the long term. Many will just change the login 
> shell of root to a Bourne-like shell right away.

Your lack of knowing anyone who uses it, does not indicate lack
of use.  If I want a /bin/sh root user I type:
su - toor
So now you know someone who uses it!

> 
> I have experimented a bit with the new usability features of sh in 14.0 
> and I must say that it was quite a positive experience. I could easily 
> suppress the urge to install and use bash instead of sh. I wonder if the 
> changes (but not the ones to /etc/passwd) could be MFC'd in a few 
> months, once they have matured a bit, so they would land in 13.1. As you 
> mention elsewhere in this thread, usage in scripts is not affected by 
> these changes. And for interactive use it could be a POLA violation, but 
> the astonishment would be a positive one.
> 
> -- 
> Kind regards,
> 
> Hans Ottevanger
> 
> Eindhoven, Netherlands.
> h...@beastielabs.net
> www.beastielabs.net
> 
> 

-- 
Rod Grimes rgri...@freebsd.org

Re: [HEADSUP] making /bin/sh the default shell for root

[Rodney W. Grimes]

> 
> Quoting Miroslav Lachman <000.f...@quip.cz>:
> 
> > On 22/09/2021 22:50, grarpamp wrote:
> >>> propose to make it the default shell for root starting FreeBSD 
> >>> 14.0-RELEASE
> >>
> >> Make it so.
> >>
> >> The whole rest of rc, pkg, base scripts and subsystems use a lot of  
> >> sh, not csh.
> >> So this is a good compatibility, consistancy, and gotcha-removing update,
> >> needed for decades.
> >>
> >> Even "bash" is a majority spoken shell in Linux/world, helping
> >> make crossovers if BSD becomes a bit more bash-like.
> >
> > More bashism and linuxism in BSD world, you are waking the devil.
> >
> >> The bsd sh feature updates are filling useful/needed capability gaps.
> >
> > Moving to sh without maintain the same history search behavior  
> > (start of the command and Up & Down arrows) are like cutting one leg.
> >
> > The (t)csh is what I really like on every FreeBSD machine. Never  
> > seen good configured bash (prompt + history search) on any other OS  
> > I ever visited. Not saying it is not possible but if FreeBSD will  
> > switch default shell to something else I expect to do it the way  
> > that it is more user friendly and powerful than on other OSes where  
> > everything is leaved to "users can customize it". Current state of  
> > sh behavior is really that "bad" way.
> we are talking of the default sehll for the root user. One does not
> really work as root user, but if son nothing stops who ever wants to
> to exec zsh or exec tcsh?
> 
> Whoever wants is free to add other users with root pemissions is free
> to do so.

That is a zero sum argument.  Ie, same can be said about those who
wish to have the current default changed.  Changing that default is
actually going to require NEW special casing of any code that expects
the now 30+ year default.  Those who DO like it changed, have already
made changes to have it changed, so changing the default only adds
to work for both parties, to me a net loss.

Leave the defaults alone, provide tools and such to make it easier
for people to tweak those defaults on install.  Stop adding work
to both the people who like how it is now, and people who like
the idea of this change, its not productive for anyone.


> Rolf M Dietze

-- 
Rod Grimes rgri...@freebsd.org

Re: [HEADSUP] making /bin/sh the default shell for root

[Rodney W. Grimes]

> On Wed, Sep 22, 2021 at 08:34:58AM -0700, John Baldwin wrote:
> > On 9/22/21 1:36 AM, Baptiste Daroussin wrote:
> > > Hello,
> > > 
> > > TL;DR: this is not a proposal to deorbit csh from base!!!
> > > 
> > > For years now, csh is the default root shell for FreeBSD, csh can be 
> > > confusing
> > > as a default shell for many as all other unix like settled on a bourne 
> > > shell
> > > compatible interactive shell: zsh, bash, or variant of ksh.
> > > 
> > > Recently our sh(1) has receive update to make it more user friendly in
> > > interactive mode:
> > > * command completion (thanks pstef@)
> > > * improvement in the emacs mode, to make it behave by default like other 
> > > shells
> > > * improvement in the vi mode (in particular the vi edit to respect 
> > > $EDITOR)
> > > * support for history as described by POSIX.
> > > 
> > > This makes it a usable shell by default, which is why I would like to 
> > > propose to
> > > make it the default shell for root starting FreeBSD 14.0-RELEASE (not 
> > > MFCed)
> > > 
> > > If no strong arguments has been raised until October 15th, I will make 
> > > this
> > > proposal happen.
> > > 
> > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE!
> > 
> > I think this is fine.  I would also be fine with either removing 'toor' 
> > from the
> > default password file or just leaving it as-is for POLA.  (I would probably
> > prefer removing it outright.)
> 
> HardenedBSD recently removed toor. No one has complained (yet?). A
> small Twitter poll[0] showed that 85% of people who responded do not
> use toor.

A truely disastisified customer does not complain, they simply
go some place else for there products.  Be carefull in what you
believe silence to be saying.

> 
> [0]: https://twitter.com/HardenedBSD/status/1415781911063056389
> 
> Thanks,
> 
> -- 
> Shawn Webb
> Cofounder / Security Engineer
> HardenedBSD
> 
> https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

-- 
Rod Grimes rgri...@freebsd.org

Re: Wi-Fi: HP ZBook 17 G2

[Rodney W. Grimes]

> According to , iwm(4) 
> should work.
> 
> Neither wpa_gui (with wpa_supplicant-devel 2021.06.14) nor 
> net-mgt/wifimgr can detect any network.
> 
> What am I missing?

I am not sure.. but... see below...

> 
> /etc/rc.conf includes:
> 
> create_args_wlan0="country GB regdomain etsi"

You can try adding "up" to that string, I would think
the this was already handled by the wlan ifconfig code
though, but given your output the devices was never
brought up.

> wlans_iwm0="wlan0"
> ifconfig_wlan0="WPA SYNCDHCP"
> 
> 
> 
> wlan0: flags=8802 metric 0 mtu 1500
   ^UP is missing, the interface has not been started.

>  ??? ether ?:?:?:?:?:?
>  ??? groups: wlan
>  ??? ssid "" channel 1 (2412 MHz 11b)
>  ??? regdomain ETSI country GB authmode OPEN privacy OFF txpower 30
>  ??? bmiss 10 scanvalid 60 wme bintval 0
>  ??? parent interface: iwm0
>  ??? media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
>  ??? status: no carrier
>  ??? nd6 options=29
> 
> 
> 
> FreeBSD 14.0-CURRENT #0 main-n248042-f808bb9b7e5-dirty: Sat Jul 17 
> 16:15:31 EDT 2021 
> root@testpc-freebsd.davidgroup:/usr/obj/usr/home/david/FreeBSD/src/amd64.amd64/sys/GENERIC
>  
> 1400026 1400026
> 
> 

-- 
Rod Grimes rgri...@freebsd.org

Re: PATH: /usr/local before or after /usr ?

[Rodney W. Grimes]

> 
> 
> On Fri, 16 Jul 2021 09:01:49 -0600
> Alan Somers  wrote:
> 
> > FreeBSD has always placed /usr/local/X after /usr/X in the default
> > PATH. AFAICT that convention began with SVN revision 37 "Initial
> > import of 386BSD 0.1 othersrc/etc".  Why is that?  It would make
> > sense to me that /usr/local/X should come first.  That way programs
> > installed from ports can override FreeBSD's defaults.
> 
> I think that is exactly what you don't want to happen by default
> (imagine all the ways the system could fall apart in a really hard to
> support ways if individual standard tools from base are overridden -
> especially as many users might not even notice, as it might be a
> side-effect of installing some dependency of something they need).

Michael states the exact reasoning that was used, and has been used
repeatidly over history for this ordering of path.

Any alteration of that ordering leads to issues with deterministic
behavior is the bottom line.

> 
> Users are always free to tweak PATH for their purposes of course, but
> running the UNIX tools that came with the OS by default makes a lot
> of sense to me.

Others have noted use of aliases which is a good way to handle
this.  Global aliases can be installed in /etc/csh.cshrc or
/etc/profile, other shells have similiar global config files.

> 
> -m
> 
> >  Is there a
> > good reason for this convention, or is it just inertia?

Good reason(s).

> > -Alan
> -- 
> Michael Gmelin
-- 
Rod Grimes rgri...@freebsd.org

Re: Files in /etc containing empty VCSId header

[Rodney W. Grimes]

> On Thu, Jun 10, 2021 at 03:26:58PM -0700, Kevin Oberman wrote:
> > On Wed, Jun 9, 2021 at 2:02 AM Michael Gmelin  wrote:
> > >
> > > > On 9. Jun 2021, at 01:15, Ian Lepore  wrote:
> > > >
> > > > ?On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:
> > > >>> On Tue, 8 Jun 2021 09:41:34 +
> > > >>> Mark Linimon  wrote:
> > > >>>
> > > >>>> On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote:
> > > >>>>> Sometimes it's a real interesting exercise to figure out where
> > > >>>>> a
> > > >>>>> file on your runtime system comes from in the source world.
> > > >>
> > > >> There is a command for that which does or use to do a pretty
> > > >> decent job of it called whereis(1).
> > > >>
> > > >
> > > > revolution > whereis ntp.conf
> > > > ntp.conf:
> > > > revolution > whereis netif
> > > > netif:
> > >
> > > That line might make it to a shirt one day:
> > >
> > > > revolution > whereis services
> > >
> > > ;)
> > > Michael
> > >
> > Just to clarify for those not willing or able to RTFM, it only works for
> > executables, not conf files or libraries. It reports the location of the
> > executable, the man page and the port location, if it is a port. For those
> > who did RTFM, it is wrong. It claims that it reports on the location of the
> > source, but that is not the case as far as I know. I have never seen it
> > return anything from /usr/src.
> > > whereis cc
> > cc: /usr/bin/cc /usr/share/man/man1/cc.1.gz
> > > whereis postfix
> > postfix: /usr/local/sbin/postfix /usr/local/man/man1/postfix.1.gz
> > /usr/ports/mail/postfix
> 
> I should probably just lurk, but I believe the command that
> some are looking for is ident(1).  This command is, of course,
> broken by the lost of $FreeBSD$ expansion.

ident provides a bit more detail, but yes, it WAS the solution, and
it would be nice to have that back.  

-- 
Rod Grimes rgri...@freebsd.org

Re: Files in /etc containing empty VCSId header

[Rodney W. Grimes]

> On 2021-Jun-08 17:13:45 -0600, Ian Lepore  wrote:
> >On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:
> >> There is a command for that which does or use to do a pretty
> >> decent job of it called whereis(1).
> 
> Thanks.  That looks useful.
> 
> >revolution > whereis ntp.conf
> >ntp.conf:
> >revolution > whereis netif
> >netif:
> >revolution > whereis services
> >services:
> >
> >So how does that help me locate the origin of these files in the source
> >tree?
> 
> It works for me?:
> server% whereis ntp.conf
> ntp.conf: /usr/src/usr.sbin/ntp/ntpd/ntp.conf
> server% whereis netif   
> netif: /usr/src/libexec/rc/rc.d/netif
> server% whereis services
> services: /usr/src/contrib/unbound/services
> 
> Is your source tree somewhere other than /usr/src?

And if source is not located at /usr/src, /usr/ports there is
the -S option.

> Peter Jeremy
-- 
Rod Grimes rgri...@freebsd.org

Re: ssh connections break with "Fssh_packet_write_wait" on 13 [SOLVED]

[Rodney W. Grimes]

> On  8 Jun, Michael Gmelin wrote:
> > 
> > 
> > On Thu, 3 Jun 2021 15:09:06 +0200
> > Michael Gmelin  wrote:
> > 
> >> On Tue, 1 Jun 2021 13:47:47 +0200
> >> Michael Gmelin  wrote:
> >> 
> >> > Hi,
> >> > 
> >> > Since upgrading servers from 12.2 to 13.0, I get
> >> > 
> >> >   Fssh_packet_write_wait: Connection to 1.2.3.4 port 22: Broken pipe
> >> > 
> >> > consistently, usually after about 11 idle minutes, that's with and
> >> > without pf enabled. Client (11.4 in a VM) wasn't altered.
> >> > 
> >> > Verbose logging (client and server side) doesn't show anything
> >> > special when the connection breaks. In the past, QoS problems
> >> > caused these disconnects, but I didn't see anything apparent
> >> > changing between 12.2 and 13 in this respect.
> >> > 
> >> > I did a test on a newly commissioned server to rule out other
> >> > factors (so, same client connections, some routes, same
> >> > everything). On 12.2 before the update: Connection stays open for
> >> > hours. After the update (same server): connections breaks
> >> > consistently after < 15 minutes (this is with unaltered
> >> > configurations, no *AliveInterval configured on either side of the
> >> > connection). 
> >> 
> >> I did a little bit more testing and realized that the problem goes
> >> away when I disable "Proportional Rate Reduction per RFC 6937" on the
> >> server side:
> >> 
> >>   sysctl net.inet.tcp.do_prr=0
> >> 
> >> Keeping it on and enabling net.inet.tcp.do_prr_conservative doesn't
> >> fix the problem.
> >> 
> >> This seems to be specific to Parallels. After some more digging, I
> >> realized that Parallels Desktop's NAT daemon (prl_naptd) handles
> >> keep-alive between the VM and the external server on its own. There is
> >> no direct communication between the client and the server. This means:
> >> 
> >> - The NAT daemon starts sending keep-alive packages right away (not
> >>   after the VM's net.inet.tcp.keepidle), every 75 seconds.
> >> - Keep-alive packages originating in the VM never reach the server.
> >> - Keep-alive originating on the server never reaches the VM.
> >> - Client and server basically do keep-alive with the nat daemon, not
> >>   with each other.
> >> 
> >> It also seems like Parallels is filtering the tos field (so it's
> >> always 0x00), but that's unrelated.
> >> 
> >> I configured a bhyve VM running FreeBSD 11.4 on a separate laptop on
> >> the same network for comparison and is has no such issues.
> >> 
> >> Looking at TCP dump output on the server, this is what a keep-alive
> >> package sent by Parallels looks like:
> >> 
> >>   10:14:42.449681 IP (tos 0x0, ttl 64, id 15689, offset 0, flags
> >> [none], proto TCP (6), length 40)
> >> 192.168.1.1.58222 > 192.168.1.2.22: Flags [.], cksum x (correct),
> >> seq 2534, ack 3851, win 4096, length 0
> >> 
> >> While those originating from the bhyve VM (after lowering
> >> net.inet.tcp.keepidle) look like this:
> >> 
> >>   12:18:43.105460 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF],
> >> proto TCP (6), length 52)
> >> 192.168.1.3.57555 > 192.168.1.2.22: Flags [.], cksum x
> >> (correct), seq 1780337696, ack 45831723, win 1026, options
> >> [nop,nop,TS val 3003646737 ecr 3331923346], length 0
> >> 
> >> Like written above, once net.inet.tcp.do_prr is disabled, keepalive
> >> seems to be working just fine. Otherwise, Parallel's NAT daemon kills
> >> the connection, as its keep-alive requests are not answered (well,
> >> that's what I think is happening):
> >> 
> >>   10:19:43.614803 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
> >> proto TCP (6), length 40)
> >> 192.168.1.1.58222 > 192.168.1.2.22: Flags [R.], cksum x (correct),
> >> seq 2535, ack 3851, win 4096, length 0
> >> 
> >> The easiest way to work around the problem Client side is to configure
> >> ServerAliveInterval in ~/.ssh/config in the Client VM.
> >> 
> >> I'm curious though if this is basically a Parallels problem that has
> >> only been exposed by PRR being more correct (which is what I suspect),
> >> or if this is actually a FreeBSD problem.
> >> 
> > 
> > So, PRR probably was a red herring and the real reason that's happening
> > is that FreeBSD (since version 13[0]) by default discards packets
> > without timestamps for connections that formally had negotiated to have
> > them. This new behavior seems to be in line with RFC 7323, section
> > 3.2[1]:
> > 
> > "Once TSopt has been successfully negotiated, that is both  and
> >  contain TSopt, the TSopt MUST be sent in every non-
> > segment for the duration of the connection, and SHOULD be sent in an
> >  segment (see Section 5.2 for details)."
> > 
> > As it turns out, macOS does exactly this - send keep-alive packets
> > without a timestamp for connections that were negotiated to have them.
> 
> I wonder if I'm running into this with ssh connections to freefall.  My
> outgoing IPv6 connections pass through an ipfw firewall that uses
> dynamic rules.  When the dynamic rule 

Re: ssh connections break with "Fssh_packet_write_wait" on 13 [SOLVED]

[Rodney W. Grimes]

> 
> On Thu, 3 Jun 2021 15:09:06 +0200
> Michael Gmelin  wrote:
> 
> > On Tue, 1 Jun 2021 13:47:47 +0200
> > Michael Gmelin  wrote:
> > 
> > > Hi,
> > > 
> > > Since upgrading servers from 12.2 to 13.0, I get
> > > 
> > >   Fssh_packet_write_wait: Connection to 1.2.3.4 port 22: Broken pipe
> > > 
> > > consistently, usually after about 11 idle minutes, that's with and
> > > without pf enabled. Client (11.4 in a VM) wasn't altered.
> > > 
> > > Verbose logging (client and server side) doesn't show anything
> > > special when the connection breaks. In the past, QoS problems
> > > caused these disconnects, but I didn't see anything apparent
> > > changing between 12.2 and 13 in this respect.
> > > 
> > > I did a test on a newly commissioned server to rule out other
> > > factors (so, same client connections, some routes, same
> > > everything). On 12.2 before the update: Connection stays open for
> > > hours. After the update (same server): connections breaks
> > > consistently after < 15 minutes (this is with unaltered
> > > configurations, no *AliveInterval configured on either side of the
> > > connection). 
> > 
> > I did a little bit more testing and realized that the problem goes
> > away when I disable "Proportional Rate Reduction per RFC 6937" on the
> > server side:
> > 
> >   sysctl net.inet.tcp.do_prr=0
> > 
> > Keeping it on and enabling net.inet.tcp.do_prr_conservative doesn't
> > fix the problem.
> > 
> > This seems to be specific to Parallels. After some more digging, I
> > realized that Parallels Desktop's NAT daemon (prl_naptd) handles
> > keep-alive between the VM and the external server on its own. There is
> > no direct communication between the client and the server. This means:
> > 
> > - The NAT daemon starts sending keep-alive packages right away (not
> >   after the VM's net.inet.tcp.keepidle), every 75 seconds.
> > - Keep-alive packages originating in the VM never reach the server.
> > - Keep-alive originating on the server never reaches the VM.
> > - Client and server basically do keep-alive with the nat daemon, not
> >   with each other.
> > 
> > It also seems like Parallels is filtering the tos field (so it's
> > always 0x00), but that's unrelated.
> > 
> > I configured a bhyve VM running FreeBSD 11.4 on a separate laptop on
> > the same network for comparison and is has no such issues.
> > 
> > Looking at TCP dump output on the server, this is what a keep-alive
> > package sent by Parallels looks like:
> > 
> >   10:14:42.449681 IP (tos 0x0, ttl 64, id 15689, offset 0, flags
> > [none], proto TCP (6), length 40)
> > 192.168.1.1.58222 > 192.168.1.2.22: Flags [.], cksum x (correct),
> > seq 2534, ack 3851, win 4096, length 0
> > 
> > While those originating from the bhyve VM (after lowering
> > net.inet.tcp.keepidle) look like this:
> > 
> >   12:18:43.105460 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF],
> > proto TCP (6), length 52)
> > 192.168.1.3.57555 > 192.168.1.2.22: Flags [.], cksum x
> > (correct), seq 1780337696, ack 45831723, win 1026, options
> > [nop,nop,TS val 3003646737 ecr 3331923346], length 0
> > 
> > Like written above, once net.inet.tcp.do_prr is disabled, keepalive
> > seems to be working just fine. Otherwise, Parallel's NAT daemon kills
> > the connection, as its keep-alive requests are not answered (well,
> > that's what I think is happening):
> > 
> >   10:19:43.614803 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
> > proto TCP (6), length 40)
> > 192.168.1.1.58222 > 192.168.1.2.22: Flags [R.], cksum x (correct),
> > seq 2535, ack 3851, win 4096, length 0
> > 
> > The easiest way to work around the problem Client side is to configure
> > ServerAliveInterval in ~/.ssh/config in the Client VM.
> > 
> > I'm curious though if this is basically a Parallels problem that has
> > only been exposed by PRR being more correct (which is what I suspect),
> > or if this is actually a FreeBSD problem.
> > 
> 
> So, PRR probably was a red herring and the real reason that's happening
> is that FreeBSD (since version 13[0]) by default discards packets
> without timestamps for connections that formally had negotiated to have
> them. This new behavior seems to be in line with RFC 7323, section
> 3.2[1]:
> 
> "Once TSopt has been successfully negotiated, that is both  and
>  contain TSopt, the TSopt MUST be sent in every non-
> segment for the duration of the connection, and SHOULD be sent in an
>  segment (see Section 5.2 for details)."
> 
> As it turns out, macOS does exactly this - send keep-alive packets
> without a timestamp for connections that were negotiated to have them.
> 
> Under normal circumstances - ssh from macOS to a server running FreeBSD
> 13 - this won't be noticed, since macOS uses the same default settings
> as FreeBSD (2 hours idle time, 75 seconds intervals), so the server
> side initiated keep-alive will save the connection before it has a
> chance to break due to eight consecutive unanswered 

Re: Files in /etc containing empty VCSId header

[Rodney W. Grimes]

> On Tue, 8 Jun 2021 09:41:34 +
> Mark Linimon  wrote:
> 
> > On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote:
> > > Sometimes it's a real interesting exercise to figure out where a
> > > file on your runtime system comes from in the source world.  

There is a command for that which does or use to do a pretty
decent job of it called whereis(1).


> > 
> > A tangential problem I trip over is "what is on this SD card?"
> > 
> > It generally takes me 5-10 minutes to remember:
> > 
> >   strings //boot/kernel/kernel | tail
> > 
> > AFIAK it's the only way to be sure; nothing in //* seems
> > to have that data.
> > 
> > (Yes, in theory they all live in their own little box each of
> > which is labeled but things happen ...)
> > 
> 
> I use locate for this kind of search, e.g.
> 
> locate netoptions
> /etc/rc.d/netoptions
> /usr/src/libexec/rc/rc.d/netoptions
> 
> -- 
> Gary Jennejohn
> 
> 

-- 
Rod Grimes rgri...@freebsd.org

Re: Alternate Screen

[Rodney W. Grimes]

> There was a recent discussion about a terminal database update and the 
> new Alternate Screen behavior.  I'm curious about the resolution, but I 
> can't find that discussion.  Would someone kindly send a clue-by-four 
> via overnight express?
> 
> Ultimately, I'd like to know how to get the old behavior back, with no 
> alternate screen, and thereby reduce my blood pressure.

I thought this code had been reverted, reworked and old behavior restored
with knobs to give new behavior???

> 
> Alternatively yours,
> Eric
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: RFC: changing the default NFSv4 minor version?

[Rodney W. Grimes]

> Rodney W. Grimes wrote:
> [stuff snipped]
> >Daniel Ebdrup Jensen wrote:
> >> Hi Rick,
> >>
> >>   If I understand your plans correctly, you're not going to be making
> >>   it so that minorversion=N complains?
> >
> >Ah, I think that if you specify a minorversion and the server
> >does not support that minorversion it SHOULD complain.
> Yes. The mount attempt currently fails with "minor version not supported"
> when the minor version is not supported by the server.
> My plan would not change this when "minorversion=N" is specified.
> 
> >  Only
> >if when a minorversion has NOT been specified should it silently
> >use the highest common version.
> Yes, that's my plan.
> 
> >>
> >>   In that case, I don't quite understand how it can be a POLA
> >>   violation, since presumably it'll fall back to NFSv4.0 if that's
> >>   the only thing that's supported by ntpd on some other system.
> >
> >Ignoring the ntpd typo, I think ricks concern on POLA is that currently
> >in FreeBSD if you do NOT specify any minor version you get v4.0 and
> >only v4.0 even if both sides support v4.2, so with his change things
> >are suddenly going to change, that may astonish some.
> Yes.
> 
> >>
> >>   At any rate, I'm all for it since I'm already using NFSv4.2. :)
> >
> >I support this change with the caveats that it only occurs if the
> >minorversion is unspecified and this same negotiation logic is
> >applied to both server and client.  (Ie, if I spec a minorversion
> >on the server it is no longer free to negotiate any other version,
> >IE if I spec 1 it should *NOT* drop to 0.  It may mean minorversion
> >becomes minorversions or highestminor?So that I can make a
> >server that allows minor={0,1} or even {1,2}, ie I in that second
> >case I want it to NOT use a minor=0 mount.
> The server end is passive. It either supports the minor version specified
> in the RPC by the client and performs the RPC or it replies 
> NFS4ERR_MINOR_VERSION_MISMATCH if it does not support it.
> The FreeBSD server already has sysctls:
> vfs.nfsd.server_min_minorversion4
> vfs.nfsd.server_max_minorversion4
> that allows a sysadmin to limit the minor versions supported.
> 
> I think this satisfies your server requirement?

Yes, it certainly does.

> rick
> > Yours,
> > Daniel Ebdrup Jensen
> Rod Grimes rgri...@freebsd.org
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FYI for aarch64 main [14] running a mid March version: I ended up with [usb{usbus2}] stuck at (near) 100% cpu

[Rodney W. Grimes]

> 
> On 2021-May-14, at 05:52, Rodney W. Grimes  gndrsh.dnsmgr.net> wrote:
> 
> >> Note: The context was using a non-debug main build
> >>  from mid-2021-Mar. (More details identified
> >>  later.)
> >> 
> >> The issue happend while attempting a:
> >> 
> >> # zfs send -R zpold@for-copy | zfs recv -Fdv zpnew
> >> 
> >> where the drives involved in the command were:
> >> 
> >> zpold: a USB3 SSD, using /dev/da0p3
> >> zpnew: an 480 GiByte Optane in the PCIe slot, using /dev/nda0p3
> >> 
> >> with:
> >> 
> >> # gpart show -pl
> >> =>   40  468862048da0  GPT  (224G)
> >> 40 532480  da0p1  4C8GCA72EFI  (260M)
> >> 532520   2008 - free -  (1.0M)
> >> 534528   29360128  da0p2  4C8GCA72swp14  (14G)
> >>   298946564194304 - free -  (2.0G)
> >>   34088960   33554432  da0p4  4C8GCA72swp16  (16G)
> >>   67643392  401217536  da0p3  4C8GCA72zfs  (191G)
> >>  468860928   1160 - free -  (580K)
> >> 
> >> =>40  2000409184ada0  GPT  (954G)
> >>  40  409600  ada0p1  (null)  (200M)
> >>  409640  1740636160  ada0p2  FBSDmacchroot  (830G)
> >>  174104580058720256  ada0p3  FBSDmacchswp0  (28G)
> >>  1799766056   176160768  ada0p4  FBSDmacchswp1  (84G)
> >>  197592682424482400  - free -  (12G)
> >> 
> >> =>   40  937703008nda0  GPT  (447G)
> >> 40 532480  nda0p1  CA72opt0EFI  (260M)
> >> 532520   2008  - free -  (1.0M)
> >> 534528  117440512  nda0p2  CA72opt0swp56  (56G)
> >>  117975040   16777216  - free -  (8.0G)
> >>  134752256  134217728  nda0p4  CA72opt0swp64  (64G)
> >>  268969984  668731392  nda0p3  CA72opt0zfs  (319G)
> >>  937701376   1672  - free -  (836K)
> >> 
> >> The system running was that on /dev/ada0p2 (FBSDmacchroot,
> >> which is UFS instead of ZFS).
> >> 
> >> The [usb{usbus2}] process eventually got stuck-busy, no
> >> more I/O:
> >> 
> >> CPU 0:  0.0% user,  0.0% nice,  100% system,  0.0% interrupt,  0.0% idle
> >> CPU 1:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> >> CPU 2:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> >> CPU 3:  0.4% user,  0.0% nice,  0.0% system,  0.0% interrupt, 99.6% idle
> >> 
> >>  PID USERNAMEPRI NICE SIZE   RES STATEC   TIME CPU 
> >> COMMAND
> >>   15 root-72-   0B   262144B CPU0 0   8:51  99.95% 
> >> [usb{usbus2}]
> >> 
> >> 1295 root -80  20108Ki8092Ki q->bq_   2   0:04   0.00% zfs 
> >> recv -Fdv zpnew{receive_writer_thre}
> >> 1295 root 480  20108Ki8092Ki piperd   2   0:22   0.00% zfs 
> >> recv -Fdv zpnew{zfs}
> >> 1294 root -80  17544Ki7740Ki q->bq_   2   0:01   0.00% zfs 
> >> send -R zpold@for-copy{send_reader_thread}
> >> 1294 root -80  17544Ki7740Ki q->bq_   0   0:00   0.00% zfs 
> >> send -R zpold@for-copy{send_merge_thread}
> >> 1294 root -80  17544Ki7740Ki hdr->b   2   0:00   0.00% zfs 
> >> send -R zpold@for-copy{send_traverse_threa}
> >> 1294 root 520  17544Ki7740Ki range-   3   0:20   0.00% zfs 
> >> send -R zpold@for-copy{zfs}
> >> 
> >> 1036 root -8-   0B1488Ki t->zth   0   0:00   0.00% 
> >> [zfskern{z_checkpoint_discar}]
> >> 1036 root -8-   0B1488Ki t->zth   1   0:00   0.00% 
> >> [zfskern{z_livelist_condense}]
> >> 1036 root -8-   0B1488Ki t->zth   2   0:00   0.00% 
> >> [zfskern{z_livelist_destroy}]
> >> 1036 root -8-   0B1488Ki t->zth   1   0:00   0.00% 
> >> [zfskern{z_indirect_condense}]
> >> 1036 root -8-   0B1488Ki mmp->m   3   0:00   0.00% 
> >> [zfskern{mmp_thread_enter}]
> >> 1036 root -8-   0B1488Ki tx->tx   1   0:00   0.00% 
> >> [zfskern{txg_thread_enter}]
> >> 1036 root -8-   0B1488Ki tx->tx   2   0:00   0.00% 
> >> [zfskern{txg_thread_enter}]
> >> 
> >> I was unable to ^c or ^z the process where I
> >> typed the command. I eventually stopped the
> >> system with "shutdown -p now" from a ssh
> >> session (tha

Re: RFC: changing the default NFSv4 minor version?

[Rodney W. Grimes]

> On Thu, May 13, 2021 at 11:02:35PM +, Rick Macklem wrote:
> >Hi,
> >
> >I believe that NFSv4.1 and NFSv4.2 are now mature in freebsd-current/main.
> >I also believe that NFSv4.1/4.2 is a better protocol than NFSv4.0.
> >(In particular, the sessions mechanism for "exactly once RPC semantics"
> > is a significant improvement over the duplicate request cache for NFSv4.0,
> > plus other improvements.)
> >
> >Right now, the FreeBSD NFSv4 client will use NFSv4.0 unless the
> >"minorversion" mount option is used to set the minor version to 1 or 2.
> >
> >The Linux client uses the highest minor version supported by both
> >client and server by default.

If this "Linux client" is expanded to say client and server (which I
suspect is true as I doubt it would work without support from the
server) then I am good with doing this same "fail to highest
supported version silently" in FreeBSD.

> >I'd like to propose that the default behaviour of the FreeBSD client
> >be changed to do the same, so that NFSv4.1/4.2 will be used when possible.
> >--> The "minorversion" mount option could still be used to override the
> >  above default.
> >
> >I have hesitated doing this change because it could be considered a POLA
> >violation, but I think the change from 4.0->4.1/4.2 will normally be a
> >neutral to positive experience. (To be honest, I suspect most won't notice
> >the change.)
> >
> >How do others feel about this change?
> >
> >rick
> >___
> >freebsd-current@freebsd.org mailing list
> >https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
> 
> Hi Rick,
> 
>   If I understand your plans correctly, you're not going to be making
>   it so that minorversion=N complains?

Ah, I think that if you specify a minorversion and the server
does not support that minorversion it SHOULD complain.  Only
if when a minorversion has NOT been specified should it silently
use the highest common version.

> 
>   In that case, I don't quite understand how it can be a POLA
>   violation, since presumably it'll fall back to NFSv4.0 if that's
>   the only thing that's supported by ntpd on some other system.

Ignoring the ntpd typo, I think ricks concern on POLA is that currently
in FreeBSD if you do NOT specify any minor version you get v4.0 and
only v4.0 even if both sides support v4.2, so with his change things
are suddenly going to change, that may astonish some.  

> 
>   At any rate, I'm all for it since I'm already using NFSv4.2. :)

I support this change with the caveats that it only occurs if the
minorversion is unspecified and this same negotiation logic is
applied to both server and client.  (Ie, if I spec a minorversion
on the server it is no longer free to negotiate any other version,
IE if I spec 1 it should *NOT* drop to 0.  It may mean minorversion
becomes minorversions or highestminor?So that I can make a
server that allows minor={0,1} or even {1,2}, ie I in that second
case I want it to NOT use a minor=0 mount.

> Yours,
> Daniel Ebdrup Jensen
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: More rtsx issues (13.0-R system) was: Re: CURRENT crashes at early boot on Lenovo T540p...

[Rodney W. Grimes]

> On 5/13/21 9:00 PM, Rodney W. Grimes wrote:
> >> On 12.05.2021 21:01, Marc Veldman wrote:
> >>
> >>> I?m not sure if this is an interesting data point or not,
> >>> but a warm boot without the card inserted succeeds after
> >>> a cold boot with the card inserted.
> >>
> >>It could explain, why my tests with "same code path" gave different 
> >> results!
> > 
> > I am suspect of 2 things here, something the bios does that leaves
> > the card in a state that alters the loader's disk probing, and
> > that probling itself leaving the device in a state that our kernel
> > does not like.
> > 
> > I have it very "odd" that I can boot from a rtsx sd card, ie the kernel
> > gets loaded, but fails at "mountroot" phase due to a sd card timeout.
> 
> I am baffled that the loader can read the SD card from a RTS525A. Can you 
> detail 
> the boot process and the SD card partitions.

The loader should just be using BIOS calls and should work with almost
any system that presents the SD card as a bios disk device.  IIRC when
booting with an SD card in the slot the loader finds drives C to E,
which, again IIRC are:
C:  nvme
D:  USB to SATA disk in external enclosure
E:  SD card

> 
> Please show
> 
> kenv | grep smbios.system
rgrimes@e5470:~ % kenv | grep smbios.system
smbios.system.family="Latitude"
smbios.system.maker="Dell Inc."
smbios.system.product="Latitude E5470"
smbios.system.serial="5YK7RF2"
smbios.system.sku="06DE"
smbios.system.uuid="4c4c4544-0059-4b10-8037-b5c04f524632"

> 
> and
> 
> pciconf -lvbc

The output of that was included in my original mail, and is still
in your reply below.
Repeated here:
rtsx0@pci0:3:0:0:   class=0xff rev=0x01 hdr=0x00 vendor=0x10ec 
device=0x525a subvendor=0x1028 subdevice=0x06de
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTS525A PCI Express Card Reader'
bar   [14] = type Memory, range 32, base 0xe100, size 4096, enabled
cap 01[80] = powerspec 3  supports D0 D1 D2 D3  current D0
cap 05[90] = MSI supports 1 message, 64 bit enabled with 1 message
cap 10[b0] = PCI-Express 2 endpoint max data 256(512) RO
 max read 512
 link x1(x1) speed 5.0(5.0) ASPM disabled(L0s/L1) ClockPM 
enabled
ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected
ecap 0003[148] = Serial 1 0001004ce000
ecap 0018[158] = LTR 1
ecap 001e[160] = L1 PM Substates 1


> 
> 
> Anyway can you use the driver from GitHub - version 2.0h so we start with 
> something that work for others.
> 
> Henri
> 
> > If I simply cycle the sd card in and out of its socket and then
> > give the right command string to mountroot it goes on to multiuser
> > without issue.
> > 
> > I'll also note that if I am booting from other disks (nvme or usb)
> > that I get these same sd card timeouts and I have to cycle the
> > card in and out of the socket to use it:
> > 
> > rtsx0: <2.0c Realtek RTS525A PCI MMC/SD Card Reader> mem 
> > 0xe100-0xe1000fff irq 18 at device 0.0 on pci3
> > rtsx0: pci_read_config() error - reg: 0xeeaa
> > rtsx0: Card present
> > mmc0:  on rtsx0
> > rtsx0: CRC error
> > rtsx0: Transfer fail - status: 0x90010080
> > rtsx0: CRC error
> > rtsx0: Transfer fail - status: 0x90010080
> > rtsx0: CRC error
> > rtsx0: Transfer fail - status: 0x90010080
> > rtsx0: CRC error
> > rtsx0: Transfer fail - status: 0x90010080
> > rtsx0: Interrupt card inserted/removed
> > rtsx0: Card absent
> > rtsx0: Interrupt card inserted/removed
> > rtsx0: Card present
> > mmc0:  on rtsx0
> > 
> > (The last 5 lines caused by me removeing/inserting the card)
> > 
> > Further note that this is a different controller chip version,
> > from a Dell E5470:
> > 
> > rtsx0@pci0:3:0:0:   class=0xff rev=0x01 hdr=0x00 vendor=0x10ec 
> > device=0x525a subvendor=0x1028 subdevice=0x06de
> >  vendor = 'Realtek Semiconductor Co., Ltd.'
> >  device = 'RTS525A PCI Express Card Reader'
> >  bar   [14] = type Memory, range 32, base 0xe100, size 4096, enabled
> >  cap 01[80] = powerspec 3  supports D0 D1 D2 D3  current D0
> >  cap 05[90] = MSI supports 1 message, 64 bit enabled with 1 message
> >  cap 10[b0] = PCI-Express 2 endpoint max data 256(512) RO
> >   max read 512
> >   link x1(x1) speed 5.0(5.0) ASPM disabled(L0s/L1) ClockPM 
> > enabled
> >  ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected
> >  ecap 0003[148] = Serial 1 0001004ce000
> >  ecap 0018[158] = LTR 1
> >  ecap 001e[160] = L1 PM Substates 1
> > 
> >> // Lev Serebryakov
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FYI for aarch64 main [14] running a mid March version: I ended up with [usb{usbus2}] stuck at (near) 100% cpu

[Rodney W. Grimes]

> Note: The context was using a non-debug main build
>   from mid-2021-Mar. (More details identified
>   later.)
> 
> The issue happend while attempting a:
> 
> # zfs send -R zpold@for-copy | zfs recv -Fdv zpnew
> 
> where the drives involved in the command were:
> 
> zpold: a USB3 SSD, using /dev/da0p3
> zpnew: an 480 GiByte Optane in the PCIe slot, using /dev/nda0p3
> 
> with:
> 
> # gpart show -pl
> =>   40  468862048da0  GPT  (224G)
>  40 532480  da0p1  4C8GCA72EFI  (260M)
>  532520   2008 - free -  (1.0M)
>  534528   29360128  da0p2  4C8GCA72swp14  (14G)
>298946564194304 - free -  (2.0G)
>34088960   33554432  da0p4  4C8GCA72swp16  (16G)
>67643392  401217536  da0p3  4C8GCA72zfs  (191G)
>   468860928   1160 - free -  (580K)
> 
> =>40  2000409184ada0  GPT  (954G)
>   40  409600  ada0p1  (null)  (200M)
>   409640  1740636160  ada0p2  FBSDmacchroot  (830G)
>   174104580058720256  ada0p3  FBSDmacchswp0  (28G)
>   1799766056   176160768  ada0p4  FBSDmacchswp1  (84G)
>   197592682424482400  - free -  (12G)
> 
> =>   40  937703008nda0  GPT  (447G)
>  40 532480  nda0p1  CA72opt0EFI  (260M)
>  532520   2008  - free -  (1.0M)
>  534528  117440512  nda0p2  CA72opt0swp56  (56G)
>   117975040   16777216  - free -  (8.0G)
>   134752256  134217728  nda0p4  CA72opt0swp64  (64G)
>   268969984  668731392  nda0p3  CA72opt0zfs  (319G)
>   937701376   1672  - free -  (836K)
> 
> The system running was that on /dev/ada0p2 (FBSDmacchroot,
> which is UFS instead of ZFS).
> 
> The [usb{usbus2}] process eventually got stuck-busy, no
> more I/O:
> 
> CPU 0:  0.0% user,  0.0% nice,  100% system,  0.0% interrupt,  0.0% idle
> CPU 1:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 2:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 3:  0.4% user,  0.0% nice,  0.0% system,  0.0% interrupt, 99.6% idle
> 
>   PID USERNAMEPRI NICE SIZE   RES STATEC   TIME CPU 
> COMMAND
>15 root-72-   0B   262144B CPU0 0   8:51  99.95% 
> [usb{usbus2}]
> 
>  1295 root -80  20108Ki8092Ki q->bq_   2   0:04   0.00% zfs 
> recv -Fdv zpnew{receive_writer_thre}
>  1295 root 480  20108Ki8092Ki piperd   2   0:22   0.00% zfs 
> recv -Fdv zpnew{zfs}
>  1294 root -80  17544Ki7740Ki q->bq_   2   0:01   0.00% zfs 
> send -R zpold@for-copy{send_reader_thread}
>  1294 root -80  17544Ki7740Ki q->bq_   0   0:00   0.00% zfs 
> send -R zpold@for-copy{send_merge_thread}
>  1294 root -80  17544Ki7740Ki hdr->b   2   0:00   0.00% zfs 
> send -R zpold@for-copy{send_traverse_threa}
>  1294 root 520  17544Ki7740Ki range-   3   0:20   0.00% zfs 
> send -R zpold@for-copy{zfs}
> 
>  1036 root -8-   0B1488Ki t->zth   0   0:00   0.00% 
> [zfskern{z_checkpoint_discar}]
>  1036 root -8-   0B1488Ki t->zth   1   0:00   0.00% 
> [zfskern{z_livelist_condense}]
>  1036 root -8-   0B1488Ki t->zth   2   0:00   0.00% 
> [zfskern{z_livelist_destroy}]
>  1036 root -8-   0B1488Ki t->zth   1   0:00   0.00% 
> [zfskern{z_indirect_condense}]
>  1036 root -8-   0B1488Ki mmp->m   3   0:00   0.00% 
> [zfskern{mmp_thread_enter}]
>  1036 root -8-   0B1488Ki tx->tx   1   0:00   0.00% 
> [zfskern{txg_thread_enter}]
>  1036 root -8-   0B1488Ki tx->tx   2   0:00   0.00% 
> [zfskern{txg_thread_enter}]
> 
> I was unable to ^c or ^z the process where I
> typed the command. I eventually stopped the
> system with "shutdown -p now" from a ssh
> session (that had already been in place).

Should this occur again before doing the shutdown run a
zpool status &
I have gotten in this state when the recv pool was a usb device
and for some reason it had a timeout and gone offline.  The clue
this occured are in dmesg, and zpool status.

Unplug/plug the USB device, check dmesg that it came online,
and do a zpool clear.

> 
> When I retried after rebooting and scrubbing (no
> problems found), the problem did not repeat.
> 
> I do not have more information nor a way to repeat
> the problem on demand, unfortunately.
> 
> Details of the vintage of the system software and
> such:
> 
> # ~/fbsd-based-on-what-freebsd-main.sh 
> FreeBSD FBSDmacch 14.0-CURRENT FreeBSD 14.0-CURRENT 
> mm-src-n245445-def0058cc690 GENERIC-NODBG  arm64 aarch64 145 145
> def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git 
> context.
> merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
> merge-base: CommitDate: 2021-03-12 20:29:42 +
> 7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all 
> XPT_ASYNC ccbs in a dedicated thread
> n245444 (--first-parent --count for merge-base)
> 
> The system 

Re: HEADSUP: i2c(8) has been washed and ironed

[Rodney W. Grimes]

> I have renovated the i2c(8) program and while I belive all argument
> processing is 100% compatible, various undocumented aspects of the
> program may have changed, amongst these precisely what goes to
> stdout and stderr.
> 
> Apologies if this breaks any of your scripts.
> 
> 


> There is one aspect of this program which I have not changed, but
> which bugs me utterly:  All arguments are in hex, except [-c count]
> which is decimal.
> 
> My personal preference would be if all the arguments called strtoul(3)
> with zero third argument, so that users can use decimal, octal or
> hex as they prefer, but I fear that would break pretty much every
> single script.
> 
> Alternatively [-c count] could be changed to be hex like the rest.

What about adding a new flag to enable strtoul behavior?
Or invoked by another name i2cX and install a hard link?

> 


> p...@freebsd.org | TCP/IP since RFC 956
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

More rtsx issues (13.0-R system) was: Re: CURRENT crashes at early boot on Lenovo T540p...

[Rodney W. Grimes]

> On 12.05.2021 21:01, Marc Veldman wrote:
> 
> > I?m not sure if this is an interesting data point or not,
> > but a warm boot without the card inserted succeeds after
> > a cold boot with the card inserted.
> 
>   It could explain, why my tests with "same code path" gave different results!

I am suspect of 2 things here, something the bios does that leaves
the card in a state that alters the loader's disk probing, and
that probling itself leaving the device in a state that our kernel
does not like.

I have it very "odd" that I can boot from a rtsx sd card, ie the kernel
gets loaded, but fails at "mountroot" phase due to a sd card timeout.
If I simply cycle the sd card in and out of its socket and then
give the right command string to mountroot it goes on to multiuser
without issue.

I'll also note that if I am booting from other disks (nvme or usb)
that I get these same sd card timeouts and I have to cycle the
card in and out of the socket to use it:

rtsx0: <2.0c Realtek RTS525A PCI MMC/SD Card Reader> mem 0xe100-0xe1000fff 
irq 18 at device 0.0 on pci3
rtsx0: pci_read_config() error - reg: 0xeeaa
rtsx0: Card present
mmc0:  on rtsx0
rtsx0: CRC error
rtsx0: Transfer fail - status: 0x90010080
rtsx0: CRC error
rtsx0: Transfer fail - status: 0x90010080
rtsx0: CRC error
rtsx0: Transfer fail - status: 0x90010080
rtsx0: CRC error
rtsx0: Transfer fail - status: 0x90010080
rtsx0: Interrupt card inserted/removed
rtsx0: Card absent
rtsx0: Interrupt card inserted/removed
rtsx0: Card present
mmc0:  on rtsx0

(The last 5 lines caused by me removeing/inserting the card)

Further note that this is a different controller chip version,
from a Dell E5470:

rtsx0@pci0:3:0:0:   class=0xff rev=0x01 hdr=0x00 vendor=0x10ec 
device=0x525a subvendor=0x1028 subdevice=0x06de
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTS525A PCI Express Card Reader'
bar   [14] = type Memory, range 32, base 0xe100, size 4096, enabled
cap 01[80] = powerspec 3  supports D0 D1 D2 D3  current D0
cap 05[90] = MSI supports 1 message, 64 bit enabled with 1 message
cap 10[b0] = PCI-Express 2 endpoint max data 256(512) RO
 max read 512
 link x1(x1) speed 5.0(5.0) ASPM disabled(L0s/L1) ClockPM 
enabled
ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected
ecap 0003[148] = Serial 1 0001004ce000
ecap 0018[158] = LTR 1
ecap 001e[160] = L1 PM Substates 1

> // Lev Serebryakov
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!

[Rodney W. Grimes]

> On 07.05.2021 14:36, Lev Serebryakov wrote:
> 
> >> ?? Looks like there is problem with rtsx driver!
> >  ?Oh, I forgot to add: disabling SD Card Reader in BIOS solves problem!
> > 
> >  ?And console on these crashes is totally dead, and disks are not detected 
> > yet, so I can not look at structures in memory and/or dump core.
> 
>   13.0-RELEASE installation media crashes in same way if SD reader is enabled 
> in BIOS.

Is this with or without media in the SD reader?

I have issues with rtsx on a Dell 5740 in that if the media
in in the drive during boot it times out the rtsx probe, but
after the system is up if I eject and re-insert the media it
comes on line and works fine.

Also if I try to boot from that media it gets all the way
to mountroot, which then fails cause the device did not
pass probe, but if I eject, and reinsert and then type in
the path to root it does continue to boot and properly
start up.

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: sys/sys/param.h: 'main' instead of 'Master'?

[Rodney W. Grimes]

> On Sun, Apr 18, 2021 at 07:07:44PM -0400, Ed Maste wrote:
> > On Fri, 16 Apr 2021 at 16:22, Warner Losh  wrote:
> > >
> > > > > As well as "Origin".
> > > >
> > > > (Single) Source of Truth, maybe?
> > >
> > > s/Master, p/P/ also makes sense.
> > 
> > IMO instead of lightly rewording the existing comment we could just
> > remove it, it doesn't really add any clarity.
> > 
> > Instead we ought to add an introductory sentence or two to the block
> > comment above, explaining what __FreeBSD_version actually is.
> 
> fully agreed here! I had to explained many time what __FreeBSD_version 
> actually
> was. A clear comment would be great ;)

Yes please!


-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: sys/sys/param.h: 'main' instead of 'Master'?

[Rodney W. Grimes]

> n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling  wrote:
> >
> > While viewing sys/sys/param.h I noticed that the comment of the
> > definition of __FreeBSD_version is probably out of date.
> >
> > Since the switch to Git, doesn't it have to be 'main' instead of 'master'?
> >
> 
> This isn't based on a branch name, though I guess if one were going to
> touch it anyways then "Authoritative" would be a better descriptor.

As well as "Origin".

> 
> > #cd /usr/src
> > #diff -urN sys/sys/param.h.orig sys/sys/param.h | colordiff
> > --- sys/sys/param.h.orig2021-04-09 12:59:25.363286000 +0200
> > +++ sys/sys/param.h 2021-04-16 18:28:46.621429000 +0200
> > @@ -60,7 +60,7 @@
> >   * in the range 5 to 9.
> >   */
> >  #undef __FreeBSD_version
> > -#define __FreeBSD_version 147  /* Master, propagated to newvers */
> > +#define __FreeBSD_version 147  /* main, propagated to newvers */
> >
> >  /*
> >   * __FreeBSD_kernel__ indicates that this system uses the kernel of
> > FreeBSD,
> >
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: TCP Connection hang - MSS again

[Rodney W. Grimes]

> 06.04.2021 19:54, Rodney W. Grimes wrote:
> >> 05.04.2021 19:44, Rozhuk Ivan wrote:
> >>
> >>>>> As I understand, in some cases remote host does not reply with MSS
> >>>>> option, and host behind router continue use mss 8960, that dropped
> >>>>> by router.  
> >>>> If the peer does not provide an MSS option, your local FreeBSD based
> >>>> host should use an MSS of net.inet.tcp.mssdflt bytes. The default is
> >>>> 536. So I don't think this should be a problem.
> >>>
> >>> Thats it!
> >>> Thanks, it was ~64k in mine config.
> >>
> >> This is also per-host setting, you know :-)
> >>
> >> It is generally bad idea using MTU over 1500 for an interface facing 
> >> public network
> >> without -mtu 1500. You see, because TCP MSS affects only TCP and there is 
> >> also UDP
> >> that happily produces oversized datagramms for DNS or RTP or NFS or 
> >> tunneling like L2TP or OpenVPN etc.
> >> relying on IP fragmentation.
> >>
> >> I still recommend using -mtu 1500 in addition to mssdflt in your case.
> > 
> > I do not recommend such a setting.  That would defeat any jumbo frame usage
> > locally!
> 
> Why? Default route should not be used for local delivery.

Your right, but we are both making assumptions, I assumed that most
likely the only route on the system is the default route, and your
assuming that they are running with something more than a default
route.

> > The gateway/router that is forwarding packets to the internet connection
> > needs its upstream interface mtu set properly, and configured to properly
> > return icmp need fragement messages on the interfaces towards the
> > internal network.
> 
> This results in extra delays and retransmission during outgoing data 
> transfer, not good.
> The mechanics is much more fragile than default route's mtu attribute.

The delay should be pretty slight, the router is going to return an
icmp message, and if configured to do so frag the packets and
forward them on, no retransmission would occur as the DF flag
is not normally set unless explicitly requested.

It still makes no since to me to increase the interface MTU and then
crank it back down by using a route MTU.  You might as well just leave
the MTU alone and not have 2 configurations items more or less doing
nothing.

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: TCP Connection hang - MSS again

[Rodney W. Grimes]

> 05.04.2021 19:44, Rozhuk Ivan wrote:
> 
> >>> As I understand, in some cases remote host does not reply with MSS
> >>> option, and host behind router continue use mss 8960, that dropped
> >>> by router.  
> >> If the peer does not provide an MSS option, your local FreeBSD based
> >> host should use an MSS of net.inet.tcp.mssdflt bytes. The default is
> >> 536. So I don't think this should be a problem.
> > 
> > Thats it!
> > Thanks, it was ~64k in mine config.
> 
> This is also per-host setting, you know :-)
> 
> It is generally bad idea using MTU over 1500 for an interface facing public 
> network
> without -mtu 1500. You see, because TCP MSS affects only TCP and there is 
> also UDP
> that happily produces oversized datagramms for DNS or RTP or NFS or tunneling 
> like L2TP or OpenVPN etc.
> relying on IP fragmentation.
> 
> I still recommend using -mtu 1500 in addition to mssdflt in your case.

I do not recommend such a setting.  That would defeat any jumbo frame usage
locally!

The gateway/router that is forwarding packets to the internet connection
needs its upstream interface mtu set properly, and configured to properly
return icmp need fragement messages on the interfaces towards the
internal network.

This leaking of jumbo frames to the Internet is almost always caused
by blockage of icmp packets internal to a network, and doing that
forces one to run on an mtu that is acceptable to the global Internet,
a far from optimal situation.

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 13.0-RC5 Now Available

[Rodney W. Grimes]

> On 4/3/21 3:34 PM, Glen Barber wrote:
> > The fifth RC build of the 13.0-RELEASE release cycle is now available.
> > 
> 
> Beautiful. If we see RC8 then that is fine. Testing is a wonderful
> process and I feel far better about a well tested release than an
> instant "oops" with 13.1 kicked out a week later.

BUT this is not more testing for the sake of good testing, this
is purely incidental testing because of regressions in the product.
This is, IMHO, the worst kind of testing.

> 
> Also, I really am waiting to see the ten year old bug 159356 laid
> to rest :
> 
> [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-specific
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=159356
> 
> Sort of a thorn in my side for years. Regardless, release candidates
> are a "good thing"(tm).

Not really, they indicate a lack of Quality Assurance and Control,
and without those principles you can test tell your blue in the
face and never actually get anyplace.

There is a premise in the product quality assurance sector,
"You cannot test in quality".

> 
> -- 
> Dennis Clarke
> RISC-V/SPARC/PPC/ARM/CISC
> UNIX and Linux spoken
> GreyBeard and suspenders optional

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: testers needed: loader: use display pixel density for font autoselection

[Rodney W. Grimes]

> > On 26. Feb 2021, at 17:56, Rodney W. Grimes  
> > wrote:
> > 
> >>> On 26. Feb 2021, at 05:42, Rodney W. Grimes  
> >>> wrote:
> >>> 
> >>>>> On 23. Feb 2021, at 17:53, Jakob Alvermark  wrote:
> >>>>> 
> >>>>> On 2/23/21 12:27 PM, Toomas Soome via freebsd-current wrote:
> >>>>>> hi!
> >>>>>> 
> >>>>>> I have done some work to make font pickup a bit smarter (hopefully 
> >>>>>> better;), but my own ability to test is limited to one bugged 
> >>>>>> supermicro and one MBP with retina display?
> >>>>>> 
> >>>>>> The phab link ishttps://reviews.freebsd.org/D28849  
> >>>>>> <https://reviews.freebsd.org/D28849>
> >>>>>> 
> >>>>>> I have built loader binaries as well (bios and uefi):
> >>>>>> loader_lua<http://148-52-235-80.sta.estpak.ee/loader_lua>
> >>>>>> loader_lua.efi<http://148-52-235-80.sta.estpak.ee/loader_lua.efi>

I have tested this on:
Lenovo W530
Dell E5470
Acer Aspire 1410

all work fine with resonable display resolution.

One more comment below...

> >>>>>> 
> >>>>>> To test, you should remove screen.font= line from loader.conf and test 
> >>>>>> with different resolutions.
> >>>>>> 
> >>>>>> thanks,
> >>>>>> toomas
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> Hi Toomas,
> >>>>> 
> >>>>> 
> >>>>> I tested on five different setups.
> >>>>> 
> >>>>> Surface Pro 10.6"@1920x1080:
> >>>>> 
> >>>>> The loader menu looks different, the "FreeBSD" text is on the right 
> >>>>> side of the screen.
> >>>> 
> >>>> 
> >>>> I think, this was the lua script bug we did fix not too long time ago.
> >>>> 
> >>>>> 
> >>>>> Otherwise, the font size is what I would call a normal size.
> >>>>> 
> >>>>> 
> >>>>> Acer laptop 11.6"@1366x768:
> >>>>> 
> >>>>> Menu looks fine. Almost fills the entire screen.
> >>>>> 
> >>>>> The font feels a little too big.
> >>>> 
> >>>> 
> >>>> The laptop built in displays usually do not give out EDID (we get 
> >>>> physical dimensions from EDID), so there we fall back to try to get 
> >>>> 80x25 terminal method.
> >>> 
> >>> I am having a hard time with that statement.  EDID is very common on 
> >>> laptop screens, infact I can not recall ever not seeing EDID on a laptops 
> >>> builtin screen.
> >>> My 11" acer 1400 has EDID in it.
> >>> 
> >>> 
> >> 
> >> 
> >> If there is EDID, then it is all good. I have seen cases we do not get it 
> >> with available API.
> > 
> > Is there a way for me to know if the laoder found EDID data or not?
> > It might be that the issue is that what ever loader is using for an API is 
> > not working.
> > I based my "EDID is very common on laptop screens" on the fact that X11 
> > almost always finds EDID.
> > 
> 
> Yes, gop get / vbe list   ? yes, it is inconsistent, should fix at some 
> point? :)
> 
> we do use gop get active edid/get discovered edid protocol and vbe function 
> 0x4f15.

On all my handy laptops, E5470, T400, W530, Acer 1410 edid is present and seen
by the loader.


> 
> rgds,
> toomas

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: KTLS with zfs recv

[Rodney W. Grimes]

> On Fri, Feb 26, 2021 at 9:24 AM Rodney W. Grimes <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
> 
> > > My understanding is that KTLS works very well with OpenSSL for sending,
> > but
> > > not as well for receiving, because there's nothing like a recvfile
> > > syscall.  However, it works great for both send and receive with NFS,
> > where
> > > all the data remains in the kernel. What about zfs recv?  A very common
> > > pattern is for an application to read from an SSL socket and then pipe
> > the
> > > data to zfs recv. For example, zrepl does that.  Could zfs recv instead
> > > read directly from the KTLS socket, bypassing userspace?  That could
> > > potentially save a _lot_ of cycles for a _lot_ of people.
> >
> > I did some patches and a short presentation at BSDCan that basically
> > shoves the whole zfs send and zfs recv process into the kernel, ie
> > it opens the sockets up, makes the connections, then the socket
> > is passed into the kernel(s) and it all runs in kernel mode.
> >
> >
> > https://www.bsdcan.org/2018/schedule/attachments/479_BSDCan-2018-zfs-send.pdf
> >
> > A few things need fixed like reversing who does the listen for
> > security reasons, but this feature is probably ready for prime
> > time.
> >
> > > -Alan
> >
> > --
> > Rod Grimes
> > rgri...@freebsd.org
> 
> 
> That looks potentially useful, but it doesn't use encryption.  Would it
> work if the socket had been opened by openssl with ktls?

Alan,
Should I revise the code to meet the state that was discussed
during the BSDCan talk so that it can be committed?  Matt Aherns said
at the time he felt if I just reversed the listen/connect relationship
between send and recv that it addressed enough of the security concern
to be usable "on a local and well administered" network and would
probably be safe to import into upstream ZFS.  (This was prior to
FreeBSD moving to openzfs.)

>From other discussion in this thread it does not sound difficult to
implement the KTLS end of it, but I doubt that would be portable
enough to upstream, maybe someone can speak to that issue?

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: KTLS with zfs recv

[Rodney W. Grimes]

> On Fri, Feb 26, 2021 at 9:24 AM Rodney W. Grimes <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
> 
> > > My understanding is that KTLS works very well with OpenSSL for sending,
> > but
> > > not as well for receiving, because there's nothing like a recvfile
> > > syscall.  However, it works great for both send and receive with NFS,
> > where
> > > all the data remains in the kernel. What about zfs recv?  A very common
> > > pattern is for an application to read from an SSL socket and then pipe
> > the
> > > data to zfs recv. For example, zrepl does that.  Could zfs recv instead
> > > read directly from the KTLS socket, bypassing userspace?  That could
> > > potentially save a _lot_ of cycles for a _lot_ of people.
> >
> > I did some patches and a short presentation at BSDCan that basically
> > shoves the whole zfs send and zfs recv process into the kernel, ie
> > it opens the sockets up, makes the connections, then the socket
> > is passed into the kernel(s) and it all runs in kernel mode.
> >
> >
> > https://www.bsdcan.org/2018/schedule/attachments/479_BSDCan-2018-zfs-send.pdf
> >
> > A few things need fixed like reversing who does the listen for
> > security reasons, but this feature is probably ready for prime
> > time.
> >
> > > -Alan
> >
> > --
> > Rod Grimes
> > rgri...@freebsd.org
> 
> 
> That looks potentially useful, but it doesn't use encryption.  Would it
> work if the socket had been opened by openssl with ktls?

Yes, it should.  Internally the zfs send and recv code just does reads
and writes to the socket, so what ever you setup for "connected" sockets
should work.

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: KTLS with zfs recv

[Rodney W. Grimes]

> My understanding is that KTLS works very well with OpenSSL for sending, but
> not as well for receiving, because there's nothing like a recvfile
> syscall.  However, it works great for both send and receive with NFS, where
> all the data remains in the kernel. What about zfs recv?  A very common
> pattern is for an application to read from an SSL socket and then pipe the
> data to zfs recv. For example, zrepl does that.  Could zfs recv instead
> read directly from the KTLS socket, bypassing userspace?  That could
> potentially save a _lot_ of cycles for a _lot_ of people.

I did some patches and a short presentation at BSDCan that basically
shoves the whole zfs send and zfs recv process into the kernel, ie
it opens the sockets up, makes the connections, then the socket
is passed into the kernel(s) and it all runs in kernel mode.

https://www.bsdcan.org/2018/schedule/attachments/479_BSDCan-2018-zfs-send.pdf

A few things need fixed like reversing who does the listen for
security reasons, but this feature is probably ready for prime
time.

> -Alan

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: testers needed: loader: use display pixel density for font autoselection

[Rodney W. Grimes]

> > On 26. Feb 2021, at 05:42, Rodney W. Grimes  
> > wrote:
> > 
> >>> On 23. Feb 2021, at 17:53, Jakob Alvermark  wrote:
> >>> 
> >>> On 2/23/21 12:27 PM, Toomas Soome via freebsd-current wrote:
> >>>> hi!
> >>>> 
> >>>> I have done some work to make font pickup a bit smarter (hopefully 
> >>>> better;), but my own ability to test is limited to one bugged supermicro 
> >>>> and one MBP with retina display?
> >>>> 
> >>>> The phab link ishttps://reviews.freebsd.org/D28849  
> >>>> <https://reviews.freebsd.org/D28849>
> >>>> 
> >>>> I have built loader binaries as well (bios and uefi):
> >>>> loader_lua<http://148-52-235-80.sta.estpak.ee/loader_lua>
> >>>> loader_lua.efi<http://148-52-235-80.sta.estpak.ee/loader_lua.efi>
> >>>> 
> >>>> To test, you should remove screen.font= line from loader.conf and test 
> >>>> with different resolutions.
> >>>> 
> >>>> thanks,
> >>>> toomas
> >>> 
> >>> 
> >>> 
> >>> Hi Toomas,
> >>> 
> >>> 
> >>> I tested on five different setups.
> >>> 
> >>> Surface Pro 10.6"@1920x1080:
> >>> 
> >>> The loader menu looks different, the "FreeBSD" text is on the right side 
> >>> of the screen.
> >> 
> >> 
> >> I think, this was the lua script bug we did fix not too long time ago.
> >> 
> >>> 
> >>> Otherwise, the font size is what I would call a normal size.
> >>> 
> >>> 
> >>> Acer laptop 11.6"@1366x768:
> >>> 
> >>> Menu looks fine. Almost fills the entire screen.
> >>> 
> >>> The font feels a little too big.
> >> 
> >> 
> >> The laptop built in displays usually do not give out EDID (we get physical 
> >> dimensions from EDID), so there we fall back to try to get 80x25 terminal 
> >> method.
> > 
> > I am having a hard time with that statement.  EDID is very common on laptop 
> > screens, infact I can not recall ever not seeing EDID on a laptops builtin 
> > screen.
> > My 11" acer 1400 has EDID in it.
> > 
> > 
> 
> 
> If there is EDID, then it is all good. I have seen cases we do not get it 
> with available API.

Is there a way for me to know if the laoder found EDID data or not?
It might be that the issue is that what ever loader is using for an API is not 
working.
I based my "EDID is very common on laptop screens" on the fact that X11 almost 
always finds EDID.

> >>> 
> >>> Thinkpad built in 13"@1920x1080:
> >>> 
> >>> Menu looks fine, but a little slow.
> >>> 
> >>> The font size is a little to big for my liking. When drm loads and 
> >>> mirrors the screen to my external 27" it looks comically large.
> >>> 
> >> 
> >> There is another issue - once DRM will kick in, we should re-consider the 
> >> console attributes, like fonts, but at this time, the kernel itself only 
> >> can use what was built in (8x16), or what loader was offering (default if 
> >> present). So it is up to user to act there.
> > 
> > It would be really nice if DRM could pick up what the resolution and font 
> > was when it loaded!
> 
> it should do more, my supermicro X10SAE is ony doing 800x600 with UEFI, it 
> has dell 27? 4k monitor connected. VBE can get 1600x1200 from the same set. 
> What I would like to see is, once KMS is attached (i915), I?d like to get 
> bets possible resolution and appropriate font. But thats something for future 
> work.
> 
> > 
> >> 
> >>> 
> >>> Thinkpad external 24"@1920x1200:
> >>> 
> >>> Menu looks OK, uses about a quarter of the screen.
> >>> 
> >>> Font size is fine, but once drm loads it looks a bit squeezed (like thin 
> >>> and tall), but I guess that's drm detecting the built in 1920x1080, and 
> >>> the external display is stretched.
> >>> 
> >>> 
> >>> Thinkpad external 27"@3840x2160:
> >>> 
> >>> Menu looks OK, uses about a quarter of the screen.
> >>> 
> >>> Font size is fine.
> >>> 
> >>> Looking at the dmesg though, it says: VT(efifb): resolution 1920x1080
> >>> 
> >>>

Re: testers needed: loader: use display pixel density for font autoselection

[Rodney W. Grimes]

> > On 23. Feb 2021, at 17:53, Jakob Alvermark  wrote:
> > 
> > On 2/23/21 12:27 PM, Toomas Soome via freebsd-current wrote:
> >> hi!
> >> 
> >> I have done some work to make font pickup a bit smarter (hopefully 
> >> better;), but my own ability to test is limited to one bugged supermicro 
> >> and one MBP with retina display?
> >> 
> >> The phab link ishttps://reviews.freebsd.org/D28849  
> >> 
> >> 
> >> I have built loader binaries as well (bios and uefi):
> >> loader_lua
> >> loader_lua.efi
> >> 
> >> To test, you should remove screen.font= line from loader.conf and test 
> >> with different resolutions.
> >> 
> >> thanks,
> >> toomas
> > 
> > 
> > 
> > Hi Toomas,
> > 
> > 
> > I tested on five different setups.
> > 
> > Surface Pro 10.6"@1920x1080:
> > 
> > The loader menu looks different, the "FreeBSD" text is on the right side of 
> > the screen.
> 
> 
> I think, this was the lua script bug we did fix not too long time ago.
> 
> > 
> > Otherwise, the font size is what I would call a normal size.
> > 
> > 
> > Acer laptop 11.6"@1366x768:
> > 
> > Menu looks fine. Almost fills the entire screen.
> > 
> > The font feels a little too big.
> 
> 
> The laptop built in displays usually do not give out EDID (we get physical 
> dimensions from EDID), so there we fall back to try to get 80x25 terminal 
> method.

I am having a hard time with that statement.  EDID is very common on laptop 
screens, infact I can not recall ever not seeing EDID on a laptops builtin 
screen.
My 11" acer 1400 has EDID in it.


> > 
> > Thinkpad built in 13"@1920x1080:
> > 
> > Menu looks fine, but a little slow.
> > 
> > The font size is a little to big for my liking. When drm loads and mirrors 
> > the screen to my external 27" it looks comically large.
> > 
> 
> There is another issue - once DRM will kick in, we should re-consider the 
> console attributes, like fonts, but at this time, the kernel itself only can 
> use what was built in (8x16), or what loader was offering (default if 
> present). So it is up to user to act there.

It would be really nice if DRM could pick up what the resolution and font was 
when it loaded!

> 
> > 
> > Thinkpad external 24"@1920x1200:
> > 
> > Menu looks OK, uses about a quarter of the screen.
> > 
> > Font size is fine, but once drm loads it looks a bit squeezed (like thin 
> > and tall), but I guess that's drm detecting the built in 1920x1080, and the 
> > external display is stretched.
> > 
> > 
> > Thinkpad external 27"@3840x2160:
> > 
> > Menu looks OK, uses about a quarter of the screen.
> > 
> > Font size is fine.
> > 
> > Looking at the dmesg though, it says: VT(efifb): resolution 1920x1080
> > 
> > 
> > Jakob
> > 
> 
> 
> Those cases .. I suppose the menu was still at left side, not in middle? The 
> thing there is, our menu is designed for 80x25 screen, with respective 
> constants. 

SO again... why are we deviating from that causing us issues?

> 
> many thanks for testing,

I have downloaded your modified loader, and put it in place, it shall get 
tested on my next reboot, which should be soon as 13-BETA4 should be popping 
out soon.

> toomas
> 
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: loader/boot fonts are painfully small (again)

[Rodney W. Grimes]

> 
> 
> > On 11. Feb 2021, at 23:21, Yuri Pankov  wrote:
> > 
> > Lenovo P51 laptop, 15'' 4k (3840x2160) display.
> > 
> > Booting from the latest available current snapshot (20210107), fonts
> > were at least readable; updating to the latest bits (manually installing
> > new loader as well) made them really small -- terminal size reported by
> > stty is 480x135.
> > 
> 
> It is a issue about not so good automatic font size setup. The original code 
> was using 80x24 terminal as base, it was complained it did end up with too 
> large fonts, so I did pick uefi terminal size as base (see output from mode 
> command), but thats also not perfect. Till better solution, right now the 
> option is to set font manually (screen.font variable).

Can we just stick with the "known to work almost everywhere and always"
default value of 80x24?  These small fonts are great for those of you
who have 20/20 un corrected vision, but it is a royal PITA for almost
anyone who has even a slight visual imparement, even corrected I find
it near imposible to read the default efi screens we put up.

I would suggest we also override this in the -RELEASE/SNAPSHOT
media as one just does not need to fight this font size issue
while trying to install a new system.

Thanks,
Rod
> 
> > I have also noticed large delays between different loader screens,
> > probably caused by very slow screen blanking given the terminal size?
> 
> yes, it definitely needs boost.There are few things we can do about it.
> 
> rgds,
> toomas
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: cgit: orientation

[Rodney W. Grimes]

> On Tue, Feb 9, 2021 at 5:52 PM Warner Losh  wrote:
> 
> >
> >
> > On Tue, Feb 9, 2021 at 5:47 PM Graham Perrin 
> > wrote:
> >
> >> Given this, for example:
> >>
> >> <
> >> https://cgit.freebsd.org/src/commit/?id=174a7e578a33c01401e33f9bfcc077fc3155251c=stable%2F12

This link probably came from someone copying it out of the address bar
from some browswer, the better way to get a link out of a cgit page
is to copy it from the commit: hash line that looks like:

commit 174a7e578a33c01401e33f9bfcc077fc3155251c (patch)

Right click on the hash and select copy link location.

> >> >
> >>
> >> ? with 'stable' in the URL and 'stable/12' visible in the page ? how
> >> would a reader know that the commit was to main (not stable/12)?
> >>
> >> Is there scope to make improved use of cgit, or is this a limitation of
> >> cgit?
> >>
> >
> > There's a pulldown in the upper right corner that says 'stable/12' though
> > it took me a while to find it as my eyes glided over it a couple of times.
> >
> 
> But that is due to the stable%2F12 in the URL... W/o it, it's no good.
^^ extra word?
I think you meant to say "It is good".

> Warner
> 
> Warner
> >
> >
> >> TIA
> >>
> >> ___
> >> freebsd-...@freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-git
> >> To unsubscribe, send any mail to "freebsd-git-unsubscr...@freebsd.org"
> >>
> >
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Failure of release build with release.sh on 14-CURRENT amd64

[Rodney W. Grimes]

-- Start of PGP signed section.
> On Mon, Feb 01, 2021 at 05:13:42PM -0800, Rodney W. Grimes wrote:
> 
> >One could build your own local pkg repository that contained pkg
> >and what ever other pkg's are needed during a make release and
> >modify the /etc/pkg/FreeBSD.conf file to point at it as a way
> >to work around this .
> 
> Thanks for the suggestion, might try that. I guess here you're thinking
> poudriere?

I think it is just a small set of pkg's you need so, no not poudriere,
was just thinking cd /usr/src/.../pkg; make package; cp pkg*.tgz 
/place/for/packages

> -- 
> J.
-- End of PGP section, PGP failed!

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Failure of release build with release.sh on 14-CURRENT amd64

[Rodney W. Grimes]

On some day Glen Barber wrote:
> On Mon, Feb 01, 2021 at 09:38:33PM +, tech-lists wrote:
> > On Mon, Feb 01, 2021 at 09:27:44PM +, Glen Barber wrote:
> > > On Sun, Jan 31, 2021 at 03:30:14PM +, tech-lists wrote:
> > > > Found
> > > > A pre-built version of pkg could not be found for your system.
> > > > Consider changing PACKAGESITE or installing it from ports:
> > > > 'ports-mgmt/pkg'.
> > > > 
> > > > root@generic:/usr/src/release # which pkg
> > > > /usr/sbin/pkg
> > > > 
> > > 
> > > This is because the 14.0-CURRENT packages for arm64 take a significant
> > > amount of more time to build than x86.
> > 
> > Hi,
> > 
> > Is there a way of making it use the pkg which is already installed on the 
> > system
> > running make release?
> > 
> 
> No.  /usr/sbin/pkg is the bootstrap tool to install /usr/local/sbin/pkg.
> It does not have the same functionality.

One could build your own local pkg repository that contained pkg
and what ever other pkg's are needed during a make release and
modify the /etc/pkg/FreeBSD.conf file to point at it as a way
to work around this .

> Glen

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Enabling AESNI by default

[Rodney W. Grimes]

> We've had the AESNI module for quite a few years now, and it has not
> caused any problems.
> 
> I am wondering if there are any objections to including it in GENERIC,
> so that users get the benefit without having to have the "tribal
> knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc),
> you need to load aesni.ko'
> 
> Userspace crypto that uses openssl or similar libraries is already
> taking advantage of these CPU instructions if they are available, by
> excluding this feature from GENERIC we are just causing the "out of the
> box" experience to by very very slow for crypto.
> 
> For example, writing 1MB blocks to a GELI encrypted swap-backed md(4)
> device:
> 
> with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz
> 
> fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m
> --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync
> --group_reporting --fallocate=none --runtime=60 --time_based
> 
> 
> stock:
> write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec)
> 
> with aesni.ko loaded:
> write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec)
> 
> 
> Does anyone have a compelling reason to deny our users the 5x speedup?

Its for ever dead code on a large number of machines that do not have
the hardware for it.  I know that is a decreasing set, but imho it
would be better to somehow ONLY load the module if you had CPU
support for it.  The down side is that detection would probably have
to be in the laoder as this code can be used very early on.

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Plans for git

[Rodney W. Grimes]

> On Sat, Sep 19, 2020, 2:44 PM Lucas Nali de Magalh?es 
> wrote:
> 
> > Just My 2??
> >
> > On Sep 3, 2020, at 5:19 PM, Warner Losh  wrote:
> >
> > ?On Thu, Sep 3, 2020 at 1:32 PM Chris  wrote:
> >
> > On 2020-09-03 11:33, Kristof Provost wrote:
> >
> > On 3 Sep 2020, at 19:56, Chris wrote:
> >
> > Why was the intention to switch NOT announced as such MUCH sooner?
> >
> >
> > There was discussion about a possible switch to git on the freebsd-git
> >
> > mailing
> >
> > list as early as February 2017:
> >
> >
> > https://lists.freebsd.org/pipermail/freebsd-git/2017-February/92.html
> >
> >
> > Ed gave a talk about FreeBSD and git back in 2018:
> >
> > https://www.youtube.com/watch?v=G8wQ88d85s4
> >
> >
> > The Git Transition Working group was mentioned in the quarterly status
> >
> > reports a
> >
> > year ago:
> >
> > https://www.freebsd.org/news/status/report-2019-07-2019-09.html
> >
> > and
> >
> > https://www.freebsd.org/news/status/report-2019-04-2019-06.html
> >
> > It appears to me that the references you make here all allude to
> >
> > _investigation_
> >
> > of a _possibility_ as opposed to a _likelihood_, or an _inevitable_.
> >
> > IMHO a change as significant as this, which will require tossing years of
> >
> > tooling
> >
> > out the window, and an untold amount of _re_tooling. Should have created an
> >
> > announcement at _least_ as significant as a new release gets on the mailing
> >
> > lists.
> >
> >
> >
> > Yes. We've been working on this for years. We've been working on the
> > retooling in earnest for the last 6 months. We didn't make an announcement
> > because we wanted to have most of the pieces in place before we did that.
> > We've been doing the multi-year process for multiple years now. I'll also
> > point out that only the 'git' people showed. A number of other ideas were
> > suggested, but nothing else was stood up in a serious way (hg came the
> > closest to setting up an exporter). Since there was really no alternatives
> > being proposed to git, the process was less visible than if we'd had to
> > have had a hg vs git bake off. One step has lead to the next, with much
> > status reporting done for years.
> >
> > Subversion, btw, is not viable in the long run. The Apache foundation has
> > moved all its projects from svn to git. The velocity of features with svn
> > has diminished, and the number of CI/CT/etc tool sets that supported svn
> > well has been dropping over time. It's also been identified as a barrier to
> > entry for the project. Sure, some people climb the learning curve to learn
> > and understand it, but our survey data has shown that for every one that
> > did take the time, many others did not and simply didn't contribute.
> >
> > All of these issues have been discussed at length at conferences for the
> > last 5 years at least, with increasing levels of sophistication. Had there
> > been a BSDcan this year, I'd hoped to do a talk / BOF on this to help
> > socialize the ideas and to get people's feedback in real time (rather than
> > the slow and difficult process of getting it just in email).
> >
> > We've also talked about this in the BSD office hours and core election
> > forums over the past year.
> >
> > We've been rolling out the beta git repo now for 3 months. People have
> > found issues and we've been correcting them. We've heard from people that
> > their automated tooling needs a bit of transition time, so we'll be
> > exporting the stable/11 and stable/12 branches back into subversion (and
> > the release branches) after the conversion for the life of those
> > branches, though we don't plan on doing it for the current nor stable/13
> > branches (due to the inefficiencies of git-svn, we need separate trees for
> > each, and each tree takes over a day to setup). We know we need some better
> > docs (we have some decent preliminary ones, but there's some missing bits
> > in them, and they are too long for more casual users). We need to spell out
> > different commit policies, how we're going to have to shift our "MFC"
> > terminology because that's very CVS/SVN centric (in git a merge means a
> > more specific thing than it does in svn. A cherry-pick in git is also
> > called a merge in svn, for example). We need to document to the developers
> > how to make the shift (this doc is mostly complete and was posted earlier,
> > though it could use some TLC). We'd hoped to have the documents done, the
> > policies written and vetted and have a good test system before making an
> > announcement. The last thing I wanted was to make a big announcement, only
> > to fail to deliver. And since each step of the process followed naturally,
> > there wasn't a clear A/B decision point where an announcement could have
> > been generated. We were getting close to publishing the final schedule when
> > this thread popped up, though, since it is finally feeling like it will be
> > real soon. I also had hoped to refine things so that existing developers
> > and 

Re: Deprecating ftpd in the FreeBSD base system?

[Rodney W. Grimes]

> In message  om>
> , Ed Maste writes:
> > FTP is (becoming?) a legacy protocol, and I think it may be time to
> > remove the ftp server from the FreeBSD base system - with the recent
> > security advisory for ftpd serving as a reminder.
> >
> > I've proposed adding a deprecation notice to the man page in
> > https://reviews.freebsd.org/D26447 to start this off. There are a
> > number of ftp servers in ports, and if we're going to remove the base
> > system one we can create a port for it first, as well.
> >
> > Any comments or concerns, please follow up in the code review or in email 
> > her
> > e.
> 
> We should also deprecate the FTP client.
> 
> I've been advocating removing FTP (and HTTP) from libfetch as well. People 
> should be using HTTPS only. (libfetch could support a plugin that might be 
> supplied by a port should someone be inclined to write one.)

All the world is NOT the internet, there are far to many
uses and places that do not need or warrant https, or sftp
to make this type of move.

It is already become very annoying that certain infustructure
now only supports https for what is data that has no security
concern.

Please do NOT remove the ftp client, or the ability of fetch
to use ftp or http protocols.

> 
> FTP is firewall unfriendly.

Passive mode solved that decades ago.

> 
> The F5 gateway at $JOB does not support FTP. When we still worked at the 
> office I had to take my $JOB laptop to the coffee shop to use their 
> wireless to download patches from Broadcom's FTP site. Now that I WFH (we 
> won't ever go back to the office) I download while disconnected from the 
> VPN.

I believe this is mis-information on F5 gateways, I know that at least
some of them can be configure to support ftp.  Any gateway/firewall
that can not be configure to support passive mode ftp is.. um... broken.

> Then move the removed bits to ports, which I think we already have in tnftp 
> and tnftpd.
> 
> 
> -- 
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  https://FreeBSD.org
> NTP:   Web:  https://nwtime.org
> 
>   The need of the many outweighs the greed of the few.
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Plans for git (was: Please check the current beta git conversions)

[Rodney W. Grimes]

> 
> 
> > On Sep 1, 2020, at 10:59 PM, Greg 'groggy' Lehey  wrote:
> > 
> > On Tuesday,  1 September 2020 at 13:14:10 -0400, Ed Maste wrote:
> >> We've been updating the svn-git converter and pushing out a new
> >> converted repo every two weeks, and are now approaching the time where
> >> we'd like to commit to the tree generated by the exporter,
> >> ...
> > 
> > Somehow I've missed this development.  Reading between the lines, it
> > seems that we're planning to move from svn to git, but I can't recall
> > seeing any announcement on the subject.  Can you give some background?
> > It would also be nice to find a HOWTO both for the migration and for
> > life with git.
> 
> We?ve been talking about the transition for about 5 years now. So far, only 
> people interested in git have showed up to do any work at all. Subversion has 
> lost, and even Apache, the main users of it, are moving to git. We started 
> early in the year with the firm plans and have been working on it since then. 
> These conversations have happened all over the place, and we?ve been posting 
> to developers for months now...

To the contrary 5 years ago the project on @developers basically 
ran off one of the committers over the very idea of using git
for the project.  It was shortly after I returned, so I find it
very ironic that now its all "git git git and we being heading
to this for 5 years"

Would you expect those opposed to this idea to help with it? Really?

> There?s some draft guides, but they need work which is on my plate. They are 
> OK, but have some issues on the more complicated bits.
> 
> Warner

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: nightly snapshot for CURRENT ?

[Rodney W. Grimes]

> On Mon, Jul 27, 2020 at 04:23:22PM +0200, Emmanuel Vadot wrote:
> > On Mon, 27 Jul 2020 14:14:13 +
> > Glen Barber  wrote:
> > 
> > > On Sat, Jul 25, 2020 at 12:29:42PM +0200, Emmanuel Vadot wrote:
> > > > On Fri, 24 Jul 2020 22:28:39 +
> > > > Glen Barber  wrote:
> > > > 
> > > > > On Sat, Jul 25, 2020 at 12:14:52AM +0200, Emmanuel Vadot wrote:
> > > > > > On Fri, 24 Jul 2020 22:06:07 +
> > > > > > Glen Barber  wrote:
> > > > > > 
> > > > > > > On Fri, Jul 24, 2020 at 10:31:35PM +0200, Emmanuel Vadot wrote:
> > > > > > > > On Tue, 9 Jun 2020 22:04:07 +0200
> > > > > > > > Emmanuel Vadot  wrote:
> > > > > > > > 
> > > > > > > > > On Tue, 9 Jun 2020 19:56:30 +
> > > > > > > > > Glen Barber  wrote:
> > > > > > > > > 
> > > > > > > > > > On Tue, Jun 09, 2020 at 09:47:56PM +0200, Emmanuel Vadot 
> > > > > > > > > > wrote:
> > > > > > > > > > > 
> > > > > > > > > > >  Hello all,
> > > > > > > > > > > 
> > > > > > > > > > >  I've just hit again something that I've hit (and 
> > > > > > > > > > > probably others too)
> > > > > > > > > > > often.
> > > > > > > > > > >  If a change in base break some ports and it's snapshoted 
> > > > > > > > > > > in the txz
> > > > > > > > > > > available at download.freebsd.org, you need to wait a 
> > > > > > > > > > > week for the next
> > > > > > > > > > > tarball to be available.
> > > > > > > > > > >  Since poudriere uses the tarball when you setup a jail 
> > > > > > > > > > > it means that
> > > > > > > > > > > the only solution you have is to recreate your jail by 
> > > > > > > > > > > building it, and
> > > > > > > > > > > since building world nowdays is very expensive that delay 
> > > > > > > > > > > your work too
> > > > > > > > > > > much.
> > > > > > > > > > >  Would it be possible to generate the tarballs every day 
> > > > > > > > > > > instead of
> > > > > > > > > > > every week ? At least for tier-1 arches.
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Let's revisit this sometime next week after 11.4 is out.
> > > > > > > > > > 
> > > > > > > > > > Glen
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > >  Sure, works for me.
> > > > > > > > > 
> > > > > > > > >  Thanks,
> > > > > > > > > 
> > > > > > > > 
> > > > > > > >  Ping ?
> > > > > > > > 
> > > > > > > 
> > > > > > > I thought the artifacts from the jenkins builder for CI were 
> > > > > > > sufficient.
> > > > > > > 
> > > > > > > Glen
> > > > > > > 
> > > > > > 
> > > > > >  Yes and no,
> > > > > > 
> > > > > >  I can add something to poudriere for getting the tarballs from the 
> > > > > > CI
> > > > > > artifacts but that won't be by default.
> > > > > > 
> > > > > 
> > > > > To be honest, that would be the preferred route, since updating the
> > > > > various *.txz distribution sets would break things like bootonly.iso,
> > > > > mini-memstick.img, and so on.
> > > > 
> > > >  Why would it break things ?
> > > > 
> > > 
> > > The bootonly.iso and mini-memstick.img do not contain the distribution
> > > sets, only the MANIFEST file.  So, people using these to install
> > > a system would not be able to do so, because the checksums for the sets
> > > would not match that in the MANIFEST.
> > 
> >  What about putting the daily sets in another directory ? With maybe
> > the latest 7 days or something like that.
> > 
> 
> But the CI system already does this...

Perhaps enhance the CI system to also spit out a couple of .iso artifacts?

> Glen

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ipv6_ipfilter_rules= is obsolete ?

[Rodney W. Grimes]

> In /etc/defaults/rc.conf I see this
> 
> ipv6_ipfilter_rules="/etc/ipf6.rules"
> # rules definition file for ipfilter,
> # see /usr/src/contrib/ipfilter/rules for examples
> 
> man 8 ipf  says
> 
> ipf -6  ipv4 and ipv6 rules are stored in a single table and can be read 
> from a single file. This option is no longer required to load ipv6 rules.
> 
> I interrupt this to mean that the ipv6_ipfilter_rules="/etc/ipf6.rules" 
>line in /etc/defaults/rc.conf is obsolete and should be removed 
> before RELEASE 13.0 is published for users to use.

Interesting, though I would not remove it.  It should be marked as
depricated and the /etc/rc.d/ipfilter shell script updated to emit
a warning that it is depricated, but it should still be processed
to retain backwards compatibility and NOT lock someone out of a
system who has just done an upgrade to a newer version.

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Undeletable files after kyua test runs

[Rodney W. Grimes]

> Hi Kevin,
> Hi David,
> 
> On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote:
> > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling  wrote:
> > > I recently stumbled across undeletable files that are generated by kyua
> > > test runs,
> > > for example
> > >
> > > -rwxr-xr-x  1 root  wheel  0 May  9 13:10
> > > /tmp/kyua.aB4q62/8676/work/fileforaudit
> > >
> > > I haven't yet identified the test that generate those files, but it is
> > > impossible
> > > to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but
> > > on every boot the system argues that these file aren't deletable.
> > > I tried to 'rm -rf' them by hand but, even this wasn't possible. I have
> > > looked for
> > > any extend attributes, but I didn't find any.
> > >
> > > Has anyone an idea how this is possible and may how these files can be
> > > deleted?
> > 
> > Have you done 'ls -o' to check for flags like schg?
> > --
> > Kevin Oberman, Part time kid herder and retired Network Engineer
> > E-mail: rkober...@gmail.com
> > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> 
> Argh, I haven't thought about chflags for quite some time. The chflags
> bit was set and after an
> 
> # find /tmp/ -type f -exec chflags -R 0 {} \;
   ^^Only files  ^^ meaningless when chflags is given ONLY 
files

You probably could of done:
chflags -R 0 /tmp/

> 
> I was able to finally delete them.
> 
> Thanks for the fast respone,
> 
> Gordon
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: routed && route6d removal proposal

[Rodney W. Grimes]

> 23.06.2020 2:26, Rodney W. Grimes wrote:
> 
> >> 22.06.2020 19:49, Rodney W. Grimes wrote:
> >>> Whats unmaintained about code that has no need to change cause it just 
> >>> pretty much works?
> >> Have you actually tried running routed(8) as base for real network with 
> >> loops,
> >> mix of p2p and ethernet-like interfaces, IPv4 aliases, need of 
> >> offset-lists and
> >> with diameter about 6 hops?
> > 
> > As I said I know of people that are running and it is working, and
> > Hiroko's post clearly establishes that as fact in evidence.
> > 
> > I am not even sure that RIP* has loop detection in the protocol,
> 
> It has, of course.

Slight miss communications, there really isnt a loop detection
in the on wire protocol, or multipath support, it simply excludes
certain routes that end up excluded by counting to infinity to
stop the loop (inifinity is usually 16 for this solution).
Its not like OSPF or BGP where you can calculate loops and mulipath effects.

Bottom line, RipV2 is not healthy on a network when loops exist,
though it should not lead to failure.

> 
> > as the prefered routing protocol for anything multipath (which
> > is what loops are in effect) is OSPF.
> 
> RIPv2 may be used for failover, not for multipath. Any redundant route 
> creates L3 "multipath".

Yes.

> >> I'm not talking about RIPv2 inherent deficiencies.
> >> Our routed just glitches where quagga's ripd just works.
> > 
> > And your PR# for reporting the bug is?
> 
> Was. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=51927
> Never had a chance to verify if it was really fixed in HEAD because it was 
> not for RELENG_4,
> so I moved to ripd. As you may remeber, RELENG_5 needed much time to become 
> ready for production.

I can not find any commit linked to that bug, but this is probalby before
the system to do that existed.  Unless we can confirm the bug still exists
I think it would be predunt to assume it is fixed based on what I read
in the PR, so dismissing the claim that the inbase routed "just glitches."

Can you agree with that logic Eugene?

Regards,
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ? ????? ??: vnc can't connect to socket

[Rodney W. Grimes]

> > On 21. Jun 2020, at 23:12, Rodney W. Grimes  
> > wrote:
> > 
> >>> On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote:
> >>>>> On 21. Jun 2020, at 14:28, Kostya Berger 
> >>>>> wrote:
> >>>>> 
> >>>>> Ok, it turns out, it gives the previously mentioned error only if I
> >>>>> use VNC server string 0.0.0.0:5900 (as I always did). in my VNC
> >>>>> client.But when replaced with127.0.0.1:5900it connects all right.
> >>>> 
> >>>> I don't hink 0.0.0.0 is a valid destination address you can use in
> >>>> connect(). Using 127.0.0.1 should
> >>>> be fine.
> >> 
> >> I do not believe that this is a destination address when your talking
> >> about 0.0.0.0:5900 on the VNC server side, that is a wild card accept
> >> any address and if this has been broken.. it must be fixed!
> >> 
> >>>> I guess, https://svnweb.freebsd.org/changeset/base/361752 is the
> >>>> relevant commit here.
> >>>> 
> >>> 
> >>> *BSD has always accepted 0 as a synonym for localhost (and iirc, linux
> >>> does not).  If this no longer works, it's a regression which is going
> >>> to cause existing applications and scripts to fail.  At the very least
> >>> it deserves an entry in UPDATING.
> >> 
> >> I am not aware of that, but can not deny it either, and just confirmed
> >> it to be true:
> >> root {1002}# telnet 0.0.0.0 22
> >> Trying 0.0.0.0...
> >> Connected to 0.0.0.0.
> >> Escape character is '^]'.
> >> SSH-2.0-OpenSSH_7.8 FreeBSD-20180909
> > 
> > And to add the netstat data to show what connected:
> > tcp4   0  0 127.0.0.1.22   127.0.0.1.43135
> > ESTABLISHED
> > tcp4  38  0 127.0.0.1.43135127.0.0.1.22   
> > ESTABLISHED
> > 
> > Can we back this commit out, discuss it in next weeks call,
> > and then find a way forward?
> > 
> >> 
> >> INADDR_ANY is the wildcard listen address, but as a destination what code 
> >> remapped
> >> it to 127.0.0.1?
> >> 
> >> We should very seriously consider restoring this behavior.
> Reallowing 0.0.0.0 is covered by https://reviews.freebsd.org/D25401

Thank you Michael.

> Best regards
> Michael
> >> 
> >>> -- Ian
> >>> 
> >>>> Best regards
> >>>> Michael
> >>>>> ?? ?? Yahoo ? ??? Android 
> >>>>> 
> >>>>> ??, 21 ???. 2020 ? 9:40 Kostya Berger
> >>>>> ???(-?):   Hi,upgraded to 362292 via buildworld.Now I cannot
> >>>>> connect to my bhyve guest as I used to: neither via VNC nor via
> >>>>> RDP.VNC gets error: unable to connect the socket. Address family
> >>>>> not supported by protocol family (47).
> >>>>> Neither can I ping my bhyve IP (it uses a separate NIC and should
> >>>>> have no problems)
> >>>>> Internet connectivity is ok and I can ping other hosts on my
> >>>>> network.
> >>>>> In 359997 all works fine.
> >>>>> ?? ?? Yahoo ? ??? Android  
> >>>>> ___
> >>>>> freebsd-current@freebsd.org mailing list
> >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >>>>> To unsubscribe, send any mail to "
> >>>>> freebsd-current-unsubscr...@freebsd.org"
> >>>> 
> >>>> ___
> >>>> freebsd-current@freebsd.org mailing list
> >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >>>> To unsubscribe, send any mail to "
> >>>> freebsd-current-unsubscr...@freebsd.org"
> >>>> 
> >>> 
> >>> ___
> >>> freebsd-current@freebsd.org mailing list
> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> >>> 
> >>> 
> >> 
> >> -- 
> >> Rod Grimes 
> >> rgri...@freebsd.org
> >> ___
> >> freebsd-current@freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> >> 
> > 
> > -- 
> > Rod Grimes 
> > rgri...@freebsd.org
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: routed && route6d removal proposal

[Rodney W. Grimes]

> 22.06.2020 19:49, Rodney W. Grimes wrote:
> 
> > Whats unmaintained about code that has no need to change cause it just 
> > pretty much works?
> 
> Have you actually tried running routed(8) as base for real network with loops,
> mix of p2p and ethernet-like interfaces, IPv4 aliases, need of offset-lists 
> and
> with diameter about 6 hops?

As I said I know of people that are running and it is working, and
Hiroko's post clearly establishes that as fact in evidence.

I am not even sure that RIP* has loop detection in the protocol,
as the prefered routing protocol for anything multipath (which
is what loops are in effect) is OSPF.

> 
> I'm not talking about RIPv2 inherent deficiencies.
> Our routed just glitches where quagga's ripd just works.

And your PR# for reporting the bug is?


-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: routed && route6d removal proposal

[Rodney W. Grimes]

> Hey,
> 
> I would like to propose removal of  sbin/routed and usr.sbin/route6d.

I disagree with removal, as your analysis is flawed.

> routed(8) is the daemon implementing RIPv2 routing protocol.
> route6d(8) is the daemon implementing RIPng routing protocol for IPv6.
> 
> RIP [1] was one of the first  protocols used in the networking. The first 
> version was implemented back in 1982.

RIPv1 was implemented in 1982, RIPv2 became RFC2453 in November 1998, and is a 
current and valid IETF standard, STD56.
It was updated by RFC4822 in February 2007.

> 
> 1. Network landscape has changed since then. BGP, OSPF, IS-ISIS and other 
> routing protocols have been created and greatly improved over years. People 
> have created and adopted numerous designs leveraging OSPF/ISIS or BGP.
> RIP became obsolete a while ago as there were no competitive advantage it can 
> offer.

> "It is the oldest routing protocol used by the network industry and is 
> considered by many to be inefficient or border-line obsolete." ? [2], 2009
RIPv2 is not obosolete, and your reference is not authoritave on what is or is 
not an obsolete network protocol.
I know of people using RIPv2 in networks.

> "Today, the only reason you might run across a network running RIPv2 is 
> either that the network is very old and in serious need of an upgrade or the 
> network is running cheaper, consumer-grade routing hardware that can only 
> support RIP" ? [3], 2016.

Or there simply is no need for anything more complicated.  RipV2 is a very 
simple protocol and works fine for small networks in many settings.

> 
> 1.1. Nowadays the daemon name is simply misleading. Given situation described 
> above, one does expect far wider functionality from the program named 
> "route[6]d" than just  RIP implementation.

I'll agree the name is missleading, so change it, but removal on your false 
basis is not.

> 
> 2. Multiple routing stacks supporting all major routing protocol including 
> RIP exists these days: bird, frr, quagga. Many BGP-only designs in are 
> gaining popularity, so do bgp speakers such as exabgp or gobgp.  Nowadays, if 
> one needs dynamic routing on the host, OSPF or BGP speaker is the choice. 
> FreeBSD packages contains well-maintained ports for these. Having RIP[ng] 
> speakers in base offers no advantage. 

Routing stacks?  You mean routing daemons?  Forcing users to install bir, frr 
or quagga when all they need, or have been using for a long time is in base 
ripv2 is not good for users.

> 3. Both routed/route6d are largely unmaintained [4] and presents an 
> additional attack vector. Here is the list of last non-trivial commits to 
> routed/route6d:

Whats unmaintained about code that has no need to change cause it just pretty 
much works?

> 
> sbin/routed:
> r327276 - coverity
> r317035 - rtsock fix
> r299825 - coverity
> r299822 - coverity, from netbsd
> r299821 - coverity, from netbsd
> r299784 - coverity, from netbsd
> r299771 - coverify, from netbsd
> r286347 - bugfix
> r276602 - SA14:21 patch
> r271919 - SA14:21 fix
> r215702 - logic fix, 2010
> 
> usr.sbin/route6d:
> r337500 - functional fix, 2018
> r317035 - rtsock fix
> r311994 - coverity
> r311985 - coverity
> r299869 - coverity
> r299491 - coverity
> r270234 - link-local fix
> r243233 - functionality improvement, 2012
> 
> To summarise: RIP protocol is obsolete, implementations for newer protocols 
> exists in ports,  implementation in base  is unmaintained.
> 
> With all that in mind I propose to remove routed and route6d from base in 
> FreeBSD 13.
> Timeline:
> June 5 - feedback aggregation and decision point
> July 19 - removal (proposed)
> 
> 
> [1] https://en.wikipedia.org/wiki/Routing_Information_Protocol
> [2] 
> https://www.globalknowledge.com/ca-en/resources/resource-library/articles/basics-of-understanding-rip/
> [3] 
> https://www.networkcomputing.com/data-centers/comparing-dynamic-routing-protocols
> [4] 
> https://bugs.freebsd.org/bugzilla/buglist.cgi?cmdtype=runnamed_id=361897=routed_prs
> 
> /Alexander
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ? ????? ??: vnc can't connect to socket

[Rodney W. Grimes]

> > On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote:
> > > > On 21. Jun 2020, at 14:28, Kostya Berger 
> > > > wrote:
> > > > 
> > > > Ok, it turns out, it gives the previously mentioned error only if I
> > > > use VNC server string 0.0.0.0:5900 (as I always did). in my VNC
> > > > client.But when replaced with127.0.0.1:5900it connects all right.
> > > 
> > > I don't hink 0.0.0.0 is a valid destination address you can use in
> > > connect(). Using 127.0.0.1 should
> > > be fine.
> 
> I do not believe that this is a destination address when your talking
> about 0.0.0.0:5900 on the VNC server side, that is a wild card accept
> any address and if this has been broken.. it must be fixed!
> 
> > > I guess, https://svnweb.freebsd.org/changeset/base/361752 is the
> > > relevant commit here.
> > > 
> > 
> > *BSD has always accepted 0 as a synonym for localhost (and iirc, linux
> > does not).  If this no longer works, it's a regression which is going
> > to cause existing applications and scripts to fail.  At the very least
> > it deserves an entry in UPDATING.
> 
> I am not aware of that, but can not deny it either, and just confirmed
> it to be true:
> root {1002}# telnet 0.0.0.0 22
> Trying 0.0.0.0...
> Connected to 0.0.0.0.
> Escape character is '^]'.
> SSH-2.0-OpenSSH_7.8 FreeBSD-20180909

And to add the netstat data to show what connected:
tcp4   0  0 127.0.0.1.22   127.0.0.1.43135ESTABLISHED
tcp4  38  0 127.0.0.1.43135127.0.0.1.22   ESTABLISHED

Can we back this commit out, discuss it in next weeks call,
and then find a way forward?

> 
> INADDR_ANY is the wildcard listen address, but as a destination what code 
> remapped
> it to 127.0.0.1?
> 
> We should very seriously consider restoring this behavior.
> 
> > -- Ian
> > 
> > > Best regards
> > > Michael
> > > > ?? ?? Yahoo ? ??? Android 
> > > > 
> > > > ??, 21 ???. 2020 ? 9:40 Kostya Berger
> > > > ???(-?):   Hi,upgraded to 362292 via buildworld.Now I cannot
> > > > connect to my bhyve guest as I used to: neither via VNC nor via
> > > > RDP.VNC gets error: unable to connect the socket. Address family
> > > > not supported by protocol family (47).
> > > > Neither can I ping my bhyve IP (it uses a separate NIC and should
> > > > have no problems)
> > > > Internet connectivity is ok and I can ping other hosts on my
> > > > network.
> > > > In 359997 all works fine.
> > > > ?? ?? Yahoo ? ??? Android  
> > > > ___
> > > > freebsd-current@freebsd.org mailing list
> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > To unsubscribe, send any mail to "
> > > > freebsd-current-unsubscr...@freebsd.org"
> > > 
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "
> > > freebsd-current-unsubscr...@freebsd.org"
> > > 
> > 
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> > 
> > 
> 
> -- 
> Rod Grimes rgri...@freebsd.org
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ? ????? ??: vnc can't connect to socket

[Rodney W. Grimes]

> On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote:
> > > On 21. Jun 2020, at 14:28, Kostya Berger 
> > > wrote:
> > > 
> > > Ok, it turns out, it gives the previously mentioned error only if I
> > > use VNC server string 0.0.0.0:5900 (as I always did). in my VNC
> > > client.But when replaced with127.0.0.1:5900it connects all right.
> > 
> > I don't hink 0.0.0.0 is a valid destination address you can use in
> > connect(). Using 127.0.0.1 should
> > be fine.

I do not believe that this is a destination address when your talking
about 0.0.0.0:5900 on the VNC server side, that is a wild card accept
any address and if this has been broken.. it must be fixed!

> > I guess, https://svnweb.freebsd.org/changeset/base/361752 is the
> > relevant commit here.
> > 
> 
> *BSD has always accepted 0 as a synonym for localhost (and iirc, linux
> does not).  If this no longer works, it's a regression which is going
> to cause existing applications and scripts to fail.  At the very least
> it deserves an entry in UPDATING.

I am not aware of that, but can not deny it either, and just confirmed
it to be true:
root {1002}# telnet 0.0.0.0 22
Trying 0.0.0.0...
Connected to 0.0.0.0.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.8 FreeBSD-20180909

INADDR_ANY is the wildcard listen address, but as a destination what code 
remapped
it to 127.0.0.1?

We should very seriously consider restoring this behavior.

> -- Ian
> 
> > Best regards
> > Michael
> > > ?? ?? Yahoo ? ??? Android 
> > > 
> > > ??, 21 ???. 2020 ? 9:40 Kostya Berger
> > > ???(-?):   Hi,upgraded to 362292 via buildworld.Now I cannot
> > > connect to my bhyve guest as I used to: neither via VNC nor via
> > > RDP.VNC gets error: unable to connect the socket. Address family
> > > not supported by protocol family (47).
> > > Neither can I ping my bhyve IP (it uses a separate NIC and should
> > > have no problems)
> > > Internet connectivity is ok and I can ping other hosts on my
> > > network.
> > > In 359997 all works fine.
> > > ?? ?? Yahoo ? ??? Android  
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "
> > > freebsd-current-unsubscr...@freebsd.org"
> > 
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> > freebsd-current-unsubscr...@freebsd.org"
> > 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CTF: UEFI HTTP boot support

[Rodney W. Grimes]

> This is what we have running in AWS right now, kinda proof of concept but
> it's not that difficult to generalize:
> 
> [root@ip-172-31-10-188 /usr/local/etc/freeswitch]# mdconfig -lv
> md0 preload   160M  -
> 
> [root@ip-172-31-10-188 /usr/local/etc/freeswitch]# df
> Filesystem512-blocksUsed  Avail Capacity  Mounted on
> /dev/ufs/root_20200617071427 1300080 1220480  7960094%/
> devfs  2   2  0   100%/dev
> /dev/ufs/etc_20200617071427 99126384   273670%/etc
> /dev/ufs/local_202006170714272746992 2572144 17484894%/usr/local
> /dev/ufs/boot_20200617071427  389560  361208  2835293%/boot
> tmpfs  65536 624  64912 1%/tmp
> tmpfs  20480  16  20464 0%
>  /usr/home/ssp-user
> tmpfs 524288  336816 18747264%/var
> 
> Root file system is untrimmed 1.2GB UFS, generated with mkuzip compressed
> down to 160MB with the UZIP, and pre-loaded along with the kernel. The
> /usr/local file system is read-only UFS+UZIP images placed directly onto
> the GPT and probed out with GEOM_LABEL. Out of those only /etc is
> read-write. The idea here is that the box should theoretically survive
> total loss of connectivity to both root and the /usr/local storage (or we
> can replace it on the fly with the new version).
> 
> [root@ip-172-31-10-188 /usr/local/etc/freeswitch]# mount
> /dev/ufs/root_20200617071427 on / (ufs, local, read-only)
> devfs on /dev (devfs, local, multilabel)
> /dev/ufs/etc_20200617071427 on /etc (ufs, local, synchronous)
> /dev/ufs/local_20200617071427 on /usr/local (ufs, local, read-only)
> /dev/ufs/boot_20200617071427 on /boot (ufs, local, read-only)
> tmpfs on /tmp (tmpfs, local)
> tmpfs on /usr/home/ssp-user (tmpfs, local)
> tmpfs on /var (tmpfs, local)
> 
> Configuration is dead simple:
> 
> vfs.root.mountfrom="ufs:ufs/root_20200617071427"
> image_load="YES"
> image_name="/root.uzp"
> image_type="mfs_root"
> autoboot_delay="-1"
> 
> It takes less than 100 lines of code I think to generate this out of
> buildworld/buildkernel. 0 third party tools.
> 
> Replace loading root from disk with loading it from HTTP server and it
> would work just as good with the only need to load 1 or two files.

I think your understating several of the stumbling blocks
that exist here.  As Warner pointed out there are some
pokey sticks around doing this over the net fs doing this
from a local disk.

> 
> There is only one catch there - with real UEFI hardware sometimes there is
> small(ish) region followed by a hole and then the much bigger region.
> Unfortunately our loader picks smaller region for its work area and
> md_image loading mechanism is not good enough to either place it entirely
> into a bigger segment, or do scatter-gather and split it out and make the
> kernel do some VM trick to re-assemble later. But with some
> post-installworld cleaning if you can compress down the full image to some
> 30-40MB that usually works and has everything one may need including
> kitchen sink (i.e. python 3.7 with few modules). As I said, no woodo magic
> like famous crunchgen, just a very liberal application of the rm -rf.
> 
> With regards to ro vs. rw, recipy is "don't do it" :) If you want hard RO
> embedded into kernel - compress your image with mkuzip first and then embed
> it into kernel. This what FreeBSD/MIPS guys have mastered a lot (platform
> was very tight on flash), which is why geom_uzip is practically in every
> MIPS kernel config file. But that works (or should work) just as well on
> x64. Not only that would save lots of VM but also the RO proper attribute
> will be provided by the geom_uzip for free.
> 
> I am by the way hacking some way to populate /var with something more
> interesting that just stock /etc/mtree/BSD.var.dist, there will be a review
> request soon. :)

You may want to look at /etc/rc.initdiskless, the /var and /etc population
do have one existing solution.

> 
> -Max
> 
> On Wed, Jun 17, 2020 at 2:33 PM Miguel C  wrote:
> 
> > On Wed, Jun 17, 2020 at 9:28 PM Dave Cottlehuber 
> > wrote:
> >
> > > On Wed, 17 Jun 2020, at 17:52, Rodney W. Grimes wrote:
> > > > > Rodney W. Grimes  wrote:
> > > > > > > The "fake cd drive" is in the kernel, loader just copies the iso
> > > into
> > > > > > > memory like any other module, and by the time that's done you
> > just
> > > > > > > reboot into the newly installed system, which again uses

Re: CTF: UEFI HTTP boot support

[Rodney W. Grimes]

> 
> > On Jun 17, 2020, at 12:12 PM, Warner Losh  wrote:
> > 
> > I missed the start of this thread, so maybe I'm missing a key detail. 
> > However, I thought UEFI didn't have a RAM-disk, per se, but that we could 
> > load memory areas and pass that into the kernel using freebsd-only methods. 
> > But UEFI is a bit weird, so maybe it will generate a virtual cdrom...
> 
> See 
> https://uefi.org/sites/default/files/resources/FINAL%20Pres4%20UEFI%20HTTP%20Boot.pdf
> 
> ? RAM Disk Standard
> 
> ? UEFI 2.5 defined RAM Disk device path nodes
> - Standard access to a RAM Disk in UEFI
> - Supports Virtual Disk and Virtual CD (ISO image) in persistent or
> volatile memory?

Does freeBSD have any way to access these "Virtual Disk"
or Virtual CD images once we leave the world of the loader?
I believe we do not, as these are BIOS/UEFI devices that
require calls into the UEFI code, which, IIRC is gone
once we exit the loader and start the kernel proper,
or shortly there after.

As far as I know these devices well not be found by the FreeBSD
cam layer ATA or AHCI drivers as they do not present an actual
PCI device to find.

> Rebecca Cran
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CTF: UEFI HTTP boot support

[Rodney W. Grimes]

> On Wed, Jun 17, 2020 at 11:53 AM Rodney W. Grimes <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
> 
> > > Rodney W. Grimes  wrote:
> > > > > The "fake cd drive" is in the kernel, loader just copies the iso into
> > > > > memory like any other module, and by the time that's done you just
> > > > > reboot into the newly installed system, which again uses
> > > > >
> > > > > vfs.root.mountfrom="cd9660:/dev/md0.uzip"
> > > >   ^^^
> > > >
> > > > Argh, the cd9660 confused me, I think your doing a
> > > > "root on mfs/md"?
> > >
> > > loader.conf says
> > >
> > > rootfs_load="yes"
> > > rootfs_name="contents.izo"
> > > rootfs_type="md_image"
> > > vfs.root.mountfrom="cd9660:/dev/md0.uzip"
> > >
> > > contents.izo is uzip'd contents.iso which file(1)
> > > describes as ISO 9660 CD-ROM filesystem data ''
> > >
> > > That's for normal boot, for the loader 'install' command
> > > it expects an uncompressed iso for rootfs.
> >
> > Ok, now the puzzle is how much work to get from a stock FreeBSD .iso
> > image to something that works with this.  Obviously we need a non-stock
> > /boot/loader.conf file, or to type some commands manually at a loader
> > prompt.  I believe the stock GENERIC kernel has the md_root support
> > for this already, so it may not be that hard to do.
> >
> 
> Looking at the code, I think MD_ROOT alone is insufficient here...

I was a bit worried about that, but hopefull.  We do work out of the
box with a NFS root as long as the NIC is found during boot.  And
given that I load the loader over NFS the loader can also find my
/boot/ directory and the files in it, so that part is already solved.

> If there's no MD root provided, we look for the symbols mfs_root and
> mfs_root_end, which I think means that rootfs_ in the above example needs
> to be md_root_ instead so that we find it.

Isnt this all handled by the loader?  I think we have 2 slightly
different cases here.  THe one sjg shows up, where you actually
load the md_image from a  seperate file, and the case your talking
about where you actually embed the kernel and image into a single
file.

> 
> You may need to have a custom kernel with 'options MD_ROOT_READONLY'
> because isofs is read-only.
> 
> And there's a small chance you may need to define ROOTDEVNAME in the build
> as well to be "cd9660:/dev/md0.uzip"

I do not think that is necessesary but I'll keep it in mind, at present
I do over ride the vfs.root.mountfrom to point to my version specific
root file system using some ipxe variables.

> 
> Every time I do stuff like this I have to re-puzzle it out, alas, but these
> should give you some guide posts. It should be better documented in md(4),
> but isn't at the moment.

Thanks for exposing what may be some pointy sticks to stumble on.

> 
> I'd honestly try to get this setup working first loading all the files off
> a local disk before layering in the networking on top of that.

Probalby a good idea, as the usually failure mode in the diskless
word is black screens leaving little detail about what went wrong.

> Warner
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CTF: UEFI HTTP boot support

[Rodney W. Grimes]

> On Tue., Jun. 16, 2020, 8:35 a.m. Rodney W. Grimes, <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
> 
> > > I've been trying out FreeBSD with raspberry Pi4 (4GB) and wanted to see
> > > what the state of HTTP BOOT is in FreeBSD, so I bumped into this!
> > >
> > > I'm curious if it should be possible to point to a img/iso directly (I
> > > tried to use the img.xz unpacked it and make it available on a local web
> > > server and that didn't seem to work for me)  but maybe thats cause those
> > > images miss something, so arm64 aside does that work for amd64? I.E.
> > using
> > > the bootonly.iso?
> >
> > One problem you run into in attemtping this is even if you get an
> > image downloaded and started that image is being provided by some
> > memory device driver that emulates some type of iso device.
> > FreeBSD does not have a driver for that device so once the kernel
> > gets to the point of mounting its root file system it falls on
> > its face with a mountroot failure.
> >
> 
> I donno what you are talking about Rodney, frankly! You information might
> be way outdated, like 15 years outdated. :) FreeBSD comes with very decent
> compressed image support in MD(4)+geom_uzip, which could be just UFS
> snapshot or something created with mkimg utility. That said image could be
> then either loaded after the kernel or embedded into one. Using this
> approach we deploy our systems here, both kernel and all root + python
> interpreter + custom gui installer fit into 40mb ISO but apart from loader
> bits it's just two files.

Max,
Let me try explain what this user is actually experienceing,
and that is taking a box stock linux distro, sticking it on a webserver
and using PXE/HTTP booting to a running system.  FreeBSD can not
achieve that today WITHOUT some additional work.  All that
stuff like UFS snapshot, mkimg utlity, embeding the image is a ton
of work compared to what others are doing.

This person probably does not even have a running FreeBSD box to do
any of your suggested solutions on.

So give me some credit, I have only been doing "diskless" since 1982,
and actually do exactly what the OP is doing with Esxi, Ubuntu, Windows
Installers, etc.  Just my choice of protocol at the PXE layer is NFS
instead of HTTP, but my config files can do HTTP with 1 variable change
and point a web server at the root of my boot images tree.

I even have a menu entry that sends me off to:
https://netboot.xyz/

Regards,
Rod

> 
> -Max
> 
> 
> > >
> > > And on the other hand is there any doc on how to set up dhcp/http
> > specific
> > > to FreeBSD similar to https://en.opensuse.org/UEFI_HTTPBoot_Server_Setup
> > ?
> >
> > Since Linux uses this idea of a kernel payload and an initrd payload
> > to boot with it is much easier to get these 2 things over the network
> > and then have a workable system.  FreeBSD does not have the initrd
> > payload and that complicates things, you need a functionaly filesystem
> > avaliable at the end of kernel initilization.
> > >
> > > I looked into https://www.freebsd.org/doc/handbook/network-diskless.html
> > > but that doesn't seem to be up to date (or at least it focuses only on
> > PXE
> > > and TFTP).
> >
> > Yes, old but workable.  I have a more advanced system that supports NFS
> > booting using NFS support in PXE.  The only thing done via tftp is to
> > upgrade the PXE running on the client to one that speaks NFS, then the
> > kernel is loaded via NFS and the root file system is later provided
> > via NFS.  The use of NFS provides very fast boots, and I do not need
> > a web server to do it :-).
> >
> > > For clarification my ultimate goal is to use a few pi4's as "thin
> > clients",
> > > so eventually I will have to setup an image of the system with the needed
> > > software (freerdp) but for starters I just wanted to check if pointing
> > > directly to a img/iso would work and that does not seem to be the case.
> >
> > I would strongly suggest use of NFS instead of trying to provide an
> > ISO image, as you no longer need to store the ISO in memory on the
> > client box, and with a pi4 your already memory contrained.
> >
> > > Thanks.
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "
> > freebsd-current-unsubscr...@freebsd.org"
> > --
> > Rod Grimes
> > rgri...@freebsd.org
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> >
> >

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CTF: UEFI HTTP boot support

[Rodney W. Grimes]

> Rodney W. Grimes  wrote:
> > > The "fake cd drive" is in the kernel, loader just copies the iso into
> > > memory like any other module, and by the time that's done you just
> > > reboot into the newly installed system, which again uses
> > >
> > > vfs.root.mountfrom="cd9660:/dev/md0.uzip"
> >   ^^^
> > 
> > Argh, the cd9660 confused me, I think your doing a
> > "root on mfs/md"?
> 
> loader.conf says
> 
> rootfs_load="yes"
> rootfs_name="contents.izo"
> rootfs_type="md_image"
> vfs.root.mountfrom="cd9660:/dev/md0.uzip"
> 
> contents.izo is uzip'd contents.iso which file(1)
> describes as ISO 9660 CD-ROM filesystem data ''
> 
> That's for normal boot, for the loader 'install' command
> it expects an uncompressed iso for rootfs.

Ok, now the puzzle is how much work to get from a stock FreeBSD .iso
image to something that works with this.  Obviously we need a non-stock
/boot/loader.conf file, or to type some commands manually at a loader
prompt.  I believe the stock GENERIC kernel has the md_root support
for this already, so it may not be that hard to do.


-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CTF: UEFI HTTP boot support

[Rodney W. Grimes]

> On 6/16/20 5:17 AM, Miguel C wrote:
> 
> > I've been trying out FreeBSD with raspberry Pi4 (4GB) and wanted to see
> > what the state of HTTP BOOT is in FreeBSD, so I bumped into this!
> >
> > I'm curious if it should be possible to point to a img/iso directly (I
> > tried to use the img.xz unpacked it and make it available on a local web
> > server and that didn't seem to work for me)  but maybe thats cause those
> > images miss something, so arm64 aside does that work for amd64? I.E. using
> > the bootonly.iso?
> 
> Unfortunately HTTP boot only works as far as the kernel: UEFI fetches 
> loader.efi, the loader fetches and runs the kernel over HTTP -- and then 
> you need to use NFS to mount the filesystem (or have a local root 
> filesystem).
> 
> 
> UEFI also has RamDisk support, but I don't think that's for remote 
> ISO/disk files, just local files.
> 

Does FreeBSD kernel have a driver that can talk to the UEFI ramdisk?

I believe that is how many of the other distro's
are actually able to do this "load the stock .iso over the
network and just run from that in memory."  I have booted
serveral things this way and it is a nice feature.

> -- 
> Rebecca Cran
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CTF: UEFI HTTP boot support

[Rodney W. Grimes]

> Rodney W. Grimes  wrote:
> > > Are you refering to something like:
> > >
> > > vfs.root.mountfrom="cd9660:/dev/md0.uzip"
> > >
> > > we boot that way all the time.
> > 
> > What provides the cd9660 driver to FreeBSD?  When you load the .iso
> > over a network card, aka PXE/HTTP, the code that does that usually
> > creates a ram disk and a "fake cd drive" that stops working as soon
> 
> We don't use PXE much except in a bringup lab, and then I think we use
> NFS for rootfs.

Probably much like what I do once my kernel is loaded.

> Normally if iso is comming from network it is to do an install
> eg loader is doing 'install tftp://host/install.tar'
> 
> The "fake cd drive" is in the kernel, loader just copies the iso into
> memory like any other module, and by the time that's done you just
> reboot into the newly installed system, which again uses
> 
> vfs.root.mountfrom="cd9660:/dev/md0.uzip"
  ^^^

Argh, the cd9660 confused me, I think your doing a
"root on mfs/md"?

> but in that case the rootfs is an iso image on local disk.
> 
> The rootfs iso is minimal - enough to fsck and mount real media
> and initialize Verified Exec.
> It improves our chances of being able to recover from severe disk
> corruption after cleaning lady pulls the cord, to vaccuum ;-)
> 
> --sjg
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CTF: UEFI HTTP boot support

[Rodney W. Grimes]

> On Tue, Jun 16, 2020, 17:53 Miguel C  wrote:
> 
> > On Tue, Jun 16, 2020 at 4:35 PM Rodney W. Grimes <
> > freebsd-...@gndrsh.dnsmgr.net> wrote:
> >
> > > > I've been trying out FreeBSD with raspberry Pi4 (4GB) and wanted to see
> > > > what the state of HTTP BOOT is in FreeBSD, so I bumped into this!
> > > >
> > > > I'm curious if it should be possible to point to a img/iso directly (I
> > > > tried to use the img.xz unpacked it and make it available on a local
> > web
> > > > server and that didn't seem to work for me)  but maybe thats cause
> > those
> > > > images miss something, so arm64 aside does that work for amd64? I.E.
> > > using
> > > > the bootonly.iso?
> > >
> > > One problem you run into in attemtping this is even if you get an
> > > image downloaded and started that image is being provided by some
> > > memory device driver that emulates some type of iso device.
> > > FreeBSD does not have a driver for that device so once the kernel
> > > gets to the point of mounting its root file system it falls on
> > > its face with a mountroot failure.
> > >
> > > >
> > > > And on the other hand is there any doc on how to set up dhcp/http
> > > specific
> > > > to FreeBSD similar to
> > https://en.opensuse.org/UEFI_HTTPBoot_Server_Setup
> > > ?
> > >
> > > Since Linux uses this idea of a kernel payload and an initrd payload
> > > to boot with it is much easier to get these 2 things over the network
> > > and then have a workable system.  FreeBSD does not have the initrd
> > > payload and that complicates things, you need a functionaly filesystem
> > > avaliable at the end of kernel initilization.
> > > >
> > > > I looked into
> > https://www.freebsd.org/doc/handbook/network-diskless.html
> > > > but that doesn't seem to be up to date (or at least it focuses only on
> > > PXE
> > > > and TFTP).
> > >
> > > Yes, old but workable.  I have a more advanced system that supports NFS
> > > booting using NFS support in PXE.  The only thing done via tftp is to
> > > upgrade the PXE running on the client to one that speaks NFS, then the
> > > kernel is loaded via NFS and the root file system is later provided
> > > via NFS.  The use of NFS provides very fast boots, and I do not need
> > > a web server to do it :-).
> > >
> > > > For clarification my ultimate goal is to use a few pi4's as "thin
> > > clients",
> > > > so eventually I will have to setup an image of the system with the
> > needed
> > > > software (freerdp) but for starters I just wanted to check if pointing
> > > > directly to a img/iso would work and that does not seem to be the case.
> > >
> > > I would strongly suggest use of NFS instead of trying to provide an
> > > ISO image, as you no longer need to store the ISO in memory on the
> > > client box, and with a pi4 your already memory contrained.
> > >
> >
> > Thanks for the tips, but I was really looking for HTTP BOOT info no NFS,
> > that's why I replied to this thread.
> >
> > I might look into that at some point if HTTP BOOT is not an option of
> > course, but this thread is about a Call for Testers for UEFI HTTP BOOT, not
> > NFS and I would like to help test, the pi4 project just conveniently
> > touches on the same use case (an it also does have support for http boot
> > using https://rpi4-uefi.dev/) so I'm curious if I can test that way.
> >
> > Other than the iso I can ofc attempt the dhcp+dns+webserver setup but for
> > that I would need a bit more guidance as the linked URL here is linux
> > centric, hence why some docs would help.
> >
> 
> >
> >
> Am I just misremembering or can't you get freebsd to load an mfsroot-image,
> which can act as rw fs ?

Yes, but that is *not* an .iso as was asked above.

> I seem to remember pc-bsd DVDs using this say 7 years ago.

Yes.

> 
> You would of course have to modify/build your own iso image with the
> mfsroot-image on it.

Perhaps, if you can get the mfsroot image into memory by the loader
while you still have access to the bios code.

> Best regards
> Andreas

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CTF: UEFI HTTP boot support

[Rodney W. Grimes]

> Rodney W. Grimes  wrote:
> > > I'm curious if it should be possible to point to a img/iso directly (I
> > > tried to use the img.xz unpacked it and make it available on a local web
> > > server and that didn't seem to work for me)  but maybe thats cause those
> > > images miss something, so arm64 aside does that work for amd64? I.E. using
> > > the bootonly.iso?
> > 
> > One problem you run into in attemtping this is even if you get an
> > image downloaded and started that image is being provided by some
> > memory device driver that emulates some type of iso device.
> > FreeBSD does not have a driver for that device so once the kernel
> > gets to the point of mounting its root file system it falls on
> > its face with a mountroot failure.
> 
> Are you refering to something like:
> 
> vfs.root.mountfrom="cd9660:/dev/md0.uzip"
> 
> we boot that way all the time.

What provides the cd9660 driver to FreeBSD?  When you load the .iso
over a network card, aka PXE/HTTP, the code that does that usually
creates a ram disk and a "fake cd drive" that stops working as soon
as you stop running the PXE code, which means the device does not
show up while the kernel is probing.  FreeBSD simply does not support
bios devices in this manner, unless something has changed I am totally
unaware of.


-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CTF: UEFI HTTP boot support

[Rodney W. Grimes]

> I've been trying out FreeBSD with raspberry Pi4 (4GB) and wanted to see
> what the state of HTTP BOOT is in FreeBSD, so I bumped into this!
> 
> I'm curious if it should be possible to point to a img/iso directly (I
> tried to use the img.xz unpacked it and make it available on a local web
> server and that didn't seem to work for me)  but maybe thats cause those
> images miss something, so arm64 aside does that work for amd64? I.E. using
> the bootonly.iso?

One problem you run into in attemtping this is even if you get an
image downloaded and started that image is being provided by some
memory device driver that emulates some type of iso device.
FreeBSD does not have a driver for that device so once the kernel
gets to the point of mounting its root file system it falls on
its face with a mountroot failure.

> 
> And on the other hand is there any doc on how to set up dhcp/http specific
> to FreeBSD similar to https://en.opensuse.org/UEFI_HTTPBoot_Server_Setup?

Since Linux uses this idea of a kernel payload and an initrd payload
to boot with it is much easier to get these 2 things over the network
and then have a workable system.  FreeBSD does not have the initrd
payload and that complicates things, you need a functionaly filesystem
avaliable at the end of kernel initilization.
> 
> I looked into https://www.freebsd.org/doc/handbook/network-diskless.html
> but that doesn't seem to be up to date (or at least it focuses only on PXE
> and TFTP).

Yes, old but workable.  I have a more advanced system that supports NFS
booting using NFS support in PXE.  The only thing done via tftp is to
upgrade the PXE running on the client to one that speaks NFS, then the
kernel is loaded via NFS and the root file system is later provided
via NFS.  The use of NFS provides very fast boots, and I do not need
a web server to do it :-).

> For clarification my ultimate goal is to use a few pi4's as "thin clients",
> so eventually I will have to setup an image of the system with the needed
> software (freerdp) but for starters I just wanted to check if pointing
> directly to a img/iso would work and that does not seem to be the case.

I would strongly suggest use of NFS instead of trying to provide an
ISO image, as you no longer need to store the ISO in memory on the
client box, and with a pi4 your already memory contrained.

> Thanks.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: nightly snapshot for CURRENT ?

[Rodney W. Grimes]

> On Tue, 9 Jun 2020 19:56:30 +
> Glen Barber  wrote:
> 
> > On Tue, Jun 09, 2020 at 09:47:56PM +0200, Emmanuel Vadot wrote:
> > > 
> > >  Hello all,
> > > 
> > >  I've just hit again something that I've hit (and probably others too)
> > > often.
> > >  If a change in base break some ports and it's snapshoted in the txz
> > > available at download.freebsd.org, you need to wait a week for the next
> > > tarball to be available.
> > >  Since poudriere uses the tarball when you setup a jail it means that
> > > the only solution you have is to recreate your jail by building it, and
> > > since building world nowdays is very expensive that delay your work too
> > > much.
> > >  Would it be possible to generate the tarballs every day instead of
> > > every week ? At least for tier-1 arches.
> > > 
> > 
> > Let's revisit this sometime next week after 11.4 is out.
> > 
> > Glen
> > 
> 
>  Sure, works for me.
> 
>  Thanks,

Its not quite a snapshot, but it is the bits one needs to quickly
contruct one, and that is in the jenkins artifacts.  I even
modified my diskless boot environment creater so I can give it
a rX that exists in Jenkins and it builds me a diskless boot
tree all set up ready for testing/recovery.

http://artifacts.ci.freebsd.org/snapshot/head/${SVNREV}/${ARCH}/${ARCH}/base.txz

> -- 
> Emmanuel Vadot  
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Office Hours today @ 18:00 UTC - Core Candidates

[Rodney W. Grimes]

-- Start of PGP signed section.
> On 2020-05-27 22:01, Philip Paeps wrote:
> > On 2020-05-27 22:35:14 (+0800), Allan Jude wrote:
> >> Sorry for the late notice, I thought I sent this last week.
> >>
> >> After the slate of candidates was finalized last week, I invited all of
> >> them to join a live stream today at 18:00 UTC to answer questions from
> >> the FreeBSD Community.
> > 
> > Do you ever plan to schedule one of these at a time that works for those
> > of us in the eastern hemisphere?
> > 
> > 18:00 UTC is 02:00 in Hong Kong, Taiwan and China, 03:00 in Japan and
> > 04:00 in the east of Australia to name but a couple of places where we
> > have sizeable (or at least non-zero) populations of FreeBSD developers.
> > 
> > I'm sure we can watch the recordings after the fact, but I'm sure some
> > of us would also welcome the opportunity to ask questions in real time.
> > 
> > Thank you.
> > 
> > Philip
> > 
> 
> Philip: We did one at 02:00 UTC on April 16th. But attendance was only
> ~20, compared to ~65 for the 18:00 UTC slot.

Since I have no idea on what our global proportions per time zone are
I can not tell if that is a good showing or a not so good.

Do we have any data on the global distribution of @developers?

> https://wiki.freebsd.org/OfficeHours
> 
> Would you be willing to help host/promote another attempt for a more
> Asia friendly time?
> 
> -- 
> Allan Jude
> 
-- End of PGP section, PGP failed!

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Move from termcap(5) to terminfo(5)

[Rodney W. Grimes]

> Hello everyone,
> 
> I can't find any proper rationale in our history (maybe I missed it) which
> explains why our ncurses is stuck on using termcap(5) instead of terminfo(5)
> Except an argument in the Makefile that builds ncurses:
> "Used instead of the hideous read_termcap.c abomination."
> 
> Which I do not find really useful.
> 
> I would like to make the move from termcap to terminfo which would give us the
> bonus to be able to track terminfo sources from upstream aka ncurses and to
> add and use tic(1).
> 
> Given the very few people that are actually maintaining the termcap database. 
> I
> don't think there is a good rationale at keeping our own format (as far as I
> know everyone moved to terminfo(5)) and parser.
> 
> Without any strong arguments against it I will start working on that move by
> next week.
> 
> If you have some knowledge you want to share: "be careful about this or that" 
> I
> would be more than happy to collect it, to make sure the transition is as 
> smooth
> as possible.

The feedback I have from the few people that *are* effected by our
lack of use of terminfo is positive on this change.
Our use of termcap is a pain for them, especially with the base vs
ports issues.

As far as I am aware the termcap vs terminfo is simply historical in
nature with no strong reason to change it.  It use to be that both
had pretty close shares of the supported by software segment.  That
historical precedence has worn thin, as there is very little support
for termcap today.


> Best regards,
> Bapt

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: sysutils/screen-ncurses port

[Rodney W. Grimes]

> On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste 
> > Daroussin wr
> > ites:
> > > 
> > >
> > > --vwrr5drfobpkyvop
> > > Content-Type: text/plain; charset=us-ascii
> > > Content-Disposition: inline
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > Would people be open to the idea of a sysutils/screen-ncurses port that=
> > > =20
> > > > depends on devel/ncurses instead of ncureses in base? The reason for 
> > > > this=
> > > =20
> > > > is there are screen.* terminfo entries in devel/ncurses that don't 
> > > > exist =
> > > in=20
> > > > termcap(5). People who want that extra functionality would be advised 
> > > > to=
> > > =20
> > > > install the alternative pkg or build the sysutils/screen port with 
> > > > the=20
> > > > appropriate option.
> > > >=20
> > > > Or, simply change the default from whatever ncurses is available to 
> > > > alway=
> > > s=20
> > > > install devel/ncurses. People could always select one of the other 
> > > > option=
> > > s.=20
> > > > Personally, I'm not enamoured with this approach.
> > >
> > > I think it is a terrible idea, and we should fix the initial problem 
> > > instea=
> > > d of
> > > workarounding it.
> > >
> > > 1/ why those are not in our termcap(5) ? they should be added if they are
> > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> > 
> > I came to this conclusion last night after sending this email thread oud 
> > and will test it some time today.
> > 
> > >
> > > 2/ we should allow our base ncurses to get informations from newer 
> > > termcap(=
> > > 5) if
> > > needed.
> > > So far the default TERMCAP is
> > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}
> > >
> > > First the user can be advise to point configure the $home/.termcap this 
> > > is =
> > > for
> > > quick now.
> 
> that is in your scope via a pkg-message :D
> 
> > >
> > > Second for later futur proof mechanism we could modify our termcap reader 
> > > (=
> > > we
> > > use our own, not the one in provided by ncurses). to be able to fetch 
> > > termc=
> > > ap
> > > capabilities from /usr/local/share/misc/termcap/*.conf for example
> > >
> > > This way ports with random termcap info to add would be able to do it 
> > > witho=
> > > ut
> > > the requirement to wait for a commit in base and a MFC.
> > 
> > This is probably outside of my scope at the moment but, yes, agreed.
> > 
> I will then.
> I added that to my TODO

Thank you Bapt, I know a visually impared person that is battling in
this space often that this should help to reduce the pain level a
fair bit.

> 
> Bestr regards,
> Bapt

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: How to enable tcp bbr in FreeBSD???

[Rodney W. Grimes]

> On Fri, Apr 24, 2020 at 01:31:35PM +0200, Kurt Jaeger wrote:
> > 
> > Thanks. Is BBR active automatically or is there a sysctl or
> > socket option to activate it ?
> 
> net.inet.tcp.cc.available: List available congestion control algorithms
> net.inet.tcp.cc.algorithm: Default congestion control algorithm

Start at:
man mod_cc


-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenZFS port updated

[Rodney W. Grimes]

> FreeBSD support has been merged into the master branch of the openzfs/zfs 
> repository, and the FreeBSD ports have been switched to this branch.
> 
> OpenZFS brings many exciting features to FreeBSD, including:
>  * native encryption
>  * improved TRIM implementation
>  * most recently, persistent L2ARC
> 
> Of course, avoid upgrading your pools if you want to keep the option to go 
> back to the base ZFS.

Has anyone published a set of pool options vs *ZFS implementations so one can 
figure out least common denomitator set of options when creating cross system 
pools, as the trial and error method is a royal pain.

> 
> OpenZFS can be installed alongside the base ZFS. Change your loader.conf 
> entry to openzfs_load=?YES? to load the OpenZFS module at boot, and set PATH 
> to find the tools in /usr/local/sbin before /sbin. The base zfs tools are 
> still basically functional with the OpenZFS module, so changing PATH in rc is 
> not strictly necessary.
> 
> The FreeBSD loader can boot from pools with the encryption feature enabled, 
> but the root/bootenv datasets must not be encrypted themselves.
> 
> The FreeBSD platform support in OpenZFS does not yet include all features 
> present in FreeBSD?s ZFS. Some notable changes/missing features include:
>  * many sysctl names have changed (legacy compat sysctls should be added at 
> some point) 
>  * zfs send progress reporting in process title via setproctitle
>  * extended 'zfs holds -r' 
> (https://svnweb.freebsd.org/base?view=revision=290015)
>  * vdev ashift optimizations 
> (https://svnweb.freebsd.org/base?view=revision=254591)
>  * pre-mountroot zpool.cache loading (for automatic pool imports)
> 
> To the last point, this mainly effects the case where / is on ZFS and /boot 
> is not or is on a different pool. OpenZFS cannot handle this case yet, but 
> work is in progress to cover that use case. Booting directly from ZFS does 
> work.
> 
> If there are pools that need to be imported at boot other than the boot pool, 
> OpenZFS does not automatically import yet, and it uses /etc/zfs/zpool.cache 
> rather than /boot/zfs/zpool.cache to keep track of imported pools.  To ensure 
> all pool imports occur automatically, a simple edit to /etc/rc.d/zfs will 
> suffice:

I am not so keen on the idea of "cache" data living in /boot, but I suppose 
/boot is already tainted with per machine data that should of lived someplace 
else.

> diff --git a/libexec/rc/rc.d/zfs b/libexec/rc/rc.d/zfs
> index 2d35f9b5464..8e4aef0b1b3 100755
> --- a/libexec/rc/rc.d/zfs
> +++ b/libexec/rc/rc.d/zfs
> @@ -25,6 +25,13 @@ zfs_start_jail()
>  
>  zfs_start_main()
>  {
> + local cachefile
> +
> + for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do
> + if [ -f $cachefile ]; then
> + zpool import -c $cachefile -a
> + fi
> + done
>   zfs mount -va
>   zfs share -a
>   if [ ! -r /etc/zfs/exports ]; then
> 
> This will probably not be needed long-term. It is not necessary if the boot 
> pool is the only pool.
> 
> Happy testing :)
> 
> - Ryan
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: sort.core error doing installworld on Current.

[Rodney W. Grimes]

> > 
> > Op 17-04-2020 om 03:31 schreef Rodney W. Grimes:
> > >> On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman  
> > >> wrote:
> > >>
> > >>> So you some how had a sort core dump sitting in
> > >>> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how
> > >>> did get there? I'd take a look at the date on the file and, it it is 
> > >>> older
> > >>> than the buildworld, just assume that it was left-over garbage. In 
> > >>> either
> > >>> case, you can delete it and do another installworld.
> > >>>
> > >>> That should most likely fix things, but, if the buildworld or 
> > >>> installworld
> > >>> had a crash of sort(1) that left the file, further investigation might 
> > >>> be
> > >>> needed. Re-making the zoneinfo would help track it down should this be 
> > >>> a re
> > >>> al bug, but it's my uneducated guess that it's not.
> > >>> --
> > >>> Kevin Oberman, Part time kid herder and retired Network Engineer
> > >>> E-mail: rkober...@gmail.com
> > >>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> > >>>
> > >> Please forgive that awful post! I missed a part of your message by 
> > >> laziness.
> > >>
> > >> It's odd that the error of sort(1) crashing was not caught by the script.
> > > Yes, that is a Makefile flaw someplace.
> > > Further there must be a wildcard being used to decide which files to
> > > install, that is a further Makefile flaw.  Wildcards should NOT be used
> > > in the source of an install list, exactly because of this type of cruft
> > > that can be dropped in an obj dir.

>From src/share/zoneinfo/Makefile at about line 93:
92  if make(*install*)
93  TZS!= cd ${TZBUILDDIR} && find * -type f | LC_ALL=C sort
  this is a very bad thing to do in a 
Makefile.

94  .endif

Now I still don't know why sort cored, but I am sure this is the line that did 
it.

> > >
> > >> Clearly, sort should NOT crash! Again, a re-build of zoneinfo might catch
> > >> something. Looking at the core might tell you which "sort" was 
> > >> involved...
> > >> the one you just built or the one in the base system. This could be just 
> > >> a
> > >> FOTU, but I would not bet on it.
> > > I suspect a recent zoneinfo commit as the root cause.
> > >
> > I have no idea how to bypass this issue.
> > I have used sort from the latest snapshot and placed that file on the 
> > system and in the build dir, but i keep getting the core
> > 
> > How can i test an build and install part for zoneinfo
> > 
> > If i go into the dir /usr/src/share/zoneinfo and do make install it does 
> > not work, do i need to add something?
> 
> Can you show us the output from
> cd /usr/src/share/zoneinfo
> make clean && make depend && make all && make install
> Someplace in that we should get to see sort crashing...
> 
> > 
> > Thank you both for your time
> > 
> > >> --
> > >> Kevin Oberman, Part time kid herder and retired Network Engineer
> > >> E-mail: rkober...@gmail.com
> > >> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> > >>
> > >>
> > >>>
> > >>> On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks 
> > >>> wrote:
> > >>>
> > >>>> I have a machine running FreeBSD head.
> > >>>> rev 13.0-CURRENT #11 r360008
> > >>>>
> > >>>> This is a quite powerful machine, so i thought it was a good idea to 
> > >>>> let
> > >>>> that server do the build and for my virtualbox machine i can use the
> > >>>> powerful machine to do a installword over NFS.
> > >>>>
> > >>>> But when i did the make installworld step the client so to say gives an
> > >>>> error.
> > >>>>
> > >>>> install   -o root -g wheel -m 444
> > >>>> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu
> > >>>> /usr/share/zoneinfo/Zulu
> > >>>> install   -o root -g wheel -m 444
> > >>>> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules
> > >>>> /usr/share/zoneinfo/posixrules
> > >>

Re: sort.core error doing installworld on Current.

[Rodney W. Grimes]

> 
> Op 17-04-2020 om 03:31 schreef Rodney W. Grimes:
> >> On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman  wrote:
> >>
> >>> So you some how had a sort core dump sitting in
> >>> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how
> >>> did get there? I'd take a look at the date on the file and, it it is older
> >>> than the buildworld, just assume that it was left-over garbage. In either
> >>> case, you can delete it and do another installworld.
> >>>
> >>> That should most likely fix things, but, if the buildworld or installworld
> >>> had a crash of sort(1) that left the file, further investigation might be
> >>> needed. Re-making the zoneinfo would help track it down should this be a 
> >>> re
> >>> al bug, but it's my uneducated guess that it's not.
> >>> --
> >>> Kevin Oberman, Part time kid herder and retired Network Engineer
> >>> E-mail: rkober...@gmail.com
> >>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> >>>
> >> Please forgive that awful post! I missed a part of your message by 
> >> laziness.
> >>
> >> It's odd that the error of sort(1) crashing was not caught by the script.
> > Yes, that is a Makefile flaw someplace.
> > Further there must be a wildcard being used to decide which files to
> > install, that is a further Makefile flaw.  Wildcards should NOT be used
> > in the source of an install list, exactly because of this type of cruft
> > that can be dropped in an obj dir.
> >
> >> Clearly, sort should NOT crash! Again, a re-build of zoneinfo might catch
> >> something. Looking at the core might tell you which "sort" was involved...
> >> the one you just built or the one in the base system. This could be just a
> >> FOTU, but I would not bet on it.
> > I suspect a recent zoneinfo commit as the root cause.
> >
> I have no idea how to bypass this issue.
> I have used sort from the latest snapshot and placed that file on the 
> system and in the build dir, but i keep getting the core
> 
> How can i test an build and install part for zoneinfo
> 
> If i go into the dir /usr/src/share/zoneinfo and do make install it does 
> not work, do i need to add something?

Can you show us the output from
cd /usr/src/share/zoneinfo
make clean && make depend && make all && make install
Someplace in that we should get to see sort crashing...

> 
> Thank you both for your time
> 
> >> --
> >> Kevin Oberman, Part time kid herder and retired Network Engineer
> >> E-mail: rkober...@gmail.com
> >> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> >>
> >>
> >>>
> >>> On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks 
> >>> wrote:
> >>>
> >>>> I have a machine running FreeBSD head.
> >>>> rev 13.0-CURRENT #11 r360008
> >>>>
> >>>> This is a quite powerful machine, so i thought it was a good idea to let
> >>>> that server do the build and for my virtualbox machine i can use the
> >>>> powerful machine to do a installword over NFS.
> >>>>
> >>>> But when i did the make installworld step the client so to say gives an
> >>>> error.
> >>>>
> >>>> install   -o root -g wheel -m 444
> >>>> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu
> >>>> /usr/share/zoneinfo/Zulu
> >>>> install   -o root -g wheel -m 444
> >>>> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules
> >>>> /usr/share/zoneinfo/posixrules
> >>>> install   -o root -g wheel -m 444
> >>>> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core
> >>>> /usr/share/zoneinfo/sort.core
> >>>> install: /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core:
> >>>> Permission denied
> >>>> *** Error code 71
> >>>>
> >>>> Stop.
> >>>> bmake[5]: stopped in /usr/src/share/zoneinfo
> >>>> *** Error code 1
> >>>>
> >>>> Stop.
> >>>> bmake[4]: stopped in /usr/src/share
> >>>> *** Error code 1
> >>>>
> >>>> Stop.
> >>>> bmake[3]: stopped in /usr/src
> >>>> *** Error code 1
> >>>>
> >>>> Stop.
> >>>> bmake[2]: stopped in /usr/src
> >>>>

Re: sort.core error doing installworld on Current.

[Rodney W. Grimes]

> On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman  wrote:
> 
> > So you some how had a sort core dump sitting in
> > /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how
> > did get there? I'd take a look at the date on the file and, it it is older
> > than the buildworld, just assume that it was left-over garbage. In either
> > case, you can delete it and do another installworld.
> >
> > That should most likely fix things, but, if the buildworld or installworld
> > had a crash of sort(1) that left the file, further investigation might be
> > needed. Re-making the zoneinfo would help track it down should this be a re
> > al bug, but it's my uneducated guess that it's not.
> > --
> > Kevin Oberman, Part time kid herder and retired Network Engineer
> > E-mail: rkober...@gmail.com
> > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> >
> Please forgive that awful post! I missed a part of your message by laziness.
> 
> It's odd that the error of sort(1) crashing was not caught by the script.

Yes, that is a Makefile flaw someplace.
Further there must be a wildcard being used to decide which files to
install, that is a further Makefile flaw.  Wildcards should NOT be used
in the source of an install list, exactly because of this type of cruft
that can be dropped in an obj dir.

> Clearly, sort should NOT crash! Again, a re-build of zoneinfo might catch
> something. Looking at the core might tell you which "sort" was involved...
> the one you just built or the one in the base system. This could be just a
> FOTU, but I would not bet on it.

I suspect a recent zoneinfo commit as the root cause.

> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> 
> 
> >
> >
> > On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks 
> > wrote:
> >
> >> I have a machine running FreeBSD head.
> >> rev 13.0-CURRENT #11 r360008
> >>
> >> This is a quite powerful machine, so i thought it was a good idea to let
> >> that server do the build and for my virtualbox machine i can use the
> >> powerful machine to do a installword over NFS.
> >>
> >> But when i did the make installworld step the client so to say gives an
> >> error.
> >>
> >> install   -o root -g wheel -m 444
> >> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu
> >> /usr/share/zoneinfo/Zulu
> >> install   -o root -g wheel -m 444
> >> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules
> >> /usr/share/zoneinfo/posixrules
> >> install   -o root -g wheel -m 444
> >> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core
> >> /usr/share/zoneinfo/sort.core
> >> install: /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core:
> >> Permission denied
> >> *** Error code 71
> >>
> >> Stop.
> >> bmake[5]: stopped in /usr/src/share/zoneinfo
> >> *** Error code 1
> >>
> >> Stop.
> >> bmake[4]: stopped in /usr/src/share
> >> *** Error code 1
> >>
> >> Stop.
> >> bmake[3]: stopped in /usr/src
> >> *** Error code 1
> >>
> >> Stop.
> >> bmake[2]: stopped in /usr/src
> >> *** Error code 1
> >>
> >> Stop.
> >> bmake[1]: stopped in /usr/src
> >> *** Error code 1
> >>
> >> Stop.
> >> make: stopped in /usr/src
> >> .ERROR_TARGET='installworld'
> >> .ERROR_META_FILE=''
> >> .MAKE.LEVEL='0'
> >> MAKEFILE=''
> >> .MAKE.MODE='normal'
> >> _ERROR_CMD='.PHONY'
> >> .CURDIR='/usr/src'
> >> .MAKE='make'
> >> .OBJDIR='/usr/obj/usr/src/amd64.amd64'
> >> .TARGETS='installworld'
> >> DESTDIR=''
> >> LD_LIBRARY_PATH=''
> >> MACHINE='amd64'
> >> MACHINE_ARCH='amd64'
> >> MAKEOBJDIRPREFIX='/usr/obj'
> >> MAKESYSPATH='/usr/src/share/mk'
> >> MAKE_VERSION='20181221'
> >> PATH='/sbin:/bin:/usr/sbin:/usr/bin'
> >> SRCTOP='/usr/src'
> >> OBJTOP='/usr/obj/usr/src/amd64.amd64'
> >>
> >> It looks likes sort coredumps in the usr/share/zoneinfo part of the base.
> >> As it has no permission on the NFS share it errors out.
> >> On the server itself, the installworld goes well, but it leaves a
> >> sort.core file behind in /usr/share/zoneinfo
> >>
> >> cd /usr/share/zoneinfo
> >> ls -al
> >>
> >>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Working on Zoom port

[Rodney W. Grimes]

> All,
> 
> Given how Zoom is getting used a lot more these days, I've started
> working on a port that installs the Zoom linux client.
> 
> Here is a link to my github if anyone wants to help:
> 
> https://github.com/emc2/freebsd-ports/tree/zoom
> 
> 
> I'm not done yet.  The zoom linux client installs a bunch of Qt
> libraries in its own directory.  These either need to be installed with
> a port, or else the right configs need to be set to search for libraries
> there.
> 
> I'm going to take a break, but I'm going to circle back to this.
> 

You are aware of the rather large pile of recent security issues
surronding zoom I hope.

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel failure because ctfconvert not installed

[Rodney W. Grimes]

> On Fri, Apr 10, 2020 at 10:45 AM Rodney W. Grimes <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
> 
> > > 
> > > In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri
> > Pankov writes:
> > > >Trond Endrest?l wrote:
> > > >> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote:
> > > >>
> > > >>> OK, I figured it out.
> > > >>>
> > > >>> I used to have MK_CTF=no in src.conf, but I recently changed it to
> > > >>> WITH_CTF=no.
> > > >>
> > > >> It's either WITH_xxx=yes or WITHOUT_xxx=yes
> >
> 
> It's either -DWITH_FOO or -DWITHOUT_FOO. yes or no  never enters into it.

Then we *COULD*, maybe even *SHOULD* check for a value and
complain if one is set.

> 
> 
> > > >Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that
> > > >value is NOT checked:
> > > >
> > > >The values of variables are ignored regardless of their setting; even
> > if
> > > >  they would be set to "FALSE" or "NO".  The presence of an option
> > > >causes it to be honored by make(1).
> > >
> > > That is not even close to POLA-compliance...
> >
> 
> It took 20 years for someone to notice. If it takes 20 years to be
> astonished, I suspect that it comes close to 'least' by any sane measure.

I do not see the word *recent* in POLA.
As far as I can tell POLA is time invariant.

> 
> > I am not a fan of it either, not sure when this idea came about
> > of doing WITH_ and WITHOUT and ignoring the set value, but it
> > is very non POLA given how many variables we do have with set values.
> >
> 
> We've literally ignored the value for the last 20 years or so (we started
> in the 4.x time frame). This is the first time it's come up. It's hard to
> make a convincing POLA argument based on this data.

Wrong or bad for 20 years makes it no less wrong.

> We specifically ignored it because we had crazy s*** in the tree like
> NOSHARED=no meaning something. And it wasn't quite the something you'd
> think it would mean without careful study (it meant do link this shared,
> which is straight forward enough. But it didn't mean do create this library
> as shared).

What you call crazy s*** is just double negatives, and though it is
poor it actually has clear symantics.

You want crazy s***
WITH_xxx=yes
WITH_xxx=no
do exactly the same thing!   Now thats crazy s***

> 
> 
> > > Obviously negative values ("false", "no") should either be reported as
> > > errors or preferably be respected.
> >
> 
> You can't make something foolproof because fools are so ingenious. Also,
> turns out it's trickier to "fix" than you might think.

It really isnt hard to fix... just stop using, then later allowing a value
on WITH_xxx or WITHOUT_xxx.

Right now we could add a warning if a value is set, people would slowly
weed out this poor use, and in time up the warning to an error.

> 
> We almost certainly are not going to change this.
Your position, others are free to disagree, as I do.

> Why aren't we going to
> change it? It took 20 years for someone to complain and it may break
> currently working scripts that rely on the documented behavior of the
> variable being defined to define WITH_FOO=n for  some crazy reason. And
> this isn't a theoretical example, I know of at least two build systems that
> define WITH_FOO or WITHOUT_FOO to some value. Also, does WITHOUT_FOO=no
> mean "I don't want foo"? or "I don't not want foo?" So if you don't do it
> for WITHOUT but do to it for WITH, you wind up with another mess of
> inconsistency, or you wind up getting close to have NOSHARED=no again.

See proposed "change and fix".  

> Warner
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel failure because ctfconvert not installed

[Rodney W. Grimes]

> 
> In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri Pankov 
> writes:
> >Trond Endrest?l wrote:
> >> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote:
> >> 
> >>> OK, I figured it out.
> >>>
> >>> I used to have MK_CTF=no in src.conf, but I recently changed it to
> >>> WITH_CTF=no.
> >> 
> >> It's either WITH_xxx=yes or WITHOUT_xxx=yes.
> >
> >Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that 
> >value is NOT checked:
> >
> >The values of variables are ignored regardless of their setting; even if 
> >  they would be set to "FALSE" or "NO".  The presence of an option 
> >causes it to be honored by make(1).
> 
> That is not even close to POLA-compliance...

I am not a fan of it either, not sure when this idea came about
of doing WITH_ and WITHOUT and ignoring the set value, but it
is very non POLA given how many variables we do have with set values.

> 
> Obviously negative values ("false", "no") should either be reported as
> errors or preferably be respected.
> 
> PS: [This is not the bikeshed you are looking for]

BLUE!

> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS: OpenZFS: lost the ability to boot a BE

[Rodney W. Grimes]

> To temporarily mount a ZFS filesystem:
> 
> mount -t zfs poolname/data/set /path/here

Is there anyway to get the zfs command to add mountpoint as
a temporary value like it does some of the others so that

zfs mount -o mountpoint=/mnt poolname/data/set

would just do the right thing?

> 
> 
> On 2020-03-30 19:53, Graham Perrin wrote:
> > On 30/03/2020 19:47, Graham Perrin wrote:
> >> I lost the ability to boot the environment named 'r357746', I suspect
> >> this occurred after I set it to use OpenZFS in lieu of ZFS.
> >>
> >> I would like to edit its /boot/loader.conf (revert to zfs_load="YES")
> >> but re: https://github.com/openzfs/zfs/issues/4553 I can not think of
> >> a way to mount the dataset.
> >>
> >> Please, how can I proceed?
> > 
> > Whilst booted from a different environment, I mounted the dataset whilst
> > in single user mode, edited /boot/loader.conf ? a little tricky, because
> > after the mount I could no longer use zfs commands (ZFS library
> > initialisation failed, words to that effect). Then beadm to activate the
> > BE, and shutdown -r now
> > 
> > Success :-)
> > 
> > With zfs_load="YES" (in lieu of openzfs_load="YES") the BE is usable.
> > 
> >> 
> >>
> >> Re: ZFS: destroying snapshots without compromising boot environments
> >>
> >> On 28/03/2020 15:36, Graham Perrin wrote:
> >>> On 28/03/2020 15:19, Allan Jude wrote:
> >>>
> >>> > You can try to destroy the snapshot, if it is the basis of a clone,
> >>> then
> >>> > you will get an error, that you'd need to destroy the BE first, so you
> >>> > might decide to keep that snapshot. As long as you don't use the -R
> >>> flag
> >>> > to zfs destroy dataset@snapshot, it will not destroy the clones.
> >>> >
> >>> > You can also use 'zfs promote' to make the clone into the parent,
> >>> making
> >>> > the original parent into the clone. This allows you to destroy that
> >>> > original and the snapshot while keeping the clone.
> >>>
> >>> Perfect, thank you. I was nervous about destruction without warning.
> >>>
> >>> Below, are the differences (in measurement) between beadm and bectl
> >>> to be expected?
> >>>
> >>> 
> >>>
> >>> root@momh167-gjp4-8570p:~ # beadm list
> >>> BE?? Active Mountpoint? Space Created
> >>> Waterfox -? -?? 15.9G 2020-03-10 18:24
> >>> r357746f -? -??? 1.3G 2020-03-20 06:19
> >>> r359249b NR /?? 74.7G 2020-03-28 01:19
> >>> root@momh167-gjp4-8570p:~ # beadm list -aDs
> >>> BE/Dataset/Snapshot??? Active Mountpoint
> >>> Space Created
> >>>
> >>> Waterfox
> >>> ? copperbowl/ROOT/Waterfox -? - 137.0M
> >>> 2020-03-10 18:24
> >>> ??? r359249b@2020-03-17-21:57:17?? -? - 59.2G
> >>> 2020-03-17 21:57
> >>> ? copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 -? - 67.0M
> >>> 2020-03-20 06:19
> >>>
> >>> r357746f
> >>> ? copperbowl/ROOT/r357746f -? - 1.2G
> >>> 2020-03-20 06:19
> >>> ??? Waterfox@2020-03-20-06:19:45?? -? - 59.2G
> >>> 2020-03-20 06:19
> >>>
> >>> r359249b
> >>> ? copperbowl/ROOT/r359249b@2020-03-17-21:57:17 -? - 15.7G
> >>> 2020-03-17 21:57
> >>> ? copperbowl/ROOT/r359249b NR / 59.0G
> >>> 2020-03-28 01:19
> >>> root@momh167-gjp4-8570p:~ # bectl list
> >>> BE?? Active Mountpoint Space Created
> >>> Waterfox -? -? 204M? 2020-03-10 18:24
> >>> r357746f -? -? 1.21G 2020-03-20 06:19
> >>> r359249b NR /? 74.7G 2020-03-28 01:19
> >>> root@momh167-gjp4-8570p:~ # bectl list -aDs
> >>> BE/Dataset/Snapshot? Active Mountpoint
> >>> Space Created
> >>>
> >>> Waterfox
> >>> ? copperbowl/ROOT/Waterfox?? -? - 204M
> >>> 2020-03-10 18:24
> >>> ? Waterfox@2020-03-20-06:19:45?? -? - 67.0M
> >>> 2020-03-20 06:19
> >>>
> >>> r357746f
> >>> ? copperbowl/ROOT/r357746f?? -? - 1.21G
> >>> 2020-03-20 06:19
> >>>
> >>> r359249b
> >>> ? copperbowl/ROOT/r359249b?? NR / 74.7G
> >>> 2020-03-28 01:19
> >>> ? r359249b@2020-03-17-21:57:17?? -? - 15.7G
> >>> 2020-03-17 21:57
> >>> root@momh167-gjp4-8570p:~ # zfs list -t snapshot
> >>> NAME USED AVAIL?
> >>> REFER? MOUNTPOINT
> >>> copperbowl/ROOT/Waterfox@2020-03-20-06:19:45??? 67.0M - 59.2G? -
> >>> copperbowl/ROOT/r359249b@2020-03-17-21:57:17??? 15.7G - 59.2G? -
> >>> copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers 8K - 1.24G? -
> >>> copperbowl/poudriere/jails/head@clean??? 328K - 1.89G? -
> >>> root@momh167-gjp4-8570p:~ # zfs destroy
> >>> copperbowl/ROOT/r359249b@2020-03-17-21:57:17
> >>> cannot destroy 'copperbowl/ROOT/r359249b@2020-03-17-21:57:17':
> >>> snapshot has dependent clones
> >>> use '-R' to destroy the following datasets:
> >>> copperbowl/ROOT/r357746f
> >>> copperbowl/ROOT/Waterfox@2020-03-20-06:19:45
> >>>