If you are seeing a "9.3 upgrade reboot loop", please read

[jkh]

Hi folks,

I've seen about 4 different threads about "reboot loops" after trying the GUI upgrade which folks claim can be fixed by doing a clean install. We would love some screenshots or some idea of what people are seeing during these "reboot loops" since, to be honest, that is very weird for at least the following reasons:

1. We haven't seen this once in all of our 9.2.1.x->9.3-BETA updates (and, as you might imagine, we have done a lot of them during our run-up to 9.3-BETA since it's a new process) so it must be something about the specific HW configuration or USB sticks people are using.
2. The GUI update process, since it involves a "conversion" from UFS to ZFS, is essentially the same as a fresh install. It absolutely has to format your boot device, after saving your configuration data into memory, and this kind of "trampoline upgrade" should be essentially indistinguishable from a fresh install, so the fact that people are finding a scratch ISO install to be a "fix" is, again, deeply weird.
3. If anyone has a failing USB stick, and we have seen literally hundreds (if not thousands) of those go bad in the field due to what are frankly a lot of really terrible quality USB sticks in the world, the first upgrade is when you would see the problem. If you saw any of these sorts of install-time issues but "fixed" them, please scrub your boot pool (it's in System->Boot) and see if this detects any errors.

Thanks!

 

[Todd Vernick]

Intel i3, kingston 8GB, ASUS micro-itx board, 2x 1.5 TB drives, 1 64GB SSD for jails, sandisk 8GB usb disk for OS.
Got to the rebooting part on the web gui. Checked output from computer plugged into hdmi and saw lots of hex scrolling on the screen.
After that it basically rebooted and came to a point where it couldn't m0unt anything from the usb stick, and than it said it couldn't mount numerous other mount points on root partition.
It then asks something about using a rescue.sh file but already proceeds to reboot itself, and loop.

 

[Nigel]

I had this too, on my HP Microserver N36L. I only have 2GB RAM on this machine, so wondered if the upgrade process had run out of memory, and corrupted the config.
I did a fresh install, which worked, but find that after every update, the machine fails to boot, requiring a power down to cure.

 

[Ericloewe]

I had this too, on my HP Microserver N36L. I only have 2GB RAM on this machine, so wondered if the upgrade process had run out of memory, and corrupted the config.
I did a fresh install, which worked, but find that after every update, the machine fails to boot, requiring a power down to cure.

Considering the minimum amount of RAM for FreeNAS 9.3 is 8GB, I'd fix that before worrying about upgrades.

 

[Nigel]

Why? it works fine for me, once it's up and running!

 

[Ericloewe]

Why? it works fine for me, once it's up and running!

For starters, because it's very clearly stated to be the minimum requirement.

Are you familiar with the concept of hardware requirements? If you phone Microsoft and tell them you've found a bug in Windows 8.1 that only happens when you're running with 128MB of RAM, they'll tell you "follow the minimum hardware requirements".

Seriously, this argument pops up so frequently that it's irritating. Feel free to read around or continue living in your fantasy world.

 

[Nigel]

Very helpful response!

I consider all feedback about a beta program to be useful.
It's responses from people like you that make people not bother!

 

[solarisguy]

@Nigel, since 9.3 is only using ZFS you would need to use very, very small amount of storage to not have problems with ZFS further down the road...

 

[lastcmaster]

Supermicro X9SCM-F, Xeon(R) CPU E31230 @ 3.20GHz, 32GB 1333 MHz ECC, 8GB SanDisk Cruzer Fit, AMI BIOS 2.10, 10x500G/1T disk on two Sil-3726 PM
In my case the boot device didn't get registered until after the mfsdisk was mounted and had started running trampoline.rc. This was consistent over at least five to six reboots until I manually broke it and sent it back to slice 1 with the boot manager.
The board/bios support both UEFI and legacy and sometimes it fails the legacy boot because the legacy USB stuff just seems to take too long time and you fall into the EFI menu.
I had the same problem with the board when I started using it with FreeBSD (8-STABLE I think) and used an no-brand SATA controller to get PM support (the C204 on the board does not support PM) but after switching to a HighPoint Marvell 88SE912x AHCI SATA controller I have not had any specific problems with this but then the machine did't have to reboot more than once every year when I upgraded FreeBSD so I can't say.
I solved the problem by adding a loop in the trampoline.rc on the mfsdisk that checked for the device and then continued.

 

[cyberjock]

Very helpful response!

I consider all feedback about a beta program to be useful.
It's responses from people like you that make people not bother!

And it's users like you that don't want to listen to the pro's because the answer isn't what you want to hear.

The truth:

The documentation says you need 8GB of RAM minimum. If you don't like that, don't come here with your problems when the develop. Notice I didn't say "if". I said "when". That's the harsh reality.

The fact that you'd ignore someone with 2ooo posts because "you know better", yet you are the one coming for help, is quite disappointing. It definitely lets others know who not to answer in the future because you want the answer that you want to hear and not the real answer. I have no doubt that a few users with high post counts have added you to their ignore list.

 

[Scareh]

https://bugs.freenas.org/issues/6830

for now this is closed, tested it with a HP microserver with 8 gig ram, with an Emtec 8Gig stick, where i previously had the problem, it doesn't show right now anymore.