Re: ata broken on Thinkpad A22m

[Thomas Mueller]

On Fri, 10 Oct 2003 08:37:41 -0700 (PDT) Brian Buchanan wrote:
> After updating to yesterday's -CURRENT, my IBM Thinkpad A22m stoped
> booting.  It hangs at:
> 
> GEOM: create disk ad0 dp=0xc3ded670
> ad0: 38154MB  [77520/16/63] at ata0-master UDMA33
> ata1: resetting devices ..
> done
> 

I had the same problem on my HP XT6050 laptop. This patch solved the problem
for me.

--- ata-queue.c.1.7 Tue Oct  7 16:38:46 2003
+++ ata-queue.c Fri Oct 10 09:28:56 2003
@@ -316,7 +316,7 @@
 {
 /* clear timeout etc */
 request->timeout_handle.callout = NULL;
-#if 0
+
 /* call interrupt to try finish up the command */
 request->device->channel->hw.interrupt(request->device->channel);
 
@@ -327,7 +327,6 @@
   ata_cmd2str(request));
return;
 }
-#endif
 
 /* if this was a DMA request stop the engine to be on the safe side */
     if (request->flags & ATA_R_DMA) {

-- 
Thomas Mueller  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: drm / drm2 removal in 12

[Thomas Mueller]

Excerpt from Oliver Pinter:

> Let's do some more step backwards, and see how the graphics driver
> developments works from the corporation side.
> They not bother about any of the BSDs, they focus only to Windows and
> Linux. If you want to use a recent (haha recent, something after  2014) you
> are forced to use new drivers from linux.
> The fore/advantage on the Linux side are the zillions of corporately paid
> kernel developers.
> They can just focus on a new hw supports, on freebsd side, there are no
> corporately paid drm driver developer. Sadly.
> In linux word their internal KPI (try a Google for a "stable API nonsense"
> words) moves so fastly, that porting of these drivers gets non trivial
> without a dedicated paid team.
 
> If you want to change on this situation, try to learn for you could help or
> send directed donations to freebsd foundation. ;)

Linux and FreeBSD are not the only open-source OSes.

There is also (Net, Open, DragonFly)BSD, Haiku, OpenIndiana and others.

Maybe better would be for the hardware manufacturers to release more general 
specifications that could be adapted to any OS, by the NetBSD developers, Haiku 
developers, etc.  Certainly not to ignore Linux.

Tom

___
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: dmesg submission service -- please submit today

[Thomas Mueller]

I can submit a dmesg even if I'm in NetBSD at the time: mount the FreeBSD 
partition and get the latest /mount-point/var/run/dmesg.boot .

Question is what about those devices that don't work in FreeBSD but work in 
NetBSD, or which work in neither FreeBSD nor NetBSD?  I'm thinking of re, where 
one Ethernet works in NetBSD but not FreeBSD.  Also, wireless rsu and athn.  
Maybe I can also think of others.

I noticed a lot of SCSI cards listed in GENERIC, but most these have gone out 
of production long ago as USB and SATA have taken over.

Tom

___
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: dmesg submission service -- please submit today

[Thomas Mueller]

I just submitted /var/run/dmesg.boot from my current NetBSD and from FreeBSD 
11.1-STABLE.

I was surprised to see some other BSD OSes listed, including 5 dmesg reports 
from Bitrig and 3 from RetroBSD.

I had been tracking three bitrig trees from https://github.com/bitrig : bitrig, 
bitrig-xenocara and bitrig-ports , noticed no activity at all since December 
2016 or January 2017: dead OS.

Tom

___
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"

Graphics open-source-friendliness, AMD Ryzen vs. Intel

[Thomas Mueller]

I may need to buy parts for a new computer because of malfunctions on current 
motherboard and CPU (Intel Sandy Bridge dating to May 2011).

Question is whether I am better off, regarding open-source-friendliness of 
graphics chips for running Xorg, with AMD Ryzen or the newer Intel chipsets.  I 
know to avoid NVIDIA.

I am inclined to run FreeBSD-current and build Xorg from FreeBSD ports.

When I boot into UEFI setup, I see the CPU temperature is or quickly goes to 97 
C and stays there.  

I tried replacing the thermal paste and installing a new case fan to replace 
one that had quit, but CPU temperature still shows and stays at 97 C.

Now I have a replacement Arctic Cooler heatsink and fan on order to replace the 
original Intel heatsink and fan whose connectors were damaged in taking out and 
struggling to get back in. 

Currently, I boot into UEFI Setup, but after a couple minutes, the computer 
powers off and then tries to power back on, then off again a few seconds later, 
until I end the loop by turning off the power supply switch.  I can guess CPU 
overheating.

I could transplant the current hard drive (Seagate NAS 4 TB) to get a quicker 
start software-wise.

Tom

___
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"

Inability to build FreeBSD-current amd64

[Thomas Mueller]

I have failed in three attempts over the past week to build FreeBSD-current 
amd64, error message is about the same each time.

Build host uname -a shows

FreeBSD amelia 11.1-STABLE FreeBSD 11.1-STABLE #4: Sun Jul 30 17:28:39 UTC 2017 
root@amelia2:/usr/obj/BETA1/usr/src11/sys/SANDY11NC  amd64

Is there a known snag?  Would I do better to attempt to build 12-STABLE, or use 
a FreeBSD-current installation from August 2, 2017 as host?

Snag seems related to llwm, which has been a troublemaker.

Build ends with

===> usr.bin/clang/llvm-mc (all)
Warning: Object directory not changed from original 
/usr/src/usr.bin/clang/llvm-mc
c++ -target x86_64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe 
-I/usr/obj/usr/src/amd64.amd64/lib/clang/libllvm -I/usr/src/lib/clang/include 
-I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"\" 
-DLLVM_TARGET_ENABLE_AARCH64 -DLLVM_TARGET_ENABLE_ARM -DLLVM_TARGET_ENABLE_MIPS 
-DLLVM_TARGET_ENABLE_POWERPC -DLLVM_TARGET_ENABLE_SPARC 
-DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser 
-DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter 
-DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler 
-DLLVM_NATIVE_TARGET=LLVMInitializeX86Target 
-DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo 
-DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections 
-fdata-sections -gline-tables-only -fstack-protector-strong
  -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -fno-exceptions 
-fno-rtti -std=c++11 -stdlib=libc++ -Wno-c++11-extensions  -Wl,--gc-sections  
-o llvm-mc.full  Disassembler.o llvm-mc.o 
/usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a  -lz  -lncursesw  
-lpthread
objcopy --only-keep-debug llvm-mc.full llvm-mc.debug
objcopy --strip-debug --add-gnu-debuglink=llvm-mc.debug  llvm-mc.full llvm-mc
===> usr.bin/clang/llvm-mca (all)
Warning: Object directory not changed from original 
/usr/src/usr.bin/clang/llvm-mca
c++  -target x86_64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe 
-I/usr/src/contrib/llvm/tools/llvm-mca 
-I/usr/obj/usr/src/amd64.amd64/lib/clang/libllvm -I/usr/src/lib/clang/include 
-I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"\" 
-DLLVM_TARGET_ENABLE_AARCH64 -DLLVM_TARGET_ENABLE_ARM -DLLVM_TARGET_ENABLE_MIPS 
-DLLVM_TARGET_ENABLE_POWERPC -DLLVM_TARGET_ENABLE_SPARC 
-DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser 
-DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter 
-DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler 
-DLLVM_NATIVE_TARGET=LLVMInitializeX86Target 
-DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo 
-DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections 
-fdata-sections -g
 line-tables-only -MD -MF.depend.Views_DispatchStatistics.o 
-MTViews/DispatchStatistics.o -fstack-protector-strong -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member 
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses 
-Qunused-arguments  -fno-exceptions -fno-rtti -std=c++11 -stdlib=libc++ 
-Wno-c++11-extensions  -c 
/usr/src/contrib/llvm/tools/llvm-mca/Views/DispatchStatistics.cpp -o 
Views/DispatchStatistics.o
error: unable to open output file 'Views/DispatchStatistics.o': 'No such file 
or directory'
1 error generated.
*** Error code 1

Stop.
make[5]: stopped in /usr/src/usr.bin/clang/llvm-mca
*** Error code 1

Stop.
make[4]: stopped in /usr/src/usr.bin/clang
*** Error code 1

Stop.
make[3]: stopped in /usr/src/usr.bin
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src


Tom

___
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: Inability to build FreeBSD-current amd64

[Thomas Mueller]

> Hi Tom,
> Are you using any nonstandard build options/modes?
> Cheers!
> -Enji

I don't think I am using any nonstandard build options/modes.

/etc/src.conf is

WITHOUT_SVNLITE=yes
WITHOUT_PORTSNAP=yes
#WITHOUT_MANCOMPRESS=yes
#WITHOUT_DOCCOMPRESS=yes
WITHOUT_SENDMAIL=yes
WITH_CLANG_EXTRAS=yes
WITH_LLD_IS_LD=yes

/etc/make.conf is

PORTSDIR=/BETA1/usr/ports
PACKAGES=/usr/packages
WRKDIR=${.CURDIR}/work11.amd64
#MANCOMPRESSED=no
#MK_MANCOMPRESS="no"
#WITHOUT_MANCOMPRESS=yes
MAKE_JOBS_UNSAFE=yes
FORCE_PKG_REGISTER=yes
# WITH_PKGNG=yes
OPTIONS_SET.mpop=GNUTLS NLS
WITH_BDB_VER=6
WITH_SSP_PORTS=yes
DEFAULT_VERSIONS+= perl5=5.28
DISABLE_VULNERABILITIES=yes

Build didn't even start when I had WITHOUT_MANCOMPRESS on.

Trouble occurs before there is any attempt to build the kernel.

Tom

___
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: Inability to build FreeBSD-current amd64

[Thomas Mueller]

from tech-lists:

> What do you do before buildworld?

> I'll rm -rf /usr/obj and /var/cache/ccache [1], create them again, then in
> /usr/src I'll do this:

> make -j32 cleanworld && make -j32 cleandir && make -j32 clean

> before make buildworld. it's probably overkill but it'll for sure clean
> away any cruft

> [1] make sure they get deleted without error. I've encountered
> bad_file_descriptor error in ccache dir before and it caused all kinds
> of errors when building, which looked like build errors but obv. were
> not.

I did rm -R /usr/obj/* , so everything there was clean as far as I could see.

I had no /var/cache/cache .

I could still try to build current from the old current from August 2, 2017, or 
STABLE-12 from the old 11.1-STABLE from July 30, 2017.

Otherwise I still have stuff to do with NetBSD and Linux toolchains (OpenWRT, 
buildroot, crosstool-ng and ptxdist from Pengutronix).

Is there anything comparable to https://releng.netbsd.org/cgi-bin/builds.cgi , 
but for FreeBSD?

If I see 0 passed, 67 failed for NetBSD-HEAD, I figure I should wait for a 
better time.  But what about FreeBSD?

Tom

___
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: Inability to build FreeBSD-current amd64

[Thomas Mueller]

What do most FreeBSD users who rebuild system from source do regarding 
WITH_CLANG_EXTRAS in /etc/src.conf ?

I have WITH_CLANG_EXTRAS=yes in /etc/src.conf and wonder if that could be 
screwing my build.

Build seems to stumble on the llvm stuff, and llvm has really bloated in recent 
times.

But then if I remove WITH_CLANG_EXTRAS, would I face great trouble with llvm in 
the ports, where llvm is so critical to the bigger things including Xorg?

Would removing WITH_CLANG_EXTRAS also reduce the build time which has been 
around 6:45 (hours:minutes) just to fail?


Tom

___
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: Inability to build FreeBSD-current amd64

[Thomas Mueller]

> In general, WITH_CLANG_EXTRAS controls the building of extra tools such
> as a disassembler, and tools for working on clang itself such as bug
> reporting tools.  I don't have a really detailed answer because I've
> never enabled the option.  I've always perceived it as being something
> most people don't need.  WITHOUT_CLANG_EXTRAS may cut some time from
> your build, but it probably won't cut it in half or anything.

>- Ian  

I am not concerned about the time to build CLANG_EXTRAS so much as the 
possibility of CLANG_EXTRAS stopping the build.

WITH_CLANG_EXTRAS worked back in July-August 2017, but it may have ballooned 
since then beyond FreeBSD buildability.


Tom

___
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: Inability to build FreeBSD-current amd64

[Thomas Mueller]

from Niclas Zeising:

> I run a build WITH_CLANG_EXTRAS, and that worked, on current, last weekend, if
> that's what you're asking about.
 
> This won't take away the need for llvm ports in certain ports builds, however,
> such as firefox and mesa.

So now I wonder why I failed four times straight building current.  One 
definition of insanity is doing the same thing repeatedly and expecting a 
different result.

Maybe the build host, 11.1-STABLE from July 30, 2017, was too old?  I wouldn't 
have thought it was too old.

I could also try an old current host from August 2, 2017, or try to build 
12-STABLE from my 11.1-STABLE host.  Would I do better to build amd64 or i386 
from amd64 host?  I presently have no FreeBSD i386 installation, only amd64.

Tom

___
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: Inability to build FreeBSD-current amd64

[Thomas Mueller]

from Niclas Zeising:


So now I wonder why I failed four times straight building current.  One 
definition of insanity is doing the same thing repeatedly and expecting a 
different result.

Maybe the build host, 11.1-STABLE from July 30, 2017, was too old?  I wouldn't 
have thought it was too old.

I could also try an old current host from August 2, 2017, or try to build 
12-STABLE from my 11.1-STABLE host.  Would I do better to build amd64 or i386 
from amd64 host?  I presently have no FreeBSD i386 installation, only amd64.

I can't quote anything from your message because of problems with mutt on 
xterm; this is NetBSD 8.99.39 amd64 with icewm.

But here is the relevant error message, I believe:

===> usr.bin/clang/llvm-mca (all)
Warning: Object directory not changed from original 
/usr/src/usr.bin/clang/llvm-mca
c++  -target x86_64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe 
-I/usr/src/contrib/llvm/tools/llvm-mca 
-I/usr/obj/usr/src/amd64.amd64/lib/clang/libllvm -I/usr/src/lib/clang/include 
-I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"\" 
-DLLVM_TARGET_ENABLE_AARCH64 -DLLVM_TARGET_ENABLE_ARM -DLLVM_TARGET_ENABLE_MIPS 
-DLLVM_TARGET_ENABLE_POWERPC -DLLVM_TARGET_ENABLE_SPARC 
-DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser 
-DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter 
-DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler 
-DLLVM_NATIVE_TARGET=LLVMInitializeX86Target 
-DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo 
-DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections 
-fdata-sections -g
 line-tables-only -MD -MF.depend.Views_DispatchStatistics.o 
-MTViews/DispatchStatistics.o -fstack-protector-strong -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member 
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses 
-Qunused-arguments  -fno-exceptions -fno-rtti -std=c++11 -stdlib=libc++ 
-Wno-c++11-extensions  -c 
/usr/src/contrib/llvm/tools/llvm-mca/Views/DispatchStatistics.cpp -o 
Views/DispatchStatistics.o
error: unable to open output file 'Views/DispatchStatistics.o': 'No such file 
or directory'
1 error generated.
*** Error code 1

I switched to the other computer with an installation of FreeBSD-current from 
August 2, 2017, and managed to succeed.

I had the same mergemaster problem cited in another thread, copied 
etc/master.passwd and etc/group from the 12-STABLE src tree.

That enabled me to successfully get through the update, but the result was a 
strong negative selling point for FreeBSD: no internet access.

Ethernet (re) would not connect, Hiro H50191 USB wi-fi adapter gave "Device not 
configured" as rsu0, and Edimax USB wi-fi adapter dropped the connection as I 
was trying the dhclient or ifconfig step.  Only other thing I could try is 
urndis with my mobile phone as access point.  I really ought to try that on 
FreeBSD and/or NetBSD.

I thought maybe the lack of etc/master.passwd and etc/group in src tree was a 
fault of subversion on NetBSD from pkgsrc as opposed to subversion on FreeBSD 
from ports, but browsing svnweb.freebsd.org/base/head revealed that 
master.passwd and group had indeed been moved, and mergemaster had not been 
appropriately updated.

Tom

___
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: UEFI firmware and getting FreeBSD recognized by default: who to talk to?

[Thomas Mueller]

from Karl Denninger:

> On 6/22/2019 14:05, Rebecca Cran wrote:
> > On 2019-06-22 12:59, Karl Denninger wrote:
> >> I use Refind for this sort of thing and it has (thus far!) survived
> >> upgrades.  The only "gotcha" is that I had a Windows 10 "Feature"
> >> upgrade that reset the default boot in the firmware to Windows; it
> >> didn't damage anything but did require that I go reset the UEFI default
> >> to boot the Refind EFI loader instead of the Windows one.

> > I do like that rEFInd knows about FreeBSD, and it's one of the "UEFI OS"
> > entries that remains. But I'd prefer it if a "FreeBSD" entry was
> > automatically created!

> It is.  

> All I had to do was put the EFI loader in a directory under the UEFI
> partition and Refind found it.  I didn't have to specifically tell it
> that it was there.

> The explicit "set" command (which I issued under Windows) is to tell the
> firmware what the default is; you do it once on original installation of
> Refind.  The Windows 10 feature update set it back to default to
> Windows, which was quite annoying but not really a big deal.  One  
> command, once, from the Windows command line (same as the one to set it
> in the first place) was all that was required.

> The danger with tampering with where Windows 10 puts its EFI loader
> (e.g. copying Refind there after moving it somewhere else) is that
> Bitlocker may throw up on you if you do that.  In fact you do have to do
> things in the right order or Bitlocker's default configuration (at least
> on a TPM equipped machine) will have a hissy fit -- you cannot change
> anything in the EFI partition after initializing Bitlocker, including
> the Refind configuration file (this most-specifically applies to the
> "wait for boot time"; I find the default obnoxiously long) so you have
> to make that edit and put the other stuff in the UEFI partition (e.g.
> FreeBSD's EFI loader and Refind) BEFORE turning Bitlocker on.

> I've been running this way since 12.x showed up since 12.x can boot a
> geli-encrypted system directly on my laptop.  Works nicely.

This is scary (Bitlocker), sent me to Wikipedia to look up Bitlocker.

Can you turn Bitlocker off after turning it on and get your system back?

Now I am even more scared to ever get a computer with MS-Windows!

One think on my mind is if I need a new motherboard, would it have the 
undesired Secure Boot?  I guess I'd have to ask the seller and look on the 
motherboard manufacturer's website (MSI, ASRock, Asus, Gigabyte, or other).

I have no Secure Boot now.

I am trying to set up UEFI to boot my FreeBSD and NetBSD installations, and 
later, Linux.

Tom

___
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: UEFI firmware and getting FreeBSD recognized by default: who to talk to?

[Thomas Mueller]

from Karl Denninger and my previous post:

> > This is scary (Bitlocker), sent me to Wikipedia to look up Bitlocker.

> > Can you turn Bitlocker off after turning it on and get your system back?
> You SHOULD (better have!) kept the recovery key.  If you have it, you
> can boot with it.  Then turn it off and back on, and it will generate a
> new key.
> > Now I am even more scared to ever get a computer with MS-Windows!
   
> > One think on my mind is if I need a new motherboard, would it have the 
> > undesired Secure Boot?  I guess I'd have to ask the seller and look on the 
> > motherboard manufacturer's website (MSI, ASRock, Asus, Gigabyte, or other).
   
> > I have no Secure Boot now.
> Probably.  But you can shut THAT off (and should) provided you wish to
> dual boot.  The exception is ARM-based systems, many of which are
> secure-boot ONLY.  For Intel machines I've never run into one that can't
> have it turned off (and I'd return it immediately if I found one.)
> > I am trying to set up UEFI to boot my FreeBSD and NetBSD installations, and 
> > later, Linux.

> Tom

> Easy.  Refind should do that and allow selection from a menu.

Can one recover after losing the recovery key?  I think I would want to avoid 
Bitlocker from the outset (malware!).

I was thinking about AMD Ryzen if I need to replace motherboard.  I would need 
a new CPU with any new motherboard, Intel or AMD-compatible, would also need 
new RAM (DDR4, I now have DDR3), and probaby a new case.

But I would keep and transfer any hard drives that are still good.

Can rEFInd find and boot FreeBSD, NetBSD, Haiku, etc?

I don't see any refind, however partially capitalized, in FreeBSD base system 
or ports, or NetBSD base system or pkgsrc.  I find efibootmgr now in FreeBSD, 
but not NetBSD, base system.

I would want to label boot options with the partition label (like WD2G18, 
WD2G19, WD2G20, WD2G21, and others) so I can see on the boot menu.

I also notice it is difficult to choose the root partition when booting UEFI.  
I could create a zero-byte or very small file in root directory with the 
partition label name, like /WD2G18 on partition WD2G18 just to show up with ls.

Tom

___
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: UEFI firmware and getting FreeBSD recognized by default: who to talk to?

[Thomas Mueller]

from Niclas Zeising and my previous post:

> > On 6/22/2019 20:16, Thomas Mueller wrote:
> > > I am trying to set up UEFI to boot my FreeBSD and NetBSD installations, 
> > > and later, Linux.

> > Easy.  Refind should do that and allow selection from a menu.

> I wrote this as an instruction on how to get FreeBSD and Windows dual-booting
> using rEFInd.  You can probably adapt that to get going with other OSes as
well.   
> https://gist.github.com/zeising/5d2402d92b4cf421c7402d663b2d9e41

> I hope it is of some value.

I can use efibootmgr from FreeBSD 12-STABLE or HEAD, or possibly bcfg in the 
built-in UEFI shell.

I notice the close relation between what efibootmgr shows and what I see on the 
boot menu.

UEFI shell is not user-friendly, but I am slowly learning new things.

Severe thunderstorm is now threatening this area, I hear the winds increasing.

Tom

___
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: sweeping change over all NIC drivers

[Thomas Mueller]

from Gleb Smirnoff:

> I'd like to commit a sweeping change over all NIC drivers,
> details can be found here:

> https://reviews.freebsd.org/D21943

> The stack changes froim the review are already committed,
> only a bunch of drivers are left. You can browse them as
> individual commits here:

> https://github.com/glebius/FreeBSD/commits/if_foreach_maddr

> Although changes are close to trivial, there is always a place
> for a mistake. So reviewing is appreciated. Testing is even
> more appreciated. Here is list of drivers affected (65 total):

(re and rtwn included but not rsu)

I built FreeBSD 12-stable and current five months ago, and they have been 
sitting rather idle because of no internet access with current, and possible 
but very awkward with 12-stable.

Only good thing I got was efibootmgr.

I assume these changes are only for FreeBSD-current now and have to be tested 
and proven before committing to releng 12.

But I am working on other things now on the computer and will not be able to 
get to FreeBSD-current immediately.

Tom

___
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: DRM-current-kmod is still a problem at r353339

[Thomas Mueller]

from Neel Chauhan:

> For me, the following code is still necessary for me (HP Spectre x360 
> 2018), which is the remaining parts of the patches not committed if you 
> are using a recent kernel. I don't know about you all ThinkPad users, it 
> should still apply as it's Intel in general not just HP or Lenovo. 
> Without these patches, I get a kernel panic.
 
> Keep in mind that the patch may render as spaces, but it should be tabs.

What happens if the patch is applied with spaces as opposed to tabs?

I believe, in C, there is no difference as far as compiling is concerned.

Or is it just a standard for formatting?

Tom

___
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"

make installworld for i386 fails on Kyuafile

[Thomas Mueller]

I was successful on make buildworld and kernel, but make installworld failed on 
a missing file somewhere:

/usr/share/man/man3/pmclog_read.3.gz -> /usr/share/man/man3/pmclog.3.gz
===> lib/libproc (install)
install -C -o root -g wheel -m 444   libproc.a /usr/lib
install -C -o root -g wheel -m 444   libproc_p.a /usr/lib
install -s -o root -g wheel -m 444 libproc.so.2 /usr/lib
install -l s libproc.so.2 /usr/lib/libproc.so
install -C -o root -g wheel -m 444  /BETA1/usr/src/lib/libproc/libproc.h 
/usr/include
===> lib/libproc/tests (install)
install -o root  -g wheel -m 444  Kyuafile.auto  /usr/tests/lib/libproc/Kyuafile
install: /usr/tests/lib/libproc/Kyuafile: No such file or directory
*** Error code 71

Stop.
bmake[6]: stopped in /BETA1/usr/src/lib/libproc/tests
*** Error code 1


svn revision is 271942.

I never had this particular error happen before, even though I've had 
successful builds and installs subsequent to 20140110 (referring to UPDATING; I 
never used NO_CLEAN).

What could have happened this time?  Shouuld I follow the directions in 
UPDATING 20140110 and

find /BETA1/usr/obj.i386 -name Kyuafile | xargs rm -f ? 

or svn update and rebuild, but this time running rm -R /BETA1/usr/obj.i386/* 
before rebuilding?

Or is there a bug?

Tom

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

Re: make installworld for i386 fails on Kyuafile

[Thomas Mueller]

On Mon, Sep 22, 2014 at 11:15 AM, Thomas Mueller
 wrote:
> I was successful on make buildworld and kernel, but make installworld failed 
> on a missing file somewhere:
>
> /usr/share/man/man3/pmclog_read.3.gz -> /usr/share/man/man3/pmclog.3.gz
> ===> lib/libproc (install)
> install -C -o root -g wheel -m 444   libproc.a /usr/lib
> install -C -o root -g wheel -m 444   libproc_p.a /usr/lib
> install -s -o root -g wheel -m 444 libproc.so.2 /usr/lib
> install -l s libproc.so.2 /usr/lib/libproc.so
> install -C -o root -g wheel -m 444  /BETA1/usr/src/lib/libproc/libproc.h 
> /usr/include
> ===> lib/libproc/tests (install)
> install -o root  -g wheel -m 444  Kyuafile.auto  
> /usr/tests/lib/libproc/Kyuafile
> install: /usr/tests/lib/libproc/Kyuafile: No such file or directory

Julio Merino responded:

> Fixed in r271950. Problem introduced in r271937 which seems to have
> missed part of the change sent out for review in D710.

Thanks for the response!

Now I know it wasn't some fault at my end.

I updated again with svn from NetBSD, and was successful on (FreeBSD) i386.  
Next is to build/update for amd64.


Tom

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

Re: make installworld for i386 fails on Kyuafile

[Thomas Mueller]

> On Thu, Feb 26, 2015 at 10:08:40PM -0500, Michael Butler wrote:
> M> The recent changes which served to hide "struct ifaddr" have broken
> M> net-snmp:

> I know and slowly working on that:

> https://lists.freebsd.org/pipermail/svn-src-head/2015-February/068674.html

> Totus tuus, Glebius.

How will users know when this bug is fixed so that net-snmp will build on 
current?

I was snagged on this as a dependency in trying to build print/hplip.

Tom

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

Re: [CFT] Call for testing pkg 1.5.0

[Thomas Mueller]

Excerpt from Baptiste Daroussin:

- Initial support for OS X
- Initial support for NetBSD/EdjeBSD

How would pkg-1.5.0 integrate with NetBSD pkgsrc?

I didn't think there were any plans to port FreeBSD ports to NetBSD.  Or is 
such a plan in the works?

EdjeBSD should be EdgeBSD.  A little spelling error can be critical when trying 
to find something on the Internet.

Web site is edgebsd.org (I just went there).

Tom

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

Re: [Testers needed!] WiFi drivers changes

[Thomas Mueller]

>   As part of the "opaque ifnet project" [1], we are doing some code shake
> with all IEEE802.11 (read WiFi) drivers. The drivers, that provide a parent
> interface for the wlan(4) interface.

>   The core idea is that parent device loses its ifnet(9) structure. The
> code is already complete for the stack, but only 2 drivers are converted
> to new KPI: iwn(4) and bwi(4). We got 22 more drivers left. The changes
> are quite mechanical, but nevertheless testing is required before committing.

> So, if you run FreeBSD head and wlan(4), please sign up here as tester:

> https://wiki.freebsd.org/projects/ifnet/net80211

> As soon as I see testers there, I will start converting more drivers.

> For those who want to review the patch, or even help with converting,
> you are welcome here:

> https://reviews.freebsd.org/D2655

> Waiting for your feedback :)

> [1] https://wiki.freebsd.org/projects/ifnet

> Totus tuus, Glebius.

There are two I could test: athn and rsu, but neither fits iwn or bwi, and athn 
is not in FreeBSD src at all.

athn is in NetBSD-current and 7.0_BETA, sometimes is able to connect, but 
usually I get
athn0: could not load firmware (35)

Always fails with OpenBSD on USB stick (liveusb-openbsd.sourceforge.net), also 
fails with kernels from OpenBSD 5.5, 5.6 and 5.7 as does Ethernet (re); no 
success with rsu either in OpenBSD.

I see on the website that sys/dev/re was tested.

I notice, since the most recent change (2015-04-09) in sys/dev/re, that this 
Ethernet now works for me on new computer where it didn't before:
MSI Z77 MPOWER motherboard.

Also, the latest fix (2015-01-05) to sys/dev/usb/wlan/if_rsu.c seems to make 
Hiro H50191 USB WLAN adapter work again.

This success is on current amd64 and i386; no such success on FreeBSD 
10.1-STABLE.

But my installed ports date to last July 26; I installed lang/gcc-aux last 
August 17; started updating last May 12 but hit a snag on the png update 
reverse dependencies, now am starting over on a new GPT partition while 
preserving the old (current amd64).

Tom

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

Re: CFT: ndis(4) testers needed!

[Thomas Mueller]

> I need to make couple of non-functional but rather large changes
> to the if_ndis driver and will appreciate if anyone signs up to
> test my changes. Please contact me if you can provide help.

> Totus tuus, Glebius.

I have two possible candidates for testing:

Hiro H50191 USB wi-fi adapter, but this seems to work as rsu in FreeBSD-current 
but not 10-STABLE.

Atheros AR9271 on-motherboard quasi-USB wi-fi, sometimes works in 
NetBSD-current but most of the time fails to load firmware.

I have .inf and .sys files for Hiro but not for Atheros AR9271 ("install" under 
wine and get .inf and .sys that way?).

Are these suitable for testing ndis?

My Realtek re(4) Ethernet now works with recent updates in current, I think 
also 10-STABLE but have to check that again.

I only sporadically do anything with FreeBSD 10-STABLE, nothing with FreeBSD < 
10.0.

Tom

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

Re: CFT: ndis(4) testers needed!

[Thomas Mueller]

> I ended with doing the aforementioned 2 changes as one.

> The diff is living here:

> https://reviews.freebsd.org/D2655

> It spans the net80211 layer and converts (almost) all 802.11 drivers
> to new KPI. Now it also converts if_ndis, and this is the change I
> am asking you to test.

> Unlike all other drivers, converting if_ndis wasn't trivial. There are
> likely bugs introduced, so it may happen that we will need several
> rounds of testing.

> Totus tuus, Glebius.

What do I need to download?  There is a lot of stuff on the page you cite, and 
I see a link to the right, Download Raw Diff.  Is that what I'm supposed to 
download?

What do you want me to test it on?  

I have Hiro H50191 USB WLAN adapter, including .inf and .sys files.

I also have, on MSI MPOWER motherboard, Atheros AR9271 quasi-USB WLAN, and 
Realtek 8111E Ethernet, with MS-Windows drivers but no .INF and .SYS files on 
DVD that came with the motherboard.

Is there a way to convert MS-Windows drivers that come with no .inf and .sys 
files to ndis-compatible format?  Or just test on the Hiro H50191?

Also, after applying the patch to the source tree, what if anything do I have 
to do to not be messed up for subsequent svn updates to source tree?

Tom

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

Re: CFT: ndis(4) testers needed!

[Thomas Mueller]

> I ended with doing the aforementioned 2 changes as one.

> The diff is living here:

> https://reviews.freebsd.org/D2655

> It spans the net80211 layer and converts (almost) all 802.11 drivers
> to new KPI. Now it also converts if_ndis, and this is the change I
> am asking you to test.

> Unlike all other drivers, converting if_ndis wasn't trivial. There are
> likely bugs introduced, so it may happen that we will need several
> rounds of testing.

> Totus tuus, Glebius.

What do I need to download?  There is a lot of stuff on the page you cite, and 
I see a link to the right, Download Raw Diff.  Is that what I'm supposed to 
download?

What do you want me to test it on?  

I have Hiro H50191 USB WLAN adapter, including .inf and .sys files.

I also have, on MSI MPOWER motherboard, Atheros AR9271 quasi-USB WLAN, and 
Realtek 8111E Ethernet, with MS-Windows drivers but no .INF and .SYS files on 
DVD that came with the motherboard.

Is there a way to convert MS-Windows drivers that come with no .inf and .sys 
files to ndis-compatible format?  Or just test on the Hiro H50191?

Also, after applying the patch to the source tree, what if anything do I have 
to do to not be messed up for subsequent svn updates to source tree?

Tom

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

Re: CFT: ndis(4) testers needed!

[Thomas Mueller]

> I ended with doing the aforementioned 2 changes as one.

> The diff is living here:

> https://reviews.freebsd.org/D2655

> It spans the net80211 layer and converts (almost) all 802.11 drivers
> to new KPI. Now it also converts if_ndis, and this is the change I
> am asking you to test.

> Unlike all other drivers, converting if_ndis wasn't trivial. There are
> likely bugs introduced, so it may happen that we will need several
> rounds of testing.

> Totus tuus, Glebius.

I have Hiro H50191 USB WLAN adapter, including .inf and .sys files.

I also have, on MSI MPOWER motherboard, Atheros AR9271 quasi-USB WLAN, and 
Realtek 8111E Ethernet, with MS-Windows drivers but no .INF and .SYS files on 
DVD that came with the motherboard.

Also, after applying the patch to the source tree, what if anything do I have 
to do to not be messed up for subsequent svn updates to source tree?

I didn't mean to send the same old message a second time (sorry); I was at a 
difficult-to-read interface, this is what I meant to send:

UPDATE, typing from FreeBSD vt and X crashing system:

I ran svn up on the source tree, applied the patch, make buildworld succeeded, 
but building the kernels all failed, with and without ndis, so I dare not make 
installworld, which would put userland out of sync with kernels and likely give 
me nonworking system.

Now, I try to startx as nonroot, then there is no more signal to monitor, but 
keyboard is recognized, at least CapsLock and ScrollLock light and unlight the 
LEDs.  Returning Ctrl-Alt-F1 blindly and typing "shutdown -r now" does nothing, 
I must press Reset button.

Now I want to undo the patch, unless there is something better you can suggest, 
like maybe a fix?

I want to get a working system again.

svn revert --depth=infinity ?

I don't really know what happened that X won't start any more, it's on a 
Western Digital Green Drive bought at the end of May 2013, maybe it's nearing 
end of life?

Or maybe something with the buildworld and buildkernel had an adverse effect on 
the file system?

I think I'm missing something in the References headers but was doing the best 
I can without graphic interface.  Text DRMKMS screen I get when booting 
NetBSD-current looks the same as what I get in FreeBSD-current after returning 
from X, and much better-looking than the text vt screen I get upon booting 
FreeBSD before starting X.

Tom

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

Re: CFT: ndis(4) testers needed!

[Thomas Mueller]

You sent a patch, net80211.diff.bz2 .

Before I extract and apply the patch, how does that differ from D2655.diff ?  
Is it an updated version, does it include ndis or only FreeBSD-native drivers?

Do you want me to test Hiro H50191 with native rsu, or ndis, or both separately?

I guess I need to do, from src tree base,

svn revert
svn up .
patch < /path/to/net80211.diff

Does that look correct?

Packages/ports have fallen behind, due to problems with rsu driver and not 
being able to use Ethernet in FreeBSD (now OK), still on png-1.5.18; 
xorg-server is still on 1.12.4_7,1 .

An attempt to upgrade using portmaster in accordance with UPDATING 20141225 
instructions hit a snag, could possibly have rendered xorg-server nonrunnable.


Tom

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

Re: CFT: ndis(4) testers needed!

[Thomas Mueller]

I did the update a little before your last message.

svn revert

by itself doesn't work, I get an error message, then run

svn help revert

and that gets me on the right track.

I did the update and patch from NetBSD, which I believe works the same as it 
would from FreeBSD, subsequently booted into FreeBSD and cd /usr/src

make buildworld worked again with no error, but make kernel failed.

Error occurs somewhere in iwi or iwm, and that prevents the kernel from 
building, so I don't get to test ndis, but it may point to what needs fixing.

Would it be safe to comment out iwi and other Intel wireless nics in kernel 
config and then try again to make buildkernel without rerunning buildworld?

Or should I wait for next update?  But you probably want to know where the 
snags are even if they don't relate to my hardware.

End of the buildkernel.log:

===> iwi (all)
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include 
/usr/obj/usr/src/sys/SANDY11NC/opt_global.h -I. -I/usr/src/sys -fno-common -g 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-I/usr/obj/usr/src/sys/SANDY11NC  -mcmodel=kernel -mno-red-zone -mno-mmx 
-mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__  
-Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign  -mno-aes -mno-avx  -std=iso9899:1999 -c 
/usr/src/sys/modules/iwi/../../dev/iwi/if_iwi.c -o if_iwi.o
ctfconvert -L VERSION -g if_iwi.o
ld -d -warn-common -r -d -o if_iwi.ko.debug if_iwi.o
ctfmerge -L VERSION -g -o if_iwi.ko.debug if_iwi.o
:> export_syms
awk -f /usr/src/sys/conf/kmod_syms.awk if_iwi.ko.debug  export_syms | xargs -J% 
objcopy % if_iwi.ko.debug
objcopy --only-keep-debug if_iwi.ko.debug if_iwi.ko.symbols
objcopy --strip-debug --add-gnu-debuglink=if_iwi.ko.symbols if_iwi.ko.debug 
if_iwi.ko
===> iwifw (all)
===> iwifw/iwi_bss (all)
uudecode -p 
/usr/src/sys/modules/iwifw/iwi_bss/../../../contrib/dev/iwi/ipw2200-bss.fw.uu > 
iwi_bss
iwi_bss iwi_bss
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include 
/usr/obj/usr/src/sys/SANDY11NC/opt_global.h -I. -I/usr/src/sys -fno-common -g 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-I/usr/obj/usr/src/sys/SANDY11NC  -mcmodel=kernel -mno-red-zone -mno-mmx 
-mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__  
-Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign  -mno-aes -mno-avx  -std=iso9899:1999 -c iwi_bss.c -o 
iwi_bss.o
ctfconvert -L VERSION -g iwi_bss.o
ld -d -warn-common -r -d -o iwi_bss.ko.debug iwi_bss.fwo iwi_bss.o
ctfmerge -L VERSION -g -o iwi_bss.ko.debug iwi_bss.fwo iwi_bss.o
:> export_syms
awk -f /usr/src/sys/conf/kmod_syms.awk iwi_bss.ko.debug  export_syms | xargs 
-J% objcopy % iwi_bss.ko.debug
objcopy --only-keep-debug iwi_bss.ko.debug iwi_bss.ko.symbols
objcopy --strip-debug --add-gnu-debuglink=iwi_bss.ko.symbols iwi_bss.ko.debug 
iwi_bss.ko
===> iwifw/iwi_ibss (all)
uudecode -p 
/usr/src/sys/modules/iwifw/iwi_ibss/../../../contrib/dev/iwi/ipw2200-ibss.fw.uu 
> iwi_ibss
iwi_ibss iwi_ibss
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include 
/usr/obj/usr/src/sys/SANDY11NC/opt_global.h -I. -I/usr/src/sys -fno-common -g 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-I/usr/obj/usr/src/sys/SANDY11NC  -mcmodel=kernel -mno-red-zone -mno-mmx 
-mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__  
-Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign  -mno-aes -mno-avx  -std=iso9899:1999 -c iwi_ibss.c -o 
iwi_ibss.o
ctfconvert -L VERSION -g iwi_ibss.o
ld -d -warn-common -r -d -o iwi_ibss.ko.debug iwi_ibss.fwo iwi_ibss.o
ctfmerge -L VERSION -g -o iwi_ibss.ko.debug iwi_ibss.fwo iwi_ibss.o
:> export_syms
awk -f /usr/src/sys/conf/kmod_syms.awk iwi_ibss.ko

Re: CFT: ndis(4) testers needed!

[Thomas Mueller]

> I've build a small nanobsd image (for i386 arch) that include this patch:
> http://dev.bsdrp.net/FreeBSD/GLEBWIFI-0.2-full-i386-vga.img.xz

> You can install it on a small (128MB USB flash) for testing it without
> re-installing your system.
> Installation instruction for copying this image into a USB flash disk
> (/dev/da1 in this example):

> fetch http://dev.bsdrp.net/FreeBSD/GLEBWIFI-0.2-full-i386-vga.img.xz
> -o - | xzcat | dd of=/dev/da1 bs=128k
> Then boot on this USB flash disk.

> Regards,

> Olivier

Now there's another update from Gleb Smirnoff to try, so I think I'll try that, 
start "make buildworld" at bedtime.

I ran

svn revert -R /BETA1/usr/src

and intend to update and patch within a few hours.

I don't think anybody makes 128 MB USB sticks any more, smallest in current 
production may be 4 GB or 8 GB.  For the price, no use buying anything under 8 
GB or perhaps 16 GB.

I have two old IDE hard drives, 341 MB and 1271 MB, that I access with Sabrent 
USB 2.0 enclosure.

This enclosure also has eSATA interface that works with SATA but not IDE hard 
drives.

1271 MB drive worked when I last tried some months ago, but 341 MB drive just 
gives gibberish.  I don't know whether the 55 sectors per track is incompatible 
with USB adapter, or if the drive has gone bad.

Tom

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

Re: CFT: ndis(4) testers needed!

[Thomas Mueller]

UPDATE: I was successful with buildworld and kernel with the patch, both the 
custom kernel with ndis and the GENERIB kernel without ndis.

GENERIB differs from GENERIC by eliminating some old devices like SCSI cards 
and ISA EThernet cards, but I add some wi-fi drivers like urtw, urtwn and rsu.

Using the main custom kernel, I was able to build an ndis module from the 
WinX64 drivers net8192su.inf, rtl8192su.sys and net8192su.cat, but when I tried 
to ifconfig, the device ndis, ndis0, rtl8192su, rtl8192su0, were not recognized.

Being in FreeBSD-current amd64, I used 64-bit WinXP (WinX64); there were also 
drivers for Win 32-bit, for 2000, XP, Vista and 7, all offered in both 32-bit 
and 64-bit, except Win 2000, 32-bit only.

Hiro USB wireless adapter is H50191, their website is www.hiroinc.com .

I wonder if I could have missed a firmware file but couldn't find it in the 
directory structure (maybe net8192su.cat ?).

Thinking I might have used the wrong syntax with ifconfig, I tried again with 
rsu0 instead of ndis0 or other failed attempts, and was successful connecting 
to Internet.

Where to go from here?  I don't want to svn up the src tree until I receive 
further instructions, should I revert or just update on top of what's already 
there?

But with the FreeBSD-native rsu, I did update ports and doc trees using svn.

Files I got with ndisgen, and the original driver files, are, copying-pasting 
from vt console.  If double spaced, that's because of a vt bug:

root@amelia2:/RTL8188_8191_8192_SU_WindowsDriver_1086.48.0809.2011.F0049_12.P040

6_UI_1.00.0187.L/88_91_92_SU_Driver/WinX64 # ls -l  

total 2696  

-rw-r--r--  1 root  wheel1 Aug 13 01:54 bus_if.h

-rw-r--r--  1 root  wheel1 Aug 13 01:54 device_if.h 

-rwxr-xr-x  1 root  wheel13762 Aug 19  2011 net8192su.cat   

-rwxr-xr-x  1 root  wheel15622 Aug 13 01:50 net8192su.cat.ko

-rwxr-xr-x  1 root  wheel29731 Aug 13 01:48 net8192su.inf   

-rwxr-xr-x  1 root  wheel   776808 Aug 11  2011 rtl8192su.sys   

-rw-r--r--  1 root  wheel  1818552 Aug 13 01:54 rtl8192su_sys.ko   


Tom

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

Re: CFT: ndis(4) testers needed!

[Thomas Mueller]

> T> Thinking I might have used the wrong syntax with ifconfig, I tried again 
> with rsu0 instead of ndis0 or other failed attempts, and was successful 
> connecting to Internet.

> AFAIU, if you got rsu(4) driver in your kernel it will attach to the hardware,
> and the ndis(4) driver won't be able to.

> Have you tried to used ndis(4) before on an unpatched vanilla FreeBSD?

> Totus tuus, Glebius.

I have tried to use ndis before, but never successfully.  I used custom kernel, 
but src tree was not patched.

Do I have to build a separate kernel without rsu to test ndis, or is disabling 
at loader good enough?

set hint.rsu.0.disabled="1"

Then would the device name be ndis0, or rtl8192su0, or without the 0, or 
something else?

Would I have to run ndisgen again?  Or did the presence of rsu in kernel have 
no effect on building the module?

I might also want to test on FreeBSD-current i386.

Which MS-Windows version should I prefer between 2000, XP, Vista and 7?  My 
fallible inclination is toward XP.

Tom

___
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: CFT: ndis(4) testers needed!

[Thomas Mueller]

> If you haven't ever successfully run ndis before on this hardware, then 
> testing
> the patch is quite useless :( Since we don't have a working reference point.

> Sorry for waisting your time.

> Totus tuus, Glebius.

I remember trying ndis from a USB-stick installation of FreeBSD 9.2-STABLE, but 
it failed.

I could try again, since I already have the setup, with
set hint.rsu.0.disabled="1"  from loader prompt.

Still a small chance, but I have the setup.  Maybe there is a needed firmware 
file in non-obvious place.

Then should I svn revert the src tree and update normally, without patches?

When possible, it would be good to have more documentation of how to set up 
with ndis, and what to do when the Windows drivers don't include .inf and .sys 
files.

Tom

___
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: CFT: ndis(4) testers needed!

[Thomas Mueller]

> If you haven't ever successfully run ndis before on this hardware, then 
> testing
> the patch is quite useless :( Since we don't have a working reference point.

> Sorry for waisting your time.

> Totus tuus, Glebius.

I remember trying ndis from a USB-stick installation of FreeBSD 9.2-STABLE, but 
it failed.

I could try again, since I already have the setup, with
set hint.rsu.0.disabled="1"  from loader prompt.

UPDATE: I tried, rsu did not show on "ifconfig", but it seems not viable.  Last 
15 lines of var/log/messages are:

Aug 14 06:34:34 amelia2 root: /etc/rc: INFO: RSA1 host key exists.
Aug 14 06:34:34 amelia2 root: /etc/rc: INFO: RSA host key exists.
Aug 14 06:34:34 amelia2 root: /etc/rc: INFO: DSA host key exists.
Aug 14 06:34:34 amelia2 root: /etc/rc: INFO: ECDSA host key exists.
Aug 14 06:34:34 amelia2 root: /etc/rc: INFO: ED25519 host key exists.
Aug 14 06:34:38 amelia2 login: ROOT LOGIN (root) ON ttyv0
Aug 14 06:36:19 amelia2 kernel: ndis0:  on usbus1
Aug 14 06:36:19 amelia2 kernel: ndis0: NDIS API version: 5.1
Aug 14 06:36:19 amelia2 kernel: ndis0: ioctl 0xf800 isn't supported
Aug 14 06:36:19 amelia2 last message repeated 20 times
Aug 14 06:36:19 amelia2 kernel: ndis0: init handler failed
Aug 14 06:36:19 amelia2 kernel: device_attach: ndis0 attach returned 6
Aug 14 06:36:19 amelia2 root: Unknown USB device: vendor 0x0cf3 product 0x3000 
bus uhub4
Aug 14 06:36:19 amelia2 root: Unknown USB device: vendor 0x0cf3 product 0x9271 
bus uhub4
Aug 14 06:37:26 amelia2 login: ROOT LOGIN (root) ON ttyv1

I feel like I was justified in this last try, having gone so far already.

I browsed

en.wikipedia.org/wiki/NDISwrapper

and saw various reasons why ndis would likely fail.  Maybe it's really not 
workable for Hiro H50191.

Now should I svn revert the src tree and update normally, without patches?

When possible, for the sake of others if not myself, it would be good to have 
more documentation of how to set up with ndis, and what to do when the Windows 
drivers don't include .inf and .sys files.

Regarding two Unknown USB device messages, I believe 0x9271 is on-motherboard 
quasi-USB wireless adapter, and 0x3000 might be on-motherboard Bluetooth (ubt).

Tom

___
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: CFT: ndis(4) testers needed!

[Thomas Mueller]

> > set hint.rsu.0.disabled="1"

> This isn't sufficient.  This leaves the device named rsu0 but disables it 
> without
> letting other drivers attach to it.  You need to remove the rsu driver 
> entirely
> or use devctl to force the driver to ndis.

> John Baldwin

I can try on the slight chance that using devctl will make any difference 
regarding ndis.

I have something else to do on that FreeBSD installation, like installing the 
missing devel/readline that should have been installed as a dependency of 
lang/gawk; I don't know why it wasn't.

This error showed when I failed trying to build Haiku cross-tools.


Tom

___
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"

Make installworld fails on file not found (Error code 71)

[Thomas Mueller]

I was trying to test the new i915 graphics driver but got stuck in building and 
installing the userland:

/usr/share/man/man2/mknodat.2 -> /usr/share/man/man2/mknod.2
/usr/share/man/man2/munlock.2 -> /usr/share/man/man2/mlock.2
/usr/share/man/man2/munlockall.2 -> /usr/share/man/man2/mlockall.2
/usr/share/man/man2/modfnext.2 -> /usr/share/man/man2/modnext.2
/usr/share/man/man2/nmount.2 -> /usr/share/man/man2/mount.2
/usr/share/man/man2/unmount.2 -> /usr/share/man/man2/mount.2
/usr/share/man/man2/mq_timedreceive.2 -> /usr/share/man/man2/mq_receive.2
/usr/share/man/man2/mq_timedsend.2 -> /usr/share/man/man2/mq_send.2
/usr/share/man/man2/ntp_gettime.2 -> /usr/share/man/man2/ntp_adjtime.2
/usr/share/man/man2/numa_setaffinity.2 -> /usr/share/man/man2/numa_getaffinity.2
install: link /usr/share/man/man2/numa_getaffinity.2 -> 
/usr/share/man/man2/numa_setaffinity.2: No such file or directory
*** Error code 71

Stop.
make[5]: stopped in /usr/src/lib/libc
*** Error code 1

Stop.
make[4]: stopped in /usr/src/lib
*** Error code 1

Stop.
make[3]: stopped in /usr/src
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src


Now I have a new kernel on a userland dating to last April 27.

I got this same result with "make installworld" also on previous attempt just a 
day previous.

Do I need to clean out old build directory tree?  Build runs cleandir 
automatically, but do I need more, like rm -R /usr/obj/* ?

If this happened in NetBSD, I would use -r with build.sh which gets rid of 
outdated stuff in build directories, and will get a chance to try this as I try 
to update a system last built 14 months ago.

What do I need to do in FreeBSD?

Tom

___
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: Make installworld fails on file not found (Error code 71)

[Thomas Mueller]

from Jeffrey Bouquet:

> I'd installworld in single user mode...  sorry for no backstory. Worked here.

Sure, I used single user mode, as advised in UPDATING file.

from Sergey Kandauro:

> This looks like if you would try to installworld on newer sources and older
> objs without doing buildworld first to get in sync.

I ran "make buildworld" successfully, and "make kernel" before rebooting into 
single-user mode, mergemaster -Fp and make installworld.

Tom

___
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: Make installworld fails on file not found (Error code 71)

[Thomas Mueller]

I was trying to test the new i915 graphics driver but got stuck in building and 
installing the userland:

/usr/share/man/man2/mknodat.2 -> /usr/share/man/man2/mknod.2
/usr/share/man/man2/munlock.2 -> /usr/share/man/man2/mlock.2
/usr/share/man/man2/munlockall.2 -> /usr/share/man/man2/mlockall.2
/usr/share/man/man2/modfnext.2 -> /usr/share/man/man2/modnext.2
/usr/share/man/man2/nmount.2 -> /usr/share/man/man2/mount.2
/usr/share/man/man2/unmount.2 -> /usr/share/man/man2/mount.2
/usr/share/man/man2/mq_timedreceive.2 -> /usr/share/man/man2/mq_receive.2
/usr/share/man/man2/mq_timedsend.2 -> /usr/share/man/man2/mq_send.2
/usr/share/man/man2/ntp_gettime.2 -> /usr/share/man/man2/ntp_adjtime.2
/usr/share/man/man2/numa_setaffinity.2 -> /usr/share/man/man2/numa_getaffinity.2
install: link /usr/share/man/man2/numa_getaffinity.2 -> 
/usr/share/man/man2/numa_setaffinity.2: No such file or directory
*** Error code 71

Stop.
make[5]: stopped in /usr/src/lib/libc
*** Error code 1

Stop.
make[4]: stopped in /usr/src/lib
*** Error code 1

Stop.
make[3]: stopped in /usr/src
*** Error code 1


I tried svn-updating, building and installing again, the last time was after 
running "make cleandir" twice from /usr/src, then "make clean".

But I find the host system has no file

install: link /usr/share/man/man2/numa_getaffinity.2 -> 
/usr/share/man/man2/numa_setaffinity.2: No such file or directory

either regular or compressed; last userland update was April 27, 2015.

So I can't figure what I'm doing wrong, that any further attempt to update 
FreeBSD-current is a stab in the dark until I get a better clue.

either regular or compressed.

So I can't figure what I'm doing wrong.

Tom

___
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: Make installworld fails on file not found (Error code 71)

[Thomas Mueller]

> > It looks like a problem with WITHOUT_MANCOMPRESS.

> > I am looking into it.


> A fix is now committed. It has been broken since June.

> Regards,
> Bryan Drewery

Thanks for the fix, computer is now busy with NetBSD update from 6.99.44 (16 
months old) to 7.99.21 for both amd64 and i386, but I intend to get back to the 
FreeBSD update after that is done.

I checked /etc/src.conf and found
WITHOUT_MANCOMPRESS=yes
WITHOUT_DOCCOMPRESS=yes

I looked in other directions for the problem and would have just been wasting 
time and computer energy.

Compressed man pages can be a nuisance, and not really necessary or helpful 
with today's big hard drives and USB sticks.

Good I was able to expose a bug of four months' standing.

Tom

___
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: Make installworld fails on file not found (Error code 71)

[Thomas Mueller]

> > It looks like a problem with WITHOUT_MANCOMPRESS.

> > I am looking into it.


> A fix is now committed. It has been broken since June.

> Regards,
> Bryan Drewery

Thanks for the fix, computer is now busy with NetBSD update from 6.99.44 (16 
months old) to 7.99.21 for both amd64 and i386, but I intend to get back to the 
FreeBSD update after that is done.

I checked /etc/src.conf and found
WITHOUT_MANCOMPRESS=yes
WITHOUT_DOCCOMPRESS=yes

I looked in other directions for the problem and would have just been wasting 
time and computer energy.

Compressed man pages can be a nuisance, and not really necessary or helpful 
with today's big hard drives and USB sticks.

Good I was able to expose a bug of four months' standing.

UPDATE: buildworld succeeded, but installworld crashed to the debugger prompt:
  Fatal trap 12: page fault while in kernel mode

Reboot attempt, both with custom kernel and GENERIB, failed:

/libc/libc.so.7: version FBSD_1.3 required by /bin/sh not defined

GENERIB is kernel config derived from GENERIC but with some outdated devices 
unlikely to be found on a modern computer system removed, and some wireless 
drivers including rsu added.

So now that FreeBSD installation is not bootable.  I ran
fsck_ffs -y /dev/dk9 
from NetBSD 7.99.21 (current) i386, /dev/dk9 being NetBSD's version of the 
FreeBSD partition name.

I can say "make installworld" likely failed because, after interrupted 
(crashed) installworld, userland was out of sync.

I have another FreeBSD partition, 10.1-STABLE amd64, dating to January 29, 
2015, could boot into that and try to update both that (10.2-STABLE) and the 
messed-up FreeBSD-current installation (with HEAD/current).

MicroNet Fantom external hard drives, 1 TB to 5 TB, USB 3.0 and eSATA, look 
attractive now, back up a whole OS installation, eSATA figures to work better 
than USB 3.0: better for FreeBSD and NetBSD, and better recognition at boot 
time by motherboard/BIOS/UEFI.

Tom

___
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"

libcrypto.so.7 not found, needed (?) for X server

[Thomas Mueller]

I just updated FreeBSD-current to r294248, and can no longer startx.

Error message is

xauth:  file /home/arlene/.serverauth.1177 does not exist

Shared object "libcrypto.so.7" not found, required by "X"
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

There is /usr/lib/libcrypto.so but notlibcrypto.so.7.

I also looked in /usr/local/lib, no libcrypto... files.

Now I run 

pkg info -f xserver and get

root@amelia:~ # pkg info -f xserver 
Shared object "libssl.so.7" not found, required by "pkg"

What happened here?  Bug in new FreeBSD?

uname -a shows

FreeBSD amelia 11.0-CURRENT FreeBSD 11.0-CURRENT #10 r294248: Mon Jan 18 
11:28:40 UTC 2016 root@amelia:/usr/obj/usr/src/sys/SANDY11NC  amd64

Tom

___
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"

Shared library version bump?

[Thomas Mueller]

Has there recently been a version bump in the shared libraries?  I saw no 
warning on this in the src or ports UPDATING files.

I can no longer startx and can no longer run many other ports, getting errors 
like

Shared object "libcrypto.so.7" not found, required by "X"
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

and

root@amelia:~ # pkg info -f xserver
Shared object "libssl.so.7" not found, required by "pkg"

Is this due to a version bump, or is it related to the messages I got in 
yesterday's kernel installation like "unknown metadata record 4 ..."?

What do I do?  Make buildworld and kernel again, or rebuild all ports?  How do 
I find which ports need updating, or rebuild all except portmaster and pkg 
which I rebuilt after getting the errors?

Tom

___
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: libcrypto.so.7 not found, needed (?) for X server

[Thomas Mueller]

Thanks for helpful advice, too much to quote, and I am too tired anyway after a 
sleepless night and day, was up too late with the HP LaserJet printer.

It looks like I might have to rebuild all ports except for portmaster and pkg, 
already done; update perl to perl5.22, check the list of ports for desired 
deletions and additions.

pkg and "pkg check" seem to know nothing about required shared libraries in 
base system.

Everything was built under FreeBSD-head, though I have 10.2-STABLE in a 
separate partition, can use that for subversion; also some USB-stick 
installations of FreeBSD and NetBSD that include subversion.

Tom

___
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: libcrypto.so.7 not found, needed (?) for X server

[Thomas Mueller]

> > root@amelia:~ # pkg info -f xserver
> > Shared object "libssl.so.7" not found, required by "pkg"

> > What happened here?  Bug in new FreeBSD?

> This is explained by the UPDATING entry of October 2015:

> 20151030:
> The OpenSSL has been upgraded to 1.0.2d.  Any binaries requiring
> libcrypto.so.7 or libssl.so.7 must be recompiled.

> -Dimitry

I found this but not on the first attempt.

Why the #$%^&* couldn't the message have said how to find which binaries 
require a certain shared library?  It's not obvious!

pkg shows only those shared libraries that come from added packages but not 
from base OS.

I notice on this list there was a possible plan to make the whole base OS into 
a package, maybe for FreeBSD 12?

Now I could follow the example given under "man ldd".

I have updated many of the old ports but have many more to go, don't want to 
rebuild those already done.

I can't find any options/flags in pkg or portmaster to show those 
ports/packages installed after or before a specified date.  I believe 
portupgrade had such a facility.

Tom

___
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: Packaging the FreeBSD base system with pkg(8)

[Thomas Mueller]

from Glen Barber:

> As many know, work has been in progress for quite some time to provide
> the ability to package and upgrade the FreeBSD base system using pkg(8).
> The majority of the initial implementation has provided much of the core
> functionality to make this possible, however much work still needs to be
> done.

(snip)

Would the base system all be one package?

In Linux, everything is part of a package, even the kernel, but something 
comparable to FreeBSD or NetBSD base system would have many packages.

Will it be possible to upgrade base system with portmaster or portupgrade, and 
would that be better than the current procedure in UPDATING?

Would pkg then be able to show a package's required shared libraries including 
shared libraries from the base system?  I was recently stung by pkg not showing 
required shared libraries from the base system.

I just subscribed to freebsd-pkgb...@freebsd.org .

Tom

___
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: NO_INSTALLEXTRAKERNELS and PkgBase

[Thomas Mueller]

I don't really know what to quote here, but the documentation is not clear.  
There ought to be something in UPDATING.

Issue is building and installing more than one kernel.  I tried once, and it 
didn't work right.  I had to go back to one kernel at a time and NO_MODULES=yes 
on second and subsequent to avoid building the same modules redundantly.

What now happens on HEAD if I

make kernel KERNCONF=SANDY11NC GENERIB
?

I don't want to build all modules more than once.

GENERIB is modified from GENERIC to remove really drivers for really outdated 
hardware, such as old SCSI cards, and add some wireless drivers such as rsu.

Tom

___
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: newcons splash screen

[Thomas Mueller]

Is the newcons nonsupport for console screensaver related to the nonsupport for 
newcons splash screen?

Situation is the same in NetBSD 7.0_RELEASE and STABLE, and current/head, no 
support for screensaver.  DRMKMS is NetBSD's equivalent/counterpart of 
FreeBSD's newcons.  Boot to console comes up into 250x67, like in FreeBSD after 
exiting X.

Tom

___
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: Differences between freebsd-base-graphics and regular current source trees?

[Thomas Mueller]

If I want to keep up with FreeBSD-current with new graphics drivers, is it 
sufficient to keep only the freebsd-base-graphics source tree to avoid the 
redundancy of keeping the regular src tree as well?

I notice some things are not updated as frequently in the freebsd-base-graphics 
tree; "git pull" showed Already up-to-date, and I noticed GENERIC file not 
up-to-date in 
/freebsd-base-graphics/sys/i386/conf/GENERIC compared to 
/usr/src/sys/i386/conf/GENERIC.

I switched regular src tree from head to stable/11 but could checkout the head 
source tree, in which case I have to move/rename /usr/src to /usr/src11 or use 
/usr/src12 for the head source tree.


Tom

___
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: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Thomas Mueller]

This raises the question, how much diskspace is required or advised for a full 
FreeBSD installation if both the base system and ports are built from source?

Some messages in this thread have raised the possibility of needing 49 to over 
100 GB, which is much more than I have allotted.

Also, what about space for a local repository when using synth for ports?

I could run out of space on some of my partitions but could make a much bigger 
separate partition if necessary, 500 GB or more.

If this question diverges from the proper thread topic, feel free to change the 
subject line and respond to freebsd-ports if that is more appropriate, so I 
won't be accused of hijacking this thread.



Tom

___
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: svn commit: r316977 - head/sys/dev/syscons

[Thomas Mueller]

> vt(4) is not a pleasant thing to look at. I am not implying that it is bad
> code or badly done. I am just saying that it is pretty gnarly and is not
> the sort of thing most enjoy dealing with. I got the distinct feeling that
> ray@ found the job much uglier than he anticipated  when he took the
> Foundation commission to write it. Since then it has been widely disparaged
> for the things that it does not do, but I am not aware that anyone has
> gotten further than looking at what is needed and then running far
> away.Some day someone (or some company) will get sufficiently inspired to
> either re-write if or add the missing features. I have no idea when that
> might happen, though.

> Kevin Oberman, Part time kid herder and retired Network Engineer

I find vt (4) nice when in 1920*1080 resolution, as opposed to the resolution 
it comes up with after booting FreeBSD.

NetBSD newer versions with DRMKMS come up in this high resolution, as does 
FreeBSD when returning to console after exiting X.

But I notice copy-and-paste by mouse on non-X console double-spaces, inserting 
a blank line between lines.

Just for comparison, mouse copy-and-paste did not work at all with 
NetBSD-current i386 and amd64, but I am now rather behind, and intend to try 
again after updating to a more current version.

Tom

___
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"

Problems with re(4) Ethernet driver in 11-STABLE and HEAD

[Thomas Mueller]

I remember having problems with Realtek 8111E Ethernet on this Intel Ivy Bridge 
computer a couple years ago, and now the problem has resurfaced.

I am fresh from updating FreeBSD to 11-STABLE and HEAD on two partitions, and 
in both cases can not connect with onboard Ethernet.

>From NetBSD 7.99.1 /var/run/dmesg.boot :

re0 at pci2 dev 0 function 0: RealTek 8168/8111 PCIe Gigabit Ethernet (rev. 
0x06)
re0: interrupting at ioapic0 pin 17
re0: Ethernet address d4:3d:7e:97:17:e2
re0: using 256 tx descriptors
rgephy0 at re0 phy 7: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 5
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto

NetBSD 7.99.1, an old build, and NetBSD going back to 5.x, worked well with 
this Ethernet, but the bug has come back in FreeBSD.

Before giving up hope on FreeBSD 11-STABLE and HEAD on this computer, I have 
Hiro H50191 USB wi-fi adapter, driver rsu, haven't used it recently but see 
where I will try to bring it back.

"dhclient re0" on HEAD (amd64) gave a couple lines of screen output before 
crashing into debugger (db>), whereupon I simply did "reboot".

On 11-STABLE, also amd64, I got some lines before it gave up , "sleeping".

On an old FreeBSD-current, svn r286653M, Aug 12, 2015, this Ethernet starts 
properly with dhclient.  Now I am afraid to update except by installing onto a 
separate partition.

I have plenty of space on 3 TB hard drive with GPT.

I am not completely sure on which FreeBSD list is most appropriate for this 
issue.

Tom

___
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"

Problem with re(4) Ethernet driver has resurfaced in 11-STABLE and HEAD

[Thomas Mueller]

I recently updated my 10.1-STABLE to 11.0-STABLE and find I can no longer 
connect with the Ethernet.

dhclient re0 produces

DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 19
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 5
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

uname -a shows

FreeBSD amelia2 11.0-STABLE FreeBSD 11.0-STABLE #1 r317932: Mon May  8 23:23:37 
UTC 2017 root@amelia2:/usr/obj/usr/src11/sys/SANDY11NC  amd64

Relevant lines from /var/run/dmesg.boot are

re0:  port 
0xe000-0xe0ff mem 0xf7d04000-0xf7d04fff,0xf7d0-0xf7d03fff irq 17 at device 
0.0 on pci2
re0: Using 1 MSI-X message
re0: Chip rev. 0x2c80
re0: MAC rev. 0x0010
miibus0:  on re0
rgephy0:  PHY 1 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 
100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 
1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, 
auto-flow
re0: Using defaults for TSO: 65518/35/2048
re0: Ethernet address: d4:3d:7e:97:17:e2
re0: netmap queues/slots: TX 1/256, RX 1/256

Problem shows much quicker in my recent build of HEAD (12-current), where 
dhclient re0
gives just a couple lines screen output before crashing into debugger 
db> prompt

Build host for 12-current installation was the recent build of 11.0-STABLE 
amd64.

Kernel strings there show

__page_fault.read
__page_fault.write
amd64
@(#)FreeBSD 12.0-CURRENT #1 r318262: Sun May 14 09:37:30 UTC 2017
FreeBSD 12.0-CURRENT #1 r318262: Sun May 14 09:37:30 UTC 2017
root@amelia4:/BETA1/usr/obj/BETA1/usr/src/sys/SANDY12NC
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 
4.0.0)
FreeBSD
12.0-CURRENT
SANDY11NC

It looks like I can connect to Internet with Hiro H50191 USB wireless adapter, 
driver rsu, but I am not sure of its stability on 11.0-STABLE and 12.0-current..

Tom

___
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"

Maintainershjip status regarding re(4) Ethernet driver?

[Thomas Mueller]

Who is the maintainer, if any, for re(4) Ethernet driver that is again giving 
me trouble on Intel Ivy Bridge computer with MSI Z77 MPOWER motherboard?

I remember Kevin Lo, but have checked the web archives for freebsd-current and 
freebsd-net, and find Kevin Lo's last posts were during October 2016.

Is Kevin Lo still with FreeBSD?

I just opened a bugzilla account with this Ethernet re(4) connectivity problem 
on my mind.

I posted the details on this list five days ago but haven't had any response.

Tom

___
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"

Bug in make setting wrong MAKESYSPATH

[Thomas Mueller]

I tried building ports, starting with ports-mgmt/synth, on HEAD (12-current) 
and ran into difficulties with syntax error in bsd.compiler.mk .

With PORTSDIR on another partition, mounted as /BETA1, I got these errors, but 
not when I null-mounted /BETA1/usr/ports as /usr/ports.

I shouldn't have to resort to this kludge, didn't have to in the recent past.

This bug shows in both 11.0-STABLE and 12.0-CURRENT.

I looked into "man make" and found that make got the wrong path for 
MAKESYSPATH, setting to /BETA1/usr/share/mk instead of what it should be, 
/usr/share/mk .

Going into /BETA1/usr/ports/archivers/zip (for a short and simple example), 
make all-depends-list   produced

sh: Syntax error: ")" unexpected
make: "/BETA1/usr/share/mk/bsd.compiler.mk" line 52: warning: "echo 4.0.0 
4.0.0) | awk -F. '{print $1 * 1 + $2 * 100 + $3;}'" returned non-zero status
sh: Syntax error: ")" unexpected
make[1]: "/BETA1/usr/share/mk/bsd.compiler.mk" line 52: warning: "echo 4.0.0 
4.0.0) | awk -F. '{print $1 * 1 + $2 * 100 + $3;}'" returned non-zero status
/BETA1/usr/ports/ports-mgmt/pkg

make -m /usr/share/mk all-depends-list produces
/BETA1/usr/ports/ports-mgmt/pkg

This looks like a bug that ought to be fixed, though there is a workaround 
using "make -m /usr/share/mk ..." every time, or presumably, setting 
MAKESYSPATH=/usr/share/mk
in the environment.

Should I file a bug report?

I could get much more verbose outputs when there are more dependencies, such as 
in /BETA1/usr/ports/ports-mgmt/synth, or more so, 
/BETA1/usr/ports/www/seamonkey

I also noticed that in newer versions of FreeBSD, /usr/share/mk/bsd.compiler.mk 
has greatly increased in size (not a bug. except when "make" goes to the wrong 
MAKESYSPATH.

Maybe add in .cshrc and .profile
MAKESYSPATH=/usr/share/mk
?

Tom

___
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 re(4) Ethernet driver has resurfaced in 11-STABLE and HEAD

[Thomas Mueller]

from YongHyeon PYUN:

> [removed stable@ from CC]

> > I recently updated my 10.1-STABLE to 11.0-STABLE and find I can no longer 
> > connect with the Ethernet.

> > dhclient re0 produces

> > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 4
> > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 11
> > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 19
> > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 7
> > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 14
> > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 5
> > No DHCPOFFERS received.
> > No working leases in persistent database - sleeping.


> If you assign an static IPv4 address to re(4) are you able to use
> the network interface?

> AFAIK there was no significant re(4) changes for a long time. Could
> you show us back trace information?

Problem with re(4) reappeared in both 11.0-STABLE and HEAD, but OK to trim 
stable@ since changes/fixes would go to HEAD first.

No connection with static IPv4 address. 

Where do I get back trace information?

Problem was more severe with HEAD in that OS immediately crashed into debugger, 
while in 11.0-STABLE, only the connection failed but may have left memory 
unstable.

I can still connect on that computer with Hiro H50191 USB wireless adapter, 
driver rsu.

Tom

___
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 re(4) Ethernet driver has resurfaced in 11-STABLE and HEAD

[Thomas Mueller]

from O. Hartmann:

> Just for my curiosity: do you have "options FLOWTABLE" defined in your kernel 
> config?

I was not even aware of "options FLOWTABLE", having not seen it in GENERIC 
kernel config.

I had to look in $SRCDIR/sys/conf/NOTES to find it.

What would I get by adding "options FLOWTABLE" to my kernel config?

Tom

___
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: Bug in make setting wrong MAKESYSPATH

[Thomas Mueller]

> On Sun, May 21, 2017 at 1:54 AM, Thomas Mueller  wrote:
> > I tried building ports, starting with ports-mgmt/synth, on HEAD 
> > (12-current) and ran into difficulties with syntax error in bsd.compiler.mk 
> > .

> > With PORTSDIR on another partition, mounted as /BETA1, I got these errors, 
> > but not when I null-mounted /BETA1/usr/ports as /usr/ports.

> > I shouldn't have to resort to this kludge, didn't have to in the recent 
> > past.

> > This bug shows in both 11.0-STABLE and 12.0-CURRENT.

> > I looked into "man make" and found that make got the wrong path for 
> > MAKESYSPATH, setting to /BETA1/usr/share/mk instead of what it should be, 
> > /usr/share/mk .

> > Going into /BETA1/usr/ports/archivers/zip (for a short and simple example),
> > make all-depends-list   produced

> > sh: Syntax error: ")" unexpected
> > make: "/BETA1/usr/share/mk/bsd.compiler.mk" line 52: warning: "echo 4.0.0 
> > 4.0.0) | awk -F. '{print $1 * 1 + $2 * 100 + $3;}'" returned non-zero 
> > status
> > sh: Syntax error: ")" unexpected
> > make[1]: "/BETA1/usr/share/mk/bsd.compiler.mk" line 52: warning: "echo 
> > 4.0.0 4.0.0) | awk -F. '{print $1 * 1 + $2 * 100 + $3;}'" returned 
> > non-zero status
> > /BETA1/usr/ports/ports-mgmt/pkg

> > make -m /usr/share/mk all-depends-list produces
> > /BETA1/usr/ports/ports-mgmt/pkg

> > This looks like a bug that ought to be fixed, though there is a workaround 
> > using "make -m /usr/share/mk ..." every time, or presumably, setting
> > MAKESYSPATH=/usr/share/mk
> > in the environment.

> > Should I file a bug report?

> > I could get much more verbose outputs when there are more dependencies, 
> > such as in /BETA1/usr/ports/ports-mgmt/synth, or more so,
> > /BETA1/usr/ports/www/seamonkey

> > I also noticed that in newer versions of FreeBSD, 
> > /usr/share/mk/bsd.compiler.mk has greatly increased in size (not a bug. 
> > except when "make" goes to the wrong MAKESYSPATH.

> > Maybe add in .cshrc and .profile
> > MAKESYSPATH=/usr/share/mk
> ?

> Hi Tom,

> make isn't at fault here as much as there's something else leaking
> bsd.compiler.mk into the ports build. That's not supposed to happen.

> Are you including any bsd.*.mk or src.*.mk files from /etc/make.conf ,
> /etc/src.conf , etc?

> Cheers,
> -Ngie

I looked through /etc/make.conf and /etc/src.conf, and there were no explicit 
references to any .mk files.

So I don't know what could have brought in /BETA1/usr/share/mk/bsd.compiler.mk .

from Simon J. Gerraty:

> The default value for MAKESYSPATH is ".../share/mk:/usr/share/mk" which
> is geared to building src/, there was some to and fro over that value
> when we first started using bmake, but that's what we settled on.

> Presumably /BETA1/usr/share/mk exists?
> If so, it will be found via .../share/mk if you start somewhere under
> /BETA1/usr/ports

> > This bug shows in both 11.0-STABLE and 12.0-CURRENT.

> Not a bug - working as intended, which doesn't mean it is doing what you
> want.

> You can of course set MAKESYSPATH as you wish, but of course
> /usr/share/mk would not be correct for building src/

/BETA1 is a mount point for a partition with an older FreeBSD 11-current 
(August 2015) installation.

Ports, doc, src11 (src tree for 11-STABLE), and src (src tree for HEAD) have 
been updated since then.

What if I had a NetBSD installation, or no BSD installation, on the partition 
where src and ports trees are located?

It seems to me that MAKESYSPATH should match the host building system FreeBSD 
version.

I also have /pkgsrc and /netbsd-HEAD/usr/src on that same partition mounted at 
/BETA1, and it didn't seem to have any adverse effect on building NetBSD system 
or packages.

For FreeBSD, besides setting MAKESYSPATH, I could mount_nullfs /BETA1/usr/ports 
at /usr/ports, and
/BETA1/usr/src or /BETA1/usr/src11 at /usr/src .

Now I believe the correct syntax for setting MAKESYSPATH in .cshrc and .profile 
would be
export MAKESYSPATH=/usr/share/mk  # for .profile, or
setenv MAKESYSPATH /usr/share/mk  # for .cshrc

Tom

___
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: Bug in make setting wrong MAKESYSPATH

[Thomas Mueller]

>From Simon J. Gerraty:

> Thomas Mueller  wrote:
> > It seems to me that MAKESYSPATH should match the host building system
> > FreeBSD version.

> Which would only be correct if building the same version of FreeBSD as
> is running on the host.
> Many folk work on multiple branches on the same machine.

I have even built FreeBSD i386 from FreeBSD amd64, and vice versa.

Even when the user tracks only one branch, such as HEAD, one or more 
/usr/share/mk files may have been updated since the last build, and therefore 
not in sync with the build host's /usr/share/mk .

For building the system, MAKESYSPATH should be $SRCDIR/share/mk , to be in sync.

I tried "make -V MAKESYSPATH" from several SRCDIRs, and that's what happened.

Like this:

$ make -C /usr/src -V MAKESYSPATH
/usr/src/share/mk
$ make -C /freebsd-base-graphics -V MAKESYSPATH
/freebsd-base-graphics/share/mk

> Thus for anyone working on src/ there is no guarantee that /usr/share/mk
> is even remotely correct.

> So you either buy into the idea of using a wrapper script and canned
> .env file for each tree (that's what I do;
> http://www.crufty.net/sjg/docs/sb-tools.htm) to ensure correct
> settings per tree (whether FreeBSD, NetBSD, ...), or you compromise and
> have 'make' itself try to find the "correct" share/mk for whereever it is.
> This is why the default MAKESYSPATH starts with .../share/mk

> > Now I believe the correct syntax for setting MAKESYSPATH in .cshrc and 
> > .profile would be
> > export MAKESYSPATH=/usr/share/mk  # for .profile, or
> > setenv MAKESYSPATH /usr/share/mk  # for .cshrc

Something like that might be appropriate for ports but not for building the 
system.

So maybe I have to set MAKESYSPATH every time I am in ports, don't know if this 
would work from /etc/make.conf (need to experiment).

I wonder what would happen if there is no FreeBSD installation at all on 
partition where ports tree is located.

> Yes, but requires you to keep /usr/share/mk in sync with whatever you a
> building, tricky if you build head, stable/10 and stable/11 on the
> same box.

I don't think you have to do that, since I find that MAKESYSPATH becomes 
$SRCDIR/share/mk .

> sjg


Tom

___
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: Bug in make setting wrong MAKESYSPATH

[Thomas Mueller]

>From Simon J. Gerraty:

> > Thomas Mueller  wrote:
> > For building the system, MAKESYSPATH should be $SRCDIR/share/mk , to be in 
> > sync.

> > I tried "make -V MAKESYSPATH" from several SRCDIRs, and that's what 
> > happened.

> Yes.  If you look at share/mk/src.sys.env.mk
> it detects that it was found via a .../ path, and replaces it in
> MAKESYSPATH with the actual location - otherwise some makefiles break.

> > So maybe I have to set MAKESYSPATH every time I am in ports, don't
> > know if this would work from /etc/make.conf (need to experiment).

> Probably not, because sys.mk will have already been found before that
> ie. the damage may already have been done

> > I wonder what would happen if there is no FreeBSD installation at all
> > on partition where ports tree is located.

> An error like:

> make: no system rules (sys.mk).

I go into /BETA1/usr/ports/ports-mgmt/synth , run
env MAKESYSPATH make all-depends-list
and then it seems to work correctly with no syntax error in
/BETA1/usr/share/mk/bsd.compiler.mk

Maybe I need to file a bug.

What happens if src, ports and doc trees are installed on an NFS share, where 
there would be no FreeBSD installation?

Tom

___
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: Bug in make setting wrong MAKESYSPATH

[Thomas Mueller]

>From Simon J. Gerraty:

> Thomas Mueller  wrote:

> > I go into /BETA1/usr/ports/ports-mgmt/synth , run
> > env MAKESYSPATH make all-depends-list

> I assume you mean MAKESYSPATH=something? otherwise env itself should
> vomit

When I did those last examples, that last line was
env MAKESYSPATH=/usr/share/mk make all-depends-list

> > and then it seems to work correctly with no syntax error in
> > /BETA1/usr/share/mk/bsd.compiler.mk
>
> > Maybe I need to file a bug.

> For what?

Bug occurs when building or configuring ports, syntax error in 
/BETA1/usr/share/mk/bsd.compiler.mk  line 52

I don't know about other situations such as building doc.

I could avoid this error either by setting (setenv or export, depending on 
shell) MAKESYSPATH or
by null-mounting /BETA1/usr/ports at /usr/ports .

> > What happens if src, ports and doc trees are installed on an NFS
> > share, where there would be no FreeBSD installation?

> Not sure what you mean. make doesn't care what the filesystem is
> if there is a share/mk found in . or somewhere above it, the default
> MAKESYSPATH will find it.

Tom

___
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: Bug in make setting wrong MAKESYSPATH

[Thomas Mueller]

>From Simon J. Gerraty:

 >> Bug occurs when building or configuring ports, syntax error in
 >> /BETA1/usr/share/mk/bsd.compiler.mk  line 52

 >This is of course specific to your particular arrangement
 >if you'd mounted /BETA1/usr/ports on /usr/ports, it would function as
 >you wish, or if /BETA1/usr/share/mk happend to match /usr/share/mk
 >it would work fine.

 >So, anoying in this case, but not a bug.

 >> I don't know about other situations such as building doc.

 >> I could avoid this error either by setting (setenv or export, depending on 
 >> shell) MAKESYSPATH or
 >> by null-mounting /BETA1/usr/ports at /usr/ports .

 >Yes.

Just because I found a workaround does not mean it is not a bug.

If I were setting up a computer or hard disk from the beginning, I would put 
ports tree, src tree(s) and doc trees on a separate partition with no FreeBSD 
installation.

NetBSD pkgsrc and src trees could be installed on same or another partition.

That would facilitate backing up the entire installation (FreeBSD or NetBSD) 
without backing up the src and other trees, which could be redownloaded by cvs, 
svn or git, as the case might be.

I guess then I would need to set MAKESYSPATH in FreeBSD ports, or null-mount 
PORTSDIR at /usr/ports.

If you look at github.com/FreeBSD, you see some modified ports trees that might 
be installed at, for instance
/freebsd-ports-graphics

Tom

___
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"

Ports still broken by ino64?

[Thomas Mueller]

I remember some ports on FreeBSD-current were rendered nonbuildable by the 
introduction of 64-bit inodes (ino64).

What is the progress on resolving those snags?

I haven't heard anything recently and was unable to find anything on 
wiki.freebsd.org.

So how do I know the current status?

I am particularly concerned with gcc5-aux and gcc6-aux which should be of 
concern because ports-mgmt/synth requires gcc6-aux as a dependency.

There was never a BROKEN in any of these ports' Makefile.

Tom

___
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: Ports still broken by ino64?

[Thomas Mueller]

On Fri, Jun 23, 2017 at 4:12 PM, Thomas Mueller  wrote:

> > I remember some ports on FreeBSD-current were rendered nonbuildable by the
> > introduction of 64-bit inodes (ino64).

> > What is the progress on resolving those snags?

> > I haven't heard anything recently and was unable to find anything on
> > wiki.freebsd.org.

> > So how do I know the current status?

> > I am particularly concerned with gcc5-aux and gcc6-aux which should be of
> > concern because ports-mgmt/synth requires gcc6-aux as a dependency.

> > There was never a BROKEN in any of these ports' Makefile.

> Tom


> IIRC, there was no general issue with building ports, though a few may have
> needed a fix. It was that packages built after the change were not
> available and older binaries would not work. I believe that the issue went
> away as soon as a new package build was completed. This took longer than
> usual as ALL packages had to be re-built, not just those which had been
> updated since the last build.

> Kevin Oberman, Part time kid herder and retired Network Engineer

So I guess I could update my FreeBSD-current installation, building from 
11-stable host, and try again to build synth?

But all the dependencies that build successfully and installed before the 
system crash would have to be rebuilt from the start.

It will take some time before I get to it, with an 11.1-BETA2 installation 
being built up and some NetBSD installations being updated (not easy, problems 
are such as to dissuade me from tryimg to use pkgsrc on FreeBSD).

I know that any old FreeBSD-current installation from January 2016 or August 
2015 must not be touched lest all or nearly all packages be rendered 
nonfunctional due to shared libraries out of sync, not to mention ino64.

Upgrade after FreeBSD 11.1-STABLE/BETA2 installation is built up and ready to 
take over.

One thing that might put rebuilding FreeBSD-current to a higher priority would 
be an update to 
$SRC_BASE/sys/dev/re/if_re.c

Tom

___
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: Ports still broken by ino64?

[Thomas Mueller]

> Maybe not, but I think so. synth(8) requires the ada compiler which means
> lang/gcc6-aux or lang/gcc5-aux and those DID require work to install on
> ino64. I believe that this is now resolved, but I would seriously consider
> simply installing synth from the package. It has no run or lib depends, so
> installing the package is risk-free.
 
> synth is the only package I install on my development system,though I do
> consider installing chromium and libreoffice from packages now and then...
> like every time I have to rebuild either. (libreoffice is awaiting for a
> rebuild right now. Maybe tomorrow. I built Chromium yesterday.)

> Kevin Oberman, Part time kid herder and retired Network Engineer

I remember synth required specifically the latest Ada compiler, gcc6-aux.

Part of the attraction is the Ada compiler suite in gcc(5,6)-aux, for the 
possibility of cross-compiling Linux toolchains including gcc with Ada.

Other dependencies would likely be needed sooner or later, anyway.

But I was successful on 11.1-PRERELEASE.

I never ran Chrome or Chromium, might want to try; also Midori and Netsurf (and 
of course, Mozilla Firefox or Seamonkey).

One attraction of Midori is the facility to fudge the useragent string, and 
hopefully thumb my nose on websites that require specific browsers/versions.

I would also like to try John Marino's port of synth to NetBSD, see if that, 
along with pkg, works better than regular pkgsrc tools.

Tom

___
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: Ports still broken by ino64?

[Thomas Mueller]

from Adrian Chadd:

> valgrind broke as part of the ino64 work :(

Valgrind was not on my mind!  Your post sent me to 

ls -d /usr/ports/*/val*

to find valgrind, and then read the pkg-descr.

One less tool for getting debugging information when something crashes?

Tom

___
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"

Buildability status of lang/gcc5-aux and lang/gcc6-aux in FreeBSD-current?

[Thomas Mueller]

What is the status of lang/gcc6-aux and lang/gcc5-aux regarding buildability in 
FreeBSD-current?

I read about these packages not building on current subsequent to ino64, but 
there was no BROKEN notice in the Makefiles.

I tried and failed on both: gcc5-aux directly and gcc6-aux as a dependency of 
ports-mgmt/synth.

I get error message (gcc6-aux):

mkdir -p ada/bldtools/sinfo
rm -f ada/bldtools/sinfo/sinfo.ads ada/bldtools/sinfo/sinfo.adb 
ada/bldtools/sinfo/xsinfo.adb ada/bldtools/sinfo/csinfo.adb
cp -p /BETA1/usr/ports/lang/gcc6-aux/work12/gcc-6-20170202/gcc/ada/sinfo.ads 
/BETA1/usr/ports/lang/gcc6-aux/work12/gcc-6-20170202/gcc/ada/sinfo.adb 
/BETA1/usr/ports/lang/gcc6-aux/work12/gcc-6-20170202/gcc/ada/xsinfo.adb 
/BETA1/usr/ports/lang/gcc6-aux/work12/gcc-6-20170202/gcc/ada/csinfo.adb 
ada/bldtools/sinfo
(cd ada/bldtools/sinfo; gnatmake -q xsinfo ; ./xsinfo sinfo.h )

raised STORAGE_ERROR : stack overflow or erroneous memory access
gmake[4]: *** 
[/BETA1/usr/ports/lang/gcc6-aux/work12/gcc-6-20170202/gcc/ada/Make-generated.in:45:
 ada/sinfo.h] Error 1
gmake[4]: Leaving directory '/BETA1/usr/ports/lang/gcc6-aux/work12/build/gcc'
gmake[3]: *** [Makefile:4128: all-gcc] Error 2
gmake[3]: Leaving directory '/BETA1/usr/ports/lang/gcc6-aux/work12/build'
gmake[2]: *** [Makefile:876: all] Error 2
gmake[2]: Leaving directory '/BETA1/usr/ports/lang/gcc6-aux/work12/build'
*** Error code 2

and similar error on gcc5-aux.

This means not only no support for Ada in FreeBSD-current, but also synth won't 
build.  Back to portmaster.

This message could have been posted to freebsd-ports, but the problem is 
specifc to freebsd-current as far as I know.

I succeeded building synth and gcc6-aux on stable/11, but synth proved 
unworkable, crashing the system most of the time.  That would merit a separate 
thread on freebsd-ports, not to be off-topic on freebsd-current.

Tom

___
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: no X after installing xorg + xfce

[Thomas Mueller]

> I have successfully installed FreeBSD-9.0-BETA2 to an amd64 bit
> machine, I have used the ports to install xfce and xorg.  When I type
> startx, I get a screen with a bunch of colors no mouse, no keyboard,
> just colors.  The machine has nvidia onboard graphics.  I am trying to
> get kernel sources installed via sysinstall to install nvidia-driver
> but I can't get anywhere from any ftp site I select at random.  I have
> updated to latest sources available on the ports and it comes up the
> same.  I have to use the nv driver, should I try the nouveau driver?
> What should I do?  I want to help in testing and have no way to report
> bugs as without X there's not much one can do :(
 
> Is it not automatically installed when one goes into
> /usr/ports/x11/xorg, and runs make install clean?
 
> Regards,
 
> Antonio

You would get the xorg server with the xorg metaport/megaport.

One thing I can think of is a little dirty trick I have seen in FreeBSD but not 
NetBSD or Linux, X comes up but no response to mouse or keyboard.

I ran startx, got twm with its windows, but no response to mouse or keyboard.

Cure was, to include in /etc/rc.conf


hald_enable="YES"
dbus_enable="YES"

Tom

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

Re: 9.0 beta2 & the new bsdinstaller

[Thomas Mueller]

Some more ideas on the new bsdinstaller cross my mind.

Since the way the bsdinstaller would make partitions is unpredictable, at least 
to the uninitiated, and in all likelihood at variance with how much space the 
user wants to allocate, it might be better to offer a roadmap to help guide the 
user to allocating space for FreeBSD using gpart or Rod Smith's gdisk.

Also, I can't see the function of the 64 KB boot partition with no file system, 
which does not boot for me, though I can boot the main partition using grub2 
from the System Rescue CD (http://sysresccd.org/).

Another concern is updating to the next beta (BETA3?) without trashing the 
installed application software (from ports).  So far, bsdinstaller hasn't 
offered any possibility of upgrading an existing installation.  I don't think a 
user wants to rebuild all ports for every new beta or release candidate.


Tom

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

Re: 9.0 beta2 & the new bsdinstaller

[Thomas Mueller]

><"Thomas Mueller 

There was a typo on my part that I failed to correct, missing > at the end of

From: "Thomas Mueller"  and others on the boot 
partition:

So the 64 KB boot partition, nonbootable on my computer, is for legacy BIOS and 
no good on UEFI?

But I was able to boot the installation memstick for BETA1 and BETA2.

If the 64 KB boot partition is nonfunctional for me, I'd like it to be 
optional.  Or maybe the installation would go through even without the boot 
partition?

I notice there is no /usr/mdec directory in FreeBSD 9.0-to-be as there was in 
FreeBSD 8.2 and still is in NetBSD.

Another question on the same general topic, the new bsdinstaller:

Is the home directory supposed to be /home or /usr/home?

I wanted /home, but the installer made /home into a symbolic link to /usr/home, 
 I corrected this successfully, but later saw, regarding PC-BSD 9.0-BETA2:
(quoting)
Auto correct if user tries to use /home to /usr/home
(end of quote)

I think I did

rm /home
mv /usr/home /

Tom

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

Re: 9.0 beta2 & the new bsdinstaller

[Thomas Mueller]

>From "Matthew D. Fuller" :

> I've been meaning to mention this, but we really should document
> somewhere that it has a _MAXIMUM_ size.
 
> I setup a system a few weeks back with GPT, and figured I'd just make
> the first 'real' partition start at the 1 meg mark.  And make
> everything before that (1 meg - the however many sectors for the pmbr)
> the freebsd-boot partition.
 
> It worked fine, up 'till the point that I tried to boot, and it
> completely failed to, complaining that the boot code was too big.  I
> had to track around in pmbr to find
 
> .   .   cmp $0x9000,%ax..   .   # Don't load past 0x9,
> .   .   jae err_big..   .   #  545k should be enough for
> .   .   mov %ax,%es..   .   #  any boot code. :)
 
> and redo the partition to 512k (leaving a few hundred k unused before
> the next partition started) before it would boot.  That's a little
> nerve-wracking to hit on a critical system...

I don't think there is any particular advantage in aligning GPT partitions on 1 
MB boundaries.

Nothing sacred about being an integer power of 2, wouldn't it be sufficient for 
boot partition size to be divisible by 4096 bytes, when the hard drive sector 
size is 4096 bytes?


Tom

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

Re: 9.0 beta2 & the new bsdinstaller

[Thomas Mueller]

More concerns and questions onthe new bsdinstall:

There is no upgrade function.  How will a user be able to upgrade to BETA3 (or 
RC1?) without wiping out BETA2 installation?

For instance, user might have built many software applications from ports and 
not want to rebuild everything.

Other issue is the 64 KB boot partition, which does not boot for me.

There ought to be an option, or is there already, to omit the boot partition.

Sysinstall had such an option, to not install the boot loader, since user could 
already have another boot manager such as LILO or grub (legacy or grub2).

Does the 64 KB boot partition have to be the first partition on the disk in 
order to be functional?  One might want to use a different boot loader, such as 
grub2, and what about the EFI system partition that is very different from a 64 
KB FreeBSD boot partition?

Tom

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

Re: Experiences with FreeBSD 9.0-BETA2

[Thomas Mueller]

>From Brett Glass :

> Unfortunately, due to past history, /usr is mixed-use. It normally
> contains both configuration information -- e.g. /usr/local/etc --
> and more volatile data such as users' home directories. This
> prevents /usr/local/etc, which also contains mission-critical
> configuration information, from being protected if you just protect
> /. Some proprietary Unices have fixed this historical flaw in the
> traditional hierarchy by moving /usr/local/etc to another location
> and them symlinking it back to where seasoned administrators expect
> it to be, thus honoring POLA. The three open source, old school
> BSDs (Free, Net, Open) have not done this to date, but it's
> something that should be considered in the long run. It would
> certainly make the creation of embedded systems easier, as well as
> enhancing security in multi-user systems!

You mean users' home directories are under /usr/home rather than /home?

I believe /home is more traditional, and decidedly my preference: good to put 
on a separate partition so it won't be touched by a system upgrade.

Tom

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

FreeBSD 9.0-BETA2 or 3?

[Thomas Mueller]

I see a thread, "FreeBSD 9-Beta3 on X300 problems." and now am curious about 
what is the current beta?

I looked at ftp://ftp.freebsd.org/pub/FreeBSD/releases/

and found a BETA3 but only for some platforms not including i386 and amd64.

Maybe the burncd problem, not working on SATA, is a temporary barrier?

Not to sound impatient, I'd rather wait for something good than something 
released prematurely.

Tom
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 9.0-BETA2 or 3?

[Thomas Mueller]

I looked at ftp://ftp.freebsd.org/pub/FreeBSD/releases/

and found a BETA3 but only for some platforms not including i386 and amd64, but 
that was yesterday.

I looked later during the day and found the BETA3 for i386 and amd64.

Now the question is how to update without trashing the BETA2 installation with 
all the applications build from ports.

I don't want to rebuild everything from ports every time there is a new beta or 
release candidate; that would be a very inefficient use of time.

If I can't update with the installer, can I update from source?

Would the best way be to download only the source (src.txz), then
 rm -rf /usr/src/*
 then extract the new source?
Otherwise I don't know what to cvsup to, and I did read the FreeBSD Handbook.  
I also read /usr/src/README and UPDATING.

I don't want to update source to HEAD which might now be 10.0-CURRENT.


Tom
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: cvsup broken on amd64?

[Thomas Mueller]

> Hi all,
 
> I've committed this to -head.
 
> I'd appreciate it if csup users would give this a thorough testing and
> report back to the list with results.
> I won't submit this as a merge candidate this to stable/9 without a
> whole lot of testing. :)
 
> Thanks,
 
 
> Adrian
 
I am now in 9.0-BETA2 amd64 and looking to update via source. 

There is /usr/bin/csup but no cvsup.  Can I safely use csup on tag RELENG_9 to 
update, or is that broken?

Does this csup come under the cvsup bug in this thread?
 
Tom

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

Re: cvsup broken on amd64?

[Thomas Mueller]

> cvsup is a port, so you would need to install that to have cvsup. csup
> and cvsup are totally different code bases in different languages.
> (csup is C and cvsup is Modula-3.) You probably want to install cvsup
> as a package as installing the port also requires building all of the
> Modula-3 compiler, not a small install.
> --
> R. Kevin Oberman, Network Engineer - Retired
> E-mail: kob6...@gmail.com

I just checked, again, directory /usr/share/examples/cvsup and was directed to 
the Handbook section on CVSup, A6.

But I checked and found nothing with "modula" in ports; later used the search 
on modula-3 and found ezm3.

I ran "make missing" and "make all-depends-list" in net/cvsup directory and got 
no dependencies in either case.  No Modula-3?

Anyway, from what I read, csup is better, and I think I can use the same 
supfile and same server that I would use for cvsup?

I've heard of Modula-2 and 3, but those languages were never widely used as far 
as I know.
 
Tom

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

Re: Memstick image differences between 8.x and 9.x

[Thomas Mueller]

One issue that has not come up on the emailing list is that dd, designed to 
work with memsticks of various capacities, can not make the backup gpt at the 
end of the memstick.

Partition is just big enough to hold the data, and I ran out of inodes at times 
due to the installer writing to /tmp on the memstick.

Maybe a script to put a backup GPT at the end on the memstick, and make the 
second partition fill the space available so as not to be too tightly squeezed?


Tom

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

Re: x.0 RELASE isn't for production.

[Thomas Mueller]

> MHO different OS releases (Unix or not) are usually at the state of
> FreeBSD current regarding stability. FreeBSD late BETA and early RC
> are usually very stable. Therefore the approximate one month period
> between the first beta and the release is adequate time.

I see your point, especially after installing NetBSD on my new computer and 
having big problems, like not being able to startx or not neing able to boot at 
all.

On the old computer, I also had big problems with NetBSD, including release, 
stable and current versions.

Building FreeBSD or NetBSD from source might be not feasible on older computers 
short on RAM and/or disk space.

There are more frequent current FreeBSD snapshots available on

http://pub.allbsd.org/pub/FreeBSD-snapshots/

This site also has snapshots for other BSDs.

Tom

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

Upgrade from source to RC1: problems with /etc : lost users and dbus

[Thomas Mueller]

I just finished the upgrade from source from 9.0-BETA2 to RC1, and I find two 
problems.

First, I lost my users; nonroot user names are not recognized, if for instance 
I type

passwd arlene

I already tried to login as arlene with old password, no good.

I copied the /etc directory to a backup on another disk 

cp -Rp /etc  /media/etcbackup-BETA2

and then copied back /media/etcbackup-BETA2/passwd (and group) to /etc

but that didn't help.

Do I have to recreate nonroot users from scratch?

Also, I got a warning about DBUS not starting.

When I tried to startx as root, I got into X, but mouse and keyboard were 
nonfunctional; 
I did type Ctrl-Alt-F1 and Ctrl-C to get out of X.

I think it was the second mergemaster part.

Should I, as root and X not running, do

mv /etc /etcbackup-RC1

and

cp -Rp /media/etcbackup-BETA2 /etc

where /media would be mount point for backup partition on USB 3.0 hard drive?

The second invocation of mergemaster (after booting single-user) can wreak 
havoc on /etc .

As I type this, I am in my older installation of FreeBSD 9.0-BETA1 but have 
access to RC1 partition.

By the way, /etc/rc.conf remained intact, showing that hald_enable and 
dbus_enable are still there:


hostname="amelia2"
keymap=us.iso.kbd
ifconfig_re0="DHCP"
ifconfig_re0_ipv6="inet6 accept_rtadv"
sshd_enable="YES"
moused_enable="YES"
ntpd_enable="YES"
hald_enable="YES"
dbus_enable="YES"

Tom

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

Re: Upgrade from source to RC1: problems with /etc : lost users and dbus

[Thomas Mueller]

from Tom Evans :

I have had this happen before, the PEBKAC. When running mergemaster,
> it will prompt you to install new passwd, master.passwd and group
> files - if you have added local users you must not say yes to this,
> you must either merge the changes in or keep your local one.
 
> If you still have a backup, you are probably missing just master.passwd.
 
> hald, dbus would fail to start since their users are no longer there.
 
> Once you've done this to your system once, you never want to do it again!

When I had this problem, I was itching to get to bed.  But since then, I 
checked /etc and the backup, and found master.passwd, copied it back, still 
have to boot into RC1 to see if the fix works.

How does one run mergemaster without running roughshod over existing 
configuration?

I did hit d (delete) on some files I didn't want to trash, such as mail.rc and 
the ports directory configuration.

I wish there were a way to do a practice run with mergemaster without 
destroying anything, just as a medical student may practice on human cadavers, 
or flying in a flight simulator, where the consequences of doing the wrong 
thing are not disastrous.  That way, I'd know what to do for next time.

I could make one backup at the beginning, before the first mergemaster -p, and 
then another after that, before the second mergemaster.

I remember etcupdate from NetBSD, see it in FreeBSD ports/sysutils, but not in 
FreeBSD base system.

Tom

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

Re: Upgrade from source to RC1: problems with /etc : lost users and dbus

[Thomas Mueller]

from Tom Evans :

I have had this happen before, the PEBKAC. When running mergemaster,
> it will prompt you to install new passwd, master.passwd and group
> files - if you have added local users you must not say yes to this,
> you must either merge the changes in or keep your local one.
 
> If you still have a backup, you are probably missing just master.passwd.
 
> hald, dbus would fail to start since their users are no longer there.
 
> Once you've done this to your system once, you never want to do it again!

When I had this problem, I was itching to get to bed.  But since then, I 
checked /etc and the backup, and found master.passwd, copied it back, still 
have to boot into RC1 to see if the fix works.

Update: the fix didn't work, even though I have the necessary things in 
master.passwd. 

>From the boot messages:

Starting dbus.
Unknown username "polkit" in message bus configuration file
Unknown username "haldaemon" in message bus configuration file
Unknown username "avahi" in message bus configuration file
Unknown username "pulse" in message bus configuration file
Failed to start message bus: Could not get UID and GID for username "messagebus"
/etc/rc: WARNING: failed to start dbus
Starting hald.
Updating motd:.
Starting ntpd.
Configuring syscons: keymap blanktime.
Starting sshd.
Starting cron.
Starting background file system checks in 60 seconds.


Update: the fix didn't work, even though I have the necessary things in 
master.passwd and /etc/rc.conf . 

>From the boot messages:

Starting dbus.
Unknown username "polkit" in message bus configuration file
Unknown username "haldaemon" in message bus configuration file
Unknown username "avahi" in message bus configuration file
Unknown username "pulse" in message bus configuration file
Failed to start message bus: Could not get UID and GID for username "messagebus"
/etc/rc: WARNING: failed to start dbus
Starting hald.
Updating motd:.
Starting ntpd.
Configuring syscons: keymap blanktime.
Starting sshd.
Starting cron.
Starting background file system checks in 60 seconds.



Update: the fix didn't work, even though I have the necessary things in 
master.passwd. 

>From the boot messages:

Starting dbus.
Unknown username "polkit" in message bus configuration file
Unknown username "haldaemon" in message bus configuration file
Unknown username "avahi" in message bus configuration file
Unknown username "pulse" in message bus configuration file
Failed to start message bus: Could not get UID and GID for username "messagebus"
/etc/rc: WARNING: failed to start dbus
Starting hald.
Updating motd:.
Starting ntpd.
Configuring syscons: keymap blanktime.
Starting sshd.
Starting cron.
Starting background file system checks in 60 seconds.

...

I still can't login as any nonroot user, even though I see the lines in 
/etc/master.passwd, which I copied back from backup, and if I startx as root, 
there is no response to keyboard or mouse.

How do I recover?  Do I have to copy the whole BETA2 /etc and possibly run 
mergemaster -p again?


How does one run mergemaster without running roughshod over existing 
configuration?

I did hit d (delete) on some files I didn't want to trash, such as mail.rc and 
the ports directory configuration.

I wish there were a way to do a practice run with mergemaster without 
destroying anything, just as a medical student may practice on human cadavers, 
or flying in a flight simulator, where the consequences of doing the wrong 
thing are not disastrous.  That way, I'd know what to do for next time.

I could make one backup at the beginning, before the first mergemaster -p, and 
then another after that, before the second mergemaster.

I remember etcupdate from NetBSD, see it in FreeBSD ports/sysutils, but not in 
FreeBSD base system.

Tom

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

Re: Upgrade from source to RC1: problems with /etc : lost users and dbus

[Thomas Mueller]

> pwd_mkdb -p /etc/master.passwd

Cheers,
  
Matthew

> Dr Matthew J Seaman MA, D.Phil.   

That did it!  Now I can login as nonroot and startx.

I found pwd_mkdb in my searching, but would not have known to use '-p'.  I 
might have done

pwd_mkdb /etc/master.passwd

from Doug Barton :

> Carefully? :)  Seriously ... always use the -P option, and/or add
> PRESERVE_FILES in your mergemaster rc file. Watch the changes carefully.
> If you have to, do the updates in more than one pass using the -r option
> for subsequent runs. Do the simple ones first, then go back and do the
> ones that you have to think harder about. I recommend against using the
> -U option.
  
> It's not rocket science, it's just like any other system administration
> task, it requires careful attention.
  
  
> Doug

That seems like a good idea, using -P option to be able to go back to something 
good if one screws up.

>From 'man mergemaster':

 The mergemaster utility is a Bourne shell script which is designed to aid
 you in updating the various configuration and other files associated with
 FreeBSD.  It is HIGHLY recommended that you back up your /etc directory
 before beginning this process.

So I could make a second backup of /etc before the second mergemaster 
invocation, after installworld.

There are lots of files to merge/edit, and one can easily become tired and make 
mistakes.  We're only human and not infallible.


Tom

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

Re: FreeBSD 9.0-RC2 Available...

[Thomas Mueller]

> If you would like to use csup/cvsup mechanisms to access the source
> tree the branch tag to use is now "RELENG_9_0", if you use "." (head)
> you will get 10-CURRENT.  If you would like to access the source tree
> via SVN it is "svn://svn.freebsd.org/base/releng/9.0/".  We still have
> the nit that the creation of a new SVN branch winds up causing what
> looks like a check-in of the entire tree in CVS (a side-effect of the
> svn2cvs exporter) so "mergemaster -F" is your friend if you are using
> csup/cvsup.

About a couple days before seeing this message, or the message on the FreeBSD 
web site, but after seeing RC2 on the ftp.freebsd.org server,
I already ran csup with

*default release=cvs tag=RELENG_9

Am I screwed, am I OK, or do I simply have to rerun csup with RELENG_9_0 
instead of RELENG_9 ?

Again, I can't find that file (needle in the haystack) in /usr/src tree that 
shows version number such as RC2.
 
Tom

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

Re: FreeBSD 9.0-RC2 Available...

[Thomas Mueller]

> On 18/11/2011 10:53, Thomas Mueller wrote:
> > *default release=cvs tag=RELENG_9

> > Am I screwed, am I OK, or do I simply have to rerun csup with RELENG_9_0 
> > instead of RELENG_9 ?
 
> Not screwed, but you'll be running 9.0-PRERELEASE rather than 9.0-RC2.
 
> If you want to switch to the 9.0-RELEASE branch, change the tag to
> RELENG_9_0 and cvsup again.  Then redo the whole buildworld dance.
 
> Cheers,
 
> Matthew
 
> --
> Dr Matthew J Seaman MA, D.Phil.

Good to know I'm not screwed, that I can recover simply by rerunning csup, this 
time with RELENG_9_0 instead of RELENG_9.

But I hadn't got to making buildworld yet on this update.

Possibly there may be no serious difference between 9.0-PRERELEASE and 9.0-RC2 
at this stage.

As for the difference between STABLE and RELEASE, I believe STABLE is a sort of 
POSTRELEASE, like the post-release update to NetBSD 5.1 that permitted access 
to Linux ext2fs partition that didn't work previously with NetBSD; inode was 
256 bytes.

I think FreeBSD 9-STABLE (RELENG_9) would be development work toward FreeBSD 
9.1, after FreeBSD 9.0 is released, but stabler than current/head.

I looked in /usr/src/sys/conf/newvars.sh and indeed found that I had 
9.0-PRERELEASE rather than RC2.
 
Tom

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

Re: /usr/home vs /home

[Thomas Mueller]

> In the old days home was typically a separate partition that was
> mounted on /home.  If you didn't have a partition the installer would
> create /usr/home and symlink /home to it.  The root was also typically
> an independent partition, so it made sense not to clutter it up with
> home directories.
 
> Now that the default behavior is to use one big partition, the
> installer defaults to /usr/home + symlink.
 
> I've always liked the more succinct /home and was wondering if there
> is any reason why not to delete the symlink and move home to / to
> mimic the old many partition style?
 
> thanks,
> dave c

My preference is to use the traditional /home, on a separate partition.  That 
way, user data can be kept safe in the case of a major upgrading or revamping 
of the system.

This principle is even applicable for MS-Windows, even if the user-data 
partition is not called "home".

A Linux user can run two or more distributions sharing the same /home with each 
other, but not the same /home as for FreeBSD because of different file system.

bsdinstall on FreeBSD 9.0-BETA1 changed my /home to a symlink to /usr/home, but 
I changed it back to my preference.

I read that PC-BSD considers /usr/home to be correct. 

I agree with Martin Sugioarto  on preparing the disks 
myself rather than letting the installer do it.  bsdinstall only made things 
more difficult for partitioning the disk, not allowing enough space, and also 
bsdinstall's boot partition was nonfunctional for me.

But I don't see any advantage to putting /, /usr, and /var on separate 
partitions.

Tom

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

Re: "options atapicam" and/or "device ATA_CAM" in kernel config?

[Thomas Mueller]

> On 11/27/11, Lowell Gilbert  wrote:
> > "b. f."  writes:

> >>> > > What is the role of "options atapicam" and "device ATA_CAM" in kernel
> >>> > > config file?

> >>> > > Are they redundant?  Kernel will build with both these options, but
> >>> > > will it make things go awry?  Is ATA_CAM deprecated?

> >> They are redundant and incompatible.  atapicam is deprecated, and
> >> ATA_CAM is the new default on FreeBSD 9 and 10. Unless you have some
> >> special requirements, you should use ATA_CAM on recent versions of
> >> FreeBSD, because it usually performs better than the old ATA code, and
> >> has added functionality.

> > Ah. My apologies to anyone I confused with my incorrect comments.

> > I must say that I'm thoroughly disappointed that my searches through the
> > official documentation didn't turn up anything related to this. Even the
> > Handbook, with extensive practical descriptions of how to use this
> > functionality, doesn't mention that its advice is irrelevant to anything
> > past 8.x.
   
> The handbook does contain some oblique and scattered references to the
> new code, or at least to constructs that are common to both the old
> and the new code, but the addition of a brief discussion of the
> differences between the new and old ATA code in the handbook -- i.e.,
> the kernel and userland components that are now obsolete, and their
> replacements -- might be of some help to users.  The primary author of
> the new code did add some material to various notes and manpages, but
> he has been very busy writing and debugging code, and English is not
> his first language, so others will have to supplement his efforts.
> Perhaps you could ask for some additions on the freebsd-doc mailing
> list?
 
> b.

Now I see it's "options ATA_CAM" or "device atapicam".  It looks like I
inadvertently transposed "device" and "options" in subject line.

Now I think I'll try to rebuild the kernel with "options ATA_CAM" and drop
"device atapicam".

This question needs to be better resolved in time for FreeBSD 9.0-RELEASE.

I cross-post this message to freebsd-current@freebsd.org so the developers
will see it.  FreeBSD users want to be able to burn CDs and DVDs, and since
SCSI hardware has fallen out of style, I can say very few if any FreeBSD 9.0 
users will have an actual SCSI CD or DVD drive.

Tom

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

man ugen error

[Thomas Mueller]

According to ugen man page, ugen can be compiled into the kernel with
device ugen
in config file.

I tried that in the kernel config when upgrading from FreeBSD 9.0-RC1 to RC2, 
but the kernel build stopped quickly with the message that ugen was not valid.  
After removing that line from kernel config, "make kernel" was successful.

I didn't find "device ugen" anywhere in the conf/NOTES or conf/GENERIC files.

I hope this man page error can be fixed in time for FreeBSD 9.0-RELEASE.

Tom

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

Re: man ugen error

[Thomas Mueller]

> On Wednesday 30 November 2011 11:24:39 Thomas Mueller wrote:
> > According to ugen man page, ugen can be compiled into the kernel with
> > device ugen
> > in config file.

> > I tried that in the kernel config when upgrading from FreeBSD 9.0-RC1 to
> > RC2, but the kernel build stopped quickly with the message that ugen was
> > not valid.  After removing that line from kernel config, "make kernel" was
> > successful.

> > I didn't find "device ugen" anywhere in the conf/NOTES or conf/GENERIC
> > files.

> > I hope this man page error can be fixed in time for FreeBSD 9.0-RELEASE.
 
> FYI: "device ugen" is now part of "device usb"
 
> Could you send me a manpage diff?

--HPS

What version of FreeBSD do you run?  Do you not have a ugen manpage?  Can you 
run "man ugen"?

I have the manpages for ugen, and "man usb", also "man 4 usb", but no diff as 
such.

I guess ugen manpage failed to reflect becoming part of usb.


Tom

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

Re: man ugen error

[Thomas Mueller]

^ What version of FreeBSD do you run?  Do you not have a ugen manpage?  Can you 
run "man ugen"?

^ I have the manpages for ugen, and "man usb", also "man 4 usb", but no diff as 
such.

^ I guess ugen manpage failed to reflect becoming part of usb.


^ Tom

> There is:

> share/man/man4/ugen.4

> in FreeBSD 10-current.
  
> It should be removed and added to old files. Could you make a patch for that?

> --HPS

I found /usr/share/man/man4/ugen.4.gz in FreeBSD 9.0-RC2.

What needs to be patched?  What file, where?

Might it be /usr/src/ObsoleteFiles.inc ?

I have extremely limited experience applying patches, no experience writing a 
patch.

Where do I learn what and how to do?  I might need to see some examples to get 
me started.


Tom

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

Re: CVS removal from the base

[Thomas Mueller]

>From Mehmet Erol Sanliturk :

> Supplying only a console-mode FreeBSD as a release is making FreeBSD
> unusable for
> peoples who they are not computing experts .
 
 
> To allow less experienced people to use FreeBSD easily , it is necessary to
> include a
> selected ports/packages into release distributions , therefore into
> so-called BASE as a
> /ports or /packages part .
 
 
> When a new FreeBSD release will be installed ,  it is becoming necessary to
> install many packages additionally , and setting many parameters in the
> *.conf , etc. , files to make it usable . One unfortunate situation is that
> some packages are NOT working at the release moment . In the packages tree
> , it seems that there is no any regular update policy for a specific
> release . It is possible to "make port_name" , but this is NOT so much
> usable also : For a specific package  , which is installing within less
> than 30 minutes by pkg_add , required more than eighteen hours by "make
> ..." . Reason was that MAKE is an extremely STUPID system ( without BRAIN )
> because , it is NOT able to remember that it has completed making a package
> part a few seconds before , and it is starting the same steps to apply up
> to the point that it is not necessary to make it once more ( after applying
> many steps which was applied before ) .

On an old computer with 256 MB RAM, or less, building some of the bigger ports 
can take many hours.

I never dared attempt to build KDE or GNOME!  But I don't think PC-BSD runs 
with 256 MB RAM.

In the recent past, FreeBSD releases offered extra iso images with packages, 
sysinstall even offered to install packages.

I tried that once, with FreeBSD 7.0, or was it 7.1 or 6.2, and didn't really 
get a workable system.

GNOME and KDE didn't work.  When I tried portupgrading, I messed everything, 
went back to Linux (Slackware), and when FreeBSD 8.0 was released, cleaned out 
my old installation, and installed FreeBSD 8.0 fresh.

Now, on a new computer, I still use icewm, haven't attempted KDE or GNOME yet. 

Tom

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

Burning CDs and DVDs on SATA drive in FreeBSD 9.0

[Thomas Mueller]

I can't get cdrtools (cdrecord or readcd) to work on FreeBSD 9.0-RC2, and now I 
see RC3 is available.

I tried "options ATA_CAM" in kernel config, removing "device atapicam", but 
still 
readcd -scanbus  or
cdrecord -scanbus
refuses to work, running as root.

"camcontrol devlist" shows my DVD drive, and I am able to mount and read 
/dev/cd0.

Is cdrtools buggy, or maybe the FreeBSD port is buggy?

I see from the Makefile that sysutils/cdrdao is broken on FreeBSD 9.x, does not 
link.

I downloaded cdrkit-1.1.11.tar.gz so as to extract and have a look at it, and 
possibly build it on my own, outside the ports system.

I see the version in ports system is 1.1.9, maybe 1.1.11 could do better?

Maybe the FreeBSD developers were too hasty to deprecate burncd?

Tom

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

Re: Burning CDs and DVDs on SATA drive in FreeBSD 9.0

[Thomas Mueller]

from my last message:

I can't get cdrtools (cdrecord or readcd) to work on FreeBSD 9.0-RC2, and now I 
see RC3 is available.

I tried "options ATA_CAM" in kernel config, removing "device atapicam", but 
still 
readcd -scanbus  or
cdrecord -scanbus
refuses to work, running as root.

"camcontrol devlist" shows my DVD drive, and I am able to mount and read 
/dev/cd0.

Is cdrtools buggy, or maybe the FreeBSD port is buggy?

"Daniel O'Connor"  responded:

> Define "refuses to work"..
 
> I have an oldish 9.0-CURRENT which works with cdrecord..
> [titus 1:16] ~ >cdrecord -scanbus
> Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-freebsd9.0) Copyright (C) 
> 1995-2010 J?rg Schilling
> Using libscg version 'schily-0.9'.
> scsibus1:
> 1,0,0   100) 'PIONEER ' 'DVD-RW  DVR-112D' '1.09' Removable CD-ROM
> 1,1,0   101) *
> 1,2,0   102) *
> 1,3,0   103) *
> 1,4,0   104) *
> 1,5,0   105) *
> 1,6,0   106) *
> 1,7,0   107) *

cdrecord -scanbus
produces


cdrecord: Inappropriate ioctl for device. CAMIOCOMMAND ioctl failed. Cannot 
open or use SCSI driver.
cdrecord: For possible targets try 'cdrecord -scanbus'.
cdrecord: For possible transport specifiers try 'cdrecord dev=help'.
Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-freebsd9.0) Copyright (C) 
1995-2010 Jörg Schilling

About the same with readcd, and cdrecord dev=help is no help.

from grarpamp :

> In the past, I've used the ftp cdrtools pkg (made from the
> port of course) and it failed to work. It's a popular tool so my
> machine was probably out of sync. Same with burncd. However,
> compiling the current cdrtools source worked fine. So I'd try
> that first, compare, and send up a bug if need be.
 
> Try to skip the scan by specifying the BTL or devpath on the
> command line. The scan is a big part of the port and might
> have breakage, at least for the app below.
 
> Also, if you're doing audio, someone over on ports has said
> they're doing an update to cdparanoia. It's minor, but useful
> for that crowd.
 
> makefs and burncd are part of the base, at least on RELENG_8.
> And makefs is used in the official releases. So they should just work.
 
> Good luck.

You mean build cdrtools, or possibly cdrkit, directly from the source outside 
the FreeBSD ports collection.

I could then see if I could make that into my own port, or else install to 
prefix /usr/local2.

If there is a conflict between cdrkit and cdrtools, maybe install the other to 
prefix /usr/local3?

Then I could spawn a subshell with /usr/local2/bin or /usr/local3/bin added to 
the PATH.

If I get something to work, I could report back to this ports emailing list, 
share the benefits with others.
 
Tom

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

Re: Burning CDs and DVDs on SATA drive in FreeBSD 9.0

[Thomas Mueller]

> Recompile the port; the CAM ioctl numbers have changed.

> Cheers
> Michiel

When did these CAM ioctl numbers change?  Was it before or after I built and 
installed cdrtools?

Running ls -rtl /var/db/pkg/cdrtools-3.00_1 produces


total 48
-rw-r--r--  1 root  wheel  17550 Sep 26 09:20 +MTREE_DIRS
-rw-r--r--  1 root  wheel470 Sep 26 09:20 +DISPLAY
-rw-r--r--  1 root  wheel   1009 Sep 26 09:20 +DESC
-rw-r--r--  1 root  wheel  11102 Sep 26 09:20 +CONTENTS
-rw-r--r--  1 root  wheel 63 Sep 26 09:20 +COMMENT
-rw-r--r--  1 root  wheel 17 Dec  7 15:44 +REQUIRED_BY


So it might have been on FreeBSD 9.0-BETA2.

I might still want to try building cdrtools and cdrkit on my own, meaning 
without using the port.

I could possibly try to make into a port of my own, if I can follow the 
Porter's Handbook.

 
Tom

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

Re: Burning CDs and DVDs on SATA drive in FreeBSD 9.0

[Thomas Mueller]

--- On Fri, 12/9/11, Marius Strobl  wrote:

> +0000, Thomas Mueller wrote:
> > > Recompile the port; the CAM ioctl numbers have
> changed.
> Cheers
> > > Michiel
 
> > When did these CAM ioctl numbers change?  Was it
> before or after I built and installed cdrtools?
 
> > Running ls -rtl /var/db/pkg/cdrtools-3.00_1 produces
 
> > total 48
> > -rw-r--r--  1 root  wheel  17550 Sep 26
> 09:20 +MTREE_DIRS
> > -rw-r--r--  1 root  wheel    470
> Sep 26 09:20 +DISPLAY
> > -rw-r--r--  1 root 
> wheel   1009 Sep 26 09:20 +DESC
> > -rw-r--r--  1 root  wheel  11102 Sep 26
> 09:20 +CONTENTS
> > -rw-r--r--  1 root  wheel 
>    63 Sep 26 09:20 +COMMENT
> > -rw-r--r--  1 root  wheel 
>    17 Dec  7 15:44 +REQUIRED_BY
 
 
> > So it might have been on FreeBSD 9.0-BETA2.
 

> I'm not sure what CAM IOCTL number change others are
> referring to but
> you certainly need to rebuild libcam consumers after
> r225950, which
> was merged to stable/9 in r226067 on October 6 2011.

> Marius
 
Thanks for response.  I'm at the older computer now, but will need to check 
/usr/src/UPDATING, and portupgrade or portmaster cdrtools after 
source-upgrading FreeBSD 9.0-RC2 to RC3. 

Tom
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Burning CDs and DVDs on SATA drive in FreeBSD 9.0

[Thomas Mueller]

--- On Sat, 12/10/11, Marius Strobl  wrote:


> > > I'm not sure what CAM IOCTL number change others
> are
> > > referring to but
> > > you certainly need to rebuild libcam consumers
> after
> > > r225950, which
> > > was merged to stable/9 in r226067 on October 6
> 2011.

> > > Marius
  
> > Thanks for response.  I'm at the older computer
> now, but will need to check /usr/src/UPDATING, and
> portupgrade or portmaster cdrtools after source-upgrading
> FreeBSD 9.0-RC2 to RC3. 

 
> There's no corresponding entry in UPDATING.
 
> Marius

Yes, shortly after I sent my last message, I checked UPDATING, found no entry 
on CAM ioctl.

Tom
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: freebsd-current Digest, Vol 465, Issue 5

[Thomas Mueller]

> [-- Attachment #1 --]
> [-- Type: text/plain, Encoding: base64, Size: 49K --]

> Help

> - Reply message -
> From: freebsd-current-requ...@freebsd.org
> To: 
> Subject: freebsd-current Digest, Vol 465, Issue 5
> Date: Thu, Sep 13, 2012 8:00 am
(and much more)

This looks like something that should have been sent to
(copying from the message headers):

List-Help: 

Tom
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: A little question about safe mode

[Thomas Mueller]

> Hello there.
> I have problem here, and don't know if it's bug or "feature" :)
> If I prerare boot media (hdd, sd card,usb, etc) with FreeBSD, and NOT
> create there fstab, I see such behavior:

> 1. I need enter manually where from mount root (e.g. ufs:ada0s1a or
> ufs:ada0s1a rw)
> 2. If I enter ufs:ada0s1a rw - I have / mounted in read-only anyway. <== Is
> this bug?...
> 3. If I try to make it rw, with commands
> mount -o rw -u /dev/ada0s1a /
> there is no errors, but root is still RO.
> 4. I can't umount / remount some elsewhere this disk, just to create fstab
>  (it's already mounted and can't be updated).

> So, is this as-by-design, that you need "any other" media to boot, just to
> create fstab, or there is "rw" mode broken, or I just missed something?

> It's very disappointing to be able boot interactively into system, but have
> no way to "fix" fstab to make it non-interactively bootable :)
> Thanks.

> --
> Regards,
> Alexander Yerenkow

I think you would need to
mount -uw /
u being for update.

It looks like your post describes single-user mode rather than safe mode.

When there is no /etc/fstab or the fstab is unworkable, you are put into
single-user mode with a prompt to enter full path to shell or Enter for
/bin/sh

Maybe you could create your boot media with /etc/fstab pointing to the
correct partition?

Tom
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [head tinderbox] failure on arm/arm

[Thomas Mueller]

from Brett :

> Just an observation: a few years ago when I got sick of Linux's "headlong 
> rush" development model, I subscribed to various BSD mailing lists to see what
> +else was out there. I considered FreeBSD at the time - there was a 
> neverending avalanche of "[head tinderbox] failure" messages. This told me 
> that I would
> +be more likely to be running code written by people who knew what they were 
> doing if I went with Open, Net, or DragonflyBSD.

> I safely run OpenBSD-current on my main computer and it always works (I think 
> I have had 2-3 build problems in about 3 years, and they were all my fault).
> At the moment, I only feel confident enough with FreeBSD-current to run it on 
> my unimportant torrent computer. This is 80% due to constant build failures,
> and 20% due to invasive changes being introduced with 
> documentation/instructions scattered over many different pages and mailing 
> lists, e.g:

> http://wiki.freebsd.org/FrontPage?action=fullsearch&context=180&value=xorg&titlesearch=Titles

> http://wiki.freebsd.org/FrontPage?action=fullsearch&context=180&value=pkgng&titlesearch=Titles

> Hypothetical user: "Is it WITHOUT_PKGNG= or WITHOUT_PKGNG=yes or 
> WITH_PKGNG=no today?"

> I wonder how many other people that you never hear from feel the same, and if 
> some sort of "x weeks commit freezeout" should apply to the build breakers.
> Cute pointy hats or whatever obviously have no effect.

> Rant over!

I too had monstrous problems rebuilding all ports that depend on png.

But I am not really satisfied with the other BSDs.  

NetBSD is hit-or-miss to build successfully, more miss than hit.  NetBSD 
supports GPT awkwardly but has no support for USB 3.0.

NetBSD is rather unstable.  I think I'd trust FreeBSD-current over a stable or 
release version of NetBSD.

How does OpenBSD compare in that regard?

I think DragonFlyBSD just introduced USB 3.0 support in 3.2.1, but that is off 
by default.

There are live USB images available for DragonflyBSD from www.dragonflybsd.org, 
and live USB images available for OpenBSD at liveusb-openbsd.sourceforge.net .

I'd like to try, just to see what they look like and how or if they support my 
hardware.


Tom
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT: Overhauled CPSW driver for BeagleBone

[Thomas Mueller]

> On Tue, 1 Jan 2013 10:55:58 -0800
> Tim Kientzle  wrote:

> > On Jan 1, 2013, at 8:12 AM, Brett Wynkoop wrote:
> > > Greeting-

> > > The driver is working much better than the driver currently in
> > > head.  I have maintained an ssh connection to the BeagleBone for
> > > more than 24 hours!

> > Just committed this to -CURRENT r244939.

> > Tim

> Ok time to cvsup then rebuild the kernel followed by a buildworld!

> Thanks Tim!

> wynk...@wynn.com   http://prd4.wynn.com/wynkoop/pgp-keys.txt

Watch what you say about cvsup!  

Have you been following the many messages on the deprecation of cvs, cvsup and 
csup following the recent security breach on FreeBSD servers?

Now you need subversion port (svn) to download and update the source tree.

Tom
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: x220 notes

[Thomas Mueller]

Excerpt from Andrey Fesenko :

> And other problems.
> 1) wi-fi
> standart rtl8192cu - not work
> change AR5B95 - work n-mode (thanks Adrian Chadd :) need hack BIOS
> dev.acpi_ibm.0.wlan: 1 <- read only
> hardware switch work, not send mesage

What did you try to make rtl8192cu work?  Did you try NDIS?

I have Hiro USB wireless adapter with rtl8191s chip, am still trying, on and
off, to get it to work.

OpenBSD has urtwn driver that should work, ported to NetBSD, but why not 
FreeBSD?  ALso, there is a Linux driver.

Tom
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: x220 notes

[Thomas Mueller]

>From Andrey Fesenko :

> NDIS failed to raise working version. Win driver terrible ~5 firmware and 
> other.

> urtwn such as usb devices and no porting FreeBSD only dirty hack
> http://lists.freebsd.org/pipermail/freebsd-wireless/2012-November/002539.html

> just wanted to get wi-fi n-mode :) actively developed now like only ath.

> I'll have to try again; NDIS failed the first time, but that might have been
> due to something missing in kernel config regarding NDIS and ndisapi.

> I can try with both WinXP and Win7 versions.

I also want to try urtwn in NetBSD (I build the kernel and userland) and
OpenBSD live USB.  OpenBSD apparently has no support for either USB 3.0 or
GPT, can't access my hard drive at all.  NetBSD has no USB 3.0 support but 
supports GPT with partitions in a strange way, /dev/dk0, /dev/dk1, /dev/dk2,
and so on, with this sequence spanning all GPT devices including USB hard
drives and USB sticks.  I install NetBSD to a USB stick but have the source,
and pkgsrc too, on an older FreeBSD UFS2/ffsv2 hard-drive partition where all
the heavy work is done.

Aside from the possibility of porting urtwn from OpenBSD or NetBSD, maybe it
could be ported from Linux?

Tom
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"