# Fresh clean install of vers. 12.0; error 19 problem =>Mountroot



## jaymax (Jan 20, 2019)

I have completed several 'repeat' installation of release 12.0 from an ISO disc to a 'new' clean HD using the GPT formatting option. As a pre-installation step of each, the prior file partition(s) were deleted and then then the disk filesystems was destroyed. At the initial startup and subsequent reboots the system hangs at the 'mount' step. Mounting with the mountroot>ufs:/dev/da2p2 seems to complete the sequence of steps. This does not matter, whether the fstab file is manual or system generated.
However, prior to tne mount step there is a long period of waiting for the da2p2 slice.

Thanks!


----------



## jaymax (Jan 22, 2019)

jaymax said:


> I have completed several 'repeat' installation of release 12.0 from an ISO disc to a 'new' clean HD using the GPT formatting option. As a pre-installation step of each, the prior file partition(s) were deleted and then then the disk filesystems was destroyed. At the initial startup and subsequent reboots the system hangs at the 'mount' step. Mounting with the mountroot>ufs:/dev/da2p2 seems to complete the sequence of steps. This does not matter, whether the fstab file is manual or system generated.
> However, prior to tne mount step there is a long period of waiting for the da2p2 slice.
> 
> Thanks!


I should have mentioned, that this is an OS in an external disk configuration. Again mounting from the mountroot prompt only makes the system disk available, other disks, cdrom etc. would each have to be added separately as the fstab file is not seen or run.


----------



## T-Daemon (Jan 23, 2019)

If you are using an external USB system disk, or have other USB disks set in /etc/fstab, then you should label the disk devices - for MBR: 18.7. Labeling Disk Devices, for GPT: Labeling partitions done right ... [1]. USB drives have the tendency to move the disk names around when other devices are attached. /dev/da1 might become /dev/da2 e.g. .

Can you post the output of`ls /dev | grep da` and the content of  /etc/fstab.

Edit:
[1] For later reference, modified disk labeling documentation, added k.jacker’s excellent “Labeling partitions..” how to.


----------



## jaymax (Jan 23, 2019)

I usually label my disks for this very reason but had not done this yet, as the USB device configuration was consistent in dmesg on each installation step and I was still working on my set up. However the data is as follows;

`ls dev | grep da`

```
dev/da0  /dev/da0s1  /dev/da1  /dev/da1s1  /dev/da2  /dev/da2p1  /dev/da2p2  /dev/da2p3
```

fstab
`cat /etc/fstab`

```
# Device    Mountpoint    FStype    Options        Dump    Pass#
/dev/da2p2       /                ufs           rw                 1            1
/dev/da2p3    none            swap         sw                0            0
/dev/cd0          /cdrom        cd9660    ro,noauto     0            0
```

partitions on disk
`gppart show da2`

```
40  3907029088  da2  GPT  (1.8T)
                40          409600    1  efi  (200M)
         409640  3898195960    2  freebsd-ufs  (1.8T)
  3898605600       8388608    3  freebsd-swap  (4.0G)
  3906994208           34920       - free -  (17M)
```

With this GPT configuration, I am not sure if the 'efi' slice is the 'boot' partition and if I should add the *'bootme'* attribute to it.


----------



## k.jacker (Jan 23, 2019)

Why not just try *ufs:/dev/da0p2* or *ufs:/dev/da1p2* at the prompt, when booting is aborted. It's just those two possibilities.
Then fix your fstab and apply labels.


----------



## jaymax (Jan 25, 2019)

I am going to make a more detailed POST of the problem


----------



## k.jacker (Jan 25, 2019)

After rereading your first post, it seems your problem is not about /etc/fstab. The delay when you boot, may be related to your usb port or drive take to long to get ready. From my own experience, I know that ASmedia USB 3.0 controller are very unreliable to boot from. In case you have your drive connected to one of those, try to connect it to a USB 2.0 port. Additionally, looking through available sysctl variables, _vfs.root_mount_allways_wait_ could be what you need. I‘d try setting it to 1 in /etc/sysctl.conf and give it a try.


----------



## jaymax (Jan 25, 2019)

See expanded post and apparent solution at possible solution


----------

