Re: Really odd BTX halted problem booting FreeBSD on VALinuxhardware
I've messed with these a lot and I'm pretty sure that the bios is trying to be 'compatible' with the geometry information it finds on the disk, Theoretically, if you set up a disk with one brand X disk controller, you'll get a different fake CHS mapping than you would with a brand Y controller. So, say you set up a machine and fdisk/label all your disks, then your controller dies, you go to the store and find that no identical one is available, you buy another one because you're uh, under pressure to get the machine working. With older controllers, things may not work right if the geometry was different than expected on the disk. So, theoretically a controller could read the geometry it finds there and then use whatever it finds as the right mapping. I think where the motherboard you mention gets hosed is when it tries to read the geometry and finds the bogus boot1 stuff there. Shrug. For me, I didn't even need 2 disks to make it fail -- single disk, and you cant even boot a floppy (or the disk) when it finds a partition table. I'll definitely switch to non-dangerous installs if/when the patch that was posted gets put in. In fact, I'll probably start using it anyway :) Fred The Adaptec BIOS is doing something really fugly when it doesn't find proper partition tables on the disks. It does it if ANY of the disks are done 'dangerously dedicated.' The easy solution: always put proper partitions on your disks. The hard solution: figure out what nastiness Adaptec is doing and slap their hand. -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd BTX halted problem booting FreeBSD on VALinuxhardware
I know I'm getting into this late but I can reliably reproduce this problem. I ran into it about 3 months ago when using a custom PXE-based installer for our SCSI boxes. I even annoyed -hackes and got John Baldwin to help me decode the register dumps. The IP does end up in the SCSI BIOS extension somewhere, which is really scary. ... The Adaptec BIOS is doing something really fugly when it doesn't find proper partition tables on the disks. It does it if ANY of the disks are done 'dangerously dedicated.' This also happens on IBM Netfinity 5600 servers (Adaptec 7890/91 on motherboard). Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd BTX halted problem booting FreeBSD on VALinuxhardware
On Fri, 27 Oct 2000, Paul Saab wrote: Mike Smith ([EMAIL PROTECTED]) wrote: :I'm just curious. How many disks are in this box? We saw something :similar here at work and it turned out that there were multiple disklabels :on the other disks and for somereason it was confusing the loader. :We dd'd the bad sections off and everything worked. Are you sure it's confusing the loader? Matt's fault address puts it in the BIOS at 0xc800, which is probably the SCSI adapter's BIOS... I wasn't 100% involved with the problem. Peter looked into and notice the disks had bogus labels (sometimes up to 3 labels on 1 disk) and when he removed them, the machines were happy again. We never looked into further because we just didn't have the time. I know I'm getting into this late but I can reliably reproduce this problem. I ran into it about 3 months ago when using a custom PXE-based installer for our SCSI boxes. I even annoyed -hackes and got John Baldwin to help me decode the register dumps. The IP does end up in the SCSI BIOS extension somewhere, which is really scary. To do it: 1. Pick a motherboard with built-in SCSI; the L440GX+ for instance. Put 2 or more disks on a controller. 2. Set the disks up dangerously dedicated, i.e. don't put proper MS partition tables on the disks. 3. Try to boot the box; watch BTX die in the same place every time. The Adaptec BIOS is doing something really fugly when it doesn't find proper partition tables on the disks. It does it if ANY of the disks are done 'dangerously dedicated.' The easy solution: always put proper partitions on your disks. The hard solution: figure out what nastiness Adaptec is doing and slap their hand. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd BTX halted problem booting FreeBSD on VALinuxhardware
If you do a hexdump on boot0 and the first sector of your disk, you'll see that boot0 has been copied onto your disk, broken partition table and all. If you then run fdisk on the disk and put in the 'right' number of sectors and let it automatically recalculate everything else, you'll get a decent fdisk table back. disklabel -B, in my opinion should either A) leave the partition table alone (even though it's part of the first sector too) or B) look at the freebsd label and automagically calculate what the values should be and put them in (as does fdisk -u when you 'Supply a decimal value for "size"' and dont explicitly calculate anything else, letting it calculate it for you. disklabel -B da0 disklabel -B da1 fdisk da0 ... The data for partition 4 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 5 (24 Meg), flag 80 (active) beg: cyl 0/ sector 1/ head 0; end: cyl 1023/ sector 63/ head 255 Fred -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd BTX halted problem booting FreeBSD on VALinuxhardware
On Fri, 27 Oct 2000, Robert Nordier wrote: Just doing the disklabel -w -r followed by the disklabel -B is creating a dangerously dedicated disk, which your BIOS apparently doesn't like. (See the first hex dump you did, where boot1 has ended up in the MBR.) That's why installing boot blocks is messing with the partition table, to answer the question you asked elsewhere. You need to dd and fdisk before the disklabel commands, which will give you a standard partition table (at the cost of 63 sectors of disk space). So why not just put a valid partition table inside the boot1 that gets put on sector zero? When boot1 gets dropped onto sector zero, it does hose the partition table, but there is no reason why a valid one couln't be put there insead of this broken one: Information from DOS bootblock is: The data for partition 1 is: UNUSED The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 5 (24 Meg), flag 80 (active) beg: cyl 0/ sector 1/ head 0; end: cyl 1023/ sector 63/ head 255 Why not edit the partition table after boot1 gets installed? Fred -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd BTX halted problem booting FreeBSD on VALinuxhardware
On Fri, 27 Oct 2000, Fred Clift wrote: If you do a hexdump on boot0 and the first sector of your disk, you'll see that boot0 has been copied onto your disk, broken partition table and a typo/thinko -- replace boot0 here with boot1 -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
