Re: machine won't start
On Wed, Jul 4, 2012 at 2:58 AM, Edward M martinezedward...@gmail.com wrote: On 07/03/2012 02:15 PM, Carsten Mattner wrote: At that point I hit hard (cold) reset and since that time the machine won't leave the BIOS startup phase (POST?). Took out the CMOS battery for a minute to no avail. Anything else I should try? Is it possible that the ROM or CPU has been damaged by the installer? I can't even get into the BIOS via DEL. I'll take out the CMOS battery overnight and try tomorrow. Thanks for any help. . Sounds like identical problem i was having with my old intel based laptop. After the first reboot, following an install, it would get stuck on the BIOS screen. i had to do. turn off the system, remove the hd, connect it on an another system and install another os, erasing dragonfly. reconnect the hd back to the laptop then the laptop would boot fine. unfortunately, i never found the solution, the hd pins were beginning to bend from removing the hd alot trying to find a workaround. The most important questions are - will the installer always corrupt the hdd in this machine? - is there a plan to fix this?
Re: machine won't start
On Tue, Jul 3, 2012 at 11:30 PM, Sascha Wildner s...@online.de wrote: On Tue, 03 Jul 2012 23:15:47 +0200, Carsten Mattner carstenmatt...@gmail.com wrote: Hi, I tried to install dfly 3.0.2 on an old amd64 box. When setup was in the configuration phase it didn't allow setting passwords with : or other characters. At that point I hit hard (cold) reset and since that time the machine won't leave the BIOS startup phase (POST?). Took out the CMOS battery for a minute to no avail. Anything else I should try? Is it possible that the ROM or CPU has been damaged by the installer? I can't even get into the BIOS via DEL. I'll take out the CMOS battery overnight and try tomorrow. Thanks for any help. It sounds like http://bugs.dragonflybsd.org/issues/989 Sascha, is it be safe to assume that once I've made the disk functional NetBSD, FreeBSD, or OpenBSD would not have the problem? I'm not sure after reading the bug report.
Re: machine won't start
On 4 July 2012 06:25, Carsten Mattner carstenmatt...@gmail.com wrote: The most important questions are - will the installer always corrupt the hdd in this machine? Well, I have never seen this issue, but if it happened one time, may happen again. If you like some challenge, try to install by hand. It is no that dificult. Try to partition the HDD - is there a plan to fix this? I can not answer this... dunno. I have an issue with NTFS partitions, Antonio Huete was trying to fix it, but there are a lot of other priorities and a problem that affects a little percentage of machines need much effort. Have you some interest in helping by programing and testing? it would be appreciated! cheers! -- Raimundo A. P. Santos Bacharelando em Informática ICMC - USP
Re: machine won't start
On Wed, 04 Jul 2012 12:16:25 +0200, Carsten Mattner carstenmatt...@gmail.com wrote: On Tue, Jul 3, 2012 at 11:30 PM, Sascha Wildner s...@online.de wrote: On Tue, 03 Jul 2012 23:15:47 +0200, Carsten Mattner carstenmatt...@gmail.com wrote: Hi, I tried to install dfly 3.0.2 on an old amd64 box. When setup was in the configuration phase it didn't allow setting passwords with : or other characters. At that point I hit hard (cold) reset and since that time the machine won't leave the BIOS startup phase (POST?). Took out the CMOS battery for a minute to no avail. Anything else I should try? Is it possible that the ROM or CPU has been damaged by the installer? I can't even get into the BIOS via DEL. I'll take out the CMOS battery overnight and try tomorrow. Thanks for any help. It sounds like http://bugs.dragonflybsd.org/issues/989 Sascha, is it be safe to assume that once I've made the disk functional NetBSD, FreeBSD, or OpenBSD would not have the problem? I'm not sure after reading the bug report. I don't know about *BSD's behavior. What you _can_ do is to use one of the scripts provided in /usr/share/examples/rconfig that we ship. hammer.sh is for a normal install, so I'd use that. Note that it assumes you want to install DragonFly to the whole disk. Just boot the CD/IMG and login as root and copy one of the scripts to your home directory. Then edit it, supplying your disk name at the top. Also make sure that you change all instances of 'fdisk' to 'fdisk -C' (as mentioned in the issue #989). Once you've reviewed your changes, run the script (beware, it's a csh script, even though it's named '.sh'; yes I know it's silly...) and cross your fingers. :) If the issue is what is described in the bug report, you should have a system that boots. Sascha
Re: machine won't start
Normally this issue can be fixed by setting the BIOS to access the disk in LBA or LARGE mode. The problem is due to a bug in the BIOS's attempt to interpret the slice table in CHS mode instead of logical block mode. It's a BIOS bug. These old BIOS's make a lot of assumptions w/regards to the contents of the slice table, including making explicit checks for particular OS types in the table. I've only ever seen the problem on old machines, and I've always been able to solve it by setting the BIOS access mode. I've never, ever found a slice table format that works properly across all BIOSs. At this juncture we are using only newer (newer being 'only' 25+ years old) slice table formats (aka LBA layouts and using proper capped values for hard drives that are larger than the 32-bit LBA layout can handle). Ultimately we will want to start formatting things w/GPT, but that opens up a whole new can of worms... old BIOSes can explode even more easily when presented with a GPT's compat slice format, at least as defined by GPT. Numerous vendors such as Apple modified their GPT to try to work around the even larger number of BIOS bugs related to GPT formatting than were present for the older LBA formatting. I consider it almost a lost cause. -Matt
Re: machine won't start
On Wed, Jul 4, 2012 at 7:31 PM, Matthew Dillon dil...@apollo.backplane.com wrote: Normally this issue can be fixed by setting the BIOS to access the disk in LBA or LARGE mode. The problem is due to a bug in the BIOS's attempt to interpret the slice table in CHS mode instead of logical block mode. It's a BIOS bug. These old BIOS's make a lot of assumptions w/regards to the contents of the slice table, including making explicit checks for particular OS types in the table. I've only ever seen the problem on old machines, and I've always been able to solve it by setting the BIOS access mode. I've never, ever found a slice table format that works properly across all BIOSs. At this juncture we are using only newer (newer being 'only' 25+ years old) slice table formats (aka LBA layouts and using proper capped values for hard drives that are larger than the 32-bit LBA layout can handle). Ultimately we will want to start formatting things w/GPT, but that opens up a whole new can of worms... old BIOSes can explode even more easily when presented with a GPT's compat slice format, at least as defined by GPT. Numerous vendors such as Apple modified their GPT to try to work around the even larger number of BIOS bugs related to GPT formatting than were present for the older LBA formatting. I consider it almost a lost cause. -Matt There was interesting debate before couple od days/weeks on OpenBSD about support for disks larger than 2TB. It turned out that they can be used just fine without GPT, but multiboot capability is mostly lost as job is done in disklable (their fdisk can't do that) http://marc.info/?l=openbsd-miscm=133857397722515w=2
Re: machine won't start
On Wed, Jul 4, 2012 at 7:31 PM, Matthew Dillon dil...@apollo.backplane.com wrote: Normally this issue can be fixed by setting the BIOS to access the disk in LBA or LARGE mode. The problem is due to a bug in the BIOS's attempt to interpret the slice table in CHS mode instead of logical block mode. It's a BIOS bug. These old BIOS's make a lot of assumptions w/regards to the contents of the slice table, including making explicit checks for particular OS types in the table. I've only ever seen the problem on old machines, and I've always been able to solve it by setting the BIOS access mode. I've never, ever found a slice table format that works properly across all BIOSs. At this juncture we are using only newer (newer being 'only' 25+ years old) slice table formats (aka LBA layouts and using proper capped values for hard drives that are larger than the 32-bit LBA layout can handle). Ultimately we will want to start formatting things w/GPT, but that opens up a whole new can of worms... old BIOSes can explode even more easily when presented with a GPT's compat slice format, at least as defined by GPT. Numerous vendors such as Apple modified their GPT to try to work around the even larger number of BIOS bugs related to GPT formatting than were present for the older LBA formatting. I consider it almost a lost cause. -Matt Thanks Matt for the explanation and tip. It did of course hang when I tried to DEL into the BIOS. What worked is pulling out the sata connector, entering the BIOS putting it back and then detecting the disk. Interesting the auto detection then worked. I've explicitly set it to LARGE and now I can boot a rescue cd. How many bytes should I zero out for the disk to be normal again? 512bytes? 4megs?
Re: machine won't start
:Thanks Matt for the explanation and tip. : :It did of course hang when I tried to DEL into the BIOS. :What worked is pulling out the sata connector, entering :the BIOS putting it back and then detecting the disk. :Interesting the auto detection then worked. I've explicitly :set it to LARGE and now I can boot a rescue cd. : :How many bytes should I zero out for the disk to be :normal again? 512bytes? 4megs? The BIOS is basically just accessing the slice table in the first 512 bytes of the disk. If I want to completely wipe a non-GPT formatted disk I usually zero-out (with dd) the first ~32MB or so to catch both the slice table and the stage-2 boot and the disklabel and the likely filesystem header. Destroying a GPT disk requires (to be safe) zero'ing out both the first AND the last X bytes of the physical media to also ensure that the backup GPT table is also scrapped. Again, to be safe I zero-out around 32MB at the beginning and 32MB at the end w/dd (if it's GPT). This will effectively destroy everything on the disk from the point of view of probing, so please note that these instructions are NOT going to leave multi-OS installations intact. -Matt Matthew Dillon dil...@backplane.com
Re: machine won't start
On Wed, Jul 4, 2012 at 8:07 PM, Matthew Dillon dil...@apollo.backplane.com wrote: :Thanks Matt for the explanation and tip. : :It did of course hang when I tried to DEL into the BIOS. :What worked is pulling out the sata connector, entering :the BIOS putting it back and then detecting the disk. :Interesting the auto detection then worked. I've explicitly :set it to LARGE and now I can boot a rescue cd. : :How many bytes should I zero out for the disk to be :normal again? 512bytes? 4megs? The BIOS is basically just accessing the slice table in the first 512 bytes of the disk. If I want to completely wipe a non-GPT formatted disk I usually zero-out (with dd) the first ~32MB or so to catch both the slice table and the stage-2 boot and the disklabel and the likely filesystem header. Destroying a GPT disk requires (to be safe) zero'ing out both the first AND the last X bytes of the physical media to also ensure that the backup GPT table is also scrapped. Again, to be safe I zero-out around 32MB at the beginning and 32MB at the end w/dd (if it's GPT). How do I tell dd to delete x bytes at the end of device? Negative values? This will effectively destroy everything on the disk from the point of view of probing, so please note that these instructions are NOT going to leave multi-OS installations intact.
Re: machine won't start
On Wed, Jul 4, 2012 at 8:11 PM, Carsten Mattner carstenmatt...@gmail.com wrote: On Wed, Jul 4, 2012 at 8:07 PM, Matthew Dillon dil...@apollo.backplane.com wrote: :Thanks Matt for the explanation and tip. : :It did of course hang when I tried to DEL into the BIOS. :What worked is pulling out the sata connector, entering :the BIOS putting it back and then detecting the disk. :Interesting the auto detection then worked. I've explicitly :set it to LARGE and now I can boot a rescue cd. : :How many bytes should I zero out for the disk to be :normal again? 512bytes? 4megs? The BIOS is basically just accessing the slice table in the first 512 bytes of the disk. If I want to completely wipe a non-GPT formatted disk I usually zero-out (with dd) the first ~32MB or so to catch both the slice table and the stage-2 boot and the disklabel and the likely filesystem header. Destroying a GPT disk requires (to be safe) zero'ing out both the first AND the last X bytes of the physical media to also ensure that the backup GPT table is also scrapped. Again, to be safe I zero-out around 32MB at the beginning and 32MB at the end w/dd (if it's GPT). How do I tell dd to delete x bytes at the end of device? Negative values? Will try seek=nG
Re: machine won't start
On 4 July 2012 14:31, Matthew Dillon dil...@apollo.backplane.com wrote: I consider it almost a lost cause. Don't get it: trying to fix this is a lost cause? -- Raimundo A. P. Santos Bacharelando em Informática ICMC - USP
Re: machine won't start
On Wed, Jul 4, 2012 at 8:16 PM, Carsten Mattner carstenmatt...@gmail.com wrote: On Wed, Jul 4, 2012 at 8:11 PM, Carsten Mattner carstenmatt...@gmail.com wrote: On Wed, Jul 4, 2012 at 8:07 PM, Matthew Dillon dil...@apollo.backplane.com wrote: :Thanks Matt for the explanation and tip. : :It did of course hang when I tried to DEL into the BIOS. :What worked is pulling out the sata connector, entering :the BIOS putting it back and then detecting the disk. :Interesting the auto detection then worked. I've explicitly :set it to LARGE and now I can boot a rescue cd. : :How many bytes should I zero out for the disk to be :normal again? 512bytes? 4megs? The BIOS is basically just accessing the slice table in the first 512 bytes of the disk. If I want to completely wipe a non-GPT formatted disk I usually zero-out (with dd) the first ~32MB or so to catch both the slice table and the stage-2 boot and the disklabel and the likely filesystem header. Destroying a GPT disk requires (to be safe) zero'ing out both the first AND the last X bytes of the physical media to also ensure that the backup GPT table is also scrapped. Again, to be safe I zero-out around 32MB at the beginning and 32MB at the end w/dd (if it's GPT). How do I tell dd to delete x bytes at the end of device? Negative values? Will try seek=nG dd's seek= operates on blocks so have to supply multiple of bs=. Thanks again Matt and everybody.
Re: machine won't start
: I consider it almost a lost cause. : : :Don't get it: trying to fix this is a lost cause? Yah, because if we fix it for one BIOS we break it for another. Hence, a lost cause. There is no single fix which covers all BIOSs. -Matt
Re: machine won't start
Been down that path, and almost lost my sanity. The code that probes for disks via the BIOS (in openbsd's boot loader) is just as sensitive, causing hangs, etc. Writing that was... interesting. The partition table entries are just about as sensitive (as you've found out), and the joy is all the different ways that BIOS will interpret values (and hang on values). Even better, I've seen BIOSen that would change the geometry information returned on (a USB stick was common) based on the partition table information that they may or may not have read from the first 512 bytes of a disk. Yuck. -Toby. On Wed, Jul 4, 2012 at 12:35 PM, Matthew Dillon dil...@apollo.backplane.com wrote: : I consider it almost a lost cause. : : :Don't get it: trying to fix this is a lost cause? Yah, because if we fix it for one BIOS we break it for another. Hence, a lost cause. There is no single fix which covers all BIOSs. -Matt
