Re: ZFS (in virtual machine): $HOME being a dataset causes xauth to timeout- access delays?
On Thu, Apr 01, 2021 at 07:18:56PM -1000, parv/freebsd wrote: > On Thu, Apr 1, 2021 at 3:38 PM parv/freebsd wrote: > > I am wondering if $SRC_BASE, $MAKEOBJDIRPREFIX, & $WRKDIRPREFIX being > ZFS datasets now would increase compile time. I will found that out in > few weeks (in case of buildworld & kernel) as earlier I had both $SRC_BASE & > $MAKEOBJDIRPREFIX as plain directories & took ~5--6 hours. > > I have FreeBSD 12-STABLE in VirtualBox 5.2.44 on Windows 10. All the "disks" > > are file-backed virtual disks. > > > > I noticed that after making $HOME a ZFS dataset, there were delays ... > > - generally in start of Xorg; > > - exhibited by xauth (after using "startx") error messages about timeout > > with authority files. > > > > After reverting back $HOME not being a dataset on its own as before, there > > are no delays in start of Xorg; nor are any timeout message from xauth as > > before. > > > > Has anybody else noticed that? I can't say that I've noticed any slowness. I normally don't use xauth unless I'm doing something exotic (like su to another user but want to have them able to use my X display), so probably not the best example. I've also been using zfs on FreeBSD in favor of any other filesystem since it was an option, so I'm probably probably totally worthless for speed comparison. That being said... I often feel like I'm rocking the 1986 X vibes because, while I like eye candy, that eye candy is coming with a lot of baggage. Gnome/KDE? Hah! I'm using ctwm. But if you've got said eye candy that wants to walk your file system tree and you've got a /home/$USER/.zfs/snapshot with lots of backups that is magnifying your tree, something might be doing a lot more work than the designer was originally expecting. As far as ZFS datasets go, I keep stock+ to keep my snapshot space low. I added a few things onto the stock ZFS partitioning: zfs create -o canmount=off zroot/usr/home/$USER zfs create zroot/usr/home/$USER/.cache zfs create zroot/usr/home/$USER/.mozilla zfs create zroot/usr/ports/distfiles zfs create -o canmount=off zroot/usr/obj zfs create zroot/usr/obj/usr zfs create zroot/poudriere So /home -> /usr/home is a dataset by default, /home/$USER isn't (I'm the only user, so I wasn't worried there), but because I like doing snapshot backups of things and I noticed that my snapshots were pretty damn big for what I was working on, I decided to strip out the browser droppings by making a dataset for .cache and .mozilla. Doesn't scale, but just me. To keep my zroot/ROOT/default and boot environments clean, I created the datasets for /usr/obj (kernel objects) because that is generally disposable (except when I was doing RPI work and that was precious gold since it took days to rebuild and I might want it to match a kernel I reverted to). I added oen for /usr/ports/distfiles to keep it from bloating out /usr/ports, which is also easily reconstructed (vs the tarballs, which sometimes go AWOL). In any case, for /usr/obj, some variation of this is what I was looking at: # df -h / /usr/obj/usr FilesystemSizeUsed Avail Capacity Mounted on zroot/ROOT/default 67G4.2G 63G 6%/ zroot/usr/obj/usr 72G8.6G 63G12%/usr/obj/usr I do not need 8G of stuff that I'll probably never use again snapshotted with my root filesystem that I may keep around for extended periods of time. On disk, each of the roots generally seems to use ~1.2G of space with what they have in common, but I wasn't going to get that with /usr/obj. Now, I've got a pretty beefy box, so my compiling pain points may not match yours but you can do things like tune the datasets. For example, if you're CPU bound and you have a lot of compression on /usr/obj, you may want to turn that off (while being able to leave it on for the root partition). ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: upgrade from releng12 to releng13
On Sat, Jan 23, 2021 at 03:59:07PM -0500, mike tancsa wrote: > I noticed when doing a src upgrade on a test zfs machine, I didnt > get prompted to re-install the boot blocks after upgrading the pool post > first reboot. I got a whole mess of feature upgrades just fine, but do > I not need to do a > > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i > as well ? I don't know if it's written anywhere, but I always upgrade my bootloader before I do a zpool upgrade, just in case. If the loader doesn't know how to deal with an option it finds, it may bail which will require you to recover the system some other way (probably boot on some other media and upgrade your bootloader). When the OpenZFS stuff was installed, /usr/src/UPDATING mentioned issues (like not upgrading root pools until zstd was supported by the loader), so I'd be sure to track that for potential gotchas. I seem to recall that they yanked that warning out because it was wrong for UEFI systems (vs BIOS). ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel build fail
On Sat, Dec 26, 2020 at 04:13:28PM -0800, John Kennedy wrote: > On Sat, Dec 26, 2020 at 01:57:03PM -0800, Brian W. wrote: > > I saw this last night. > > > > With this system version > > > > $ uname -a > > FreeBSD fbsd122 12.2-RELEASE-p1 FreeBSD 12.2-RELEASE-p1 GENERIC amd64 > > > > I tried to buildworld and kernel, with ccache. After it failed with > > ccache I disabled ccache. > > > > The kernel failed in this way when I disabled ccache. > > I didn't have this problem upgrading from p2 to p2, although I did that a > while ago (12/8), and I don't use ccache. > > Now, we've _almost_ through the svn -> git change. Depending on how you > pull your source down at this instant, you might have issues. See: > > https://wiki.freebsd.org/git > > At this instant, stable/12 (and I might presume that would cover 12.2) is > in Q/A for git->svn and pushing to external mirrors is a WIP. So depending > on how you get your source, things might be a bit off. > > I'd suggest totally re-cloning the source from the freebsd.org git repos > if you're using git or wait and do the same thing in the svn way if you're > using svn. > > https://github.com/bsdimp/freebsd-git-docs/blob/main/doc-cvt.md For what it's worth, I rebuilt kernel+world of my 12.2-p2 from itself without issues (git source via anon...@git.freebsd.org:src.git). ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel build fail
On Sat, Dec 26, 2020 at 01:57:03PM -0800, Brian W. wrote: > I saw this last night. > > With this system version > > $ uname -a > FreeBSD fbsd122 12.2-RELEASE-p1 FreeBSD 12.2-RELEASE-p1 GENERIC amd64 > > I tried to buildworld and kernel, with ccache. After it failed with > ccache I disabled ccache. > > The kernel failed in this way when I disabled ccache. I didn't have this problem upgrading from p2 to p2, although I did that a while ago (12/8), and I don't use ccache. Now, we've _almost_ through the svn -> git change. Depending on how you pull your source down at this instant, you might have issues. See: https://wiki.freebsd.org/git At this instant, stable/12 (and I might presume that would cover 12.2) is in Q/A for git->svn and pushing to external mirrors is a WIP. So depending on how you get your source, things might be a bit off. I'd suggest totally re-cloning the source from the freebsd.org git repos if you're using git or wait and do the same thing in the svn way if you're using svn. https://github.com/bsdimp/freebsd-git-docs/blob/main/doc-cvt.md ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On Mon, Dec 21, 2020 at 12:47:38PM -0800, John Kennedy wrote:
> On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
> > The FreeBSD project will be moving it's source repo from subversion to git
> > starting this this weekend. The docs repo was moved 2 weeks ago. The ports
> > repo will move at the end of March, 2021 due to timing issues. ...
>
> I filed Bug 252028 (sys/conf/newvers.sh: git "-dirty" even when clean),
> but that's just a trivial issue with my source tree being marked -dirty
> when it isn't, and that would have been part of r368709 anyway. All my
> other git nits have been my own (refs/notes and origin name).
Warner/others, up to r368820, we had log entries that looked like this:
commit 3cc0c0d66a065554459bd2f9b4f80cc07426464a
Author: Li-Wen Hsu
Date: Sun Dec 20 02:59:44 2020 +
Mark the repository as being converted to Git.
This is the last Subversion commit to src.
Sponsored by: The FreeBSD Foundation
Notes:
svn path=/head/; revision=368820
Now, our git logs look like this:
commit 17eba5e32a2cf7a217bb9f1e5dcca351f2b71cfc
Author: Ed Maste
Date: Tue Dec 22 23:31:15 2020 -0500
newvers.sh: fix sense of git dirty check
Previously we reported -dirty for an unmodified tree, and no -dirty
if
there were changes.
PR: 252028
Reported by:John Kennedy
(Specifically, no Notes: with revision= value)
For the kernel I compiled today, the uname output dumps out:
FreeBSD 13.0-CURRENT #245 r368820+878d53410f75-c255274(main): ...
Last kernel was (-dirty since fixed):
FreeBSD 13.0-CURRENT #244 r368820+3cc0c0d66a06-c255241(main)-dirty: ...
So, the r368820-value isn't being updated for it to find anymore. The middle
value corresponds to the git commit and does have value (878d53410f75 is your
"UPDATING: Announce git transition", 3cc0c0d66a06 was the "Mark the repository
as being converted to Git" r368820 commit).
How do you plan on referencing distinct patches now? If the revision number
is going away, we might as well yank it out since it'll be r368820 forever.
For my git projects, I often use a "git tag -a" (annotated) commit at useful
milestones, but I'm not sure what you're using it for:
[git describe]
vendor/bc/3.2.3-255270-g3f3cc995a35a
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote: > The FreeBSD project will be moving it's source repo from subversion to git > starting this this weekend. The docs repo was moved 2 weeks ago. The ports > repo will move at the end of March, 2021 due to timing issues. ... I filed Bug 252028 (sys/conf/newvers.sh: git "-dirty" even when clean), but that's just a trivial issue with my source tree being marked -dirty when it isn't, and that would have been part of r368709 anyway. All my other git nits have been my own (refs/notes and origin name). ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: authentication errors on 'make fetchindex' in /usr/ports
On Thu, Dec 03, 2020 at 04:57:53PM -0600, Bob Willcox wrote: > I am trying to upgrade a 12.1-stable system installed back in July to > 12.2-stable. > I downloaded the new ports hierarchy and now when I attempt to run 'make > fetchindex' > I get these errors: > > /usr/bin/env fetch -am -o /usr/ports/INDEX-12.bz2 > https://www.FreeBSD.org/ports/INDEX-12.bz2 > Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt > Authority X3 > 546533376:error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify > failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: > fetch: https://www.FreeBSD.org/ports/INDEX-12.bz2: Authentication error > Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt > Authority X3 > 546533376:error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify > failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: > > Can someone help? Can you run the command by hand? I can, although I'm using: 12.2-RELEASE-p1 r368257+2ab1386b6891(releng/12.2). I seem to recall some work on the certificate repository pre 12.2-RELEASE, so you might be stuck in a weird spot. If I do this little bit of uglyness, we can see some details: openssl s_client -showcerts -connect www.freebsd.org:https < /dev/null | \ perl -ne '(/-BEGIN CERTIFICATE-/../-END CERTIFICATE-/) && print' | \ while read LINE; do case "$LINE" in "-BEGIN CERTIFICATE-") CERT="$LINE";; "-END CERTIFICATE-")echo -e "$CERT\n$LINE" | openssl x509 -text -noout;; *) CERT="$CERT\n$LINE";; esac done | \ grep -E '^Certificate:|Not|Issuer:|Subject:' depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = www.freebsd.org verify return:1 DONE Certificate: Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 Not Before: Oct 17 20:36:10 2020 GMT Not After : Jan 15 20:36:10 2021 GMT Subject: CN = www.freebsd.org Certificate: Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3 Not Before: Mar 17 16:40:46 2016 GMT Not After : Mar 17 16:40:46 2021 GMT Subject: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 So, do you have the glue for the current Let's Encrypt root in your store? As I recall, that had some intermediate cross-signing stuff expire recently. Doesn't seem like it would be an issue here. openssl x509 -text < /usr/share/certs/trusted/DST_Root_CA_X3.pem | \ grep -E '^Certificate:|Not|Issuer:|Subject:' Certificate: Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3 Not Before: Sep 30 21:12:19 2000 GMT Not After : Sep 30 14:01:15 2021 GMT Subject: O = Digital Signature Trust Co., CN = DST Root CA X3 As a one-off, fetch has the --no-verify-hostname and --no-verify-peer options, but you'll probably want to update your system past a bad store since there are probably a bunch of Let's Encrypt certs out there these days. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12.1p7 no longer boots after doing zpool upgrade -a
On Fri, Jul 10, 2020 at 02:25:02PM -0500, Kyle Evans wrote: > > So one recipe doesn't even seem to make the freebsd-boot partition, so is > > it > > optional for a pure UEFI boot? Should we always gpart-bootcode it if it > > exists > > and upgrade BOOTx64.efi when the EFI partition exists, or is there a few > > more > > wrinkles we need to worry about? > > Correct, freebsd-boot is not needed for a pure UEFI boot. I wouldn't > necessarily bother updating the freebsd-boot partition unless you > suspect you may need to switch back to legacy boot at some point; UEFI > is now rock-solid on all of my systems, so I've personally found no > such need and on many of them I've removed the old freebsd-boot bits. > > If you've got an ESP, you should update that manually. If you want to > maintain the option of legacy boot, you should use gpart-bootcode for > that but don't use it on the ESP with boot1.efifat. I don't know why I would. Its pretty hard to find a non-UEFI motherboard these days and, as you've said, it's been pretty solid. I don't think I said it initially, but this originally started off of 12.0 boot media (~2019/5/31), rather than me partitioning it by hand or some more modern 12.1+ stick. > > In any case, is it a logical theory that my possible boot-order problem > > is because drive order got swapped and maybe one wasn't properly updated? > > They seem to be the same: > > > > # md5 /dev/nvd[01]p2 > > MD5 (/dev/nvd0p2) = 2ded438a2c97ea551446cc2d1d3b498e > > MD5 (/dev/nvd1p2) = 2ded438a2c97ea551446cc2d1d3b498e > > > > Ideally I'd like to have not boot through the UEFI boot menu every time. > > > > I'm not sure why the drive order seems to matter right now. > > > > When you get booted back to the UEFI menu, is it a specific drive that > you must select or do both equally work from that point? My options are basically M.2_1 and M.2_2 (not sure what labeled them, I think that is the exact name, can confirm later). #2 is currently the "first" drive, and changing boot order in the BIOS to favor #1 doesn't seem to fix that. As I said, the motherboard died and the drives were moved to a new system and I suspect that the order was swapped. I never had a reason to question my ability to boot from the 2nd disk, and hadn't done anything that merited an upgrade that made me look at it this closely. Before I figured out what was going on, it would work some of the time. I suspect a race condition (where sometimes #1 would "win"), but I can't find something that makes #2 a bad initial boot disk. I don't see anything in the boot messages that say which drive it had glommed onto. I can't say that I've tried to select #2. I can try that later on today. It's doing my weekly upgrade-build right now. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12.1p7 no longer boots after doing zpool upgrade -a
On Thu, Jul 09, 2020 at 08:24:54AM -0500, Kyle Evans wrote: > On Thu, Jul 9, 2020 at 8:12 AM Guido van Rooij wrote: > > > > I did a zpool upgrade -a to enable large_dnode and spacemap_v2. > > After that, I did: > > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada0 > > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada1 > > and: > > gpart bootcode -p /boot/boot1.efifat -i 1 ada0 > > gpart bootcode -p /boot/boot1.efifat -i 1 ada1 > > > > Now the system no longer boots from either disk and drops to the efi shell. > > This method of updating the ESP is no longer recommended for new 12.x > installations -- we now more carefully construct the ESP with an > /EFI/FreeBSD/loader.efi where loader.efi is /boot/loader.efi. You will > want to rebuild this as such, and that may fix part of your problem. So, I've got a stable box: FreeBSD 12.1-STABLE #156 r362983+cd7a9efd329c(stable/12): Tue Jul 7 07:42:17 PDT 2020 I've got almost the same situation, except I haven't shot myself in the foot yet. My partitions: # gpart show nvd0 nvd1 => 40 976773088 nvd0 GPT (466G) 40 409600 1 efi (200M) 409640 1024 2 freebsd-boot (512K) 410664984- free - (492K) 411648 16777216 3 freebsd-swap (8.0G) 17188864 959584256 4 freebsd-zfs (458G) 976773120 8- free - (4.0K) => 40 976773088 nvd1 GPT (466G) 40 409600 1 efi (200M) 409640 1024 2 freebsd-boot (512K) 410664984- free - (492K) 411648 16777216 3 freebsd-swap (8.0G) 17188864 959584256 4 freebsd-zfs (458G) 976773120 8- free - (4.0K) So this is my first UEFI system that's hit an upgrade point: # zpool status pool: zroot state: ONLINE status: Some supported features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features. See zpool-features(7) for details. scan: scrub repaired 0 in 0 days 00:02:04 with 0 errors on Wed Jul 1 13:21:57 2020 config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 nvd1p4.eli ONLINE 0 0 0 nvd0p4.eli ONLINE 0 0 0 I usually seed these things off of stick and they evolve from there, but this one is slightly interesting because the motherboard died repeatedly and I'm guessing that the M.2 drives got reinstalled in the "wrong" order so now if I don't manually select one of the M.2 drives, it won't reboot (acts like the encryption password is bad, fails out into a shell where I reboot). In any case, I know if I upgrade, it is going to tell me to upgrade the boot code and I'm wondering what that is these days. If this was a Pre-UEFI, I would be expecting to do (only) something like: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 nvd0 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 nvd1 IE, might hit either drive, update the freebsd-boot partition by # on both, and special note that the # is now one higher because of the EFI partition. The FreeBSD wiki still has the "old" way of doing it here... https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot ... but your newer way of doing it here: https://wiki.freebsd.org/UEFI So the newer way of doing it would be something like this, except I'd by updating the file rather than looking at it's checksum/version? strings -a < /boot/loader.efi | grep -A1 'EFI loader' FreeBSD/amd64 EFI loader, Revision 1.1 (Tue Jul 7 07:33:24 PDT 2020 warl...@ouroboros.phouka.net) mount -t msdosfs /dev/nvd0p1 /mnt md5 -r /boot/loader.efi /mnt/efi/boot/BOOTx64.efi 9f64a96f3170e3327ca7dad1d574d852 /boot/loader.efi cbff58cc8ee79ce7342f5be23ad14ba3 /mnt/efi/boot/BOOTx64.efi strings -a < /mnt/efi/boot/BOOTx64.efi | grep -A1 'EFI loader' FreeBSD/amd64 EFI loader, Revision 1.1 |/-\ umount -v /mnt mount -t msdosfs /dev/nvd1p1 /mnt md5 -r /mnt/efi/boot/BOOTx64.efi cbff58cc8ee79ce7342f5be23ad14ba3 /mnt/efi/boot/BOOTx64.efi umount -v /mnt At least some of the checksum difference is because WITHOUT_REPRODUCIBLE_BUILD=YES. (Sorry for extra details, but I know when I was researching this, I ran across a *lot* of examples where we didn't have a GPT dump and people were just using partition #s and if you st
Re: Running FreeBSD on M.2 SSD
On Tue, Feb 25, 2020 at 11:07:48AM +, Pete French wrote: > I have often wondered if ZFS is more aggressive with discs, because until > very recently any solid state drive I have used ZFS on broke very quicky. ... I've always wondered if ZFS (and other snapshotting file systems) would help kill SSD disks by locking up blocks longer than other filesystems might. For example, I've got snapshot-backups going back, say, a year then those blocks that haven't changed aren't going back into the pool to be rewritten (and perhaps favored because of low write-cycle count). As the disk fills up, the blocks that aren't locked up get reused more and more, leading to extra wear on them. Eventually one of those will get to the point of erroring out. Personally, I just size generously but that isn't always an option for everybody. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Running FreeBSD on M.2 SSD
On Sun, Feb 23, 2020 at 11:18:08PM -0300, Mario Olofo wrote: > Some time ago I tried to switch from Linux to FreeBSD 12.1, used a WiFi > dongle and all good, until I found that both ZFS and UFS corrupted the > filesystem very fast. > I work with a lot of small files because of web programming (node_modules), > so after a clean install, after installing the dependencies for my project, > if I scrub the zpool, it always found that the system is corrupted and > never recover. > > I have a WD Green M.2 SSD 480GB WDS480G2G0B. > Both Linux and Windows work correctly and don't detect any problems with > the disk. > > Did someone knows if it isn't supported by FreeBSD or there's some specific > configuration params that I need to set to it work correctly? > > I made a post on the forums back in the day I had the problem, the logs I > had are all there: > https://forums.freebsd.org/threads/fixing-metadata-errors-after-zfs-clear-zfs-scrub.72139/ Can't answer your WD Green question specifically, but I'm happy with my setup, below. Good to look for quirks, but you probably also want to list other hardware involved as well (which might have it's own quirks). If you've had good success (and no corruption) with two other operating systems on the same hardware, I'd probably be looking at software and/or drivers, and that requires knowledge of the hardware. I've got dual EVOs (below is just from one I'm typing on) on two different FreeBSD boxes. Nothing specific I had to do in FreeBSD, although on the other motherboard I had to tweak the motherboard settings to give it the channels it needed to shine. kernel: nvd0: NVMe namespace kernel: nvd0: 476940MB (976773168 512 byte sectors) kernel: nvd1: NVMe namespace kernel: nvd1: 476940MB (976773168 512 byte sectors) If compiling kernel and packages from source count as having lots of little files, then I do as well. I think I'm ZFS everywhere (boot partition being the question over time). Personally, the only ZFS corruption I've had over time has been caused by bad hardware. When I moved the disks to another box, they were fine with the same version of FreeBSD. I scrub my zpool about once a month just because, plus after I get the kernel to crash. The original box went all the way back to root-on-ZFS + FreeBSD 11. The newer box just started around 12.0 (2019-05-31). ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Confused about i915kms on 12.1
On Sun, Oct 13, 2019 at 02:42:46PM -0700, Chuck Tuffli wrote:
> Many thanks to Pete and John. See inline below
> ...
> I upgraded the box per the release announcement:
>freebsd-update upgrade -r 12.1-RC1
>freebsd-update install
> with the prescribed reboots and installs. Afterwards, I did a pkg
> update and pkg upgrade. Note, I don't install anything from ports.
The FreeBSD handbook might have the extra bits you were missing:
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html
Bonus note: the 2nd "freebsd-update install" after the reboot to delete some
now-obsolete files.
The announcement really doesn't talk about upgrading ports.
In 23.2.3.2 ("Upgrading Packages After a Major Version Upgrade") they say
to do this (among other things):
pkg-static upgrade -f
So pkg-static (vs pkg) in case you have shared-library problems with the
dynamically-linked pkg, and then -f to "force" the upgrade. That may be
the missing piece here in getting rid of your previous-kernel packages
even if they might otherwise run just fine.
> $ pkg info drm-fbsd12.0-kmod-4.16.g20190814 | grep -i version
> Version: 4.16.g20190814
> FreeBSD_version: 1200086
> This version is for FreeBSD 12.0.
Clearly the old 12.0-* kernel.
> The advice I received was 'you need to build drm-kmod from ports'. I
> don't typically have a ports tree, so I did:
> # portsnap fetch
> # portsnap extract
> # cd /usr/ports/graphics/drm-kmod
> # make && make install
> After doing the makes, my immediate thought was 'that finished too fast'.
That is apparently a meta-port that doesn't behave like you'd expect. I
had to do a similar thing for myself. But I think the "-f" might have
fixed it for you above, if the packages were built on the repo (below).
> If, instead, I follow Pete's advice and run make package in
> /usr/ports/graphics/drm-fbsd12.0-kmod, a) make appears to do something
> and b) the resulting package allows my laptop to boot to a graphical
> desktop. And the FreeBSD_version looks correct:
> $ pkg info drm-fbsd12.0-kmod-4.16.g20190814 | grep -i version
> Version: 4.16.g20190814
> FreeBSD_version: 1201000
> This version is for FreeBSD 12.0.
>
> I did go back and verify that a pkg install drm-kmod appears to
> install the same (older) i915kms.ko as pkg install drm-fbsd12.0-kmod.
> Out of curiosity, is the new world order that I'll always need to
> compile drm-kmod from ports, or did I hit a window where packages
> hadn't quite caught up to ports?
I don't know. Finding out which package your .ko file came from would
tell us a bit there. I've just got in the habit of build all my packages
myself because I can get into the bleeding-edge area and run into problems
like that.
I suspect that the official answer would be "hell no" and this is the
type of experience that the FreeBSD folks like to see for the purposes
off adding things to UPDATING and such. But I know that it is going to
take a while for their poudraire to grid through all the ports
In any case, I'm glad we got you up and running.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Confused about i915kms on 12.1
On Sun, Oct 13, 2019 at 12:35:41PM -0700, Chuck Tuffli wrote: > I've been running 12.0-REL on my X1 Carbon 3rd Gen happily with xorg, > but after installing 12.1-RC1, the laptop reboots when loading the > i915kms driver. If I comment out the line in /etc/rc.conf: > > kld_list="/boot/modules/i915kms.ko" > > the laptop boots, albeit without graphics. The above comes from the > 12.0R release notes, and I didn't see any updates to this in the 12.1 > release notes. I've tried drm-kmod from both ports and packages with > the same result. Did something change with 12.1? What should I check? > TIA Not sure how your upgraded your box, but make sure that the driver is compiled for the new kernel. KBI breakage can easily behave like that. I won't be in front of a box with that setup until Monday, but from memory, graphics/drm-kmod pulls in graphics/drm-fbsd12.0-kmod (at least on my system with it's build-in Intel video card). If you do something like this, but substitute your .ko file for m4 below, you should be able to validate the package it came from and the kernel version it was targeted at: $ pkg which /usr/local/bin/*m4 /usr/local/bin/gm4 was installed by package m4-1.4.18_1,1 $ pkg info m4 | grep -i version Version: 1.4.18_1,1 FreeBSD_version: 1201000 That 1201000 means that it was compiled for 12.1 in my case. Have you overridden the default package location, leaving it aimed at 12.0? What do you mean by trying it from "ports"? How did you refresh that? (I'm just fishing for something that would have survived the upgrade process and been locked onto 12.0 vs 12.1 and stopping you from getting a good, recompiled version installed.) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pkg thinks kernel is old
On Wed, Oct 09, 2019 at 11:38:25PM +0200, Bengt Ahlgren wrote: > I've ran into this on my 11.3-STABLE system: > > # uname -K > 1103500 > # pkg update -f > Updating ivyp repository catalogue... > Fetching meta.txz: 100%560 B 0.6kB/s00:01 > Fetching packagesite.txz: 100% 410 KiB 419.9kB/s00:01 > Processing entries: 0% > Newer FreeBSD version for package zziplib: > To ignore this error set IGNORE_OSVERSION=yes > - package: 1103000 > - running kernel: 1102509 > Ignore the mismatch and continue? [Y/n]: > > I build my own packages with poudriere, and have just switched from an > 11.2-REL to an 11.3-REL jail. I didn't force-upgrade everything after > the switch, perhaps that's needed to make pkg recognise the correct > kernel version? If I saw that, I'd force-upgrade everything. With poudriere, it has seemed to always do the right thing but I haven't really tried it across big bumps yet (despite going from 12.0 into 12.1 through the beta). You might have some more major changes in there. I know pkg-upgrade won't reinstall just to bump up the version # for an installed package, but I don't know its logic. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 12.1-BETA2 Now Available
On Sat, Sep 28, 2019 at 05:21:12PM +0200, Kurt Jaeger wrote: > Upgrading a 12.1-BETA1 poudriere install with > poudriere jail -u -t 12.1-BETA2 -j 121 > fails with: ... I don't know if it's proper, but just doing a "poudriere jail -u -j 12-1" worked for me, The version reported by "poudriere jail -l" showed up correctly (*BETA2) when it completed. The poudriere run hadn't finished by the time I left Friday, but it had built over a hundred packages. My first test of this, vs creating a new jail every time the version changes. Originally created with a: poudriere jail -c -j 12-1 -v 12.1-BETA1 -m src=/usr/src In my case, /usr/src was BETA2 compiled from source when it was updated, and BETA1 when it was originally created. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12.1-PRE-RELEASE, 352114 is ok but 352202 is bad
On Wed, Sep 11, 2019 at 11:46:14PM -0400, Yoshihiro Ota wrote: > After updating from 352114 to 352202 on 12/stable, 12.1-PRE-RELEASE, my > kernel stopped booting. > ... This one runs on Parallels VM. ... > As 13-CURRENT with the last night's code boots okay, I suspect some merge > error to the branch. There was a bug (240487) yesterday that was present from r352179 up to r352217 which is literally the patch after r352202 as it landed in 12-stable. This booted for me: FreeBSD 12.1-PRERELEASE #106 r352217+0e6a9a9426c7(stable/12) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Anyone else seeing hangs at "Trying to mount root" after recent commits?
On Wed, Sep 11, 2019 at 08:59:58AM -0700, John Kennedy wrote: > For what it's worth, I have a Dell Optiplex 9020 booting r352118: > > FreeBSD 12.1-PRERELEASE #105 r352118+b6945c1f5542(stable/12) > > That's at least after r352025, which may help your bisect. Currently > crunching r352202. I boot off of ZFS (vs UFS), but that might be another > data point for someone. I paid attention to bug 240487 and saw the "Fix miss merge in r352179" r352217 patch land and just booted with that. Looks good to me so far. FreeBSD 12.1-PRERELEASE #106 r352217+0e6a9a9426c7(stable/12) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Anyone else seeing hangs at "Trying to mount root" after recent commits?
On Wed, Sep 11, 2019 at 01:38:14AM -0700, Jack L. wrote: > Yes, I upgraded 2 systems and both experience the same behavior > Dell R610 and Dell 7010 here. Afraid to upgrade any others For what it's worth, I have a Dell Optiplex 9020 booting r352118: FreeBSD FreeBSD 12.1-PRERELEASE #105 r352118+b6945c1f5542(stable/12) That's at least after r352025, which may help your bisect. Currently crunching r352202. I boot off of ZFS (vs UFS), but that might be another data point for someone. > On Tue, Sep 10, 2019 at 8:25 PM Terry Kennedy wrote: > > I have a system I updated from r352025 (which worked fine) to r352200. > > Any attempt to boot r352200 results in the system just sitting there after > > displaying the normal "Trying to mount root from ufs:/dev/da0p3 [rw]..." > > message. Nothing further, not even after a half hour. The console is non- > > responsive (not that I'd really expect anything, but...). > > > > This persists across multiple resets, power cycles, etc. Booting the > > previous r352025 works fine, as expected. > > > > Before I start trying to bisect this, is anyone else seeing this? amd64 > > on a standard Dell PowerEdge R730 if that matters. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Failing to retrieve source tarballs for anything.
On Sun, Sep 02, 2018 at 07:58:16AM +1200, Jonathan Chen wrote: > On 2 September 2018 at 05:25, Alex McKeever > wrote: > > After compiling PKG, when I go to ports to compile anything (my eMac can > > run FreeBSD but not modern Linux due to the version of the Radeon GPU) it > > fails to retrieve any of the source tarballs for any of the software, > > desktop environments etc. I would like help to fix this, as I???d like to > > run something current. > > How old is your ports tree? It it up to date? What sort of problems > are you seeing in fetching the port sources? > > Since no one else has reported any problems, it is most likely > something to do with your local environment. Alex, despite what the documentation says, I wouldn't try to build too much using the regular make methods (or portmaster). There are a number of dependencies that are incompatible that you can skate by if you use packages, synth or poudriere. Unless you're going to heavily customize your options, I'd stick with the simplest, packages, until you have a reason not to. FreeBSD 11.2 is stable... what version are you running? If you're running something really old, packages may no longer be offered and you should try to upgrade, but that is a different problem. 11.1 and 10.4 still have some life. As Jonathan noted, having an up-to-date port tree is also important. If it's too old, you may be trying to grab tarballs that no longer exist. Have you looked at chapter 4 of the FreeBSD handbook? https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html One way to update the sources is via the portsnap fetch/extract/update: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html The "binary packages" method is described here: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pkgng-intro.html If you're using packages, and you "pkg upgrade", you'll see something like: root@rpi3:~ # pkg upgrade Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. Checking for upgrades (1 candidates): 100% Processing candidates (1 candidates): 100% Checking integrity... done (0 conflicting) Your packages are up to date. My home ISP does something wonky with their DNS and I have some issues with connecting to some resources, but that is trivially solved by changing my DNS server. That typically manifests as unreachable sites or unresolvable hostnames, which might match your symptoms depending on the "fail." ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: How do I stop using local_unbound ?
On Mon, Aug 06, 2018 at 03:06:00PM +0100, Pete French wrote: > having enabled local_unbound in /etc/rc.d how do I remove that > and go back to using just DHCP delivered nameservers ? I > set it to 'NO' but yet the machine still seems to have traces of > the config in other places and keeps trying to use them, for reasons I > dont understand. > > Is there a quyick guide to clearing this off a system when you dont want to > use > it anymore ? I get that it needs to be slightly complex to do what it does, > but its proving very hard to fix the broken DNS looksup! Hmm. First, make sure that it isn't running (service local_unbound stop, etc). Then look at your /etc/resolv.conf -- unbound tends to rewrite that on initial startup, taking some of it's settings and inserting itself into the middle as a caching DNS server. At the very least, you want something like this: nameserver 8.8.8.8 I think the default DHCP client stomps all over /etc/resolv.conf fairly well, but see what options are in there (for example, options for domain-name-servers and domain-name). The stock /etc/dhclient.conf is all comments. I have issues with the DNS results my ISP returns to me, but setting up a cache or using sites like 8.8.8.8 (google public DNS, if you don't mind feeding the beast) fixes that. For something deeper, what is your /etc/host.conf? Mine is this: # Auto-generated from nsswitch.conf hosts dns That lets your /etc/hosts contents override DNS, which is often a good thing. By default, your /etc/hosts should be pretty much all comments except for these two lines: [grep -v '^#' /etc/hosts] ::1 localhost localhost.my.domain 127.0.0.1 localhost localhost.my.domain ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PRERELEASE back?
On Sat, Jun 02, 2018 at 08:14:37AM -0700, Kevin Oberman wrote: > After teh announcement of RC1 I updated my 11-STABLE box, expecting wither > that I would see RC1 or STABLE, depending on whether the 11.2 BRANCH had > been created, but instead I am "back" at 11.2-PRERELEASE #1. > > Is this intentional? At least it is confusing. It has branched off to releng/11.2 now. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mdconfig and UDF
On Fri, Jul 14, 2017 at 02:31:15PM +0500, Eugene M. Zheganin wrote: > Is there any chance to mount UDF filesystem under FreeBSD with mdconfig > and ISO image ? Mount -t cd9660 /dev/md0 /mnt/cdrom gives me the > readme.txt with "This is UDF, you idiot" and mount -t udf /dev/md0 > /mnt/cdrom gives me > > # mount -t udf /dev/md0 cdrom > mount_udf: /dev/md0: Invalid argument If I make an ISO like this (currently under 11.1-RC3): mkisofs -R -J -joliet-long -udf -iso-level 3 -o /path/to/test.iso /source/files/dir I can mount it like this via md: mdconfig -a -t vnode -f /path/to/test.iso -u 0 mount -t udf -o ro /dev/md0 /mnt When I burn it to a physical disk, I just mount it like this: mount -t udf -o ro /dev/cd0 /mnt ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
11.1-RC1 kernel panic (zfs recv)
I've had a kernel crash with 3 different RC1 kernels. kernel: FreeBSD 11.1-RC1 #71 r313908+b08656c3ba28(releng/11.1): Sun Jul 2 23:15:23 PDT 2017 kernel: FreeBSD 11.1-RC1 #72 r313908+64e0abde4c70(releng/11.1): Mon Jul 3 07:43:42 PDT 2017 kernel: FreeBSD 11.1-RC1 #73 r313908+ff3a058c4f83(releng/11.1): Mon Jul 3 11:56:29 PDT 2017 # kldstat Id Refs AddressSize Name 1 42 0x8020 1f67128 kernel 21 0x82169000 3161c0 zfs.ko 32 0x8248 c9e8 opensolaris.ko 41 0x8248d000 21c68geom_eli.ko 51 0x824af000 bc68 aesni.ko 61 0x824bb000 114f58 nvidia-modeset.ko 73 0x825d ab7f8linux.ko 83 0x8267c000 ddc0 linux_common.ko 92 0x8268a000 1056708 nvidia.ko 101 0x83821000 3602 ums.ko 111 0x83825000 3c35clinux64.ko 121 0x83862000 eb0d iscsi.ko Excuse human-induced typos in stack-trace: panic: avl_find() succeeded inside avl_add() cpuid=5 KDB: stack backgrace: #0 0x80aad9c7 at kdb_backtrace+0x67 #1 0x80a6baa6 at vpanic+0x186 #2 0x80a6b913 at panic+0x43 #3 0x82169df4 at avl_add+0x134 #4 0x821a9bed at dmu_recv_end+0x16d #5 0x82231e0f at zfs_ioc_recv+0xb1f #6 0x82233c36 at zfsdev_ioctl+0x6d6 #7 0x8093ad38 at devfs_ioctl_f+0x128 #8 0x80ac9315 at kern_ioctl+0x255 #9 0x80ac904f at sys_ioctl+0x16f #10 0x80ee0394 at amd64_syscall+0x6c4 #11 0x80ec35cb at Xfast_syscall+0xfb It is reproducible. Initially saw it with zfs send | zfs recv (kernel #71), reproduced outside of X so I could see the panic, installed kernel #72 to be more current (had it compiled but not installed since I was doing lots of I/O). Didn't happen with zfs send to file, happened on zfs recv from file, grabbed #73 since it looked like it might apply since I have a da* via ISCSI, and can still reproduce the problem. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
