Install of 8-3-RELEASE renders hard drive unusable

This is a new one for me. I've used FreeBSD in the past (stopped March 28, 2009 when a port upgrade completely crashed my system). Anyway, this week, I was trying to access some files on my old system and thought I would install the latest release to move them to my current file system. I installed the system from a DVD burned from FreeBSD-8.3-RELEASE-i386-dvd1.iso. The DVD booted nicely. I was interested to see that the installation hasn't changed in the last 5 years. Anyway. I finished the installation (from the DVD, not over the network) and the sytem rebooted. Upon reboot, the system froze in the middle of the bios. The HP message to press escape to adjust bios options came up (very first screen during an HP laptop boot, before any boot managers, etc) and it froze there. I tried a number of fixes, attempted to reload the bios (as per HP voodoo), etc. Nothing worked. So I pulled both hard drives, put the windows drive back in as the primary drive, left the BSD physical drive out of the computer and voila, everything worked. No problem, I thought. I'll reformat the problem drive and start again. So I put the problem drive back into the computer, this time in the slot assigned for the secondary drive and damned if it didn't freeze at the exact same place. So I pull the drive and everything is OK. I don't know if anyone has seen this before. If the drive I tried to install FreeBSD is installed in the laptop, it does not allow the BIOS to complete loading. In either bay. I cannot fix the drive. Brand new toshiba 500 GB drive. Totally bricked.

HP/Compaq has historically had silly BIOS implementations that look for special partitions. You may have to attach the drive to another computer to erase it, or possibly connecting it through a USB adapter after the system has booted will be enough.

I'm a bit confused. Are you saying that the FreeBSD install blows away a partition (slice) on the hard drive without warning? Specifically a slice that is not involved in the install? Wouldn't this be a bug? And a big one? Because I was installing on a disk with a functioning OS (kubuntu) with a functioining boot loader. I specifically asked that the install make not changes to the MBR. The disk had originally been partitioned as 100% windows. No issues with rebooting. I deleted that. No issues with rebooting. I partitioned to three slices (linux prefers a slice for a swap). No issues with rebooting. I installed kubuntu. No issues with rebooting. I installed FreeBSD on the remaining third slice. System dies. Disk is a brick. Nothing should have been changed anywhere else except on the FreeBSD slice.

No, I'm saying that the HP/Compaq BIOS may be misidentifying a FreeBSD partition as something special that the BIOS would use, and then failing.

There's also a long-time bug in sysinstall(8) where it will write bootcode even when told not to. In that case, it would boot into FreeBSD.

Your disk is definitely not bricked totally, only on your non-standard Compaq machine that does not follow the most basic industry standards when it comes to hard drive partitioning. Connect it to another machine and it will work just fine.

Since nobody has mentioned it: first of all, try updating the BIOS on your HP machine to the latest available. This often fixes problems like these.

This issue has may be related to this thread.

Juanitou said:

This issue has may be related to this thread.

Click to expand...

That was illuminating. It seems this is a problem that is known with a (very complicated) solution. As I said in my original post, I have a disk with a lot of stuff on it from my days using FreeBSD. I switched to Microsoft about 3 years ago, because of "help" like:

"Your disk is definitely not bricked totally, only on your non-standard Compaq machine that does not follow the most basic industry standards when it comes to hard drive partitioning. Connect it to another machine and it will work just fine."

I'm off now. I've fixed the drive that FreeBSD's install broke. And just to be sure, I tried the same install on a Dell. Same thing happened. I guess they are "non-standard" too. I don't have time to confirm that the FreeBSD install bricks hard drives on every brand of computer. Indeed, I don't have time for this formerly great OS.

It's TRUE!

I don't have much time because I'm working with the problem right now. So my ideas and words can get cross, so I'll explain it the best I can. I have 10 partitions, the first three primaries are in this order -- FreeBSD's 9.1 December-4 version, 8.2 and 9.0 . I switch from the December 04, 2012 download ((version)) to the so-called RELEASE version December 30, 2012 (problem may be personal, because I don't think they are the same). I never build the kernel since FreeBSD 8.2 until yesterday for 9.1.

So finally we get the announcement and I download that file to be sure to have the latest copy in my mind. FreeBSD 9.1 did install well and very "strong" which I notice many times .. you can hear more churning into the tin as the system install, much more than the others (and no, this was not my imagination), I could feel it and it sounded good and made me happy! .. weird, I know, but true.

So as of yesterday, I decided to I build custom kernel with the same file as I used to build 9.0 kernel and the announced-FreeBSD 9.1 crash to vfs:,

[I waste lots of time wiping any partition before replacing it so there would never be an excuse of cross-bit or whatever.]

... so I reinstalled announced-FreeBSD 9.1 and build kernel with its own GENERIC file and it still crashed to vfs:. I did this more than a few times before concluding that with announced-FreeBSD 9.1, by chance, it could have been compromise even after the port system had been compromise. But I really feel that mistakes was made with the super-block, trying to rush-in the final [unnoticeable[/i] touches before New-Years.

I went back to wipe that partition for the final time. I reboot to FreeBSD-8.2 and it was gone .. so I booted to FreeBSD 9.0 and it was gone .. So I reinstalled my working MBR (backups) just to make sure and it did not help the situation in any kind of way...

All of my primary disk are gone and I am not about to hook it to my backup hard drive that has no FreeBSD 9.1 on it. I will be looking at that hard drive later in hope to see that at lease the extended partitions with no effects.


See the numbers below. I use these exact-size since 7.2 and I check these numbers with each and every install and they were always EXACTLY the same up until FreeBSD 9.0. I never tried 8.3 but I'm sure it has the new installer also. This was the beginning of understanding the real change to me and I feared upgrade from that day. I never build kernel with 9.0 and now I think the same thing might happen anyway since reading this thread about 8.3 Maybe this has relations, maybe not, but who would ever thought to see the change and now 9.1 maybe difference. I did not check this one. It's the only one I never checked until tonight maybe. I think it is the cause of the problem. If not, I like to see someone explain this other than to say "It gives you more free-bytes".



As you see the new installer provides more free BLOCKS, which I don't think is a good thing. I'm sure they dug deeper into this and the problems of the core could have just begun. It only make good since to go back to the old installer. The new one only plus is that it build slices in the order you make them and not by the size such as the var or tmp slices like the old installer did. That was all that had to be change, and gpart is far from excellent during installation. If sysinstall was not broken why fix-it? You suppose to just add to it!

I may be wrong but I have a feeling that core has been change since December 4 with something that did not change the size of the distribution, or maybe I even received a bad download .. All I know for sure is that it did not match the 8.2 block-size. Changing the all mighty SUPER-BLOCK would be the perfect way to lose at lease that present partition, but to loss all three primary would mean that there is a possibility that one of those new features in 8.3 than 9.1 created a virus/detour in the core, even on it's own.. It makes me think, if not after, that the core was compromise long before the ports to get all of the attention as the decoy just like in the spy movies (mission accomplished, ahead of time). I have no other idea until I explore this hard drive a bit deeper tonight. I'm very happy to have had my ZERO-DAY in advance.

I don't see my thread but that's because I am a new member I guest. The issue was too serious not to share immediately, so I posted, but I wrote that I did not do custom kernel for 9.0 but I had to in order to show those numbers. So much going on right now that I fogot what I'm taking about. Soo many version, and YES, build kernel worked for FreeBSD 9.0 but not for FreeBSD 9.1 as indicated above.

finarfinjge said:

That was illuminating. It seems this is a problem that is known with a (very complicated) solution. As I said in my original post, I have a disk with a lot of stuff on it from my days using FreeBSD. I switched to Microsoft about 3 years ago, because of "help" like:

"Your disk is definitely not bricked totally, only on your non-standard Compaq machine that does not follow the most basic industry standards when it comes to hard drive partitioning. Connect it to another machine and it will work just fine."

I'm off now. I've fixed the drive that FreeBSD's install broke. And just to be sure, I tried the same install on a Dell. Same thing happened. I guess they are "non-standard" too. I don't have time to confirm that the FreeBSD install bricks hard drives on every brand of computer. Indeed, I don't have time for this formerly great OS.

Click to expand...

Before you leave, how about you describe exactly what you did to solve this definitely-not-Compaq problem?

max21 said:

It's TRUE!

Click to expand...

What? Please be specific.

So as of yesterday, I decided to I build custom kernel with the same file as I used to build 9.0 kernel and the announced-FreeBSD 9.1 crash to vfs:,

Click to expand...

Wait--so FreeBSD 9.1 worked fine until you built a custom kernel which had not been updated? That sounds like a self-inflicted problem.

All of my primary disk are gone and I am not about to hook it to my backup hard drive that has no FreeBSD 9.1 on it. I will be looking at that hard drive later in hope to see that at lease the extended partitions with no effects.

Click to expand...

What does "gone" mean? Do they boot? Are the partitions missing?

See the numbers below. I use these exact-size since 7.2 and I check these numbers with each and every install and they were always EXACTLY the same up until FreeBSD 9.0. I never tried 8.3 but I'm sure it has the new installer also. This was the beginning of understanding the real change to me and I feared upgrade from that day. I never build kernel with 9.0 and now I think the same thing might happen anyway since reading this thread about 8.3 Maybe this has relations, maybe not, but who would ever thought to see the change and now 9.1 maybe difference. I did not check this one. It's the only one I never checked until tonight maybe. I think it is the cause of the problem. If not, I like to see someone explain this other than to say "It gives you more free-bytes".

Code:

FreeBSD 8.2

..................   size	 block	  Used	  free
/dev/ad4s1a	/	  11360	11173	   643	  9644

FreeBSD 9.0 GIVES

..................   size	 block	  Used	  free
/dev/ad4s1a	/	  11360	11001	   773	  9347

As you see the new installer provides more free BLOCKS, which I don't think is a good thing.

Click to expand...

It's not a good thing or a bad thing, the filesystem defaults are different in 9.x. How is this related to the unspecified disk problem?

I'm sure they dug deeper into this and the problems of the core could have just begun. It only make good since to go back to the old installer. The new one only plus is that it build slices in the order you make them and not by the size such as the var or tmp slices like the old installer did. That was all that had to be change, and gpart is far from excellent during installation. If sysinstall was not broken why fix-it? You suppose to just add to it!

Click to expand...

sysinstall(8) was and is badly broken. bsdinstall(8) has its own problems, but they are different and mainly in the realm of missing features rather than bugs.

I don't have much time because I'm working with the problem right now. So my ideas and words can get cross, so I'll explain it the best I can.

Click to expand...

I'm sorry, but that hard drive was my world being modified by 9.1 in a way that even an expert would have trouble trying to explain. If this was to happen to the wrong person/company he might find the nearest window to jump out of. That's the way I almost thinking before realizing I have half of that work on another hard drive.

I have one blank 500 GB hard drive that I just dd and I am in the process of rebuilding partitions exactly the way it was. Than I got to transfer my work by bits and pieces ... Than I got to clone it than remove the original and put it in a safe place. That's a lot of work. By 3:00AM I will have time to check out that drive using my cloned disk. This is an AMD machine with all 64bit FreeBSD OS in full control. Part of my plan was to have windows to live vBOX so I can learn more about FreeBSD more easily.

I can tell you right now that all of my partition are sill there. I saw them all while using a partitioning tool before pulling that drive. My work comes first than I'll be safe and sane enough to deal with that drive. I hope to post my finding by noon and I hope it was all my fault but I don't think so.

Thanks for the reply but don't make it sound like most is well when it not. Such as your comment about sysinstaller. If it was broken, don't replace it, fix it, than add your gpart for gpt and zfs to use. Don't make MBR users suffer in the process which I do see. I like FreeBSD too. How many can say they have no Windows primary partition? It's my job to protect FreeBSD by posting what I find and think.

False alarm! I just tried my so-call ZERO-DAY hard drive again. I must had been in panic mode that even caused me to join a forum. I was able to boot to partition 2 where FreeBSD 8.2 lives and I realized that I had wiped partition-3 to make ready for 9.1 also. As indicated already, I wiped partition one because I was ready to give up on 9.1.

Now that I have my thinking cap back on, I totally forgot that I been using FreeBSD 9.0 "CURRENT" on partition-1 and 3 all year long. That is the last FreeBSD that will compile my GENERIC_90 configuration file which is GENERIC with only unneeded drivers removed. So the only fact remain is FreeBSD 9.0 release and FreeBSD 9.1 release will not compile even its own GENERIC configuration file and there is no doubt about that. I tried too many times and and now I see it don't even work in the new FreeBSD 9.1. So, I'm sorry for dropping in! I need to start my own thread to ask other have they had the same problem. Somebody got to have experienced the same.

Both 9.0 and 9.1 fail to compile even itself on Gygabyte GA-VM900M as well as my older dell machine. These are my results since 1-12-2011 to 01-05-2012 ... now how can FreeBSD not know that.

Please do start a new thread. There are so many variables in what you're doing that it's hard to see what is going on. There is definitely a problem with your installation, because FreeBSD 9.0 and 9.1 will both compile the included GENERIC by default. How that is related to the booting problem is unclear.

I am seeing this again and again. Maybe there should be a fat red warning about faulty BIOS implementations in the new installer. This is slowly getting annoying when people accuse FreeBSD to break stuff when this is clearly the hardware which is buggy.

It's more than one problem with similar symptoms: BIOS finding a GPT PMBR and freaking out, BIOS finding an MBR that is not CHS aligned and failing, BIOS drive access mode (IDE/SATA/AHCI) somehow incompatible, installing over a multibooting setup and changing the bootcode, and I think there's also a problem on some machines with what MBR partition is set to active.

It's hard to find out which is at fault, as shown in this thread.

wblock,

BIOS drive access mode (IDE/SATA/AHCI) somehow incompatible, installing over a multibooting setup and changing the bootcode,

Click to expand...

I am not a intelligent techy person like yourself but I do know what a disk is suppose to look like after an install of any OS. Something that even experts never thought about. I been doing this since 7.2. seeking zero fragmentation for the love of my data. It became my hobby. I know jack else about nothing, except everything was fine until FreeBSD changed the system installers. I have no reason to lie. From that day this is what I got:

1)
Use any old hard drive. Make three primaries, formatted at FreeBSD-UFS and make at lease two partitions on the extended for a Linux OS and swap. Please use Partition Magic or Commander equivalent. .. If possible don't use gpart for this test because it may not show what I want you to see in real-life, but it might work.

2)
Than download an un-sophisticated version of Linux (the kind of OS that ask for permission for everything), 2011 or earlier. I use Arch Linux 2.6.30 out of 2009 to take care of my partitions. (That's the only job I don't give to FreeBSD.)

Don't forget to install nano and grub.

Under menu.lst type this:


Finish the install and reboot .. "OR".. simply type <cfdisk> and take a peep at what should be expected when you come back after installing FreeBSD 9x. As you see nothing is broken

While you are there, play around and make a copy of the MBR if you have time. You get the entire super-clean MBR with this command.


... After you reboot you will than install FreeBSD 9.1 on primary 1, MBR style! After installing don't boot FreeBSD, boot Arch and go back to cfdisk and wittiness for yourself the real changes done to your pre-set MBR.

RESULTS:
The install busted apart PRIMARY 1, leaving about 2mb or more of free space taken out that partition, which changed the structure of the original MBR that you created for this test.

Do the same thing with 8.2 and see what you get ... With no gpart for gpt in the installer you get an perfect install.

PcBSD 9.0 and 9.1 also gives you a perfect install because the author knows the problem and did his own math and the lost/gain of those gpart numbers is taken from "YOUR" silces and not the entire partition. Once the installer finish, you will come up with 4 -400 MB missing from the total amount installed. Basically, PcBSD rob Peter to pay Paul. If you can prove difference it will help my sanity.

I had to do hundreds of installs just to insure that every slice provide the exact amount of "free space" that I wanted for each and every slice, until perfection' than the entire disk. It takes a lot of time so and need nothing to change.

4643-mb will give you exactly 4200-mb of free space /var

So I know when FreeBSD changes things. I never change my sizes, I just give it more partitions and 21 is my max.

Could you please show the output of gpart show before and after the breakage?

I do believe there is a problem, but can't tell what it is or what is causing it. And to repeat, filesystem free space may look different in FreeBSD 9.x, because the filesystem uses 4K fragment sizes by default. FreeBSD 8.x used 2K. There may be other differences, like the number of inodes allocated by default when filesystems are created by the installer. Those differences are cosmetic; they should not keep a system from booting or break a partition table.

Another difference with the latest installer is that it should be aligning partitions to 4K sectors. That could create some small unused spaces when done on a drive with unaligned space before or after the new partitions.

Tried updating your BIOS?

The BIOS freezing when it sees a disk it doesn't like is a fault.

Your BIOS is broken. It should not be possible to cause your BIOS to freeze with stuff done to an attached hard disk - whatever FreeBSD or any other OS may have done to it.

FreeBSD may have done something to your disk that your BIOS doesn't like, but the freezing of your machine in the BIOS is not FreeBSD's fault.

But it booted until GENERIC was rebuilt...

In any case, we need more details.

Sorry I should have made reference to the poster I was referring to - the OP...

But either way, as far as I'm concerned - it should not be possible for content on a disk to crash your BIOS (thereby rendering the disk unusable and unrecoverable in that machine). Unless the BIOS is blindly trying to load it as EFI firmware extensions or similar?

If the BIOS dies in an unrecoverable way when a disk is plugged in, there is a fault in the BIOS implementation, IMHO. Which hopefully has been fixed in a BIOS update?


Sure, FreeBSD may have uncovered the bug, but...

wblock,

Could you please show the output of gpart show before and after the breakage?

Click to expand...

I can't because it's finally worked, but if you need me to dupicate every thing I will. As of now it's good to know that gpart or hardware have no effect on the build kernel process. I worried all year for the wrong reasons, but I still have an concern about how gpart do its math. Listed below is the result of my working system and something is still very strange because gpart numbers don't seem to be matching up.

This is my permanent setup and the machine I'll be using for test things. If you duplicate this setup than you'll know for sure that my number are accurate. For me it makes it easy to remember exactly how much free space I had per-slice and it follows a lot of tips found here in the past such as you should have 60MB more of tmp space than swap.

Test machine
Gigabyte GA-880GA-UD3H
HITACHI sata 3.0
Patriot DDR3 8-GB
AMD Phenom II 975
Nothing else is attached other than standard mouse/keyboard


Partition 1 - SLICE SIZES
20-GB - 1024 x 20 + 100 = under Partition Commander 20580MB | under Arch 21583.14

.
gpart show

I got this tip a few years ago reading another a thread posted by member here. Since than I always leave 7mb (with the new installer reading of 7150kb) of free space after the last slice but gpart shows a whopping 110 MB of free space !!! This make no sense. This is the kind of thing that got me concerned about gpart numbers long ago. The list of SLICE-SIZE above are 100% accurate, same here with these gpart show numbers (but manually typed in). Also, notice that slice 7 and 8 were made at the exact same size but the numbers are difference. Both slices had nothing inside since being created and I did live exactly 7mb up under them. Once you find out could you please let me know why these numbers are not matching up and what effect does it have on the system such as will it weaken partition boundary, does it have an effect on ZFS, can it effect running programs, etc? I'm thinking it may have an unseen effect on ZFS. You may need time but please don't forget. If you need more info or anything else just let me know. Just tell FreeBSD to wipe their disk, restore with an fresh MBR and start out clean each and every time when they add new stuff to the system that way I don't have to worry so much . I always wanted to tell them that because it don't take much to bring down an entire empire down these days.

Thanks wblock

The gpart(8) output is missing the MBR. gpart show should list both the MBR on ada0 and the the FreeBSD slice information in ada0s1 shown above.

It's hard to guess what might have gone wrong. gpart(8) works well for me, and I trust it, but there have been bug fixes since 9.0-RELEASE. AFAIK, the version with 9.1-RELEASE has no surprises. If you can find a way to reproduce the problem, that would go a long way toward solving it.

Oh, and a note about MBR. MBR is an old, old format. It's so old that the kernel aligns it to CHS (cylinder, head, sector) values that do not and have not applied to drives made in the last couple of decades. This is kind of like using -a63 with gpart(8). So the size and location of partitions may not be exactly what was requested.

If you can, please use GPT. It is much simpler because you don't have to deal with two or even three types of partitioning, one inside the other (slice->extended partition->FreeBSD partition). It does not have to be aligned to CHS values. The two reasons not to use it are if your BIOS is confused or you run operating systems that don't yet support GPT (Windows, but maybe some Linuxes... er, Linuxi, ... Linii?). Or if it interferes with metadata from some other format, like gmirror(8). Three, three reasons.

posted this in wrong area:
ok:

The gpart(8) output is missing the MBR. gpart show should list both the MBR on ada0 and the the FreeBSD slice information in ada0s1 shown above.

Click to expand...

What you see is all it gave me. Your install and everyone else is working, that means I got a bad download. No way to have three machines all with non-working BIOS. I think i have missing drivers and I plan to find out.

My three reasons.
Old wine taste better. My OLD lady is sweet. Earth is old and the universe is older. Old been good to me MBR provide dual booting, GPT took it away. MBR been in motion/theory BC. With GPT you must pray each day that those numbers will never bit you. Beside, IBM and Sony got something coming that may combined and "out do" both MBR and GPT in just an few more years. And most important, FreeBSD will never, ever let MBR down. Running on good old hardware is their claim to fame. GPT will die younger than MBR. I rather wait, but I got to learn how-to ZFS so I might be force to try it.

http://www.dedoimedo.com/computers/kdump-vfs-error.html

I'll reproduce those errors before this week is out. If I wasted an entire year, a few more days to find out why can't hurt.