9.10 is now in Nightlies testing

[depasseg]

Deleted. I'm a moron and can't read English today.

Your original response had me questioning everything I knew about snapshots. Fwew!

 

[jgreco]

Rolling back to an earlier boot environment accomplishes almost exactly this. You just lose whatever config changes you'd made after the update you're rolling back to.

There are a variety of workarounds, yes, but basically you still can't "roll between" releases without some caveats. In particular, the config file only rolls forwards, not backwards.

 

[rogerh]

There are a variety of workarounds, yes, but basically you still can't "roll between" releases without some caveats. In particular, the config file only rolls forwards, not backwards.

That's interesting, because when I went back to the last 9.3.1 update issued before 9.10 was released, from the first 9.10 stable update, it seemed to work OK and seemed to be using an old version of the config file. I've forgotten why I tried it (it turned out to be a non-problem) but it did lead me to think that the boot environment must have its own version of the config current at the time it was last used. Is this not true?

I don't change the config much, so I had not noticed either way before.

 

[Ericloewe]

but it did lead me to think that the boot environment must have its own version of the config current at the time it was last used.

It does. The snapshot includes everything (of matter, at least), so it keeps the config from when the upgrade was run.

 

[depasseg]

It does. The snapshot includes everything (of matter, at least), so it keeps the config from when the upgrade was run.

Any issues if the .system dataset isn't on the boot pool?

 

[Ericloewe]

Any issues if the .system dataset isn't on the boot pool?

No, the config is stored on the boot device. The .system dataset just has backups.

 

[depasseg]

I meant from the reporting perspective (RRD and whatnot).

 

[Ericloewe]

I meant from the reporting perspective (RRD and whatnot).

I'm fairly certain the .system dataset doesn't get snapshotted with the boot environmentsif it's on the boot pool, anyway, so it shouldn't make a difference.

 

[jgreco]

That's interesting, because when I went back to the last 9.3.1 update issued before 9.10 was released, from the first 9.10 stable update, it seemed to work OK and seemed to be using an old version of the config file. I've forgotten why I tried it (it turned out to be a non-problem) but it did lead me to think that the boot environment must have its own version of the config current at the time it was last used. Is this not true?

That's true. What that means is that you were only saved from trouble because you don't make many changes to the config. That's "caveats." You lost any changes to your config file, but in your special case, that doesn't matter, because losing nothing is harmless. It matters for many other situations.

 

[rogerh]

That's true. What that means is that you were only saved from trouble because you don't make many changes to the config. That's "caveats." You lost any changes to your config file, but in your special case, that doesn't matter, because losing nothing is harmless. It matters for many other situations.

Can I just clarify this? The difficulty then arises because you can't apply the modified config file from the new release to the boot environment containing an earlier release? But normally the config file (meta)configuration shouldn't change during updates of the same release?

 

[jgreco]

The "config file" is actually a database file. When you upgrade from one version to the next, and let's say the new WizzBang feature is added, it is possible that a table will be added to the database, which would probably be harmless for purposes of rollback, but also it is perfectly possible that some columns will be added, transformed, or removed. This is called a schema migration.

There are various strategies for this, but usually the simplest is for there to be a version number for the database. If a new version of the software is installed, with "version 48", and the existing database is "45", then when starting up, the code pulls in and runs some .sql scripts (for MySQL as an example), such as migration46.sql (which transforms the database to version 46), and migration47.sql, and then migration48.sql .

Once those migrations have been executed, the software should see exactly what it needs in the database. But those migration scripts have changed the database. You can no longer take a v48 database and run it on a v45 codebase.

Now, in FreeNAS, those migrations are under /usr/local/www/freenasUI/system/migrations and I haven't looked really closely at what's going on. But the point is that these are designed as a one-way thing. In theory you could also build a system to roll them back, but this gets complicated.

 

[Lawrence]

Every time I do something with my FreeNAS machine, I have to relearn some things. I am NOT a network guru, but I can normally get it to work.

So, I am trying to upgrade from 9.3 to 9.10, and the little window that shows the progress of the upgrading process appears to not be progressing. I have had it upgrading for some time now, and it hasn't moved beyond "Installing base-os" 1 of 5, and on the progress bar, it just stays at 20%.

If someone can assist, I would appreciate it. OR, if someone can point me to some more explicit instructions, I would also appreciate.

Thank you

Lawrence

 

[Ericloewe]

Every time I do something with my FreeNAS machine, I have to relearn some things. I am NOT a network guru, but I can normally get it to work.

So, I am trying to upgrade from 9.3 to 9.10, and the little window that shows the progress of the upgrading process appears to not be progressing. I have had it upgrading for some time now, and it hasn't moved beyond "Installing base-os" 1 of 5, and on the progress bar, it just stays at 20%.

If someone can assist, I would appreciate it. OR, if someone can point me to some more explicit instructions, I would also appreciate.

Thank you

Lawrence

Your boot devices are probably just struggling. Updates take ~40 minutes on my X10 server, with USB flash drives.

Wait, wait, wait and don't kill the GUI.

 

[Lawrence]

Your boot devices are probably just struggling. Updates take ~40 minutes on my X10 server, with USB flash drives.

Wait, wait, wait and don't kill the GUI.

Thank you for your response. Between the time I posted the message and when I received notification of your response, the upgrade completed and I'm on 9.10.

Again thank you.

Lawrence

 

[T75]

Hello!

I just switched to 9.10 and I have occured some minor problems, yet:

1) The NIC wasn't getting it's IP from my router's static DHCP list anymore. I then noticed there wher two NICs no althrough the machine only got one physical NIC. I could solve the problem by manually deleting both NOC entired and then readding just one.

2) The bootloader (as some paths within FreeNAS system) has a weird name for the current version in GRUB now.
Before 9.10 (so with 9.3) it was:
FreeNAS (FreeNAS-9.3-STABLE-201602031011) - 2016-03-03 23:50
But now, with 9.10 it is:
FreeNAS (FreeNAS-d1851bb04ead848f18f828f8fd48bea) - 2016-03-23 23:29
So I think that something went wrong there? Could this mean a potential problem, for example with upcoming updates?

3) The version of the virtualbox jail template is still shown as VirtualBox-4.3.12 (URL: http://download.freenas.org/jails/9.2/x64/freenas-virtualbox-4.3.12.tgz). I deleted all my old jails before updating, so it should have been updated shouldn't it? How could I do a manual update instead? I don't understand the previuos post where you say there won't be any updates, because the starting post says there would be an update to the templates in 9.10. So which of both is right?

Thank you!

Just want to bump this for #3. I've already read this and this. Currently getting this message on a fresh install: jail name may contain only alphanumeric characters or underscore

Not sure where to go from here.

 

[gpsguy]

It's a bug that will be fixed "real soon now" - https://bugs.freenas.org/issues/14881

Currently getting this message on a fresh install: jail name may contain only alphanumeric characters or underscore.

 

[T75]

Thanks, I could not find that bug when I googled for it.

 

[AssFit]

It's hard to say what "better" means in this context. It's been overhauled, but that's it. The installer needs no specific knowledge of XHCI, it's simply part of the kernel, so go to it! :)

I can confirm 9.10 support XHCI. Before I have 9.3 has installation error with Asrock N3700-ITX motherboard but 9.10 works through on Sandisk 16GB flash drive.

 

[diskdiddler]

This is what I call good news. Reading a large 4GB file over a Gigabit network from my server:
9.3.0 up to 25MB/s
9.3.2 up to 65MB/s. Yes, over 2.5 times as fast!

This is while running a virtual FreeNAS on ESXi 6.0 on a HP MicroServer N40L.
I am aware that this setup is seriously underpowered and unsupported. Therefore I never bothered you guys with my 25MB/s speed, but this speed increase makes me very happy.

As far as I can tell: FreeBSD 10 has built in support for vmxnet3 virtual network cards and that makes all the difference. With FreeBSD 9 the network speed was the bottleneck.

Looking forward to 9.3.2 final :)

I got 65 -> 100MB/s with 9.2 and 9.3 personally. Only when my array exceeded about 85% of disk space used (Cyberjock, be quiet) did I find, as quoted by many, that yes performance will decrease.


Now that it's several months later, have you noted any other bonusus in switching to 9.10?