# Mountroot problem after V2C



## FR (Mar 6, 2013)

I've installed FreeBSD 7.4 on a VMware workstation 8. I then converted the VM to OVF and uploaded it to vCloud.

When I boot the VM on vCloud it shows this



What do I need to do? the slices looks like this when running the VM on VMware Workstation

Filesystem

```
/dev/ad3s1a
devfs
/dev/ad3s1e
/dev/ad3s1f
/dev/ad3s1d
/tmp/VMwareDnD
```


----------



## usdmatt (Mar 6, 2013)

By the look of it your ad3 disk is showing up as ad0 on the new system.
I would try typing in ufs:/dev/ad0s1a at the prompt.

If this boots, edit /etc/fstab and change all the occurances of ad3 to ad0. I can't remember what happens after this sort of error, if it boots into single user mode, you may need to type `# mount -uw /` to make the root file system writeable. Then type `# exit` to finish the normal boot process.


----------



## FR (Mar 6, 2013)

Ok I got until `# mount -uw /`
Then what?


----------



## usdmatt (Mar 6, 2013)

```
# ee /etc/fstab
```

Change ad3 to ad0 where ever it shows up and then reboot.
(Esc, Enter, Enter) to get out of ee if you haven't used it before, or you can use vi if you're used to it.

If it continues to complain about file system inconsistencies after reboot and puts you back in single user mode, you may need to run `# fsck -y` to try and fix them.


----------



## FR (Mar 6, 2013)

I tried vi with no joy
`# vi /etc/fstab`

```
vi: not found
```


----------



## FR (Mar 6, 2013)

ee not found either.


----------



## SirDice (Mar 6, 2013)

FR said:
			
		

> Hi I'm a newbie here.
> I've installed FreeBSD 7.4 on a VMware workstation 8.


The entire 7.x branch went end-of-life at the end of last month and is unsupported.

http://www.freebsd.org/security/#unsup


----------



## usdmatt (Mar 6, 2013)

Ok, looks like those commands live in /usr/bin which you haven't got mounted at the moment. Try `# /rescue/vi /etc/fstab` (I assume if you have a look round the / file system you can see the contents of the /rescue and /etc directories?


----------



## FR (Mar 6, 2013)




----------



## SirDice (Mar 6, 2013)

```
fsck -y
mount -u /
mount -a -t ufs
swapon -a
```
After that you should be able to edit anything you want.


----------



## usdmatt (Mar 6, 2013)

Apparently /rescue/vi is useless without /usr mounted. This may have been fixed or it may affect current versions as well.

At this point I would probably try and fix the other file systems with `# fsck -y` and then mount the rest of the system with `# mount -a`. This should make /usr available at which point both ee and vi should work. (Edit: SirDice beat me to it)


----------



## FR (Mar 6, 2013)

*W*hat are the commands to go on doing that?


----------



## FR (Mar 6, 2013)

`# mount -a -t ufs`

```
Mount: /dev/ad3s1e : No such file or directory
```


----------



## usdmatt (Mar 6, 2013)

Well this problem just gets more and more awkward.
It's using your /etc/fstab file in order to determine which file systems to check/mount which still contains the wrong information.

I've never done any of this but try the following (Assuming sed isn't another so-called 'rescue' command that doesn't work unless you already have a fairly working system):


```
/rescue/sed 's/ad3/ad0/' /etc/fstab > /etc/fstab.new
```

Use cat to output the contents of /etc/fstab and /etc/fstab.new. They should be the same other than the device name changing to ad0. Then use `# mv /etc/fstab.new /etc/fstab` to overwrite the original fstab and try the fsck again.


----------



## FR (Mar 6, 2013)

The rescue/sed was not found either. [cmd=]#cat /etc/fstab[/cmd] shows this though


----------



## usdmatt (Mar 6, 2013)

Ok, try the following


```
# fsck -y /dev/ad0s1f
# mount /dev/ad0s1f /usr
# vi /etc/fstab (change ad3 to ad0)
# reboot
```


----------



## FR (Mar 6, 2013)

You're the man! This did it. The VM (vAPP) is now running on vCloud.
THANK YOU :beergrin


----------



## wblock@ (Mar 6, 2013)

After getting into single user mode, I usually just remount / read/write (`# mount -u /`), cat(1) /etc/fstab, and manually mount /var, /tmp, and /usr.  It's not hard to do the substitutions mentally since you just had to do it for the / filesystem device.  After that, /etc/fstab can be edited.

But the problem can reappear any time a system is moved to different hardware.  Using filesystem labels or GPT labels makes your systems portable and more robust.  They are worth using even if you don't plan on changing hardware.


----------

