Upgrading from BSD12.2 to BSD13.2

M

magentron

I have followed the instructions on how to do a major upgrade, what I do not understand is when it comes to the point in the upgrade process where files have been downloaded and merged, the next step when it says files will be deleted, is this done automatically or is a manual intervention required to delete files? all I get in the terminal is a highlighted <END> and the system just stays at that point and fails to complete the upgrade, I have attempted this on an installed BSD on hardware, and also in a virtual machine, in both cases the process stops at the deleting files and highlighted <END> in the terminal, question what to do next? I have had this running for over a day and the process is just stuck at this point. Note this is the same as doing a minor update from say 13.1 to 13.2 there is something I am missing in this upgrade process.
 
It's showing those files with less(1), the q quits less(1), not the update process.

Code: 
       q or Q or :q or :Q or ZZ
	      Exits less.
 
putting things into context:

After applying patches and fetching files, then displaying the message showing that a file(s) could not be merged, pressing enter key, the vi editor opens up, displaying the following lines.
Code: 
<<<<<<<<<Current version
video:*:44:username
==================
video:*:44:
new time:*:47:
idle time:*:48:
>>>>>>>>> 13.2-RELEASE
after deleting lines between the <<<< and >>>> (including the <<< and >>> lines and then writing the changes and quitting vi, a message then asks is this reasonable (yes/no)? hitting yes then the screen shows lines of files that will be deleted. Paging down using the space bar to the end of the file list is displayed (END) and highlighted. What is not clear, should there be some intervention or if this process is automated, which was the basis of my question.

I then followed covacat suggestion of hitting the q button this solved the matter and the process completed
NOTE: It would appear that this step is missing from the handbook and what to delete in the vi editor!

However, after the first reboot, the upgrade failed as it hung just after loading the kernel with the problem of framebuffer issue as reported on other posts on the forum. Even switching to the old kernel option on the boot menu still caused the boot to fail at the entropy and framebuffer stage of booting.
It would seem that between older versions and currently supported new versions, there have been some changes concerning support for CPUs and probably EFI in the code base. This means some older hardware will not be upgradable to newer versions of BSD, even though the CPUs are 64-bit.

Therefore I could not complete the upgrade from an older BSD version to a supported new version 13.2 or higher, as it would appear this could be a hardware compatibility issue.
 
<<<<<<<<<Current version video:*:44:username ================== video:*:44: new time:*:47: idle time:*:48: >>>>>>>>> 13.2-RELEASE
This is standard "diff" format, indicating what's different and "there's a conflict". The first 3 lines (between the <<<<<<<<< and ==================) are the file looks right now, lines between ================== and >>>>>>>>> are from the "version to be merged".

You need to resolve the conflicts, which are basically the line for "video". I think the end result for you should have been:

video:*:44:username new time:*:47: idle time:*:48:

Basically delete all the marker lines, get rid of one of the 2 "video" lines and make sure the remaining "video" line looks like it does in the current file.
 
Could be related to the changes in the file. It sounds like the way you modified /etc/groups removed video and a couple other items.

Are you running root on ZFS or root on UFS?
If ZFS, you could always boot into a previous BE and then fix the current one.
If UFS, boot from USB or install media into a live system, manually mount filesystems and you can fix them.

magentron said:
However, after the first reboot, the upgrade failed as it hung just after loading the kernel with the problem of framebuffer issue as reported on other posts on the forum. Even switching to the old kernel option on the boot menu still caused the boot to fail at the entropy and framebuffer stage of booting.
Click to expand...
I don't know the specifics, but I think there was something related to framebuffer size changes along the way. Not sure if it was tied to EFI booting or it affected BIOS booting also, but there may be a clue in searching the forums.

But using the install media for say 13.2 and live booting the system may help figuring it out.

You mention older hardware, but I don't see where you've explicitly said what your hardware is and how you are booting (UEFI or BIOS). You may also want to say if you are using root on ZFS or UFS.
 
It does the same when trying to boot from a usb media with the latest 13.2 or 14.1 versions, the hardware is a MacBook 2006 with a 64bit CPU, but the EFI firmware is 32 bits and booting is 32 bits, older version BSD 12.2 / 12.4 installs OK, but cannot use it due to cannot fetch packages, and I have tried to use the latest BSD versions but there appears that the latest versions will not boot old hardware.
 
Ahh. I'm at my limit, but I think there have been reports/threads on the forums about similar hardware. I don't recall if there were any specific solutions.
 
It would appear to me that the latest versions of BSD 13 / 14 and onwards. Have dropped support for older hardware by design if version 12 boots and installs OK but the latest versions don't it must be compatibility issues with the EFI firmware, booting, and kernel with the hardware and BSD. That is my conclusion by installing Version 12.2 and then trying to upgrade to 13.2 which did not complete and gave the same results as trying to boot from a USB media with version 13.2 - If there was an extra option on the boot menu, to allow legacy booting in respect of old versions, but being able to install the latest versions that would solve the issue. But thinking about it if the EFI and booting is 32bits then this would force the CPU to run in 32-bit mode. Therefore since BSD is withdrawing support for 32bit OS, then it would appear this is from version 13 onwards.

Thanks very much for your help and interest in the matter.
 
  • Like
Reactions: mer
So, you see a boot menu, therefore loader(8) works. And you write you get the error after "loading the kernel", so ... you DO see the ---<<BOOT>>--- message? Then it can start the kernel just fine, therefore your theory about anything regarding "32bit" doesn't seem too plausible. It's not that unlikely the issue can be solved (could you be a bit more specific about the error please?), although of course, Apple hardware is always "special"...

BTW, it's quite irritating to read about "BSD12.2" etc. The latest version of BSD was 4.4BSD-Lite2. From the context, it's somewhat obvious you mean FreeBSD, but as there are quite some other descendents of BSD, please, if you mean FreeBSD, write FreeBSD, thanks.
 
Yes, my apologies I should have written FreeBSD so any reference to BSD means FreeBSD and not the BSD you have mentioned.

I will provide more details about the errors during the boot process, it has been mentioned that there are other threads on the forum relating to the same issue, so if it is not a 32-bit issue, then what is causing the booting process to crash out and hang? It only occurs on all FreeBSD versions from 13 onwards, FreeBSD versions 11 and 12 will boot correctly and will allow installation.
 
The following relates to a FreeBSD13.2 installation, after the first reboot during an upgrade process from FreeBSD 12.2 to FreeBSD13.2 which failed to complete.

after the autoboot, the following is displayed on the screen:

Loading Kernel......
/boot/kernel/kernel text=0x18aa98 text=0xdfd150 text=0x675174 data=0x140 data=0x1c38e8*0x43b718 0x0*0x18fe88*0x1ae449/
loading configured modules...
/boot/entropy size-0x1000
/etc/hostid size-0x25
staging 0x71000000 (not copying) tramp 0x7dc6a000 PT4 0x7d9c0000
Start @ 0xffffffff8038b000...
EFI framebuffer information:
addr, size 0x0, 0x0
dimensions 0 x 0
stride 0
masks 0x00000000, 0x00000000, 0x00000000, 0x00000000,

- at this point, the cursor is frozen and the process has hung.

NOTE: the above is for an Upgrade that did not fully complete, as it failed on its first reboot.


The next Screenshot relates to booting from a USB drive, which has an iso image of FreeBSD 13.3

Autoboot is 0 seconds

Loading kernel...
/boot/kernel/kernel text=0x18d490 text=0xe0a4e8 text=0x67fb0c data=0x140 data=0x1832d1*0x47bd2f 0x8*0x191af0*0x8*9x1b5ed/
Loading configured modules...
can't find '/boot/entropy'
can't find 'etc/hostid'
staging 0x74e000000 (not copying) tramp 0x7dc6a000 PT4 0x7d9c0000
Start @ 0xffffffff8038e000...
EFI framebuffer information:
addr, size 0x0, 0x0
dimensions 0 x 0
stride 0
masks 0x00000000, 0x00000000, 0x00000000, 0x00000000,

- again the cursor is frozen and the process is hung.
 
Is there a way to step through the booting process, using the keyboard to display what files and modules are loading/executing during the booting process?
 
Ah ok, so it hangs before starting the kernel (otherwise you'd see at least this ---<<BOOT>>--- line). Then this could indeed be an issue with loader(8).

Just a simple idea for some trial&error: There are three EFI flavors of loader(8) coming with FreeBSD currently: /boot/loader_4th.efi, /boot/loader_lua.efi and /boot/loader_simp.efi. The default /boot/loader.efi which is normally installed to your ESP is a hardlink to the _lua flavor, so you could try whether one of the others happens to work.
 
OK, so how do I try each of the options?

I read in the History of loader(8) "The loader first appeared in FreeBSD 3.1. The loader scripting lan-
guage changed to Lua by default in FreeBSD 12.0."

Given that there were no apparent issues with FreeBSD12 booting and being able to be installed, has the loader default flavor changed from Lua in versions 13 /14?
 
Try to update your BIOS firmware. I think your EFI is too old and didn't report the video resolution and you just don't see the output of the boot process when it switch to gop.
 
Reply for VladiBG: I don't think Apple uses a BIOS as such, and there is no way to access it if they did, to my knowledge. As far as I understand most firmware & EFI updates are part of the Mac Operating System since on certain hardware Apple used to lock the EFI & Booting in terms of either 32 or 64-bits even though the CPUs are 64-bits. So by installing a different Apple OSX there would be an EFI firmware update, and they can stop certain Apple products from installing OSX i.e. trying to upgrade from Snow-Leopard 32-Bits to El-Capitan 64-Bits on an early Mac, there are unofficial hacks such as I understand it, that that use an EFI shell to overcome this. I don't think this problem is just related to the hardware in my case, as there are other threads on the forum on the same matter using different hardware.

It does appear that the framebuffer could be part of the issue in my understanding framebuffer relates to video but in the context of EFI booting where modules and drivers are part of the booting process, this is a complex issue and quite vague as to what is taking place behind the booting process of EFI. But it still does not answer why FreeBSD 12 boots correctly and can be installed on a hard disk, just that downloading the pkg and ports no longer works (not due to internet connectivity). But FreeBSD 13 onwards does not get past the kernel loading stage?

If as you suggested this is a resolution issue, is there any way in which as part of the booting process there could be a workaround in which the resolution can be configured by the user at boot, this may require another option added to the video option 5, pre-booting, or modifying a file and changing the resolution?

Thanks very much for your views
 
Is there any difference if you set hw.vga.textmode=1 into the loader prompt OR set kern.vt.fb.default_mode let's say to "1024x768"
 
So let's put this into perspective If a 64-bit Ubuntu Linux 24.04 using EFI can load, run, and be installed on this hardware why can't the latest version of FreeBSD not boot?

If FreeBSD has just dropped support for 32-bit hardware that's fine Linux did that some years ago.

But it should still boot using the 64 Bit CPUs like Ubuntu. This appears a FreeBSD issue that needs to be resolved!

What is Linux doing that enables older 64-bit CPUs and hardware to still use their operating system, that the latest FreeBSD are not in the booting process?
 
magentron said:
So let's put this into perspective If a 64-bit Ubuntu Linux 24.04 using EFI can load, run, and be installed on this hardware why can't the latest version of FreeBSD not boot?
Click to expand...
Because Ubuntu has support for booting on 32 bit (U)EFI? FreeBSD has never, and will never, support 32 bit (U)EFI.

magentron said:
If FreeBSD has just dropped support for 32-bit hardware that's fine Linux did that some years ago.
Click to expand...
That is not the issue here. This has nothing to do with the OS being 32 bit or 64 bit. Or dropping support for 32 bit.
magentron said:
What is Linux doing that enables older 64-bit CPUs
Click to expand...
This issue has nothing to do with the CPU.
 
I have tried all the latest FreeBSD versions from 13 to 14 the only version which boots and installs is version 12 and lower versions
 
You must log in or register to reply here.
Back
Top