Re: The DFly website is down.
On Fri, Jan 07, 2022 at 07:38:26AM -0600, Ladar Levison wrote: > I assume everyone (but me) knows that dragonlfybsd.org isn't working? I > also can't load mirror-master.dragonflybsd.org. L~ Yes, it was down for a while until Matt rebooted a server. (It's fun following along on IRC.) -- James
Re: How do I reinstall kde?
> https://ibb.co/Pwx2Zyn That one (not being able to sign into your Firefox account on dfly) has been discussed on IRC. kworr on IRC had a workaround that worked for me: use a different OS to sign into your Firefox account, then move that Firefox profile directory over to your dfly machine. -- James
Re: no X on a machine with onboard video
On Fri, Nov 19, 2021 at 10:50:33AM -0600, Antonio Olivares wrote: > On Fri, Nov 19, 2021 at 9:54 AM Antonio Olivares > wrote: > > > > On Fri, Nov 19, 2021 at 9:53 AM nacho Lariguet wrote: > > > > > > On Fri, 19 Nov 2021 09:19:24 -0600 > > > Antonio Olivares wrote: > > > > > > > On Fri, Nov 19, 2021 at 8:55 AM karu.pruun wrote: > > > > > > > > > > Hello > > > > > > > > > > When you boot to console, can you 'kldload radeon' and see if it > > > > > works? If yes, then drm/radeon load fine. > > > > When I load radeon driver, machine freezes > > > > # kldload radeon > > > > Had to restart. > > > BIOS or uEFI booting ? > > > > BIOS > > > > Best Regards, > > > > > > Antonio > > I will be away from computer for several days. It is an old machine, > but it worked well. I may look at getting a pci video card for it, if > I cannot get it to work. I just want for it to work, but I will have > to wait for more ideas to troubleshoot this. Thank you for your help. > If there are more suggestions, I will try them when I get back the > monday after thanksgiving. > > Best Regards, > > > Antonio I have a laptop with unsupported integrated graphics (Intel). I created /etc/X11/xorg.conf with the following content, and now it works, though the graphics are not accelerated. Section "Device" Identifier "main_graphics_device" Driver "scfb" EndSection (Thanks to daftaupe on IRC for that.) -- James
Re: Setting up DragonflyBSD
On Thu, Nov 18, 2021 at 06:31:21AM -0300, André Pfeiffer wrote: > Hello everyone, > > Some months ago I sent some messages about not being able to set up > DragonflyBSD. With the new version launched I was able to boot the > installer for the first time ever on my computer! This made me very happy. > However, as one can see on the pictures attached, I was unable to succeed. > I used the default setup, except for swap space which I removed and added > to root storage as I do with all my setups. I also encrypted everything > except for boot storage. After Image 2 I changed root password and went for > a reboot. This led to image 3, which didn't reboot no matter which key was > pressed. Lastly, after a forceful reset I was left with image 4. What did I > do wrong? > > Best regards, > > Pfeiffer. In image 4, it looks like the system has decided to shut down for some reason. Normally that message would appear after the superuser runs a command like "shutdown now". Maybe there is a message earlier on the screen explaining why the system decided to shut down. You can scroll to earlier messages by pressing scroll lock and then using page up. For image 3, I think you should wait for someone wiser than me to comment... -- James
Re: Problems with sites using Let's Encrypt certificates
On Thu, Oct 14, 2021 at 03:19:50AM -0400, Pierre Abbat wrote: > On Wednesday, October 13, 2021 8:40:11 PM EDT James Cook wrote: > > - If you upgrade to DragonflyBSD 6.0.1, the problem will go away. See > > > > https://www.dragonflydigest.com/2021/10/13/26267.html > > I'm running 6.1.0.3. Should I upgrade to the latest master? > > Pierre On master, I think this is the commit where it got fixed, dated Oct 1: https://gitweb.dragonflybsd.org/dragonfly.git/commit/a8c12d712d94f2b0a5770db307512179706bad0c So if you last upgraded before that, that will probably fix it for you. -- James
Re: Problems with sites using Let's Encrypt certificates
> I remain puzzled, however, why the mirror-master.dragonflybsd.org site > could have had an expired Web certificate for the last two weeks > without manual repair and reports on this list that first appeared on > 30-Sep-2021, the day the certificate expired. This sounds like a known issue with LetsEncrypt and dfly 6.0.0's version of LibreSSL. Assuming that's the case, here's a summary: - No, the certificate is not out of date. - Your client doesn't like the certificate chain presented by the server because the last certificate in the chain has expired. - Most clients (including newer versions of LibreSSL) accept the chain because the second-last certificate in a chain is actually a root certificate. So, the last one can be ignored. - If you upgrade to DragonflyBSD 6.0.1, the problem will go away. See https://www.dragonflydigest.com/2021/10/13/26267.html - LetsEncrypt is still including that expired certificate at the end of the chain in order to maintain compatibility with older versions of Android. I guess those Android versions don't trust that second-last cert, and have an exception so they trust the last cert in the chain beyond its normal lifetime. -- James
fsck.ext2: "dscheck(da8s2): b_bcount 6 is not on a sector boundary (ssize 512)"
I just tried running fsck.ext2 from e2fsprogs on an ext2 filesystem of mine. All seems to go well until after "Pass 5: Checking group summary information". Then on the console (in a brighter font) I see dscheck(da8s2): b_bcount 6 is not on a sector boundary (ssize 512) and (dimmer again, so I guess this is fsck.ext2 speaking) Error writing file system info: Invalid argument And the filesystem is not marked clean like fsck usually does: if I run fsck.ext2 /dev/da8s2 again, it says "/dev/da8s2 was not cleanly unmounted, check forced." Any ideas what might be going wrong? I'm guessing from the error message that /dev/da8s2 only allows sector-aligned writes, or something like that... is that true, and it different in FreeBSD? -- James
Re: wireguard trouble
On Mon, May 31, 2021 at 09:31:57AM +0800, Aaron LI wrote: > Hi James, > > I knew this issue quite some time ago (> 1 year). It’s an issue in the > golang’s net/route package. It was broken by the RTM_VERSION bump in > DragonFly and first reported at: > > https://github.com/golang/go/issues/34368 > > Although the above issue has been resolved, I think it’s a partial fix. So > there is the tun creation issue we’re having in wireguard. > > I tried a bit to investigate the issue but without a result then. Then I > suspended the work since I was (and still am) not using wireguard. > > Cheers, > Aaron It turns out there was indeed a remaining issue with the RTM_VERSION bump, but it's with listing the interfaces, not with creating tun. I think I can fix it. For now I filed https://github.com/golang/go/issues/46674 with details. -- James
Re: wireguard trouble
On Sun, Jun 06, 2021 at 07:54:30PM -0400, Justin Sherrill wrote:
> On Sun, Jun 6, 2021 at 5:20 PM James Cook wrote:
>
> > Question, for anyone who knows: was there some time in the past when
> > opening /dev/tun0 would create the tun0 interface?
> >
>
> Going by the last note I have, it should be autocreated when opening it, so
> as of 2019, yes. And still now?
>
> https://www.dragonflydigest.com/2019/08/14/23310.html
daftaupe on IRC pointed to commit f1e9a4ff which changed the behaviour.
It looks like previously /dev/tun0 through /dev/tun3 were auto-created.
Current status:
I've made a local change to wireguard-go that opens /dev/tun instead of
looking for /dev/tunX. Now there's another problem: the call to
net.InterfaceByName("tun0") in Go is returning an error "route ip+net:
no such network interface". Maybe this is related to the original
problem Aaron mentioned.
I will keep digging. So far I've tried inserting a C call to
if_nametoindex("tun0") near where net.InterfaceByName("tun0") is
called, and observed that it returns a positive number: the interface
does exist at that point. This reinforces my impression that it's the
fault of the Go net library.
--
James
Re: wireguard trouble
On Mon, May 31, 2021 at 09:31:57AM +0800, Aaron LI wrote: > Hi James, > > I knew this issue quite some time ago (> 1 year). It’s an issue in the > golang’s net/route package. It was broken by the RTM_VERSION bump in > DragonFly and first reported at: > > https://github.com/golang/go/issues/34368 > > Although the above issue has been resolved, I think it’s a partial fix. So > there is the tun creation issue we’re having in wireguard. > > I tried a bit to investigate the issue but without a result then. Then I > suspended the work since I was (and still am) not using wireguard. > > Cheers, > Aaron Thanks Aaron. I'm currently trying to puzzle my way through what's going on. Question, for anyone who knows: was there some time in the past when opening /dev/tun0 would create the tun0 interface? I ask because the CreateTUN function in the dfly patch for wireguard-go (net/wireguard-go/dragonfly/patch-tun_tun__dragonfly.go) seems to just try opening /dev/tun0. As far as I can tell, that's not the correct way to create a tun interface: instead, you're supposed to open /dev/tun. This leads to the error I posted earlier: Failed to create TUN device: open /dev/tun0: no such file or directory The message is printed by wireguard-go, which is called from the add_if() function of wg-quick. Either (a) I am misunderstanding how wireguard setup is supposed to work, or (b) something has changed since the dfly patch was written. I'm going to proceed on the assumption that it's (b), but it would be nice to know for sure. -- James
wireguard trouble
I tried to set up wireguard on dfly for the first time today, without success. Any idea what is going wrong? What I did: - doas pkg install wireguard - Created a file "wg". Heavily redacted version: [Interface] PrivateKey = XXX [Peer] PublicKey = XXX AllowedIps = 10.167.1.0/24 EndPoint = XXX_host:XXX_port PersistentKeepalive = 25 - doas ifconfig tun0 create - doas wg setconf tun0 wg The last command outputs: Unable to modify interface: No such file or directory I also tried the wg-quick script: - doas ifconfig tun0 destroy - Renamed wg to "tun0.conf" - doas wg-quick up ./tun0.conf Result falsifian angel-dfly etc $ doas wg-quick up ./tun0.conf [#] wireguard-go tun0 INFO: (tun0) 2021/05/30 04:04:57 Starting wireguard-go version 0.0.20200320 ERROR: (tun0) 2021/05/30 04:04:57 Failed to create TUN device: open /dev/tun0: no such file or directory [#] rm -f /var/run/wireguard/tun0.sock My use of "tun0" is just a guess based on some searching; wg(8) and wg-quick(8) don't actually say which interfaces are meant to be used with wireguard. (A documentation oversight?) I was worried maybe it only works on FreeBSD, but DeltaPorts includes a patch for the wg-quick script, so I guess someone got it working at some point. -- James
