Other ways to upgrade?

[Brad Bowers]

If I'm running 8.0.1-BETA2... is there a way to upgrade via SSH? I understand that a GUI upgrade to RC1 isn't supported, but would it be possible to upgrade without physical access to the machine?

 

[jgreco]

I believe 8.0.1-BETA2 used the smaller 1GB flash. That makes it tricky at best, assuming you have a larger flash device installed in the machine.

If you only have a 1GB flash in the machine, there is no practical way to do it.

If you have a larger flash in there, you might be able to weasel through a repartition of the flash so that you can update the secondary OS partition - FreeNAS supports two OS partitions for upgrade purposes.

However, it's risky. If you have OOB management (IP KVM, etc) you can probably do it, otherwise, you're not likely to be successful unless you've done this sort of thing before.

 

[ProtoSD]

There actually is a way to do it from the command line. I can't recall off the top of my head what it is, but it's possible. @jgreco is correct about the size of your flash drive though, so if you don't have a 2GB drive it still won't work.

 

[joeschmuck]

I recall there was a change (can't recall if that was Beta-3) where the upgrade path was to use the iso, the other paths all failed. Of course that is for the novice, I'm not sure how you would be able to change the partition size of the boot device remotely while running from it.

 

[Brad Bowers]

I have a 4gb or an 8gb flash drive on it right now... so that's not an issue. As far as crawling around in a cmd line to upgrade, I'm fine with that as long as I got some confirmation that it was likely to work... otherwise I'll make arrangements to get over there at some point...

 

[jgreco]

I recall there was a change (can't recall if that was Beta-3) where the upgrade path was to use the iso, the other paths all failed. Of course that is for the novice, I'm not sure how you would be able to change the partition size of the boot device remotely while running from it.

You don't. You change the partition size of the OTHER boot partition, also relocating it in the process, to match the new expected layout (see new flash image). Then you ram the new firmware onto the other boot partition, double- and triple- and quadruple-check that you've not made any errors, flip the default boot partition, type "reboot", and pray you didn't just cost yourself an 800 mile trip. Used to do stuff like this all the time. It's certainly possible. It's just a matter of whether or not it's easier to sit in your office chair for a few hours making sure you got the manual puttering all right, or if it's easier to drive 14 hours in each direction. Quite frankly, I used to do this stuff WITHOUT the luxury of an alternate booting partition, so I look at the FreeNAS situation as "sweeeeeet. [Cartman]"

 

[jgreco]

I have a 4gb or an 8gb flash drive on it right now... so that's not an issue. As far as crawling around in a cmd line to upgrade, I'm fine with that as long as I got some confirmation that it was likely to work... otherwise I'll make arrangements to get over there at some point...

It's likely to work if you are careful and thorough. Since you haven't done this before (I'm guessing), you would find it easier if you had a local system to make your mistakes on, loaded up with the same sort of setup that you have on the inaccessible machine. I would say it's virtually required.

One little problem is that I really stopped needing to do this sort of stuff around FreeBSD 4, and a lot of the disk manipulation stuff has changed quite a bit. So I cannot give you an exact recipe. But I can give you some guidance.

You need a detailed list of what your disk looks like now, and what you need it to look like after. I suggest a reboot after each step to make sure things are "right." My current 2GB-FreeNAS-on-an-8GB-flash looks like

Code:

# fdisk da4
******* Working on device /dev/da4 *******
parameters extracted from in-core disklabel are:
cylinders=971 heads=255 sectors/track=63 (16065 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=971 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 1930257 (942 Meg), flag 80 (active)
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 890/ head 15/ sector 63
The data for partition 2 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 1930383, size 1930257 (942 Meg), flag 0
        beg: cyl 891/ head 1/ sector 1;
        end: cyl 757/ head 15/ sector 63
The data for partition 3 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 3860640, size 3024 (1 Meg), flag 0
        beg: cyl 758/ head 0/ sector 1;
        end: cyl 760/ head 15/ sector 63
The data for partition 4 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 3863664, size 41328 (20 Meg), flag 0
        beg: cyl 761/ head 0/ sector 1;
        end: cyl 801/ head 15/ sector 63

Now I don't know offhand what partition 3 is, but partition 4 is /data, and will need to be bumped farther out on your disk. It might also be currently smaller than 20 MB. So your first act is to make a dump of /data ("dump 0sf 99999 /mnt/storagex/data.dmp /dev/ufs/FreeNASs4" or whatever). Then move partition 4 to the new location (3863664, 41328) and do a newfs on it, mount it, restore, and remove restoresymtable.

You can move partition 3 in the same manner. Mine's empty so probably no real worries except getting it located properly.


Now move and resize partition 2. This is the tricky bit; this will wind up being the new boot partition. It's probably all zeroes, or at least, mine seems to be. That's fine. Don't fret that there's nothing to dump. You need to get the latest "GUI upgrade" image that you want to cram on your FreeNAS, and uncompress it. You feed that file into the script "/root/updatep2". This may take a while as it has to write a gig of flash.

Now you hold your breath and reboot. If lucky, you'll be running the new FreeNAS. If not lucky, you'll be grabbing your jacket and an ISO to go visit your remote machine.

But you're not done yet. You also need to resize partition 1, after reboot (when you're now running on partition 2).

These are, of course, fairly general instructions. If you're uncomfortable, then probably don't try it. If it makes sense to you, then you probably have the necessary skills to pull it off.

 

[gcooper]

The CLI is the next stop for improving the system in 8.1.. stay tuned ;)..

 

[ProtoSD]

Yeah, the CLI could 'go away' according to this reply from Gcooper (developer):

by gcooper

.... people need to get out of the mode of doing everything using direct commands in the FreeBSD root shell because it's only going to get the system out of sync.

What we need to do for the next major release is provide a polished CLI means to configure the system as well as a GUI means to configure the system and turn off the root shell (or at least provide developer mechanisms to access the shell). Otherwise things like this will continue to crop up where the user was doing something that is blatantly unsupported, but because we don't warn the user that they're doing something unsupported we work ourselves into a debug/triage loop that we really shouldn't have to get ourselves into.

This is part of the reason why so many platforms (iOS, Android, etc) block off developer access by default: there are enough intertwined systems that get out sync because people have access to the backend pieces which allows them to get the middleware out of sync by effectively pulling the rug out from under it.

 

[gcooper]

Yeah, the CLI could 'go away' according to this reply from Gcooper (developer):

Direct access to the CLI, e.g. running zfs destroy manually from a root shell. There's no reason why users shouldn't have access to a minimal / polished shell and then a "oh dash it all.. I'm breaking the seal... it might eat my cat, dog, etc shell". Caveat being: if you screw up your system, you're on your own because you're running homebrew (just like with some Droid phones, etc).

 

[gcooper]

Let's put it this way: the people who should be accessing the direct console and monkeying around with stuff should be folks who understand how to modify their system and fix it in the event that things go south. I wouldn't want to sit my mom or dad down at a root shell or login on my box and say "have at it!", because I think that they would potentially get into trouble not fully understanding how things work.

There's no reason why power users shouldn't be able to do that though, but it's going to be highly discouraged.

Some other poweruser features are coming soon, but there are going to be really fat warnings when people go and do stuff, because you can make your machine completely unbootable if you follow improperly prescribed directions and don't understand some of the underlying caveats of what someone suggests.

I have been bitten a number of times and I understand it's all part of a learning curve, and there are many bright people here who don't fit the same audience as my parents, but it's not that hard to get stuck with Unix if you do the right incantations :/.

 

[jgreco]

Well, aside from "FreeNAS works/Nexenta doesn't", one of the nice things about FreeNAS vs Nexenta is that it hasn't completely made the shell into a strange broken pseudo-whatever that is hard to use when you need it and unpredictable in unexpected ways. There are advantages and disadvantages to acting as an abstraction layer between the OS and the user.

There's a certain amount of sense in the Solaris model of tagging certain things as part of ZFS (sharenfs=..., sharesmb=..., shareiscsi=..., etc) to avoid unnecessary sync problems. It's harder with FreeBSD, I think, but it might be useful to see if FreeNAS can avoid maintaining private copies of things where they're not readily accessible. However, last time someone criticized FreeNAS on a related topic (XML config), we saw the thread rapidly stomped on and locked from further discussion. So I am taking this moment to point out that the design choice to use a non-readily-modifiable binary configuration serves to frustrate users who might otherwise just edit the config; that same mentality will drive users to try issuing shell commands to "fix" the things they need to fix, because they cannot figure out how else to do it.