Solved Can't boot zroot after upgrading 10.0 to 10.4

mariourk

Well-Known Member

Thanks: 5
Messages: 261

#1
I ran into a weird problem, when updating FreeBSD-10.0 to 10.4. Iran the usual command

freebsd-update -r 10.4-RELEASE upgrade

This started the usual upgrade process, all the way to the point where I have to reboot and run freebsd-update install again. So I did. I waited a while, until I could SSH back into the system and ran freebsd-update install again. This resulted in a ton of segmentation errors. The upgrade failed and no base command (rm, ls, cp, etc) worked anymore.

I decided to reboot the system again, only this time not remote. I noticed this error during boot

Code:
gtpzfsboot: error 1 lba 32
gtpzfsboot: error 1 lba 1

Then it tried to boot, but apparently it can't boot to the zfs partition. Instead it tries to boot something else (I forget. Maybe /boot/kernel?)

When I boot from a FreeBSD livecd and try to import zroot, it immediately throws errors on the screen about faulty binaries.

As far as I can tell, the base install is screwed. But I have no idea what went wrong. Maybe someone has an idea? I rather prevent this from ever happening again.

And if someone thinks that this mess can still be recovered, I'm all ears.

Thanks!
 

SirDice

Administrator
Staff member
Administrator
Moderator

Thanks: 6,237
Messages: 27,228

#2
When I boot from a FreeBSD livecd and try to import zroot, it immediately throws errors on the screen about faulty binaries.
Make sure you use a 10.4-RELEASE based live CD. And when you import the pool, make sure you set altroot correctly or else you may be mounting the pool on top of the LiveCD.
 
OP
OP
mariourk

mariourk

Well-Known Member

Thanks: 5
Messages: 261

#3
I'm using a FreeBSD-11.1 LiveCD. I'm not sure if that makes a huge difference.

I figured out the altroot setting by now. And I'm actually able to mount the zpool to /mnt. As far as I can see, my data is save. I should be able to backup it all to another location. But the base-system seems to be completely screwed. Most of he commands don't work, starting with /bin/sh.

I actually have given up on this install already. Even when I would be able to fix it, I just wouldn't trust it anymore. So, tomorrow I'm planning to do a new install, on new drives. At least it gives me a chance to start fresh, do things a little different and be up-to-date with the latest FreeBSD release. And an incentive to look into sysutils/beadm.

But I still want to understand what went wrong, how this even could happen en how to prevent it from ever happening again.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Thanks: 6,237
Messages: 27,228

#4
I'm using a FreeBSD-11.1 LiveCD. I'm not sure if that makes a huge difference.
As weird as it may seem, 10.4 is actually newer than 11.1. But there are also a few other differences between 10.x and 11.x. So for best results I would stick to the same version you're working on.

I figured out the altroot setting by now. And I'm actually able to mount the zpool to /mnt. As far as I can see, my data is safe. I should be able to backup it all to another location.
Ok, that's the important part.

But the base-system seems to be completely screwed. Most of he commands don't work, starting with /bin/sh.
It's a bit tricky to do but in /usr/freebsd-dist on the installation media you'll find a bunch of tgz files. These are the archives that are "installed" during an installation. You could try unpacking them and overwriting the broken base install. That's the same thing the 'installer' would do. Hopefully that will be enough to get the machine booting normally again.
 
OP
OP
mariourk

mariourk

Well-Known Member

Thanks: 5
Messages: 261

#6
Thanks! I'll try that first thing in the morning. Any advice on how to extract those tgz-files? I've never done those manually before.

And what about the gptzfsboot errors? Will those be fixed that way? What do they even mean?
 

chrbr

Aspiring Daemon

Thanks: 229
Messages: 634

#8
Any advice on how to extract those tgz-files?
They can be extracted using tar(1). The normal extension of a tar archive is tar. If the archive is compressed the extension is usually chosen as tgz. With tar -tzf SomeFile.tgz you can list its content. With tar -xzf SomeFile.tgz it is extracted to the current directory. There are options to extract the archive to other directories. Please check tar(1) for details.
EDIT: Typo in 2nd command fixed.
 

linux->bsd

Active Member

Thanks: 35
Messages: 110

#9
They can be extracted using tar(1). The normal extension of a tar archive is tar. If the archive is compressed the extension is usually chosen as tgz. With tar -tzf SomeFile.tgz you can list its content. With tar -tzf SomeFile.tgz it is extracted to the current directory. There are options to extract the archive to other directories. Please check tar(1) for details.
Your second command has a typo: it should be tar -xzf SomeFile.tgz to extract to the current directory.

Anyway, I wanted to point out you don't need the z flag (or the hyphen). tar xf SomeFile.tgz will do just fine. tar() is able to determine if it's compressed or not, and which type of compression was used.

Also, it's probably a good idea to use tar --unlink -xpf SomeFile.tgz as the flags when extracting the distribution files into /.
 
OP
OP
mariourk

mariourk

Well-Known Member

Thanks: 5
Messages: 261

#10
I managed to mount zroot and extract the tgz files. It seems this actually worked! I can now chroot into my environment without any erors whatsoever. And all the commands seem to work normal again.

I tried to reboot and this got one step further, because /bin/sh was back to normal again. However, it now spits out a bunch of errors when it tries to mount and boot from zroot. Also, I still get the gptzfsboot errors during boot.

Code:
Trying to mount root from zfs:zroot/ROOT/default
Mounting from zfs:root/ROOT/default failed with error 2: unknown filesystem
I tried gptzfsboot_hp_debug from Allan Jude ( comment 37 ), but no luck.
 

ShelLuser

Son of Beastie

Thanks: 1,389
Messages: 2,959

#11
Unknown filesystem implies that your kernel doesn't know about ZFS. Under normal circumstances you can force the load of the kernel modules manually. Once you booted into the boot menu hit escape so that you'll reach the ok> prompt. From there start by using lsdev to verify that it recognizes your ZFS environment. Is so then issue these commands:
  • unload
  • load /boot/kernel/kernel
  • load /boot/kernel/opensolaris.ko
  • load /boot/kernel/zfs.ko
That should prime the system with enough support to boot from ZFS.

Optionally also use: set vfs.root.mountfrom="zfs:zroot/ROOT/default", followed by boot.
 
OP
OP
mariourk

mariourk

Well-Known Member

Thanks: 5
Messages: 261

#13
Manually unloading and reloading the modules fixed the boot problem. After that I restored a backup of /etc and edited /boot/loader.conf. After rebooting again, everything seems to work again!

There are still some errors during boot, but those are minor. I shouldb e able to iron those out. But everything important seems to be ok and back into working condition, which is great!

I tried installing gptzfsboot from FreeBSD-12, but I still get those errors during boot. But dispite those errors, the system at least is back to life

Thanks for helping me out so far :)
 
Top