Re: usr.bin/xinstall r366697 versus: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71

[Nick Wolff]

I also have this breaking builds. Do we have plans to revert this until a
variant that doesn't break builds in some corner cases is completed?

On Tue, Dec 15, 2020 at 12:22 PM Ryan Moeller  wrote:

>
> On 12/12/20 2:15 AM, Graham Perrin wrote:
> > On 23/11/2020 12:18, Graham Perrin wrote:
> >
> >> On 22/11/2020 12:00, Dimitry Andric wrote:
> >>> …
> >>> I'd guess it's an unintended side-effect of
> >>> https://svnweb.freebsd.org/base?view=revision&revision=366697
> >>> ("install(1): Avoid unncessary fstatfs() calls and use mmap() based on
> >>> size").
> >>>
> >>> If you only revert usr.bin/xinstall to r366696, and then rebuild it,
> >>> does it still occur?
> >>>
> >>> -Dimitry
> >>
> >> Thank you!
> >>
> >> Success with r366696:
> >>
> >> 
> >>
> >> …
> >
> >
> > Re:
> > <
> https://lists.freebsd.org/pipermail/freebsd-current/2020-November/077634.html>
>
> > please, should I open a bug for this?
> >
> >
> > Is the issue exposed by my choice of gzip-9 for e.g. /usr/ and if so,
> > can I avoid it by (now) reverting to lz4 for that part, and/or any
> > other part, of the file system?
> >
> >
>
> Unfortunately I don't have an answer for you at this time, but ACK.
>
>
> -Ryan
>
>
> > 
> >
> >
> > root@mowa219-gjp4-8570p:~ # zfs get mountpoint,compression
> > NAME PROPERTY VALUE SOURCE
> > Transcend mountpoint /Volumes/t500  local
> > Transcend compression zstd
> > local
> > Transcend/VirtualBox mountpoint   /Volumes/t500/VirtualBox inherited
> > from Transcend
> > Transcend/VirtualBox compression  zstd inherited from Transcend
> > copperbowl mountpoint /copperbowl
> > local
> > copperbowl compression lz4
> > local
> > copperbowl/ROOT mountpoint
> > none   local
> > copperbowl/ROOT compression  lz4 inherited from copperbowl
> > copperbowl/ROOT/Waterfox mountpoint
> > /  local
> > copperbowl/ROOT/Waterfox compression  lz4 inherited from copperbowl
> > copperbowl/ROOT/r367081f mountpoint
> > /  local
> > copperbowl/ROOT/r367081f compression  lz4 inherited from copperbowl
> > copperbowl/ROOT/r367936e mountpoint
> > /  local
> > copperbowl/ROOT/r367936e compression  lz4 inherited from copperbowl
> > copperbowl/ROOT/r367936f mountpoint
> > /  local
> > copperbowl/ROOT/r367936f compression  lz4 inherited from copperbowl
> > copperbowl/ROOT/r367936f@2020-03-20-06:19:45 mountpoint
> > -  -
> > copperbowl/ROOT/r367936f@2020-03-20-06:19:45 compression
> > -  -
> > copperbowl/ROOT/r367936f@2020-11-22-23:18:47 mountpoint
> > -  -
> > copperbowl/ROOT/r367936f@2020-11-22-23:18:47 compression
> > -  -
> > copperbowl/ROOT/r367936f@2020-12-06-16:23:14 mountpoint
> > -  -
> > copperbowl/ROOT/r367936f@2020-12-06-16:23:14 compression
> > -  -
> > copperbowl/VirtualBox mountpoint
> > /usr/local/VirtualBox  local
> > copperbowl/VirtualBox compression
> > gzip-9 local
> > copperbowl/iocage mountpoint   /copperbowl/iocage inherited from
> > copperbowl
> > copperbowl/iocage compression
> > gzip-9 local
> > copperbowl/iocage/download mountpoint /copperbowl/iocage/download
> > inherited from copperbowl
> > copperbowl/iocage/download compression
> > lz4local
> > copperbowl/iocage/download/12.0-RELEASE mountpoint
> > /copperbowl/iocage/download/12.0-RELEASE inherited from copperbowl
> > copperbowl/iocage/download/12.0-RELEASE compression
> > lz4local
> > copperbowl/iocage/images mountpoint   /copperbowl/iocage/images
> > inherited from copperbowl
> > copperbowl/iocage/images compression
> > lz4local
> > copperbowl/iocage/jails mountpoint   /copperbowl/iocage/jails
> > inherited from copperbowl
> > copperbowl/iocage/jails compression
> > lz4local
> > copperbowl/iocage/jails/jbrowsers mountpoint
> > /copperbowl/iocage/jails/jbrowsers inherited from copperbowl
> > copperbowl/iocage/jails/jbrowsers compression  lz4 inherited from
> > copperbowl/iocage/jails
> > copperbowl/iocage/jails/jbrowsers/root mountpoint
> > /copperbowl/iocage/jails/jbrowsers/root inherited from copperbowl
> > copperbowl/iocage/jails/jbrowsers/root compression  lz4 inherited from
> > copperbowl/iocage/jails
> > copperbowl/iocage/log mountpoint   /copperbowl/iocage/log inherited
> > from copperbowl
> > copperbowl/iocage/log compression
> > lz4   

Re: Deprecating ftpd in the FreeBSD base system?

[Nick Wolff]

On Thu, Sep 17, 2020 at 3:54 PM Ian Lepore  wrote:

> On Thu, 2020-09-17 at 12:49 -0700, John-Mark Gurney wrote:
> > Ian Lepore wrote this message on Thu, Sep 17, 2020 at 09:01 -0600:
> > > On Thu, 2020-09-17 at 18:43 +0400, Gleb Popov wrote:
> > > > On Thu, Sep 17, 2020 at 6:05 PM Cy Schubert <
> > > > cy.schub...@cschubert.com>
> > > > wrote:
> > > >
> > > > > I've been advocating removing FTP (and HTTP) from libfetch as
> > > > > well.
> > > > > People
> > > > > should be using HTTPS only.
> > > > >
> > > >
> > > > Isn't this a bit too much? I often find myself in need to
> > > > download
> > > > something starting with "http://"; or "ftp://"; and use fetch for
> > > > this.
> > >
> > > Indeed, we have products which rely on this ability in libfetch and
> > > we
> > > have to keep supporting them for many many years to come.
> > >
> > > I hate it when someone imperiously declares [For security reasons]
> > > "People should/shouldn't be using __".  You have no idea what
> > > the
> > > context is, and thus no ability to declare what should or shouldn't
> > > be
> > > used in that context.  For example, two embedded systems talking to
> > > each other over a point to point link within a sealed device are
> > > not
> > > concerned about man in the middle attacks or other modern internet
> > > threats.
> >
> > And I really dislike when people want to make sure that their unique
> > case that less than a percent of people would every hit blocks the
> > security improvements for the majority of people...
> >
> > I've given up on a number of security improvements in FreeBSD because
> > of this attitude...
> >
>
> Good.  Because what you call "improvements" I would probably call
> "Imposing policy rather than providing tools."
>
> I've don't complain about making defaults the safest choices available.
> I complain about removing options completely because they're unsafe in
> some circumstances according to some people.
>
> -- Ian
>
>
> ___
> 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"
>

  Even making defaults the "safest choice" I have any issue with. Security
is a balance between risk, environment and usability.  The "Safest choice"
is turning your box off or cutting your internet connection. Now hardening
as an option in a global config file for whatever program I have no issue
with just need to be very careful on what is hardened by default and what
is exposed as an option for hardening to those who need it. Also as a
reminder just because something has a hardening option that is disabled by
default that doesn't mean the project ever needs to enable it by default.
Sometimes we add those options and have a migration path/timeline to them
being enabled by default sometimes we just add those options for those who
need them whether by policy, environment, or paranoia.

So a global option in a config file or ENV variable to disable unencrypted
protocols by default is fine. It just should

Also in defense of http is it allows caching. If you are downloading a
signed resource to 10, 100 or 1,000,000 boxes and don't care who knows
caching maybe a very helpful option.

--Nick "darkfiberiru" Wolff
___
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: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

[Nick Wolff]

Sorry boot is broken from harddrive or iso(as cdrom) for some users(at
least 3) since somewhere in the revisions listed above and that still
stands as of the Head snapshot of 072519. Sorry for lack of clarity. There
was a thread under Problem with USB after r349133 but I decided to rename
it to try to catch more people's eyes/get more reports in if people run
into the issue. Don't think or at least know for sure USB is the problem as
when you bypass the waiting for USB you get a different hang farther into
system booting.

I will try to bisect the build in that magic revision range once I figure
out on what system as it's my primary builder that's having this issue. Not
that I have a lack of hardware I guess just time to setup something else.




On Mon, Jul 29, 2019, 21:45 Clay Daniels Jr. 
wrote:

> Rodney, you are right that the .iso "should work", and a lot of other
> projects, from Microsoft Windows 10 to Trident BSD only a furnish an iso,
> and no img file. FreeBSD is one of the few that give you both choices. The
> problem goes deeper than any one operating system. If you've ever used the
> Rufus tool to make a bootable usb, which is all Rufus does, you may have
> come across problems with "mount root". I found this article, answered by a
> Rufus developer very enlightening.
>
> https://superuser.com/questions/1170832/why-are-there-different-options-for-creating-bootable-usb-compared-to-a-cd
>
> I have a collection of usb thumbdrives here at my desk, and use them a
> lot, but I also bought me some blank dvd disks and use them too.
>
> But I think you are right, Nick Wolff's problem may be a a bug to be
> reported. All I know is I took the same file,
> FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso
> 
> , burned it to a dvd, and I'm now writing this email from the FreeBSD
> 13.0-CURRENT r350322 partition of my computer.
>
> Clay
>
___
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"

Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

[Nick Wolff]

I just tested the snapshot from 20190725 and still am getting the root
mount rating for "boot on boot. I think something deeper broke between
r349133 and r349160 because even when I turn off wait for Root Mount on usb
root via a loader variable boot just get's stuck later on in the process.

This is all happening on an x11-dpi-nt board.

http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso

On Mon, Jul 22, 2019 at 12:57 PM Nick Wolff  wrote:

> Hans,
>
> I'm building r350003  at the moment which is after the acpi change was
> moved into an unloaded module.
>
>
>
> On Mon, Jul 22, 2019 at 12:13 PM Hans Petter Selasky 
> wrote:
>
>> On 2019-07-22 17:23, Nick Wolff wrote:
>> > Sorry for email spam but I was wrong. Just gets stuck now during
>> reproping
>> > a pci device after init happens(this is actually a trueos build which is
>> > why you see openrc). That device it's getting stuck on is "Sky Lake-E
>> CBDMA
>> > Registers" which shouldn't have a driver attached.
>> >
>> https://drive.google.com/file/d/19NFI0Dcupu3ZcVxbcr2vYFZ-iDqiIzkx/view?usp=sharing
>> >
>> > Though it maybe something else getting stuck at this point and that just
>> > happens to be the last thing on the screen.
>> >
>>
>> There was a recent change to add an ACPI wrapper for the USB HUB driver,
>> but that was a bit premature and introduced some bugs. For now the ACPI
>> USB HUB wrapper is not enabled by default. Do you experience issues with
>> the latest -current ?
>>
>> --HPS
>>
>>
___
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: Problem with USB after r349133

[Nick Wolff]

Hans,

I'm building r350003  at the moment which is after the acpi change was
moved into an unloaded module.



On Mon, Jul 22, 2019 at 12:13 PM Hans Petter Selasky 
wrote:

> On 2019-07-22 17:23, Nick Wolff wrote:
> > Sorry for email spam but I was wrong. Just gets stuck now during
> reproping
> > a pci device after init happens(this is actually a trueos build which is
> > why you see openrc). That device it's getting stuck on is "Sky Lake-E
> CBDMA
> > Registers" which shouldn't have a driver attached.
> >
> https://drive.google.com/file/d/19NFI0Dcupu3ZcVxbcr2vYFZ-iDqiIzkx/view?usp=sharing
> >
> > Though it maybe something else getting stuck at this point and that just
> > happens to be the last thing on the screen.
> >
>
> There was a recent change to add an ACPI wrapper for the USB HUB driver,
> but that was a bit premature and introduced some bugs. For now the ACPI
> USB HUB wrapper is not enabled by default. Do you experience issues with
> the latest -current ?
>
> --HPS
>
>
___
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: Problem with USB after r349133

[Nick Wolff]

Sorry for email spam but I was wrong. Just gets stuck now during reproping
a pci device after init happens(this is actually a trueos build which is
why you see openrc). That device it's getting stuck on is "Sky Lake-E CBDMA
Registers" which shouldn't have a driver attached.
https://drive.google.com/file/d/19NFI0Dcupu3ZcVxbcr2vYFZ-iDqiIzkx/view?usp=sharing

Though it maybe something else getting stuck at this point and that just
happens to be the last thing on the screen.

On Mon, Jul 22, 2019 at 10:52 AM Nick Wolff  wrote:

> Thomas/HPS,
>
> I did manage to get a boot with hw.usb.no_boot_wait=1 set in loader.conf.
> So if any debugging information off a running system would be helpful let
> me know.
>
> Thanks,
>
> Nick Wolff
>
> On Mon, Jul 22, 2019 at 10:27 AM Nick Wolff 
> wrote:
>
>> Hello Thomas,
>>
>> Any updates? Did you get a bugzilla ticket filed?
>>
>> Thanks,
>>
>> Nick Wolff
>>
>> On Sat, Jul 6, 2019 at 2:48 PM Thomas Laus  wrote:
>>
>>> On 2019-07-06 10:17, Graham Perrin wrote:
>>> >
>>> > I had the almost same (different bus numbers), just once, after
>>> updating
>>> > -CURRENT from r349099 to r349762.
>>> >
>>> > The subsequent boot of r349762 was free from the symptom.
>>> >
>>> > HP EliteBook 8570p, docked, with a Kensington keyboard and Logitech
>>> > trackball connected to USB ports at the side of the dock.
>>> >
>>> > At one of the USB ports at the rear of the dock was a rechargeable
>>> > motorised device, which I disconnected after the (one) USB issue.
>>> >
>>> I just built and installed r349161 and observed the same problem with
>>> the rc.conf probe for USBUS7 ... USBUS0.
>>>
>>> I will build r349160 and make a report.
>>>
>>> Tom
>>>
>>>
>>> --
>>> Public Keys:
>>> PGP KeyID = 0x5F22FDC1
>>> GnuPG KeyID = 0x620836CF
>>> ___
>>> 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"

Re: Problem with USB after r349133

[Nick Wolff]

Thomas/HPS,

I did manage to get a boot with hw.usb.no_boot_wait=1 set in loader.conf.
So if any debugging information off a running system would be helpful let
me know.

Thanks,

Nick Wolff

On Mon, Jul 22, 2019 at 10:27 AM Nick Wolff  wrote:

> Hello Thomas,
>
> Any updates? Did you get a bugzilla ticket filed?
>
> Thanks,
>
> Nick Wolff
>
> On Sat, Jul 6, 2019 at 2:48 PM Thomas Laus  wrote:
>
>> On 2019-07-06 10:17, Graham Perrin wrote:
>> >
>> > I had the almost same (different bus numbers), just once, after updating
>> > -CURRENT from r349099 to r349762.
>> >
>> > The subsequent boot of r349762 was free from the symptom.
>> >
>> > HP EliteBook 8570p, docked, with a Kensington keyboard and Logitech
>> > trackball connected to USB ports at the side of the dock.
>> >
>> > At one of the USB ports at the rear of the dock was a rechargeable
>> > motorised device, which I disconnected after the (one) USB issue.
>> >
>> I just built and installed r349161 and observed the same problem with
>> the rc.conf probe for USBUS7 ... USBUS0.
>>
>> I will build r349160 and make a report.
>>
>> Tom
>>
>>
>> --
>> Public Keys:
>> PGP KeyID = 0x5F22FDC1
>> GnuPG KeyID = 0x620836CF
>> ___
>> 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"

Re: Problem with USB after r349133

[Nick Wolff]

Hello Thomas,

Any updates? Did you get a bugzilla ticket filed?

Thanks,

Nick Wolff

On Sat, Jul 6, 2019 at 2:48 PM Thomas Laus  wrote:

> On 2019-07-06 10:17, Graham Perrin wrote:
> >
> > I had the almost same (different bus numbers), just once, after updating
> > -CURRENT from r349099 to r349762.
> >
> > The subsequent boot of r349762 was free from the symptom.
> >
> > HP EliteBook 8570p, docked, with a Kensington keyboard and Logitech
> > trackball connected to USB ports at the side of the dock.
> >
> > At one of the USB ports at the rear of the dock was a rechargeable
> > motorised device, which I disconnected after the (one) USB issue.
> >
> I just built and installed r349161 and observed the same problem with
> the rc.conf probe for USBUS7 ... USBUS0.
>
> I will build r349160 and make a report.
>
> Tom
>
>
> --
> Public Keys:
> PGP KeyID = 0x5F22FDC1
> GnuPG KeyID = 0x620836CF
> ___
> 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"