UFS Mounting old partitions after upgrade mishap

olwin

olwin

Had a failed upgrade of my system from 12.3 to 13.0 that resulted in corrupted boot loader, i.e the system wouldn't boot. After trying around wit that problem and not solving it without overwriting data I decided to install a fresh version 13 on another drive and mount the filesystems on the old drive from there. However, that has so far failed miserably, despite my research. It's probably an easy fix, but I'm lost.

Active, working disk:

Code: 
root@ticker:/home/olwin # gpart show da0
=>       63  209715137  da0  MBR  (100G)
         63          1       - free -  (512B)
         64  209715136    1  freebsd  [active]  (100G)

root@ticker:/home/olwin # gpart show da0s1
=>        0  209715136  da0s1  BSD  (100G)
          0  201326592      1  freebsd-ufs  (96G)
  201326592    8388544      2  freebsd-swap  (4.0G)

root@ticker:/home/olwin # more /etc/fstab
# Device        Mountpoint      FStype  Options Dump    Pass#
/dev/da0s1a     /               ufs     rw      1       1
/dev/da0s1b     none            swap    sw      0       0
root@ticker:/home/olwin #

The disk I want to mount:
Code: 
root@ticker:/home/olwin # gpart show da1
=>       63  524287937  da1  MBR  (250G)
         63  524281212    1  freebsd  [active]  (250G)
  524281275       6725       - free -  (3.3M)

root@ticker:/home/olwin # gpart show da1s1
=>        0  524281212  da1s1  BSD  (250G)
          0  104857600      1  freebsd-ufs  (50G)
  104857600  377487360      4  freebsd-ufs  (180G)
  482344960   41936252      2  freebsd-swap  (20G)
Any help would be appreciated
 
I would mount the old disk on /mnt for the purpose of copying valuable configuration files and data to the new disk.
 
So old drive is sliced, old style formatted. When the new system is up, with old drive plugged in at da1, what is the output of:
ls -ltr /dev/da1*
There will a few at least, I'm guessing
da1s1a probably the 50G partition
da1s1b probably the 20G swap partition
da1s1d probably the 180G partition

Then as root, simply
mount /dev/da1s1a /mnt
then see what's on /mnt, when done,
umount /mnt
then
mount /dev/da1s1d /mnt
see what's on /mnt when done
umount /mnt
 
To mount the "A" and "D" slices use /dev/da1s1a for your 50GB slice and /dev/da1s1d for your 180GB slice. For future installation avoid using the old BSD slices and migrate to GPT.
To mount them it should look like this:
mkdir /mnt/1
mkdir /mnt/2

mount /dev/da1s1a /mnt/1
mount /dev/da1s1b /mnt/2
 
mer said:
So old drive is sliced, old style formatted. When the new system is up, with old drive plugged in at da1, what is the output of:
ls -ltr /dev/da1*
There will a few at least, I'm guessing
da1s1a probably the 50G partition
da1s1b probably the 20G swap partition
da1s1d probably the 180G partition

Then as root, simply
mount /dev/da1s1a /mnt
then see what's on /mnt, when done,
umount /mnt
then
mount /dev/da1s1d /mnt
see what's on /mnt when done
umount /mnt
Click to expand...

This is pretty much what I was trying to do, from previous experience, but alas:
Code: 
root@ticker:/home/olwin # ls -ltr /dev/da1*
crw-r-----  1 root  operator  0x60 Jun  9 11:50 /dev/da1s1
crw-r-----  1 root  operator  0x5c Jun  9 11:50 /dev/da1
crw-r-----  1 root  operator  0x63 Jun  9 13:15 /dev/da1s1a
crw-r-----  1 root  operator  0x66 Jun  9 13:15 /dev/da1s1b
crw-r-----  1 root  operator  0x67 Jun  9 13:15 /dev/da1s1d
root@ticker:/home/olwin # mount /dev/da1s1a /mnt
mount: /dev/da1s1a: No such file or directory
root@ticker:/home/olwin #
 
That is weird.
Is dmesg showing anything odd?
Are you typing in /dev/da1s1a or cut and paste with the mouse? If cut and paste, try typing just to make sure no weird characters
 
VladiBG said:
What is the output of:
file -s /dev/da1s1a
fstyp /dev/da1s1a
Click to expand...

The only "weird" thing with my setup is that they're VM:s on a Vmware platform. Other than that, nothing out of the ordinary
Code: 
root@ticker:/home/olwin # file -s /dev/da1s1a
/dev/da1s1a: DOS/MBR boot sector, BSD disklabel
root@ticker:/home/olwin # fstyp /dev/da1s1a
fstyp: /dev/da1s1a: filesystem not recognized
root@ticker:/home/olwin #
 
mer said:
That is weird.
Is dmesg showing anything odd?
Are you typing in /dev/da1s1a or cut and paste with the mouse? If cut and paste, try typing just to make sure no weird characters
Click to expand...

Typed - and no difference

From dmesg:
Code: 
Root mount waiting for: CAM usbus0 usbus1
da0 at mpt0 bus 0 scbus2 target 0 lun 0
da0: <VMware Virtual disk 2.0> Fixed Direct Access SPC-4 SCSI device
da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit)
da0: Command Queueing enabled
da0: 102400MB (209715200 512 byte sectors)
da0: quirks=0x140<RETRY_BUSY,STRICT_UNMAP>
da1 at mpt0 bus 0 scbus2 target 1 lun 0
da1: <VMware Virtual disk 2.0> Fixed Direct Access SPC-4 SCSI device
da1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit)
da1: Command Queueing enabled
da1: 256000MB (524288000 512 byte sectors)
da1: quirks=0x140<RETRY_BUSY,STRICT_UNMAP>
 
The filesystem on /dev/da1s1a is corrupted or there's no UFS on it. Check the same command fstyp /dev/da1s1d to see if the filesystem is detected on the other slice.
 
VladiBG said:
The filesystem on /dev/da1s1a is corrupted or there's no UFS on it. Check the same command fstyp /dev/da1s1d to see if the filesystem is detected on the other slice.
Click to expand...
Very much the same with d.

And:
Code: 
root@ticker:/home/olwin # fsck_ufs -y /dev/da1s1
** /dev/da1s1
Cannot find file system superblock
root@ticker:/home/olwin # fsck_ufs -y /dev/da1s1a
** /dev/da1s1a
Cannot find file system superblock
root@ticker:/home/olwin # fsck_ufs -y /dev/da1s1d
** /dev/da1s1d
Cannot find file system superblock
 
Is it possible these partitions were encrypted? Do you remember or know?
 
The order of the partitions is a little weird though. But that may have been the result of a couple of years of managing it and moving some things around.
 
SirDice said:
The order of the partitions is a little weird though. But that may have been the result of a couple of years of managing it and moving some things around.
Click to expand...
Old installation with many upgrades, that's true. Totally pain-free until now
 
I'm out of ideas here. Maybe i would try with testdisk(1) to search for valid superblock and rebuild the partition information.
Do you remember what you did after the upgrade from 12.3->13.0.
 
VladiBG said:
I'm out of ideas here. Maybe i would try with testdisk(1) to search for valid superblock and rebuild the partition information.
Do you remember what you did after the upgrade from 12.3->13.0.
Click to expand...
Well, I didn't do anything really. Used freebsd-upgrade, like I did on two previous machines the days before - only this time it disconnected during the second install run. And that's when it wouldn't boot again.

Like:
no ufs
no ufs
No /boot/loader
If I remember correctly
 
olwin said:
only this time it disconnected during the second install run
Click to expand...
Disconnected how? The console or ssh session from which you ran freebsd-update(8)? Or did the storage backend disconnect from the VMWare host? All the first freebsd-update install does is update the kernel. That's a fairly quick process. The second install run is a little more involved but it would certainly not completely hose the entire filesystem on all your partitions. The upgrade process is just an elaborate copying of files. If it got interrupted you could end up with a few broken files here and there, or at the very least a partially completed copy of the new files. I don't see how this could possibly corrupt the whole UFS filesystem.
 
freebsd-update doesn't touch your bootloader or MBR so it must be something else. Did you try to update your MBR or install a bootloader using gpart?
 
SirDice said:
What does hexdump -C -n 64 /dev/da1s1a output?
Click to expand...
Code: 
root@ticker:/home/olwin # hexdump -C -n 64 /dev/da1s1a
00000000  eb 3c 00 00 00 00 00 00  00 00 00 00 02 00 00 00  |.<..............|
00000010  00 00 00 00 00 00 00 00  12 00 02 00 00 00 00 00  |................|
00000020  00 00 00 00 00 16 1f 66  6a 00 51 50 06 53 31 c0  |.......fj.QP.S1.|
00000030  88 f0 50 6a 10 89 e5 e8  c0 00 8d 66 10 cb fc 31  |..Pj.......f...1|
00000040
 
VladiBG said:
freebsd-update doesn't touch your bootloader or MBR so it must be something else. Did you try to update your MBR or install a bootloader using gpart?
Click to expand...
I didn't do anything other than an ordinary freebsd-update, that's why I'm so bewildered by the outcome
 
SirDice said:
Disconnected how? The console or ssh session from which you ran freebsd-update(8)? Or did the storage backend disconnect from the VMWare host? All the first freebsd-update install does is update the kernel. That's a fairly quick process. The second install run is a little more involved but it would certainly not completely hose the entire filesystem on all your partitions. The upgrade process is just an elaborate copying of files. If it got interrupted you could end up with a few broken files here and there, or at the very least a partially completed copy of the new files. I don't see how this could possibly corrupt the whole UFS filesystem.
Click to expand...
The ssh session disconnected, I had to leave it for a little while because of other business.

Thought about your encrypted question and realised I wasn't the one doing the initial setup, but a contractor. He _might_ have opted for encryption, but I have no idea why and he's quit a long time ago so I can't ask
 
olwin said:
The ssh session disconnected, I had to leave it for a little while because of other business.
Click to expand...
Ok, just a tip if you do this over a remote connection, run the update on a sysutils/screen or sysutils/tmux session. If you lose the connection the process will simply continue and you can pick up the session again when you reconnect. Still though, at worst this would just cut off the copy process and it won't have completely copied all the new files. Nothing that would or could cause a major filesystem corruption.

I feared you may have unintentionally overwritten the partitions with bootcode in an attempt to fix it. But the hexdump doesn't show bootcode, it does show some data there though.

It's a weird long shot but what does zpool import show?
 
SirDice said:
Ok, just a tip if you do this over a remote connection, run the update on a sysutils/screen or sysutils/tmux session. If you lose the connection the process will simply continue and you can pick up the session again when you reconnect. Still though, at worst this would just cut off the copy process and it won't have completely copied all the new files. Nothing that would or could cause a major filesystem corruption.

I feared you may have unintentionally overwritten the partitions with bootcode in an attempt to fix it. But the hexdump doesn't show bootcode, it does show some data there though.

It's a weird long shot but what does zpool import show?
Click to expand...
Thanks for the tip, I'll try that next time.

Still confused about what happened, I've made several upgrades and nothing like this before.

root@ticker:/home/olwin # zpool import

no pools available to import
 
You must log in or register to reply here.
Back
Top