Brad Bowers
Dabbler
- Joined
- Jun 9, 2011
- Messages
- 17
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?
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.
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...
# 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
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.
Yeah, the CLI could 'go away' according to this reply from Gcooper (developer):