Installation using NFS spams console

I have been building FreeBSD CURRENT every 2 weeks for years. I build on a fest PC and then use NFS exports of /usr/src and /usr/obj to update several other PC's. I received many 'Permission denied' messages as the kernel and world installs progressed. make[4]: warning:

Re: Beadm can't create snapshot

On 9/12/22 05:29, Ryan Moeller wrote: Here's the patch for the kernel and brief instructions: https://reviews.freebsd.org/P547 That worked. I was not familiar with patching a file using git. My experience has always used the 'patch' utility and a unified diff. I just made a backup of the

Re: Beadm can't create snapshot

On 8/17/22 10:35, Thomas Laus wrote: I attempted to create a ZFS snapshot after upgrading this morning and received this error After all of the discussion to compare and contrast beadm vs. bectl my read only bit is still set as of this morning 29-AUG-2022. # beadm create n257658 cannot

Non EFI boot issue

Another issue with the update today. This update went well on all of my PC's that use EFI but spews a lot of disturbing messages on my only laptop without an EFI BIOS: Attempted recovery for standard superblock: failed Attempt to find boot zone recovery data: failed It jumps to what is

Beadm can't create snapshot

I attempted to create a ZFS snapshot after upgrading this morning and received this error # beadm create n257443 cannot create 'zroot/ROOT/n257443': 'snapshots_changed' is readonly # My version info: 14.0-CURRENT FreeBSD 14.0-CURRENT #9 main-n257443-f7413197245: Wed Aug 17 08:15:27 EDT 2022

[FIXED] Re: main-n254654-d4e8207317c results in "no pools available to import"

On 4/11/22 11:17, Dennis Clarke wrote: Did the usual git pull origin main and buildworld/buildkernel but after installkernel the machine will not boot. The rev seems to be main-n254654-d4e8207317c. I can boot single user mode and get a command prompt but nothing past that. Is there

Re: main-n254654-d4e8207317c results in "no pools available to import"

On 4/18/22 21:43, Graham Perrin wrote: On 12/04/2022 23:35, Dennis Clarke wrote: … at least two examples in the wild. … Not the same symptom, but caught my eye: RC3 Guided ZFS on root with encryption unmountable Beyond that, I

Re: main-n254654-d4e8207317c results in "no pools available to import"

On 4/13/22 07:17, Thomas Laus wrote: I had an idea that maybe a GELI encrypted disk may have an issue.  Both my laptop and desktop have encrypted disks.  The gpart partitions have a .efi appended to the name that 'gpart list' shows.  Not everyone uses GELI and that may be our difference

Re: main-n254654-d4e8207317c results in "no pools available to import"

On 4/12/22 18:35, Dennis Clarke wrote: I will focus on the problem case I have and try to get better information. Somehow. I had an idea that maybe a GELI encrypted disk may have an issue. Both my laptop and desktop have encrypted disks. The gpart partitions have a .efi appended to the name

Re: main-n254654-d4e8207317c results in "no pools available to import"

On 4/12/22 08:29, Ronald Klop wrote: Are you guys both using NVME or EFI? Just wondering if the common problem is in ZFS or some other component. I just repeated this issue on the desktop computer that is used for my weekly builds that get distributed to the other PC's in the house. In

Re: main-n254654-d4e8207317c results in "no pools available to import"

On 4/11/22 14:18, Ronald Klop wrote: On 4/11/22 17:17, Dennis Clarke wrote: Did the usual git pull origin main and buildworld/buildkernel but after installkernel the machine will not boot. The rev seems to be main-n254654-d4e8207317c. I can boot single user mode and get a command prompt

Re: Kernel Panic main-n252492-ad15eeeaba3 - Solved

On 1/17/22 16:33, Thomas Laus wrote: I just updated today to main-n252492-ad15eeeaba3 from: main-n252313-ae13829ddce on 3 PC's. I tried bisecting the 87 changes involved between main-n252508-aac52f94ea5 to main-n252492-ad15eeeaba3 and started at the halfway point and worked forward. After

Kernel Panic main-n252492-ad15eeeaba3

I just updated today to main-n252492-ad15eeeaba3 from: main-n252313-ae13829ddce on 3 PC's. Two of them had the update go well but my Dell Inspiron 1545 had a panic after booting. This laptop doesn't have a scroll buffer and the entire panic message scrolls off the screen, so can't take a

Re: EFI boot partition overwritten: mount -t msdosfs (or mount_msdosfs(8))

On 7/18/21 2:21 PM, Graham Perrin wrote: > On 16/07/2021 18:35, Warner Losh wrote: >> # newfs_msdos -F 32 /dev/ada0p4 >> # mount -t msdos /dev/ada0p4 /boot/efi > > > Typo: msdosfs, not msdos. > > Alternatively, mount_msdosfs(8). > > Alternatively (I agree, even better), incorporate things such

Re: EFI boot partition overwritten

On 7/16/21 1:35 PM, Warner Losh wrote: > > There should be. Yes. Last time I went hunting for a place to shoe-horn it > in, I got distracted by something else. > > The instructions are relatively straight forward. I'm writing them here for > your benefit, and also in case someone wants to send

EFI boot partition overwritten

Group: This is an issue for more than just CURRENT. The 'usr/src/UPDATING' file has the instructions for updating the ZFS bootblocks but not the EFI partition. I recently upgraded a RELEASE-12.2 to RELEASE-13.0. The freebsd-update procedure did not upgrade the ZFS bootblocks. I forgot that

Re: drm-kmod kernel crash fatal trap 12

On 6/19/21 2:21 PM, Bakul Shah wrote: > > You may wish to see if Andriy Gapon's method (LOCAL_MODULES_DIR, > LOCAL_MODULES) > works better for you. > > I trust Makefile* to do the right thing with META_MODE and CCACHE (and if they > don't, it is a bug that would need to be fixed) so I

Re: drm-kmod kernel crash fatal trap 12

On 6/10/21 11:13 AM, Bakul Shah wrote: > This is what I did: > > git clone https://github.com/freebsd/drm-kmod > ln -s $PWD/drm-kmod /usr/local/sys/modules > > Now it gets compiled every time you do make buildkernel. > If things break you can do a git pull in the drm-kmod dir > and rebuild. >

Re: drm-kmod kernel crash fatal trap 12

Bakul Shah [ba...@iitbombay.org] wrote: > > This is what I did: > > git clone https://github.com/freebsd/drm-kmod > ln -s $PWD/drm-kmod /usr/local/sys/modules > > Now it gets compiled every time you do make buildkernel. > If things break you can do a git pull in the drm-kmod dir > and rebuild.

Re: drm-kmod kernel crash fatal trap 12

Hans Petter Selasky [h...@selasky.org] wrote: > > When you use -current, you need to compile this pkg from the latest ports. > I'm not sure if that happens automatically when you install the binary > package. > I just built drm-current-kmod as a port and things work. Building a kernel in the

Re: drm-kmod kernel crash fatal trap 12

Hans Petter Selasky [h...@selasky.org] wrote: > > Make sure you also re-build the drm-kmod module. > The drm-kmod module is the latest from the pkg server. It all worked this past Monday after the recent drm-kmod update. Things are good at n247230. I cleaned my source today and checked out

drm-kmod kernel crash fatal trap 12

I updated my system this morning to main-n247260-dc318a4ffab June 9 2012 and the first boot after the kernel was loaded I received: 'fatal trap 12' fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x20:0x82fc3d1b stack pointer =

Re: Problem with X Server when updating to 38bfc6dee33

On 2/3/21 12:12 PM, Niclas Zeising wrote: > > I think also xf86-input-synaptics was affeced by the same issue. > In any case, kern.evdev.rcpt_mask should not need any changes on FreeBSD > 12.1 or later, the defaults have been updated there.  Unless you are > using a serial mouse. > > Can you

Re: Problem with X Server when updating to 38bfc6dee33

On 2/3/21 8:07 AM, Michael Gmelin wrote: > > There was a problem with xorg-server which made it build without udev > on 14. > > Try reinstalling xorg-server from ports (something like: portsnap > fetch extract; cd /usr/ports/x11-servers/xorg-server && make clean > reinstall clean) > That also

Re: Problem with X Server when updating to 38bfc6dee33

On 2/2/21 8:16 AM, David Wolfskill wrote: > You might want to see if this ports/UPDATING entry: > > 20200320: > AFFECTS: users of x11/libxkbcommon > AUTHOR: zeis...@freebsd.org > > The libxkbcommon library (x11/libxkbcommon), used to handle keyboards > in some applications, most notably

Problem with X Server when updating to 38bfc6dee33

I updated from c3e75b6c1 to 38bfc6dee33 today and my keyboard and mouse no longer work in X. Since my system went from 13.0-CURRENT to 14.0-CURRENT, I performed a 'pkg bootstrap -f' because of the ABI change. I also performed a fresh git checkout of main after I first noticed the issue. I built

Re: DRM problem installing kernel on main-c561-gc3e75b6c1

On 1/19/21 4:18 PM, Emmanuel Vadot wrote: > > drm-current-kmod will also install its sources in /usr/local/sys/ and > this will get built with buildkernel. The problem is that if the > package is old (and it is right now) you might have sources that either > don't compile or don't work

DRM problem installing kernel on main-c561-gc3e75b6c1

I perform a CURRENT build weekly on a more powerful build machine and then export /usr/src and /usr/obj via NFS to other slower PC's. The 'installkernel' phase failed with 'linuxkpi_gplv2.ko' not found. It looks like this file is not installed before the rest of the 'drm-current-kmod' files.

What is the zstreamdump command in OpenZFS?

Group: Whenever I perform a major upgrade to any of my ZFS pools, I make a habit of sending the most recent snapshot to a file and then to a DLT tape or DVD. I run the zstreamdump utility on the file and record the checksum. I also run zstreamdump on the archive media and compare checksums.

Re: Geli encryption issue on r362779

> On 2020-07-10 03:56, Toomas Soome wrote: >> >> ok, then next one is r363042. By nature it is an safeguard against read >> past disk end. >> >> If that does not do, we really need to insert checkpoints in code and >> see where exactly this reset will happen. Also note I >> have

Re: Geli encryption issue on r362779

On 2020-07-10 03:56, Toomas Soome wrote: > > ok, then next one is�r363042. By nature it is an safeguard against read > past disk end. > > If that does not do, we really need to insert checkpoints in code and > see where exactly this reset will happen. Also note I >

Re: Geli encryption issue on r362779

On 2020-07-07 08:26, Toomas Soome wrote: > Hi! > > I believe, 362989 should fix your issue. Please do let me know. > I updated to r362989. I built world and kernel after clearing out /usr/obj and this problem still exists. It works fine on my i5 desktop, but still has a problem reading my Geli

Re: Geli encryption issue on r362779

On 2020-06-30 11:31, Toomas Soome wrote: > > hi! > > 362431: https://svnweb.freebsd.org/base?view=revision=362431 > > The majority of the code is now shared with loader (libsa/libi386), > however, we do have some bits in zfsboot.c, which is common part of > gptzfsboot and zfsboot. > That looks

Geli encryption issue on r362779

This is a repost to this list because of my submission email address did not match the one on record. == List: I just upgraded a couple of computers from r362220 to r362779 and have booting issue on my Core2 duo laptop with the passphrase unlocking the encrypted

Current r355939 + drm-current-kmod 4.16g20191217 compiles and runs

After about one week of problems, I was able to successfully compile and start DRM on 3 computers. My hardware Atom D510, Intel i5 Skylake and an Intel Core2-Duo laptop. I had to rm -rf /usr/obj/* on all of them however, to get a successful compile. Thanks Tom -- Public Keys: PGP KeyID =

Brickyard 4439 Runaway Trim from 6 Nov 2019

Claude: Another video from Juan Brown about an issue with an flight from Atlanta to New York. It is another 'fly by wire' type of aircraft and Juan goes into great detail on the hardware and software issue. Not quite a 737-Max issue, but similar. https://www.youtube.com/watch?v=vV_o9kTRXUY

Re: DRM-current-kmod is still a problem at r353339

On 2019-10-10 13:44, Mateusz Guzik wrote: > Probably whitespace issues from copypasting. I used dpaste since > people.freebsd.org was down. > > It's up, so: > https://people.freebsd.org/~mjg/pmap-fict3.diff > That patch worked for me also. The patch applied clean when I used 'wget' to retrieve

Re: DRM-current-kmod is still a problem at r353339

On 2019-10-10 12:21, Mateusz Guzik wrote: > Try this: > > http://dpaste.com/0P2MXF6 > > if it still fails, provide the panic info + the first debug line(the > one with "pv_table"). > This patch did not apply cleanly to my source tree checked out today. My pmap.c version is r353311. I saved the

DRM-current-kmod is still a problem at r353339

List: I am still getting kernel panics on my laptop after the recent changes made to /sys/amd64/amd64/pmap.c. The updated pmap.c works on my Skylake build machine but panics on my laptop. I always build on the faster computer and perform a installkernel and installworld from a nfs share. The

Re: Booting anything after r352057 kills console - additional info

On 2019-09-25 17:51, Thomas Laus wrote: > I was able to mount my zfs filesystem r+w and added the rc_debug="YES" > to my rc.conf. The additional debug messages were written to the beadm > boot environment /var/log/messages. Since the computer locked up, I was > unable to r

Re: Booting anything after r352057 kills console

On 2019-09-24 15:09, Ian Lepore wrote: > > On my system, a whole lotta stuff happens between ntpd and syscons (the > thing that configures blanktime). Try setting rc_debug=YES in rc.conf, > that should write more info to syslog about what's happening between > ntpd and the lockup point. > Ian:

Re: Booting anything after r352057 kills console

> Ian Lepore [i...@freebsd.org] wrote: > > > > On my system, a whole lotta stuff happens between ntpd and syscons (the > > thing that configures blanktime). Try setting rc_debug=YES in rc.conf, > > that should write more info to syslog about what's happening between > > ntpd and the lockup

Re: Booting anything after r352057 kills console

Ian Lepore [i...@freebsd.org] wrote: > > On my system, a whole lotta stuff happens between ntpd and syscons (the > thing that configures blanktime). Try setting rc_debug=YES in rc.conf, > that should write more info to syslog about what's happening between > ntpd and the lockup point. > The

Re: Booting anything after r352057 kills console

On 2019-09-24 11:58, Pete Wright wrote: > > darn, and they didn't give you any additional information in the > messages buffer, or generate a core file? > There were no messages in the syslog and no other log that showed anything after killing the console. On my working BEADM boot environment,

Re: Booting anything after r352057 kills console

Pete Wright [p...@nomadlogic.org] wrote: > > I remember having similar issues a while ago when we were first hacking on > drm, one thing to try is updating /boot/loader.conf with the following: > debug.debugger_on_panic=0 > dev.drm.skip_ddb="1" > dev.drm.drm_debug_persist="1" > > these are

Re: Booting anything after r352057 kills console

Poul-Henning Kamp [p...@phk.freebsd.dk] wrote: > > In message <11db909b-57ee-b452-6a17-90ec2765c...@acm.org>, Thomas Laus writes: > > >Where do I go from here? The computer is an Intel i5 Skylake with > >onboard graphics. > > Based on personal experi

Booting anything after r352057 kills console

I updated my source today and when the computer was booted, the screen turned black at the point that the drm related kernel modules would normally load. Suspecting a drm issue, I commented out the rc.conf line that loads those kernel modules. This did not fix my problem. My last good kernel

Re: Problem with USB after r349133

Nick Wolff [darkfiber...@gmail.com] wrote: > Thomas/HPS, > > I did manage to get a boot with hw.usb.no_boot_wait=1 set in loader.conf. > So if any debugging information off a running system would be helpful let > me know. > > Thanks, > Nick: That was the same workaround that I used. I had not

Re: Problem with USB after r349133

Nick Wolff [darkfiber...@gmail.com] wrote: > Sorry for email spam but I was wrong. Just gets stuck now during reproping > a pci device after init happens(this is actually a trueos build which is > why you see openrc). That device it's getting stuck on is "Sky Lake-E CBDMA > Registers" which

Re: Someone broke USB

On 2019-07-06 16:50, Hans Petter Selasky wrote: > > Are you able to bisect the commit introducing the bad behaviour? > I built and booted r349160. My 'boot mount waiting for USBUS7 -> USBUS0 issue went away but the startup halted at the 'mounting late filesystems' step of rc.conf. I had the USB

Re: Problem with USB after r349133

On 2019-07-06 10:17, Graham Perrin wrote: > > I had the almost same (different bus numbers), just once, after updating > -CURRENT from r349099 to r349762. > > The subsequent boot of r349762 was free from the symptom. > > HP EliteBook 8570p, docked, with a Kensington keyboard and Logitech >

Re: Problem with USB after r349133

On 2019-07-05 18:05, Hans Petter Selasky wrote: > > There has been very few USB changes, except for ACPI USB support in: > > https://svnweb.freebsd.org/changeset/base/349161 > https://svnweb.freebsd.org/changeset/base/349251 > It looks like I will need to build a few kernels to see what changes

Problem with USB after r349133

I upgraded to CURRENT r349575 this week and my Dell Inspiron laptop stops processing the rc.conf with this message that repeats until I perform a hard power button reset, ctl-alt-del has no effect: Root mount waiting for USBUS7 USBUS6 USBUS0. I booted my kernel.old and everything is fine at

Re: Loading DRM kills computer

Farias Martinez [aaronfar...@att.net] wrote: > I’m using current on both of my laptop one with the module i915kms > and the other laptop uses radeonkms both work fine without a problem > on my laptop. Which module are you having issues with. > The i915kms on both. Tom -- Public Keys: PGP

Loading DRM kills computer

List I have a graphics issue since about CURRENT r346025. Kernel loading DRM kills 2 different computers. My i5 Skylake works, but my Atom D510 desktop and laptop Core2-duo both have this common issue. When the DRM kernel module is loaded, I get a 'black screen' on the console and am not able

Got the same error from gptzfsboot this morning

Toomas: My laptop has been booting up flawlessly since I installed the gptzfsboot file that you sent. It also successfully rebooted from a cold start this morning but I received the same error message just a few minutes ago when powering up again. gptzfsboot: error 1 LBA 18446744072709551608

Re: Question about 'gptzfsboot'

On 2019-04-29 15:24, Ian Lepore wrote: > > I can't say anything at all about drm or other video driver issues, I'm > just not knowledgeable about that stuff at all. > > The only thing I was getting at was that the changes I made in r346675 > might make this error stop happening: > >

Re: Question about 'gptzfsboot'

On 2019-04-29 14:58, Toomas Soome wrote: > > It means you have different issues - one is about gptzfsboot causing boot > problems and apparently it got fixed when you did update the bootcode (the > boot partition is global). But also you got bitten by DRM update, and since > you had old BE

Re: Question about 'gptzfsboot'

On 2019-04-29 14:27, Thomas Laus wrote: > It was more than a broken console. All of the other 2 computers that I > upgraded to r346885 were essentially 'dead'. I could not even remotely > login to them via ssh. All of them required a hard power button reset > to get into single user

Re: Question about 'gptzfsboot'

On 2019-04-29 11:14, Ian Lepore wrote: > > I'm fighting my own video driver troubles (seems like a lot of that > going around lately); on an upgrade of a machine from 11-stable to 12- > stable I lost my console. > > But, a broken kernel and/or userland shouldn't affect your ability to > use the

Re: Question about 'gptzfsboot'

On 2019-04-29 10:33, Thomas Laus wrote: > Updating to r346885 turned out to be a disaster! There were changes to > DRM between FreeBSD 13.0-CURRENT r346544 and r346885. The desktop that > I use for a build machine because it is much faster than any of my other > PC's installed kern

Re: Question about 'gptzfsboot'

> On 2019-04-28 22:27, Ian Lepore wrote: >> >> If you're using gptzfsboot, I guess you're using zfs? I just fixed a >> problem with probing disks for zfs volumes a few days ago (r346675). >> There is even some small chance it fixes this problem, because one of >> the things I noticed was that in

Re: Question about 'gptzfsboot'

On 2019-04-28 22:27, Ian Lepore wrote: > > If you're using gptzfsboot, I guess you're using zfs? I just fixed a > problem with probing disks for zfs volumes a few days ago (r346675). > There is even some small chance it fixes this problem, because one of > the things I noticed was that in one

Re: Question about 'gptzfsboot'

On 2019-04-28 08:07, Ronald Klop wrote: > > Is this the same as this? > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144234 > The messages are similar. The boot process will normally proceed on the second or third attempt. On some days, I don't see this message appear and my laptops boot

Re: Question about 'gptzfsboot'

Toomas Soome [tso...@me.com] wrote: > > > I always update the bootcode with gpart each time when updating my system. > > > > Oh right, this from gptzfsboot… ok, I guess I should do something > I have been planning all along… Do you need some sort of quick workaround? > No quick workaround

Re: Question about 'gptzfsboot'

Toomas Soome [tso...@me.com] wrote: > > The key is about LBA in first message. Make sure you have latest > boot code installed with gpart. > I always update the bootcode with gpart each time when updating my system. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF

Question about 'gptzfsboot'

List: I have been having gptzfsboot issues with my two laptops since 12.0 was still CURRENT. I receive 'error 1' on the first boot most days. gptzfsboot: error 1 LBA 18446744072709551608 gptzfsboot: error 1 LBA 1 gptzfsboot: No ZFS pools located, can't boot Most of the time the boot process is

FIXED - Head won't build tool-chain at r339586

On 10/22/18 10:49 AM, Thomas Laus wrote: > I have been building HEAD for the past several years about every 2 > weeks. I updated my base source today from r339234 to r339586 and the > buildworld stops because a missing libarchive.so.7 dependency. It is > looking for libcrypto.so

Head won't build tool-chain at r339586

Group: I have been building HEAD for the past several years about every 2 weeks. I updated my base source today from r339234 to r339586 and the buildworld stops because a missing libarchive.so.7 dependency. It is looking for libcrypto.so.9 which has not been built at this part of the toolchain

Re: Current @ r335314 not bootable with Geli and ZFS

On 06/19/18 14:22, Thomas Laus wrote: > On 06/19/18 12:09, Allan Jude wrote: >> >> We tested all of the changes with the setup in tools/boot/rootgen.sh, it >> will be interesting to figure out what went wrong with your setup, and >> add it as a test case to

Re: Current @ r335314 not bootable with Geli and ZFS

On 06/19/18 12:09, Allan Jude wrote: > > We tested all of the changes with the setup in tools/boot/rootgen.sh, it > will be interesting to figure out what went wrong with your setup, and > add it as a test case to prevent this in the future. > > The recent changes are: > > r335245 (reading the

Current @ r335314 not bootable with Geli and ZFS

Something changed in /boot/gptzfsboot between r334610 and r335314. I built current this morning and my system is un-bootable. I am using redundant ZFS disks and only copied the updated /boot/gptzfsboot file to my ada0 drive. I was able to boot the ada1 drive that still had the gptzfsboot file

Re: GPTZFSBOOT in Current r326622 has problems - FIXED

On 12/15/17 18:37, Warner Losh wrote: > > I believe that these issues have been corrected in r326888. My > refactoring to make it easier to bring in the lua boot loader in r326593 > (after breaking the build in r326584 accidentally) uncovered some latent > subtle ordering issues. This cause

Re: GPTZFSBOOT in Current r326622 has problems

Toomas Soome [tso...@me.com] wrote: > > > With BIOS boot you can try to press key (space or anything else except enter) > - if boot1 is good, you will get boot: prompt. > BTX fails a long time before boot1 is read. I don't even get a prompt for my Geli password. Tom -- Public Keys: PGP

Re: GPTZFSBOOT in Current r326622 has problems

Warner Losh [i...@bsdimp.com] wrote: > OK. I don't recall seeing a screen shot of the entire boot. Can you send > that too (privately if you like) so I know exactly what's failing? Is it > gptzfsboot loading /boot/loader? Is it early in /boot/laoder or > It is failing with a hex dump with a

Re: GPTZFSBOOT in Current r326622 has problems

On 12/08/17 22:06, Warner Losh wrote: > Clean build? > Here is the contents of my loader.conf: loader_logo="beastie" #Desired logo:orbbw, orb, fbsdbw, beastiebw, beastie, none aesni_load="YES" geom_eli_load="YES" kern.geom.label.disk_ident.enable="0" kern.geom.label.gptid.enable="0"

Re: GPTZFSBOOT in Current r326622 has problems

On 12/08/17 22:06, Warner Losh wrote: > > Clean build? > It was a clean build. I performed a rm -rf /usr/obj/* before starting the buildworld after cvs updating to r326720. A couple of notes on my hardware: I am not using UEFI and my CPU is an early Intel i5 Skylake that has the Silicon Debug

Re: GPTZFSBOOT in Current r326622 has problems

Warner Losh [i...@bsdimp.com] wrote: > Looks like -DEFI_ZFS_BOOT was dropped from boot1.c in r326589. I've fixed > it in r326714. > Warren: I just completed a buildworld on r326720 and it failed to boot again with a hex dump and BTX failure. I can take a photograph and post it somewhere of the

Re: GPTZFSBOOT in Current r326622 has problems

On 12/06/17 19:38, Warner Losh wrote: > > OK. Still a fair number of changes, including changes to geli to fix > warnings... > > 326585-326594 is a flurry of changes. Then another in the 326609-326610 > range. There's one other trivial one. I'd wager that if '500 works, the > breakage will be

Re: GPTZFSBOOT in Current r326622 has problems

> Warner Losh [i...@bsdimp.com] wrote: > > > > You can just build the boot blocks at each step if you'd like to save > > > > some time on the binary search. > > > > > > > > cd stand > > > > make cleandir obj depend > > > > make -j XX > > > > sudo -E make install > > > > > > > > OK. Still a fair

Re: GPTZFSBOOT in Current r326622 has problems

Warner Losh [i...@bsdimp.com] wrote: > > > You can just build the boot blocks at each step if you'd like to save > > > some time on the binary search. > > > > > > cd stand > > > make cleandir obj depend > > > make -j XX > > > sudo -E make install > > > > > OK. Still a fair number of changes,

Re: GPTZFSBOOT in Current r326622 has problems

Warner Losh [i...@bsdimp.com] wrote: > You can just build the boot blocks at each step if you'd like to save some > time on the binary search. > > cd stand > make cleandir obj depend > make -j XX > sudo -E make install > Warren: I built and loaded r326500 successfully. It looks like the problem

Re: GPTZFSBOOT in Current r326622 has problems

Warner Losh [i...@bsdimp.com] wrote: > > You can just build the boot blocks at each step if you'd like to save some > time on the binary search. > > cd stand > make cleandir obj depend > make -j XX > sudo -E make install > > should suffice. There's no compiler dependency that I'm aware of. > I

Re: GPTZFSBOOT in Current r326622 has problems

Warner Losh [i...@bsdimp.com] wrote: > I've been *VERY* busy between then and now cleaning up the boot loader > "accumulated technical debt". Alas, sounds like I've broken something. So I > think it's a binary search: I'd start with 326370 as the pivot and 326500 / > 326250 as the next steps if it

Re: GPTZFSBOOT in Current r326622 has problems

Warner Losh [i...@bsdimp.com] wrote: > I've been *VERY* busy between then and now cleaning up the boot loader > "accumulated technical debt". Alas, sounds like I've broken something. So I > think it's a binary search: I'd start with 326370 as the pivot and 326500 / > 326250 as the next steps if it

Re: GPTZFSBOOT in Current r326622 has problems

Warner Losh [i...@bsdimp.com] wrote: > > Any chance you can bisect when this happened? I think I'll need more > details to see what happened. What was your old loader that world based on? > My last good gptzfsboot was r326070. I had not built anything since then until this morning when I built

GPTZFSBOOT in Current r326622 has problems

Group: I updated my amd64 computer today to r326622 and copied the /boot/gptzfsboot file to each of my ZFS hard drives p1 partition. The BTX loader stopped and could not load. This rendered my system 'un-bootable'. I copied this file from an earlier live filesystem CD, which restored my

Re: Mergemaster won't run on NFS mount

Rick Macklem [rmack...@uoguelph.ca] wrote: > Make sure mountd is running with the "-S" option on the nfs server. If not, > any mount operation done on the NFS server will result in EACCES failures > while /etc/exports is being reloaded. > (If it is running with "-S" I don't know why it would

Re: Mergemaster won't run on NFS mount

Cy Schubert [cy.schub...@komquats.com] wrote: > I used to buildworld/installeworld using NFS shares at one time. Testing it > again this morning revealed still no issues. I used a ro src and rw obj > during my test. > The NFS server computer that is being used is running ZFS for the /usr/src

Mergemaster won't run on NFS mount

I have been updating FreeBSD for years on my fastest computer and then NFS mounting /usr/src and /usr/obj to share with other PC's. I just updated FreeBSD-CURRENT to 326070 and was able to install the kernel and world. When I attempted to run mergemaster, I received the following error message:

Re: Loader.conf problem

On 11/21/17 13:04, Warner Losh wrote: > > I think I see the problem... There's no LOADER_SUPPORT_GELI in the > gptzfsboot built. Let me fix that... Seems to be caused by having > HAVE_GPT instead of HAVE_GELI r326069 should get this working again. > Can you confirm this independently. > >

Re: Loader.conf problem

On 11/21/17 12:38, Andriy Gapon wrote: > On 21/11/2017 14:48, Thomas Laus wrote: >> I had boot success when copying gptzfsboot file from my laptop that is >> running r325474. The problem CURRENT version running on my desktop is >> r326012. > > could you please compar

Re: Loader.conf problem

On 11/20/17 18:46, Warner Losh wrote: > > > On Mon, Nov 20, 2017 at 4:31 PM, Thomas Laus <lau...@acm.org > <mailto:lau...@acm.org>> wrote: > > Warner Losh [i...@bsdimp.com <mailto:i...@bsdimp.com>] wrote: > > > > Can you revert thi

Re: Loader.conf problem

Warner Losh [i...@bsdimp.com] wrote: > > Can you revert this part of the change? Go back to a known-working version > of those files? Let me know if that fixes the problem? Bonus points for > bisecting which one of the few dozen commits I did that caused this > regression... > > I don't have a

Re: Loader.conf problem

Warner Losh [i...@bsdimp.com] wrote: > On Mon, Nov 20, 2017 at 1:30 PM, Thomas Laus <lau...@acm.org> wrote: > > > I recently upgraded my FreeBSD-Current system today and did not fully > > understand the impact of changes to loader.conf. My system has a Geli > > en

Loader.conf problem

I recently upgraded my FreeBSD-Current system today and did not fully understand the impact of changes to loader.conf. My system has a Geli encrypted ZFS pool. In the past whenever I screwed up, I was able to use 'Beadm' into boot the most recent good kernel or enter a shell to reread the

Re: Encrypted Swap Problem with 12.0-CURRENT r324427

On 10/10/17 17:25, Conrad Meyer wrote: > Thomas, > > Please try r32. Based on your panic message, "panic: freeing > invalid range," it may be the same general swap issue which r32 > aimed to address. > Building and installing 12.0-CURRENT r324508 fixed my problem. I was able to reboot

Re: Encrypted Swap Problem with 12.0-CURRENT r324427

Allan Jude [allanj...@freebsd.org] wrote: > > Before the ddb> prompt there should be a message explaining what has > gone wrong to make it drops into the debugger. If it has scrolled off > the top of the screen, press scroll-lock and then you can use the arrow > keys to navigate back up into the

Encrypted Swap Problem with 12.0-CURRENT r324427

I have been having some boot issues after upgrading to r324427 this week. It gets to the step of accessing my Geli encrypted swap partition and then drops to the ddb> prompt. Sometimes it works but mostly it does not. Booting with r323984 is flawless. Has anything been changed between these 2

Another INO64 Disaster

I did not following the upgrade instructions to the letter and 'blew up' my FreeBSD laptop. Having made a recent backup of all of my important files, I decided that performing a reinstall would be easier than repairing my system. I downloaded the r318945 snapshot and performed a clean install on

  1   2   >