Re: 11-STABLE system unbootable after update
Cyrus Rahman wrote: > When you upgrade the kernel you need to upgrade any loadable kernel > modules at the same time. Yes. For a time, listing them in /etc/src.conf would get them rebuilt automatically as a sort of epilogue to building a kernel, but then something changed quite a while back, and I had to comment that line out and return to doing them manually. Often they still work without being rebuilt, and I got careless this time. Sigh. > > Recompile any kmods from ports and you should be ok. Done, but the next reboot will be into the previous boot environment, and it now seems unlikely that I will use this one again rather than making a new one from a more up-to-date revision. > > STABLE doesn't always work. It's good for adventurous people to try > it so the bugs get found out, but occasionally it is painful. Upgrade > again right after the release in a few weeks. Usually caution is in > order just before things get to the BETA stage. I upgraded just now > do help test things and discovered your bug, which I posted about a > few posts before yours on the list. Ah. I suppose I will see that while catching up on my latest email backlog caused by six days or so with no working system. Thanks again for your reply to my call for help. > > If the description I posted is similar to yours, go ahead and reply to > my message on the list, and perhaps go to bugs.freebsd.org and search > out 'loader', and add any information you might have (or at least > document the fact that you were affected). Will do. > > You can quote me on the list, I simply wanted to have you try things > out before putting my suggestions on it. Over the years I have grown > weary of unnecessary noise. > Okay. I've cc'ed the list this time. FWIW, once of the things I have been wishing for in trying new revisions of 11-STABLE is a fix for the failure of the kernel to honor the vm.max_wired sysctl variable. The crash that gave me an opportunity to try the broken revision was another case of the kernel having pagefixed so much real memory that it was not only causing paging/swapping when it should have, but I think the kernel itself couldn't get page frames it needed fast enough in some situation. I don't know whether this bug has been found and fixed yet, though, so I have temporarily returned to setting vm.kmem_size_max, which does seem to be honored. Anyway, thanks for bailing me out yesterday. The system is now somewhat usable while I satisfy my curiousity and should be fully usable upon reversion, which will probably happen tomorrow (Monday) night. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: 11-STABLE system unbootable after update
Matt Garber wrote: > On Sun, May 19, 2019 at 9:00 AM Scott Bennett wrote: > > > > > Many, many thanks to the person who responded with the solution to > > get past the > > loader crash!! My system is now getting work done again, and the rest of > > the new > > problems can be dealt with on a running system. > > > Out of curiosity, you mentioned in your previous email you created a new > boot environment for this upgrade? since additional issues remain beyond > the loader, have you considered rolling back to the known-good BE and > attempting the entire process again (with another, separate BE) in a week > or so? Especially since that would hopefully allow you to continue your > other work without any additional issues or oddities to sort through in the > meantime? > Yes, and I will likely do so, but not tonight. I am still exploring what is new/changed in this revision (besides a broken zfsloader), and I do have mprime back to work for the time being, so reverting can wait another day. I have reverted a few times in the past, but was always able to start that from the boot menu. This time really threw me until I received a reply to my plea for help telling me how to use the previous loader to get to the boot menu. I had already successfully run the r347183 kernel in single-user mode, so I figured I could do so again. What broke the zfsloader was the installworld step. After reverting to r345498 I will try bringing my source tree up to date, which would be quite a bit later than this broken r347183, and then run a fresh buildworld and buildkernel anyway. If all that fails, then I'll just go back to r345498 again and sit it out until 11.3-RELEASE happens before trying again. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: trying to expand a zvol-backed bhyve guest which is UFS
On Sun, May 19, 2019 at 9:47 PM tech-lists wrote: > Thanks very much to you both, all sorted now. I didn't realise there was > a 2TB limit for MBR either. Can I shrink the 4TB to 2TB on the zfs side > without scrambling the ufs on the guest? > You can snapshot the zvol to be safe, but you should be able to shrink it to the existing partition size. If it's a sparse zvol, it may not may that much difference. -- Adam ___ 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: trying to expand a zvol-backed bhyve guest which is UFS
Thanks very much to you both, all sorted now. I didn't realise there was a 2TB limit for MBR either. Can I shrink the 4TB to 2TB on the zfs side without scrambling the ufs on the guest? thanks, -- J. signature.asc Description: PGP signature
Re: trying to expand a zvol-backed bhyve guest which is UFS
On Sun, May 19, 2019, 6:59 PM Paul Mather, wrote: > On May 19, 2019, at 9:46 PM, tech-lists wrote: > > > Hi, > > > > context is 12-stable, zfs, bhyve > > > > I have a zvol-backed bhyve guest. Its zvol size was initially 512GB > > It needed to be expanded to 4TB. That worked fine. > > > > The problem is the freebsd guest is UFS and I can't seem to make it see > > the new size. But zfs list -o size on the host shows that as far as zfs > is > > concerned, it's 4TB > > > > On the guest, I've tried running growfs / but it says requested size is > > the same as the size it already is (508GB) > > > > gpart show on the guest has the following > > > > # gpart show > > =>63 4294967232 vtbd0 MBR (4.0T) > > 63 1 - free - (512B) > > 64 4294967216 1 freebsd [active] (2.0T) > > 4294967280 15 - free - (7.5K) > > > > => 0 4294967216 vtbd0s1 BSD (2.0T) > > 0 10653532161 freebsd-ufs (508G) > > 1065353216 83885442 freebsd-swap (4.0G) > > 1073741760 3221225456 - free - (1.5T) > > > > I'm not understanding the double output, or why growfs hasn't worked on > > the guest ufs. Can anyone help please? > > > Given the above, the freebsd-ufs partition can't grow because there is a > freebsd-swap partition between it and the free space you've added at the > end of the volume. > > You'd need to delete the swap partition (or otherwise move it to the end > of > the partition on the volume) before you could successfully growfs the > freebsd-ufs partition. > Even if you do all that, you won't be able to use more than 2 TB anyway, as that's all MBR supports. If you need more than 2 TB, you'll need to backup, repartition with GPT, and restore from backups. Cheers, Freddie Typos due to smartphone keyboard. > ___ 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: trying to expand a zvol-backed bhyve guest which is UFS
On May 19, 2019, at 9:46 PM, tech-lists wrote: Hi, context is 12-stable, zfs, bhyve I have a zvol-backed bhyve guest. Its zvol size was initially 512GB It needed to be expanded to 4TB. That worked fine. The problem is the freebsd guest is UFS and I can't seem to make it see the new size. But zfs list -o size on the host shows that as far as zfs is concerned, it's 4TB On the guest, I've tried running growfs / but it says requested size is the same as the size it already is (508GB) gpart show on the guest has the following # gpart show =>63 4294967232 vtbd0 MBR (4.0T) 63 1 - free - (512B) 64 4294967216 1 freebsd [active] (2.0T) 4294967280 15 - free - (7.5K) => 0 4294967216 vtbd0s1 BSD (2.0T) 0 10653532161 freebsd-ufs (508G) 1065353216 83885442 freebsd-swap (4.0G) 1073741760 3221225456 - free - (1.5T) I'm not understanding the double output, or why growfs hasn't worked on the guest ufs. Can anyone help please? Given the above, the freebsd-ufs partition can't grow because there is a freebsd-swap partition between it and the free space you've added at the end of the volume. You'd need to delete the swap partition (or otherwise move it to the end of the partition on the volume) before you could successfully growfs the freebsd-ufs partition. Cheers, Paul. ___ 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"
trying to expand a zvol-backed bhyve guest which is UFS
Hi, context is 12-stable, zfs, bhyve I have a zvol-backed bhyve guest. Its zvol size was initially 512GB It needed to be expanded to 4TB. That worked fine. The problem is the freebsd guest is UFS and I can't seem to make it see the new size. But zfs list -o size on the host shows that as far as zfs is concerned, it's 4TB On the guest, I've tried running growfs / but it says requested size is the same as the size it already is (508GB) gpart show on the guest has the following # gpart show =>63 4294967232 vtbd0 MBR (4.0T) 63 1 - free - (512B) 64 4294967216 1 freebsd [active] (2.0T) 4294967280 15 - free - (7.5K) => 0 4294967216 vtbd0s1 BSD (2.0T) 0 10653532161 freebsd-ufs (508G) 1065353216 83885442 freebsd-swap (4.0G) 1073741760 3221225456 - free - (1.5T) I'm not understanding the double output, or why growfs hasn't worked on the guest ufs. Can anyone help please? thanks, -- J. signature.asc Description: PGP signature
Re: 11-STABLE system unbootable after update
On Sun, May 19, 2019 at 9:00 AM Scott Bennett wrote: > > Many, many thanks to the person who responded with the solution to > get past the > loader crash!! My system is now getting work done again, and the rest of > the new > problems can be dealt with on a running system. Out of curiosity, you mentioned in your previous email you created a new boot environment for this upgrade… since additional issues remain beyond the loader, have you considered rolling back to the known-good BE and attempting the entire process again (with another, separate BE) in a week or so? Especially since that would hopefully allow you to continue your other work without any additional issues or oddities to sort through in the meantime? -- Matt ___ 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"
System does not boot with today world
FreeBSD sting 12.0-STABLE FreeBSD 12.0-STABLE r346986 STING_VT amd64 The system does not boot with today world it fails to mount zfs with error 6 .Kernel old boots without problemssincerelyFilippo ___ 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-SA-19:03 source code patch
On Wed, May 15, 2019 at 9:55 PM Greg Balfour wrote: > After applying wpa-11.patch (and the rest of the recent patches) to my > 11.2 machine I'm > having build problems. Looks like a binder directory and associated files > did not get > created. Pilot error? > > # uname -a > FreeBSD freebsd.example.com 11.2-RELEASE FreeBSD 11.2-RELEASE #0: Thu > Jan 3 19:29:29 CST 2019 > r...@freebsd.example.com:/usr/obj/usr/src/sys/GENERIC > amd64 > > --- notify.o --- > cc -target x86_64-unknown-freebsd11.2 --sysroot=/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe > -I/usr/src/usr.sbin/wpa/wpa_supplicant -I/usr/src/contrib/wpa//hostapd > -I/usr/src/contrib/wpa//src -I/usr/src/contrib/wpa//src/common > -I/usr/src/contrib/wpa//src/crypto -I/usr/src/contrib/wpa//src/drivers > -I/usr/src/contrib/wpa//src/l2_packet -I/usr/src/contrib/wpa//src/utils > -I/usr/src/contrib/wpa//src/wps -DCONFIG_CTRL_IFACE > -DCONFIG_CTRL_IFACE_UNIX -DNEED_AP_MLME > -DTLS_DEFAULT_CIPHERS=\"DEFAULT:!EXP:!LOW\" -DCONFIG_BACKEND_FILE > -DCONFIG_DEBUG_SYSLOG -DCONFIG_DRIVER_BSD -DCONFIG_DRIVER_NDIS > -DCONFIG_DRIVER_WIRED -DCONFIG_GAS -DCONFIG_HS20 -DCONFIG_IEEE80211R > -DCONFIG_INTERWORKING -DCONFIG_PEERKEY -DCONFIG_PRIVSEP > -DCONFIG_SMARTCARD -DCONFIG_TERMINATE_ONLASTIF -DCONFIG_TLS=openssl > -DCONFIG_WPS -DCONFIG_WPS2 -DCONFIG_WPS_UPNP -DPKCS12_FUNCS -DEAP_GTC > -DEAP_LEAP -DEAP_MD5 -DEAP_MSCHAPv2 -DEAP_OTP -DEAP_PEAP -DEAP_PSK > -DEAP_TLS -DEAP_TTLS -DIEEE8021X_EAPOL -DCONFIG_SHA256 -DEAP_TLS_OPENSSL > -I/usr/src/usr.sbin/wpa/wpa_supplicant -I/usr/src/contrib/wpa//hostapd > -I/usr/src/contrib/wpa//src -I/usr/src/contrib/wpa//src/common > -I/usr/src/contrib/wpa//src/crypto -I/usr/src/contrib/wpa//src/drivers > -I/usr/src/contrib/wpa//src/l2_packet -I/usr/src/contrib/wpa//src/utils > -I/usr/src/contrib/wpa//src/wps -DCONFIG_CTRL_IFACE > -DCONFIG_CTRL_IFACE_UNIX -DNEED_AP_MLME > -DTLS_DEFAULT_CIPHERS=\"DEFAULT:!EXP:!LOW\" -g -MD -MF.depend.notify.o > -MTnotify.o -std=gnu99 -fstack-protector-strong-Qunused-arguments -c > /usr/src/contrib/wpa//wpa_supplicant/notify.c -o notify.o > /usr/src/contrib/wpa//wpa_supplicant/notify.c:16:10: fatal error: > 'binder/binder.h' file not found > #include "binder/binder.h" > ^ > 1 error generated. > *** [notify.o] Error code 1 > > make[5]: stopped in /usr/src/usr.sbin/wpa/wpa_supplicant > 1 error > What what it's worth, I finally figured out the patch had to be applied with: # cd /usr/src # patch -p0 < /path/to/patch ___ 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: 11-STABLE system unbootable after update
On Sat, 18 May 2019 08:02:20 -0500 Scott Bennett wrote: > I have been running 11.2-STABLE for a while at r345498. Last weekend it > crashed, >so I took the opportunity to install the most recent build I had lying around, >r347182. >I created a new boot environment and installed the r347182 kernel into it, >shut the >system down, and rebooted. The new kernel came up and appeared to be working >okay, so >I continued with the mergemaster -p -F, make installworld, and mergemaster -F, >then >shut it down again, and rebooted. It asked for the GELI key for the boot >pool, which >I then entered. The spinning slash cursor appeared and may have changed for >one frame >or so, and then I got a message beginning with "BTX" and followed by several >lines of >hexadecimal, and then it stopped. I tried it again just to be sure, and the >result was >exactly the same. > Does anyone know whether the PMBR boot block or the loader in the > freebsd-boot >partition changed between r345498 and r347182? I found no warning in >/usr/src/UPDATING ^ I wrote the revision down wrong in my notes. It was really r347183. >about installworld potentially leaving a wasted system, so I don't have a >clear idea >of what went wrong, much less whether I missed some instruction somewhere >about source >updates. If anyone can lend me a clue here, I would greatlyappreciate it. I >only had >one working machine, and now it is only working in a "rescue" mode by booting >from a >DVD. (Probably needless to say, but I will burn new DVDs with up-to-date >stuff as soon >as my system is working the way it is supposed to again.) > This motherboard is nearly 11 years old and does not boot from USB (in > spite of >the BIOS menus say), so at the moment I am logged into SDF by running a long >out-of-date >TrueOS installer DVD, which happens to be a pain to get to boot all the way, >but I've >figured how to make it do it rather than get stuck with a logo on the screen >that never >goes away. Unfortunately, it includes no software to burn a CD or DVD, so I >cannot >make a new bootable disk for the time being. I will check email much later >today or >this evening. So far I've received one reply, which was not copied to this list, yet the person responding suggested something to try and also adked that I post the result to the list. I would have done both anyway, but the respondent may have desired anonymity on the list, so I am not quoting the message I received. The suggestion was to wait about a second after entering the GELI passphrase and then hit the space bar on my keyboard. At the resulting prompt, I should enter the path given in the prompt, but with ".old" appended. I did that, and YES!!! It worked and proceeded until I had a boot menu. I opted for single-user mode and then responded to further requests for GELI passphrases until eventually I had a root shell. Being unable to reach the boot menu was a problem hadn't previously even crossed my mind. I certainly hope that doing updates from source in the future will not cause this same booby trap again. At that point I renamed /boot/zfsloader to /boot/zfsloader.bad.r347183 and /boot/zfsloader.old to /boot/zfsloader. I also added a hard link to the latter as /boot/zfsloader.good.r345498. All is still not well, however. In multi-user mode, startx turns the screen black and switches its power setting to standby. After that it remains unresponsive until I log in via a different vt and send SIGHUP to xorg. After a rather lengthy delay (30-60 seconds, at a guess) it returns to the login session on the console vt. I have now commented out the "kld_list="/boot/modules/radeonkms.ko" line in /etc/rc.conf.local in hopes that the next boot will get the scfb driver to take it instead of the radeonkms driver from graphics/drm-next-kmod. If someone knows, is this a case where rebuilding and reinstalling graphics/drm-next-kmod? If so, then I will do that, but I see that the Makefile still appears to use the same distribution file. Many, many thanks to the person who responded with the solution to get past the loader crash!! My system is now getting work done again, and the rest of the new problems can be dealt with on a running system. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 *
