Mounting from ufs: /dev/ad0s1a failed with error 19

Hi to all.
Sorry for possible doubling, but need help to start a gateway.
After upgrading FreeBSD 8.4 -Stable to FreeBSD 9.3-RELEASE-p45
System doesn't boot correct, it stop on:
Code:
Trying to mount root from ufs: /dev/ad0s1a [rw]
mountroot: waiting for device /dev/ad0s1a
Mounting from ufs: /dev/ad0s1a failed with error 19.

Loader variables:
   vfs.root.mountfrom=ufs:/dev/ad0s1a
   vfs.root.mountfrom.options=rw
As I'm discovered disk name change from ad to ada
So try next command
Code:
ufs:/dev/ada0s1a
Trying to mount root from ufs:/dev/ada0s1a []...
mountroot: waiting for device /dev/ada0s1a
Mounting from ufs:/dev/ada0s1a failed with error 19.
If I typed "#mountroot> ?" it show next:
Code:
#mountroot> ?
List of GEOM managed disk devices:
gptid/a11c69e7-......here is a long id ada0p3 ada0p2 ada0p1 ada0
So it looks like disk become GPT, but they are not
Here is info from liveCD mode
Code:
#gpart show ada0
=>    1   78240862   ada0   MBR   (37G)
   1   62     -free-             (31K)
   63   78239889    1   freebsd   [active]  (37G)
     78239952   911       -free-      (456K)
here is the content of old fstab :
Code:
mount /dev/ada0s1a /mnt
cat /mnt/etc/fstab
/dev/ad0s1a / ufs rw 1 1
/dev/ad0s1a none swap sw 0 0
/dev/ad0s1a /tmp ufs rw 2 2
/dev/ad0s1a /var ufs rw 2 2
/dev/ad0s1a /usr ufs rw 2 2

Sorry for misunderstood, I'm a newbie.
Can any one explain please for me, what goes wrong?
How to recover, is it possible? Or do I need to make a fresh install?
 
Here is a photo of screen where it stops:
gptiddisks.jpg
 
Try booting from an 9.3-RELEASE install media and update the bootsector. Make sure you use the bootsector for MBR. The change from ad0 to ada0 doesn't change the partitioning scheme, only the name of the drive. I'm guessing the bootsector is pretty old.
 
I have already 10.3 RELEASE media. Can I use it?
Sorry, but can you please paste a command line, how should I do this, update bootsector in my case.
Thank you.
 
Yes, I think you can use 10.3 too. This should do it: gpart bootcode -b /boot/boot0 ada0
 
Update boot code. It doesn't help. The same it hang on
mountroot>
See upper post.
 
The problem that I'm not using GPT, I'm using MBR (that was pretty old system).
May be there some problem in kernel? How can I safely recompile a kernel ? may it nned some loader configuration?
 
Figure out what wrote a GPT partition table to the drive. Although that is unlikely. Also, your old /etc/fstab is not going to work. All the mountpoints are the same partition, and if swap was started, it overwrote that partition.
 
Sorry here is a real fstab
Code:
cat /mnt/etc/fstab
#Device           Mountpoint      FSType        Options       Dump       Pass#    
/dev/ada0s1a         /            ufs             rw            1            1
/dev/ada0s1b         none         swap            sw            0            0
/dev/ada0s1e         /tmp         ufs             rw            2            2
/dev/ada0s1d         /var         ufs             rw            2            2
/dev/ada0s1f         /usr         ufs             rw            2            2
Do you know how to resolve it. Can I erase a GPT marks only, is this possible?
Some one tell to run something like this in example
Code:
dd if=/dev/null of=/dev/ada0 bs=512 oseek=1
dd if=/dev/null of=/dev/ada0 bs=512 oseek="LBA-1" // = 78240861
The previous system was 8.4-STABLE with GEOM_MBR default, new 9.3 is GEOM_GPT default, in previous old kernel someone compile own kernel with
Code:
#options        GEOM_LABEL      # Provides labelization
#options        GEOM_PART_GPT   # GUID Partition Tables.
So that, why I think, system was bootable.
And this someone workaround such a job to make system start before.
And here is gpart show ada0s1
Code:
# gpart show ada0s1
=>         0          78239889          ada0s1             BSD              (37G)
           0           2097152               1             freebsd-ufs    (1.0G)
     2097152           2061952               2             frebsd-swap    (1.0G)
     4159104           9418752               4             freebsd-ufs     (4.5G)
    13577856           2097152               5             freebsd-ufs      (1.0G)
    15675008          62564881               6             freebsd-ufs      (30G)
How to fix it?
Note: I'm booting liveCD from 10.3, but problematic system kernel is 9.3-RELEASE-P45
 
The default in the kernel is not a problem, it's what is on disk that is a problem.

It's hard to tell the sequence of events. Sounds like the disk was always GPT, then a custom kernel was built to prevent GPT.

If it were me, I'd make sure it's all backed up. To repeat, do not mess with that disk until a full backup exists, created with dd(1) if necessary. Then:

gpart destroy -F ada0 to remove the GPT partitioning
gpart create -s mbr ada0 to really set it to MBR
gpart add -t freebsd -s [I]size[/I] ada0 to add a single slice. Size would be calculated by adding the start and size of the last FreeBSD partition to get the full slice size needed to hold all those partitions. I would round it up a bit to make sure there is extra room.

The FreeBSD partitioning information in ada0s1 is already there, so this should be all that is needed. Of course, it could all go horribly wrong, which is why the backups beforehand are not optional.
 
Hey, look what happens.
Wrote a i386-9.3-RELEASE image to DVD, boot from it,
run a "gpart show ada0" and guest what?
Code:
=> 34 78240796 ada0 GPT (37G)
34 128 1 freebsd-boot (64k)
162 73400192 2 freebsd-ufs (35G)
73400354 3911680 3 freebsd-swap (1.9G)
77312034 928796 - free - (453M)
It's say and think exactly as installed kernel, it think that disk is GPT. But disk with 10.3-Release, say as described above early in this thread. Is this possible now to make system boot and mount partitions?
 
I had the same the same thing today with a usb drive. At the mountroot> prompt i put ufs:/dev/da4/p2 rw
i needed the rw for it to boot. Hope its helps.
 
>I had the same the same thing today with a usb drive.

You had that problem for reason probably you removed the installation USB drive after installation and cause after reboot your main USB drive shifted down from /dev/da1... tpo /dev/da0...
 
Thanks maks - just want to say thanks as this happened to me also. I then used the DVD to do the install and didn't have to mess about figuring dev demarcations!
 
Back
Top