Help finding correct values for bsdlabel

Hello!

I'm in trouble with a freebsd installation. After a hard reboot, my installation don't boot. Just show 'Not ufs' on screen.

Booted from live CD show that the label of the disk is:

Captura.JPG


I think that this is not correct. I don't have a backup of the label or remember the correct values, but the machine don't boot.

How can I find the correct values ?

Thanks!
 
What FreeBSD version does this involve anyway? Because modern versions require at least 2 partitions: one of type freebsd-boot and one of type freebsd-ufs. Of course that implies either MBR and / or a GPT partition scheme while you use BSD. Not necessarily wrong but also not very often used anymore.

However... that setup also implies that you'd be using one partition which is split into multiple virtual filesystems ("slices"). That methodology is also pretty much deprecated. But if you are using this approach then something seems to have gone wrong because that partition would then require the freebsd partition type instead of freebsd-ufs.

(edit)

My guess is that this also explains why bsdlabel failed. - Ignore this line, bsdlabel did not fail, I was a little too hasty when glossing over the "8 partitiions" comment. But bsdlabel(8) shows that this is the intended output, so my previous comment is wrong. Even so... the argument about the wrong partition type, according to gpart, obviously still stands.

You could try using file to see if it recognizes something. Use file -s /dev/da0.... Check /dev for the right device node, I have no idea from mind what the naming scheme should be, but ls will show you.
 
What FreeBSD version does this involve anyway? Because modern versions require at least 2 partitions: one of type freebsd-boot and one of type freebsd-ufs. Of course that implies either MBR and / or a GPT partition scheme while you use BSD. Not necessarily wrong but also not very often used anymore.

However... that setup also implies that you'd be using one partition which is split into multiple virtual filesystems ("slices"). That methodology is also pretty much deprecated. But if you are using this approach then something seems to have gone wrong because that partition would then require the freebsd partition type instead of freebsd-ufs.

My guess is that this also explains why bsdlabel failed.

You could try using file to see if it recognizes something. Use file -s /dev/da0.... Check /dev for the right device node, I have no idea from mind what the naming scheme should be, but ls will show you.

Thanks ShelLuser. Yes, this is an old server with freebsd 8.

I recovered the /etc partition from a filesystem backup. This is fstab:

Code:
# Device        Mountpoint      FStype  Options Dump    Pass#
/dev/da0s1a     /               ufs     rw      1       1
/dev/da0s1b     none            swap    sw      0       0

Inside /dev there's only da0 and da0a

Thanks ....
 
ShelLuser I deleted the partition using gpart and got 'invalid argument' if I use -t freebsd intead of -t freebsd-nfs when adding a new partiton.
 
Then I think you should be focusing on upgrading that system first. FreeBSD 8 has been End of Life / unsupported for nearly 3 years already. Running outdated operating systems, especially while connected to the Internet, is highly inappropriate and extremely risk full.

(edit)

Hm, if you deleted the partition then you're pretty much back to square one. In that case my suggestion would be to download a supported release, install that and then restore a backup. Seems like the best option you have right now.
 
Then I think you should be focusing on upgrading that system first. FreeBSD 8 has been End of Life / unsupported for nearly 3 years already. Running outdated operating systems, especially while connected to the Internet, is highly inappropriate and extremely risk full.

I can't boot or access the filesystem. Impossible to update freebsd. I can update it if I recover access to it.
 
Then I think you should be focusing on upgrading that system first. FreeBSD 8 has been End of Life / unsupported for nearly 3 years already. Running outdated operating systems, especially while connected to the Internet, is highly inappropriate and extremely risk full.

(edit)

Hm, if you deleted the partition then you're pretty much back to square one. In that case my suggestion would be to download a supported release, install that and then restore a backup. Seems like the best option you have right now.

Even if I do this, I need to access the old filesystem. I dont need to boot the old filesystem, just gain access to it.
 
I can't boot or access the filesystem. Impossible to update FreeBSD. I can update it if I recover access to it.
Remove the disk, insert a new disk, install supported version of FreeBSD. Then try to recover as much as possible from the 'old' disk using a different machine.

An upgrade from such an old version is going to be problematic. And the original disk has a weird setup in any case (it looks like a "dangerously dedicated" install). Best not to use as a base for newer FreeBSD versions.

Edit: Your fstab doesn't look like a "dangerously dedicated" disk though. But you are missing the slice, bsdlabel partitions are created inside a slice.
 
What FreeBSD version does this involve anyway? Because modern versions require at least 2 partitions: one of type freebsd-boot and one of type freebsd-ufs.

Ups! Why didn't I notice this? My partitions look just like this and all of them are booting fine:
Code:
$ gpart show /dev/ada3
=>       63  234441585  ada3  MBR  (112G)
         63   12582912     1  freebsd  [active]  (6.0G)
   12582975   55838018     2  !191  (27G)
[...]

juanjico: The problem is, Your partition seems damaged. What You see in the output from bsdlabel (in the first posting) is probably a default entry. bsdlabel may create that if it doesn't find useful information on disk.
According to your fstab you had a structure with fdiskslice+packlabel, but what bsdlabel shows is a structure with only packlabel, so that is likely bogus.
It could be worth the effort to rewrite the fdiskslice, hoping that the filesystem itself (or even the packlabel) is still intact. But thats ambitious and may damage more, so SirDice's suggestion to first create a proper running system on a new disk, and then analyze from there, is the better option.
 
Back
Top