# Upgrading from 7.2 to 9.0



## jaymax (Jul 30, 2012)

I skipped some of the intermittent upgrades in between 7.2 and the current 9.0, not wanting to fall too far behind, I attempted it today with the following results

Prior Status:


> <hostname> 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May  1 08:49:13 UTC 2009



Start of upgrade:

```
#> freebsd-update fetch
#> freebsd-update install

#> reboot
#> uname -a
```



> <hostname> 7.2-RELEASE-p8 FreeBSD 7.2-RELEASE-p8 #0: Wed May 26 03:08:50 UTC 2010



Apparently there was an upgrade from 7.2-RELEASE #0: to 7.2-RELEASE-p8 #0 !

Repeating "fetch" , "install" Step =>


> No updates needed to update system to 7.2-RELEASE-p8.
> 
> WARNING: FreeBSD 7.2-RELEASE-p8 HAS PASSED ITS END-OF-LIFE DATE.



What is the correct way to proceed ?
Previously every upgrade required a sysinstall from the installation DVD, but with v 7.0, I thought the upgrade could be done with the freebsd-update utility at /var/db/freebsd-update.

I have read the pertinent web pages but they did not seem to address strategies for upgrading across more than one upgrades, much-less across multiple major versions.

Thanks!


----------



## yom (Jul 30, 2012)

the *freebsd-update* can take the -r parameter with the new release you want it to install.
The procedure is described here : http://www.freebsd.org/releases/9.0R/installation.html in the "2.2 Upgrading Using â€œFreeBSD Updateâ€" paragraph.
You can also check the manual for freebsd-update.conf(5)() for a complete description of the command.


----------



## yom (Jul 31, 2012)

I've Just saw that I did not give you the good manual.
freebsd-update(8)() is the one you could check.


----------



## jaymax (Jul 31, 2012)

*now system does not boot => mountroot prompt*

Got through the fetch and install phases apparently fine, but on the second reboot ran into  a -
Problem Error 19

Reboot from 7.2 to 9.0 Upgrade -

==> mountroot> prompt

From dmesg - there was a change of disk labeling apparently

```
ada0: Previously was known as ad4
ada1: Previously was known as ad0
ada2: Previously was known as ad1
```


From previous mountings


> ufs:/dev/ad0s1a			/
> ufs:/dev			devfs
> ufs:/dev/ad1s1e			/disk02
> ufs:/dev/ad4s1d			/disk03
> ...



/  		should be  	/dev/ada1s1a
/disk02		 ,,   ,,	/dev/ada2s1e
/disk03	 	 ,,   ,,	/dev/ada0s1d
/tmp	 	 ,,   ,,	/dev/ada1s1e	(?)
/usr	 	 ,,   ,,	/dev/ada1s1f
/var	 	 ,,   ,,	/dev/ada1s1d	(?)

mountroot> ?
=>


> ufsid/452cee98a68cc911 ada2s1e ada2s1b  ufsid/452cee9881a417da ufsid/452ceeac82f6598c ada2s1 adaif ada1e ada1d ada1a ada0s1d ada0s1b cd1 cd0 ada2 ada1 adaos1 ada0



It Does not show ada1s1a, which should be /

Attempting to mount root nevertheless: Ex -


```
mountroot> ufs:/dev/ada1s1a
=> Trying to mount root from /dev/ada1s1a []...
   mountroot: waiting for device /dev/ada1s1a ...
   Mounting from ufsid:/dev/ada1s1a failed with error 19.
```

Was thinking that perhaps I could have gone in and tinker with the fstab file, any suggestions?

Thanks!


----------



## SirDice (Jul 31, 2012)

It's most likely ada1a.


----------



## jaymax (Jul 31, 2012)

OK! Thanks
Used ada1a
got the following =>


```
mountroot> ufs:ada1a
Trying to mount root from ufs:ada1a []...
WARNING: /mnt/ad0a was not properly dismounted
exec /sbin/init: error 20
exec /sbin/oinit: error 20
exec /sbin/init.bak: error 20
exec /rescue/init: error 20
exec /stand/sysinstall: error 20
init not found in path /sbin/init:/sbin/oinit/:sbin/init.bak:/rescue/init:/stans/sysinstall
panic: no init
cpuid = 0
KDB: stack backtrace:
#0 0xcoa4b137 at kdb_backtrace+0x47
#1 0xc0a18697 at panic+0x117
#2 0xc09cb4c0 at start_init+0x340
#3 0xc09ea977 at fork_exit+0x97
#4 0xc0d32ba4 at fork_trampoline+0x8
Upime: 1m4s
Automatic reboot in 15 seconds - press a key on the console to abort
```

Next step suggestion!

Use of 

```
mountroot> ufs:/dev/ada1a
```
=> same results


----------



## wblock@ (Jul 31, 2012)

Boot with mfsBSD.  Use file -s to identify the slices and partitions on the drive.  Also do a fsck(8) on at least the boot drive filesystems.


```
# file -s /dev/ada0a
/dev/ada1a: Unix Fast File system [v2] (little-endian) [color="Red"]last mounted on /[/color], ...
# fsck -y /dev/ada1a
# fsck -y /dev/ada1d
...
```


----------



## jaymax (Aug 1, 2012)

mfsBSD boot:


```
nfsbsd#> file -s /dev/ada1a 
/dev/ada1a: Unix Fast File system [v2] (little-endian) last mounted on /mnt/ad0a, last written ... {a bunch of info on disk partition info}
nfsbsd#> fsck -y /dev/ada1a 
fsck: Could not determine filesystem type
```

Using fsck_ffs


```
nfsbsd#> fsck_ffs /dev/ada1a
** /dev/ada1a
BAD SUPER BLOCK: VALUES IN SUPPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE ioctl (GCINFO}: Inappropriate 1octl for device
fsck_ffs: /dev/ada1a: can't read disk label
```

???


----------



## SirDice (Aug 1, 2012)

It might be due to a corrupt partition table.

http://www.freebsd.org/releases/9.0R/relnotes-detailed.html#AEN1277


----------



## jaymax (Aug 1, 2012)

*More details*

The full output of the <file -s> cmd was =>


```
nfsbsd# file -s /dev/ada1
Unix Fast File system [v2] (little-endian) last mounted on /mnt/ad0a, last written at Sun
 Aug 1 20:17:46 1999, clean flag 0, readonly flag 0, number of blocks 262144, number of
 data blocks 253815, number of cylinder groups 4, block size 16384, fragment size 2048,
 average file size 16384, pending blocks to free 0, pending inodes to free 0, system-wide
 uuid 0, minimum percentage of free blocks 8, TIME optimization
```

and the fsck_ff output was =>


```
nfsbsd#> fsck_ffs /dev/ada1a
** /dev/ada1a
BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE ioctl
 (GCINFO}: Inappropriate 1octl for device
fsck_ffs: /dev/ada1a: can't read disk label
GEOM: ada1: geometry does not match label (16h,63s != 16h,255s).
```

Normally, the system keeps several copies of the SUPER BLOCK, but where to find them ?

I have looked at the link at 
http://www.freebsd.org/releases/9.0R...d.html#AEN1277 
Release 9.x's new propensity to check on disk integrity, and workaround by overriding the "check" step.

Probably, the best approach might be to decide on which step is better?
i) find the alternate storage locations for the SUPER BLOCK if the first is corrupted or
ii) Overriding the "check" step !

Suggestions!


----------



## gkontos (Aug 1, 2012)

jaymax said:
			
		

> Probably, the best approach might be to decide on which step is better?
> i) find the alternate storage locations for the SUPER BLOCK if the first is corrupted or
> ii) Overriding the "check" step !
> 
> Suggestions!



Override the step and make sure that you can fsck your drive. Fix /etc/fstab,  and boot your system. Then recompile all your ports.


----------



## jaymax (Aug 1, 2012)

Thanks Gontos,

I'm going to follow your suggestions. 
I was just about to post another: Anyway, I'll pause it for awhile.

To execute the steps, I need to modify the loader.conf file, but I can only do this by booting in to the loader mode. The file is located at /boot/loader.conf

Now, what editor can I use in this mode, vi, ee, type are inaccessible ?

Thanks!


----------



## gkontos (Aug 1, 2012)

After you run fsck from mfsbsd, you can mount the root partition under /tmp and then use vi to edit loader.conf and fstab.

[CMD=""]set kern.geom.part.check_integrity="0"[/CMD]
[CMD=""]boot[/CMD]


----------



## jaymax (Aug 1, 2012)

> After you run fsck from mfsbsd, you can mount the root partition under /tmp and then
> use vi to edit loader.conf and fstab.



Herein lies the dilemma!

Running fsck with virtually all options => 


> fsck: Could not determine filesystem type


Again, I can't mount any of the drives because fsck_ffs labels them as DIRTY or UNCLEAN.

I have run fsck interactive i.e. fsck_ffs

I have run fsck_ffs -b 160 /dev/ada1a, [ -b 160, SUPER BLOCK location]=> an endless stream
 of changes all requiring a [y/n], all affirmative responses. So I ended up doing a 
fsck_ffs -y -b 160 /dev/ada1a instead.

After a couple of minutes (affirmative "Yes" running)
=>

```
UPDATE STANDARD SUPERBLOCK? yes

   ***** FILE SYSTEM MARKED CLEAN *****
   ***** FILE SYSTEM WAS MODIFIED *****
```

          ----------------------


```
nfsbsd# mount /dev/ada1a /tmp
nfsbsd# ls /tmp  lost+found
```

???

Booting attempted without mfsBSD ==> 





> Missing operating system


Is there a way to reverse this?


----------



## gkontos (Aug 2, 2012)

Have you looked inside lost+found? There is a good chance that the root partition is there.

If not, then the root partition has to be reinstalled. (Not so easy as it sounds but doable)


----------



## jaymax (Aug 2, 2012)

Ooops! You are correct, lost+found is a directory, itself containing several numbered subdirectories, numbered from #00133 - #18346. They have 700 permissions (drwx------) These are root files, many are links to other system files and explicitly so named in the page output.

df -m => about 57M, a bit smaller than expected.

How should I proceed from here?

Thanks!

PS:
Notes on "lost+found" - fsck_ffs man page


> Orphaned files and directories (allocated but unreferenced) are, with the
> operator's concurrence, reconnected by placing them in the lost+found
> directory.  The name assigned is the inode number.  If the lost+found
> directory does not exist, it is created.  If there is insufficient space
> its size is increased.



Seems as if all of the root partition was/is "Orphaned files and directories", since the lost+found directory is now the only and complete content of /dev/ada1a 

How do I get out from this?


----------



## gkontos (Aug 2, 2012)

Plan(B) only.


----------



## jaymax (Aug 2, 2012)

Plan(B) - as in 





> root partition has to be reinstalled


----------



## gkontos (Aug 3, 2012)

jaymax said:
			
		

> Plan(B) - as in



Correct.


----------



## gkontos (Aug 3, 2012)

On second thought, there is a much better approach you can take at this point. What you have now is a system that refuses to boot, with a corrupted root partition. Even if you were able to pass this, you would still need to rebuild all your ports.

Suggestion:


Boot with mfsbsd or FreeBSD 9.0-RELEASE CD. 
Mount the root partition and try to look for master.passwd, passwd and group files.
Mount /usr  and get a complete backup of /usr/local/etc
Mount /var and get a complete backup of /var/db/pkg and /var/db/ports. (Depending on the use of this box you might need to backup other stuff from /var)
Mount /home and get a full backup from there too.

After you are sure that you have everything you need, proceed with a new FreeBSD 9.x installation.


Restore /var/db/ports
Restore /var/db/pkg 
Use a tool like ports-mgmt/portmaster or ports-mgmt/portupgrade to rebuild all the ports.
Restore /usr/local/etc
Restore /home 
Restore master.passwd, passwd and group
And you will have your old system back.


----------



## jaymax (Aug 4, 2012)

Thanks Gkontos!

I just went ahead with the reinstall before I saw your suggestions. I had been thinking of something similar, but all my files are in the Lost+found folder with the inode #'s as file names - 1830 +. I was thinking of using grep to fish out relevant files but then though it would not be worth it.

I just did as I have done on every major upgrade since 4.x ---> REINSTALL ??

I have a dump that I could probably have used, but I am scared of messing things up, luckily I have been storing my data etc on separate discs.

Thanks again!


----------

