Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.setup > #821 > unrolled thread
| Started by | Noob <root@localhost> |
|---|---|
| First post | 2011-07-22 00:45 -0400 |
| Last post | 2011-08-06 10:00 -0700 |
| Articles | 16 on this page of 56 — 19 participants |
Back to article view | Back to comp.os.linux.setup
Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@localhost> - 2011-07-22 00:45 -0400
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Ian Collins <ian-news@hotmail.com> - 2011-07-22 10:50 +1200
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@localhost> - 2011-07-22 01:26 -0400
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Paul <nospam@needed.com> - 2011-07-21 19:38 -0400
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-22 16:29 +0200
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Paul <nospam@needed.com> - 2011-07-22 14:28 -0400
Re: Help, the dog ate my MBR (Linux/Windows dual boot) g.fink@gmx.net (Gernot Fink) - 2011-07-22 04:35 +0000
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Mike Easter <MikeE@ster.invalid> - 2011-07-21 19:20 -0700
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-22 11:00 +0200
Re: Help, the dog ate my MBR (Linux/Windows dual boot) GangGreene <GangGreene@invalid.com> - 2011-07-22 05:29 -0400
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-22 12:01 +0200
Re: Help, the dog ate my MBR (Linux/Windows dual boot) g.fink@gmx.net (Gernot Fink) - 2011-07-22 10:28 +0000
Re: Help, the dog ate my MBR (Linux/Windows dual boot) "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2011-07-21 23:33 -0400
Re: Help, the dog ate my MBR (Linux/Windows dual boot) BGB <cr88192@hotmail.com> - 2011-07-21 21:26 -0700
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-22 16:25 +0200
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Bob Willard <BobwBSGS@TrashThis.comcast.net> - 2011-07-22 12:17 -0400
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-22 18:35 +0200
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Arno <me@privacy.net> - 2011-07-22 18:41 +0000
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Paul <nospam@needed.com> - 2011-07-22 14:52 -0400
Re: Help, the dog ate my MBR (Linux/Windows dual boot) The Natural Philosopher <tnp@invalid.invalid> - 2011-07-23 02:23 +0100
Re: Help, the dog ate my MBR (Linux/Windows dual boot) scott@slp53.sl.home (Scott Lurndal) - 2011-07-22 19:19 +0000
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-23 20:51 +0200
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-24 16:54 +0200
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Arno <me@privacy.net> - 2011-07-24 15:29 +0000
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-27 11:36 +0200
Re: Help, the dog ate my MBR (Linux/Windows dual boot) The Natural Philosopher <tnp@invalid.invalid> - 2011-07-27 12:13 +0100
Re: Help, the dog ate my MBR (Linux/Windows dual boot) scott@slp53.sl.home (Scott Lurndal) - 2011-07-27 20:48 +0000
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-28 10:43 +0200
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-07-29 00:49 +0100
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Ian Collins <ian-news@hotmail.com> - 2011-07-23 09:44 +1200
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Franc Zabkar <fzabkar@iinternode.on.net> - 2011-07-23 10:05 +1000
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Paul <nospam@needed.com> - 2011-07-22 20:58 -0400
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Franc Zabkar <fzabkar@iinternode.on.net> - 2011-07-23 11:31 +1000
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-07-29 01:18 +0100
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Franc Zabkar <fzabkar@iinternode.on.net> - 2011-07-23 19:02 +1000
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-07-29 01:37 +0100
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Franc Zabkar <fzabkar@iinternode.on.net> - 2011-07-23 17:34 +1000
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-23 21:25 +0200
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Franc Zabkar <fzabkar@iinternode.on.net> - 2011-07-25 08:15 +1000
Re: Help, the dog ate my MBR (Linux/Windows dual boot) scott@slp53.sl.home (Scott Lurndal) - 2011-07-24 23:08 +0000
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Franc Zabkar <fzabkar@iinternode.on.net> - 2011-07-25 09:46 +1000
Re: Help, the dog ate my MBR (Linux/Windows dual boot) scott@slp53.sl.home (Scott Lurndal) - 2011-07-25 02:19 +0000
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Paul <nospam@needed.com> - 2011-07-24 22:38 -0400
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Franc Zabkar <fzabkar@iinternode.on.net> - 2011-07-25 19:38 +1000
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Franc Zabkar <fzabkar@iinternode.on.net> - 2011-07-25 19:34 +1000
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Michael Press <rubrum@pacbell.net> - 2011-08-03 21:56 -0700
Re: Help, the dog ate my MBR (Linux/Windows dual boot) John Hasler <jhasler@newsguy.com> - 2011-08-04 08:15 -0500
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-07-29 01:10 +0100
Re: Help, the dog ate my MBR (Linux/Windows dual boot) gordonb.22upl@burditt.org (Gordon Burditt) - 2011-07-23 17:15 -0500
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-07-24 16:42 +0200
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-10-27 11:13 +0200
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Arno <me@privacy.net> - 2011-10-27 15:24 +0000
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-10-28 11:06 +0200
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-07-29 00:49 +0100
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Noob <root@127.0.0.1> - 2011-08-01 11:27 +0200
Re: Help, the dog ate my MBR (Linux/Windows dual boot) Nico Kadel-Garcia <nkadel@gmail.com> - 2011-08-06 10:00 -0700
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Franc Zabkar <fzabkar@iinternode.on.net> |
|---|---|
| Date | 2011-07-25 09:46 +1000 |
| Message-ID | <tmap275nlfabe690qa24bt6f0ntqp7o1ig@4ax.com> |
| In reply to | #860 |
On 24 Jul 2011 23:08:09 GMT, scott@slp53.sl.home (Scott Lurndal) put finger to keyboard and composed: >Franc Zabkar <fzabkar@iinternode.on.net> writes: >>On Sat, 23 Jul 2011 21:25:06 +0200, Noob <root@127.0.0.1> put finger >>to keyboard and composed: >> >>>I got a copy of the MBR by running >>>dd if=/dev/sda of=mbr.bin bs=512 count=2 >>> >>>This should get to LBA 0, right? > >Yes. count=1 is sufficient for the MBR itself. I believe the OP specified count=2 so that he could account for the 14-byte offset. >>I wonder if you could disable Linux's HDD cache when performing your >>tests. Then you could test the drive's cache memory (8MB) by dd-ing >>data in 16MB blocks. In fact it should be sufficient to dd the first >>8MB of data twice in succession, and then compare the two results. >>This is because part of the 8MB cache is occupied by the drive's >>firmware. This would mean that the second read should flush the first >>sectors from the cache. >> >>AFAICS, the following commands should do it: >> >> dd if=/dev/sda of=mbr_1.bin bs=512 count=32768 >> dd if=/dev/sda of=mbr_2.bin bs=512 count=32768 > >Much much much much more efficient to use bs=16m count=1, which will issue a single read >versus 32,768 reads. > >If the hard disk is an IDE or SATA drive, you can use the hdparm command to disable >the drive cache. I was thinking that the OP should disable the OS cache in system RAM rather than the drive's onboard cache. However, I agree that your idea has merit also. >It is highly unlikely that this is a drive problem, however. Much more likely that >the scatter gather list entry given by the driver to the SATA/IDE controller is fubared >which implies a memory issue (although I can't figure a 14-byte offset from a single >bit error). > >Another possiblity is a corrupted driver or rootkit. If this were the case, then if the OP were to boot from an optical drive before attempting to boot from the HDD, he should see a good MBR. If instead he boots first from the HDD, and the corruption or rootkit takes effect by loading code into RAM, a subsequent soft reboot (Ctrl-Alt-Del) may result in him seeing a bad MBR rather than the real one at LBA 0. A hard reset should be OK, though. >scott - Franc Zabkar -- Please remove one 'i' from my address when replying by email.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2011-07-25 02:19 +0000 |
| Message-ID | <yo4Xp.165725$Dt6.28639@news.usenetserver.com> |
| In reply to | #861 |
Franc Zabkar <fzabkar@iinternode.on.net> writes: >I was thinking that the OP should disable the OS cache in system RAM >rather than the drive's onboard cache. However, I agree that your idea >has merit also. With linux, specify "iflag=direct" on the dd(1) command to bypass the OS cache. However, given that the OS cache is always page-sized[*] and page-aligned, I find it quite difficult to believe that something in the OS cache layer is corrupting data in this fashion. scott [*] 4096 bytes on x86 and X86_64.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.com> |
|---|---|
| Date | 2011-07-24 22:38 -0400 |
| Message-ID | <j0ikur$1lb$2@dont-email.me> |
| In reply to | #862 |
Scott Lurndal wrote:
> Franc Zabkar <fzabkar@iinternode.on.net> writes:
>
>
>> I was thinking that the OP should disable the OS cache in system RAM
>> rather than the drive's onboard cache. However, I agree that your idea
>> has merit also.
>
> With linux, specify "iflag=direct" on the dd(1) command to bypass the
> OS cache.
>
> However, given that the OS cache is always page-sized[*] and page-aligned,
> I find it quite difficult to believe that something in the OS cache layer
> is corrupting data in this fashion.
>
> scott
>
> [*] 4096 bytes on x86 and X86_64.
Looks like a job for some kind of bootable disk editor (one
which is sans OS). I wonder what's available.
Paul
[toc] | [prev] | [next] | [standalone]
| From | Franc Zabkar <fzabkar@iinternode.on.net> |
|---|---|
| Date | 2011-07-25 19:38 +1000 |
| Message-ID | <m8eq27d8lq0so94kjc6i99e7dedfsm4gbt@4ax.com> |
| In reply to | #863 |
On Sun, 24 Jul 2011 22:38:19 -0400, Paul <nospam@needed.com> put finger to keyboard and composed: >Looks like a job for some kind of bootable disk editor (one >which is sans OS). I wonder what's available. The following disc editor has a DOS version. I would think it should be OK as long as you don't load smartdrv. DMDE - DM Disk Editor and Data Recovery Software: http://softdm.com/download.html - Franc Zabkar -- Please remove one 'i' from my address when replying by email.
[toc] | [prev] | [next] | [standalone]
| From | Franc Zabkar <fzabkar@iinternode.on.net> |
|---|---|
| Date | 2011-07-25 19:34 +1000 |
| Message-ID | <nudq27dvga9efpro9fods1qiarpfjvf0n3@4ax.com> |
| In reply to | #862 |
On 25 Jul 2011 02:19:10 GMT, scott@slp53.sl.home (Scott Lurndal) put finger to keyboard and composed: >Franc Zabkar <fzabkar@iinternode.on.net> writes: > > >>I was thinking that the OP should disable the OS cache in system RAM >>rather than the drive's onboard cache. However, I agree that your idea >>has merit also. > >With linux, specify "iflag=direct" on the dd(1) command to bypass the >OS cache. > >However, given that the OS cache is always page-sized[*] and page-aligned, >I find it quite difficult to believe that something in the OS cache layer >is corrupting data in this fashion. I'm suggesting that the OS cache needs to be bypassed so that we can be certain that the data are coming from the drive on the second pass with dd. If the OS cache were enabled, then we would just be comparing the OS cache against itself. - Franc Zabkar -- Please remove one 'i' from my address when replying by email.
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-08-03 21:56 -0700 |
| Message-ID | <rubrum-FFD77A.21561503082011@news.albasani.net> |
| In reply to | #860 |
In article <tB1Xp.52981$NY4.46062@news.usenetserver.com>, scott@slp53.sl.home (Scott Lurndal) wrote: > It is highly unlikely that this is a drive problem, however. Much more likely that > the scatter gather list entry given by the driver to the SATA/IDE controller is fubared > which implies a memory issue (although I can't figure a 14-byte offset from a single > bit error). Has everything passed me by? (Rhetorical question. Answer: yes) "Fubar" used to be sufficient. If you know what "mung" means, Patty at the front desk of the assisted living facility will award you a token for a free game of Bingo. -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <jhasler@newsguy.com> |
|---|---|
| Date | 2011-08-04 08:15 -0500 |
| Message-ID | <87aabpxqq5.fsf@thumper.dhh.gt.org> |
| In reply to | #882 |
Scott Lurndal writes: > ...fubared which implies a memory issue... Michael Press writes: > "Fubar" used to be sufficient. people used to know what FUBAR meant. > If you know what "mung" means... No one who knows what "mung" means would use "issue" as a synonym for "problem". -- John Hasler jhasler@newsguy.com Dancing Horse Hill Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> |
|---|---|
| Date | 2011-07-29 01:10 +0100 |
| Message-ID | <IU.D20110729.T001125.P60032.Q0@J.de.Boyne.Pollard.localhost> |
| In reply to | #845 |
> I say this because those 64 bytes which are normally assigned to the
> four 16-byte partition slots are instead occupied by code and a text
> string ("Floppy"). There are also JMP instructions (eg je 0x1c3, jb
> 0x1ec, jne 0x1e1) that point to locations within this block.
>
You are being led down the garden path by a GRUB2 programming trick.
See the GRUB2 source for details. There's a 3 line comment that
explains exactly what this is and why it's in the same place as the MBR
primary partition table entries.
[toc] | [prev] | [next] | [standalone]
| From | gordonb.22upl@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2011-07-23 17:15 -0500 |
| Message-ID | <ns-dnSPODM9h2rbTnZ2dnUVZ_uSdnZ2d@posted.internetamerica> |
| In reply to | #833 |
>> Something trashed my MBR. Now when I boot the PC, >> I get the dreaded "NON-SYSTEM DISK. PLEASE INSERT >> SYSTEM DISK AND PRESS ENTER" (or something close). > > By MBR, I meant the first sector of my hard disk drive, > i.e. the boot-strapping code, and the table of primary > partitions. > >> My setup: >> PATA 120-GB HDD on IDE0 master >> PATA DVD reader on IDE1 master >> No IDE slaves. No SATA drives. (SATA disabled in BIOS) >> >> I had used gparted to create three primary partitions >> (all partitions are aligned to 1 MiB, even though >> this is not a 4K-sector HDD) >> partition 1 : 80.00 GiB (for WinXP) >> partition 2 : 33.75 GiB (for Fedora 13) >> partition 3 : 765 MiB (for swap) I think Linux has a version of fdisk(8) similar to the BSD version: you can edit the type, start, and length of each partition. It will also put back the standard boot code part of the MBR. You can also list the whole partition setup and geometry. If you've got a better tool that does this (gpartd, parted), you might use that instead, but you want something you can boot from CD and use to repair a screwed up MBR on a hard disk. Although it is possible to hunt for and find filesystems on disk, it's possible for such a tool to pick up on old filesystems from before re-arranging the partitions, and it's generally a lot faster to just know the size and length of all of them. I've been doing backups of systems by putting a set of compressed dumps of filesystems on sets of DVDs. Along with the dumps, I put some small individual files to make recovering a situation like this easier: - the output of fdisk(8) for use to put back the MBR. Actually there are two forms of output, one that can be read back in and one human-readable one with more info. Manually typing in this info isn't that hard and there isn't that much of it. You could back this up on one sheet of paper if you want; you probably don't intentionally change the MBR very often. - the output of disklabel(8) for each partition (*BSD only). This is a subdivision of a partition into multiple slices. It acts a lot like a sub-MBR, but it's a different format. - A copy of /etc/fstab. Since I like lots of filesystems it is useful to know which filesystem gets mounted where. Yes, there's also a copy in the root dump, but it's easier to reference with a file outside it. - Copies of the output of "atacontrol list", "camcontrol devlist" and "usbconfig list" to show the setup for ATA drives, SCSI drives, and USB devices. These are probably FreeBSD only but I suspect Linux has similar commands. This shows what is connected where, including models of drives, to put back cables if needed. > Short version of the rest of original message : the first sector > had been shifted by 14 bytes. Weird, right? > > And the plot thickens. Later that same night, I copied the > MBR a second time in the live CD environment; and this second > time, the first 14 bytes of the MBR were ZERO, i.e. > they had changed !! I've had a problem of the MBR apparently getting trashed a couple of times. Either that or some horrible mess in the root filesystem where fsck is complaining about lots and lots of errors. Before resorting to drastic action, I suggest powering down the system (and for laptops, remove all batteries and disconnect charger) for a while. Sometimes the problem just goes away, like a bad copy of the MBR is sitting in the drive's cache and it goes away when the power goes off. > Even stranger, the next morning, I booted the PC, > and the 14-byte offset had disappeared. > > I'm starting to think that this might be a hardware problem, > as both Linux AND the BIOS seem to have had troubles getting > the MBR consistently. Something else I haven't mentioned: > when Windows resumes from hibernation, the whole system > sometime reboots (this started about 2/3 weeks ago), around > the same time I changed the RAM from 2x512 to 2x1024. A recent RAM change warrants checking. I had problems on a system other than my primary one and let memtest86+ run for a week or two. I am suspicious of memory tests, as way back in 1976 I had a rather unreliable 8080 system and it turned out that the memory test was pretty much guaranteed to generate dynamic RAM refresh even if the onboard refresh failed completely, (Suspicion was that it was failing intermittently due to a design flaw) covering up the problem. I don't know how memtest86+ does in this area. > I tested the RAM, no errors after one hour of checking. > The S.M.A.R.T. counters for the HDD claim the drive is > "healthy". S.M.A.R.T. can't test problems in CPU RAM and probably doesn't test disk controller cache RAM. > However, considering that the drive is inserting random > garbage around requested data, I'm wondering if this could > be the drive's controller failing? Would this show up in I've had a system where a marginal power supply caused a disk controller RAM buffer to drop bits occasionally, eventually scattering bit errors all over the disk. But this is pre-IBM-PC hardware. > a S.M.A.R.T. diagnostic? My guess is no. > Or am I on the wrong track, and do you see something else > that might be responsible? How often did you *power off* the system? Consider this possibility: a power glitch (possibly related to a marginal power supply) causes a corrupted sector cached in the disk controller (the real one is still OK, but you read the bad copy). By the time you power off, the bad sector in cache might or might not have been written back to disk. Power cycle, and the corrupted sector might just fix itself!
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2011-07-24 16:42 +0200 |
| Message-ID | <j0hb08$4hv$1@dont-email.me> |
| In reply to | #833 |
Noob wrote:
> The S.M.A.R.T. counters for the HDD claim the drive is "healthy".
For the record (and in case someone spots something fishy)
here's the output of smartctl for the drive.
# smartctl -x /dev/sda
smartctl 5.40 2010-10-16 r3189 [x86_64-redhat-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Model Family: Maxtor DiamondMax 10 family (ATA/133 and SATA/150)
Device Model: Maxtor 6B120P0
Serial Number: B40Q5GFH
Firmware Version: BAH41B70
User Capacity: 122,942,324,736 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 7
ATA Standard is: ATA/ATAPI-7 T13 1532D revision 0
Local Time is: Sun Jul 24 16:39:07 2011 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x80) Offline data collection activity
was never started.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (1202) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
No General Purpose Logging support.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 54) minutes.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
3 Spin_Up_Time 0x0027 207 205 063 Pre-fail Always - 16291
4 Start_Stop_Count 0x0032 251 251 000 Old_age Always - 5685
5 Reallocated_Sector_Ct 0x0033 253 253 063 Pre-fail Always - 0
6 Read_Channel_Margin 0x0001 253 253 100 Pre-fail Offline - 0
7 Seek_Error_Rate 0x000a 253 252 000 Old_age Always - 0
8 Seek_Time_Performance 0x0027 248 239 187 Pre-fail Always - 51306
9 Power_On_Minutes 0x0032 233 233 000 Old_age Always - 500h+12m
10 Spin_Retry_Count 0x002b 253 252 157 Pre-fail Always - 0
11 Calibration_Retry_Count 0x002b 253 252 223 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 239 239 000 Old_age Always - 5690
192 Power-Off_Retract_Count 0x0032 253 253 000 Old_age Always - 0
193 Load_Cycle_Count 0x0032 253 253 000 Old_age Always - 0
194 Temperature_Celsius 0x0032 032 253 000 Old_age Always - 35
195 Hardware_ECC_Recovered 0x000a 253 252 000 Old_age Always - 7425
196 Reallocated_Event_Count 0x0008 253 253 000 Old_age Offline - 0
197 Current_Pending_Sector 0x0008 253 253 000 Old_age Offline - 0
198 Offline_Uncorrectable 0x0008 253 253 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0008 199 199 000 Old_age Offline - 0
200 Multi_Zone_Error_Rate 0x000a 253 252 000 Old_age Always - 0
201 Soft_Read_Error_Rate 0x000a 253 252 000 Old_age Always - 22
202 Data_Address_Mark_Errs 0x000a 253 252 000 Old_age Always - 0
203 Run_Out_Cancel 0x000b 253 252 180 Pre-fail Always - 1
204 Soft_ECC_Correction 0x000a 253 252 000 Old_age Always - 0
205 Thermal_Asperity_Rate 0x000a 253 252 000 Old_age Always - 0
207 Spin_High_Current 0x002a 253 252 000 Old_age Always - 0
208 Spin_Buzz 0x002a 253 252 000 Old_age Always - 0
209 Offline_Seek_Performnce 0x0024 241 241 000 Old_age Offline - 144
210 Unknown_Attribute 0x0032 253 252 000 Old_age Always - 0
211 Unknown_Attribute 0x0032 253 252 000 Old_age Always - 0
212 Unknown_Attribute 0x0032 253 253 000 Old_age Always - 0
Read SMART Log Directory failed.
ATA_READ_LOG_EXT (addr=0x00:0x00, page=0, n=1) failed: scsi error aborted command
Read GP Log Directory failed.
SMART Extended Comprehensive Error Log (GP Log 0x03) not supported
SMART Error Log Version: 1
No Errors Logged
SMART Extended Self-test Log (GP Log 0x07) not supported
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
Warning: device does not support SCT Commands
SATA Phy Event Counters (GP Log 0x11) not supported
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2011-10-27 11:13 +0200 |
| Message-ID | <j8b7c7$r2e$1@dont-email.me> |
| In reply to | #833 |
EPILOGUE (top-posted, please delete history if replying) Well, it was indeed a hardware problem: after weeks of correct operation, and the occasional weirdness once in a while, port IDE0 suddenly and completely failed, refusing to detect any peripheral (HDD or optical drive) plugged into it. I suppose I have three options: 1) change the MB (I'd need to buy used, since socket 939 MBs are rare now) 2) buy a SATA HDD, and just tape over IDE0 3) Configure HDD as master, DVD drive as slave on IDE1 I'm leaning towards solution 2, until I upgrade the whole system (well MB+CPU+RAM at least; I have decent GPU, PS, and case) Regards. -- History below, provided for the record: > Noob wrote: > >> Something trashed my MBR. Now when I boot the PC, >> I get the dreaded "NON-SYSTEM DISK. PLEASE INSERT >> SYSTEM DISK AND PRESS ENTER" (or something close). > > By MBR, I meant the first sector of my hard disk drive, > i.e. the boot-strapping code, and the table of primary > partitions. > >> My setup: >> PATA 120-GB HDD on IDE0 master >> PATA DVD reader on IDE1 master >> No IDE slaves. No SATA drives. (SATA disabled in BIOS) >> >> I had used gparted to create three primary partitions >> (all partitions are aligned to 1 MiB, even though >> this is not a 4K-sector HDD) >> partition 1 : 80.00 GiB (for WinXP) >> partition 2 : 33.75 GiB (for Fedora 13) >> partition 3 : 765 MiB (for swap) > > Short version of the rest of original message : the first sector > had been shifted by 14 bytes. Weird, right? > > And the plot thickens. Later that same night, I copied the > MBR a second time in the live CD environment; and this second > time, the first 14 bytes of the MBR were ZERO, i.e. > they had changed !! > > Even stranger, the next morning, I booted the PC, > and the 14-byte offset had disappeared. > > I'm starting to think that this might be a hardware problem, > as both Linux AND the BIOS seem to have had troubles getting > the MBR consistently. Something else I haven't mentioned: > when Windows resumes from hibernation, the whole system > sometime reboots (this started about 2/3 weeks ago), around > the same time I changed the RAM from 2x512 to 2x1024. > > I tested the RAM, no errors after one hour of checking. > The S.M.A.R.T. counters for the HDD claim the drive is > "healthy". > > However, considering that the drive is inserting random > garbage around requested data, I'm wondering if this could > be the drive's controller failing? Would this show up in > a S.M.A.R.T. diagnostic? > > Or am I on the wrong track, and do you see something else > that might be responsible? > > Regards. > > > [ Below is the rest of my original message, which I left in > because of the belated cross-post to csiphs ] > >> For my own record, my partitions are encoded as follows. >> >> http://en.wikipedia.org/wiki/Master_boot_record >> http://en.wikipedia.org/wiki/Partition_type >> >> 80 20 21 00 07 fe ff ff 00 08 00 00 00 00 00 0a >> bootable, NTFS, start = 1 MiB, count = 80 GiB >> >> 00 fe ff ff 83 fe ff ff 00 08 00 0a 00 00 38 04 >> non-bootable, linux, count = 33.75 GiB >> >> 00 fe ff ff 82 fe ff ff 00 08 38 0e 00 e8 17 00 >> non-bootable, swap, count = 765 MiB >> >> I used a Fedora 15 live CD to boot to Linux, and examine >> the MBR. I looked for the MBR signature, and noticed >> something very odd: the 0xAA55 signature was 14 bytes >> "too far", i.e. at offset 0x20c instead of 0x1fe, which >> means my broken MBR straddles sectors 0 and 1... >> >> # cat broken_mbr.dump >> 00000000 00 00 00 00 00 00 41 01 63 74 e6 00 39 00 eb 48 |......A.ct..9..H| >> 00000010 90 d0 bc 00 7c fb 50 07 50 1f fc be 1b 7c bf 1b |....|.P.P....|..| >> 00000020 06 50 57 b9 e5 01 f3 a4 cb bd be 07 b1 04 38 6e |.PW...........8n| >> 00000030 00 7c 09 75 13 83 c5 10 e2 f4 cd 18 8b f5 83 c6 |.|.u............| >> 00000040 10 49 74 19 38 2c 74 f6 a0 b5 07 b4 03 02 80 00 |.It.8,t.........| >> 00000050 00 80 00 e8 c4 0a 00 08 fa 90 90 f6 c2 80 75 02 |..............u.| >> 00000060 b2 80 ea 59 7c 00 00 31 c0 8e d8 8e d0 bc 00 20 |...Y|..1....... | >> 00000070 fb a0 40 7c 3c ff 74 02 88 c2 52 f6 c2 80 74 54 |..@|<.t...R...tT| >> 00000080 b4 41 bb aa 55 cd 13 5a 52 72 49 81 fb 55 aa 75 |.A..U..ZRrI..U.u| >> 00000090 43 a0 41 7c 84 c0 75 05 83 e1 01 74 37 66 8b 4c |C.A|..u....t7f.L| >> 000000a0 10 be 05 7c c6 44 ff 01 66 8b 1e 44 7c c7 04 10 |...|.D..f..D|...| >> 000000b0 00 c7 44 02 01 00 66 89 5c 08 c7 44 06 00 70 66 |..D...f.\..D..pf| >> 000000c0 31 c0 89 44 04 66 89 44 0c b4 42 cd 13 72 05 bb |1..D.f.D..B..r..| >> 000000d0 00 70 eb 7d b4 08 cd 13 73 0a f6 c2 80 0f 84 f0 |.p.}....s.......| >> 000000e0 00 e9 8d 00 be 05 7c c6 44 ff 00 66 31 c0 88 f0 |......|.D..f1...| >> 000000f0 40 66 89 44 04 31 d2 88 ca c1 e2 02 88 e8 88 f4 |@f.D.1..........| >> 00000100 40 89 44 08 31 c0 88 d0 c0 e8 02 66 89 04 66 a1 |@.D.1......f..f.| >> 00000110 44 7c 66 31 d2 66 f7 34 88 54 0a 66 31 d2 66 f7 |D|f1.f.4.T.f1.f.| >> 00000120 74 04 88 54 0b 89 44 0c 3b 44 08 7d 3c 8a 54 0d |t..T..D.;D.}<.T.| >> 00000130 c0 e2 06 8a 4c 0a fe c1 08 d1 8a 6c 0c 5a 8a 74 |....L......l.Z.t| >> 00000140 0b bb 00 70 8e c3 31 db b8 01 02 cd 13 72 2a 8c |...p..1......r*.| >> 00000150 c3 8e 06 48 7c 60 1e b9 00 01 8e db 31 f6 31 ff |...H|`......1.1.| >> 00000160 fc f3 a5 1f 61 ff 26 42 7c be 7f 7d e8 40 00 eb |....a.&B|..}.@..| >> 00000170 0e be 84 7d e8 38 00 eb 06 be 8e 7d e8 30 00 be |...}.8.....}.0..| >> 00000180 93 7d e8 2a 00 eb fe 47 52 55 42 20 00 47 65 6f |.}.*...GRUB .Geo| >> 00000190 6d 00 48 61 72 64 20 44 69 73 6b 00 52 65 61 64 |m.Hard Disk.Read| >> 000001a0 00 20 45 72 72 6f 72 00 bb 01 00 b4 0e cd 10 ac |. Error.........| >> 000001b0 3c 00 75 f4 c3 00 00 00 00 00 00 00 00 00 00 00 |<.u.............| >> 000001c0 00 00 00 00 00 00 dc 3b dd 3b 00 00 80 20 21 00 |.......;.;... !.| >> 000001d0 07 fe ff ff 00 08 00 00 00 00 00 0a 00 fe ff ff |................| >> 000001e0 83 fe ff ff 00 08 00 0a 00 00 38 04 00 fe ff ff |..........8.....| >> 000001f0 82 fe ff ff 00 08 38 0e 00 e8 17 00 00 00 00 00 |......8.........| >> 00000200 00 00 00 00 00 00 00 00 00 00 00 00 55 aa 00 00 |............U...| >> 00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| >> >> The partition table (64 bytes) at the end, right >> before the last two-byte signature, is valid. >> >> For comparison, I examined /boot/grub/stage1 >> >> # cat good_mbr.dump >> 00000000 eb 48 90 00 00 00 00 00 00 00 00 00 00 00 00 00 |.H..............| >> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| >> * >> 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 02 |................| >> 00000040 ff 00 00 80 01 00 00 00 00 08 fa eb 07 f6 c2 80 |................| >> 00000050 75 02 b2 80 ea 59 7c 00 00 31 c0 8e d8 8e d0 bc |u....Y|..1......| >> 00000060 00 20 fb a0 40 7c 3c ff 74 02 88 c2 52 f6 c2 80 |. ..@|<.t...R...| >> 00000070 74 54 b4 41 bb aa 55 cd 13 5a 52 72 49 81 fb 55 |tT.A..U..ZRrI..U| >> 00000080 aa 75 43 a0 41 7c 84 c0 75 05 83 e1 01 74 37 66 |.uC.A|..u....t7f| >> 00000090 8b 4c 10 be 05 7c c6 44 ff 01 66 8b 1e 44 7c c7 |.L...|.D..f..D|.| >> 000000a0 04 10 00 c7 44 02 01 00 66 89 5c 08 c7 44 06 00 |....D...f.\..D..| >> 000000b0 70 66 31 c0 89 44 04 66 89 44 0c b4 42 cd 13 72 |pf1..D.f.D..B..r| >> 000000c0 05 bb 00 70 eb 7d b4 08 cd 13 73 0a f6 c2 80 0f |...p.}....s.....| >> 000000d0 84 f0 00 e9 8d 00 be 05 7c c6 44 ff 00 66 31 c0 |........|.D..f1.| >> 000000e0 88 f0 40 66 89 44 04 31 d2 88 ca c1 e2 02 88 e8 |..@f.D.1........| >> 000000f0 88 f4 40 89 44 08 31 c0 88 d0 c0 e8 02 66 89 04 |..@.D.1......f..| >> 00000100 66 a1 44 7c 66 31 d2 66 f7 34 88 54 0a 66 31 d2 |f.D|f1.f.4.T.f1.| >> 00000110 66 f7 74 04 88 54 0b 89 44 0c 3b 44 08 7d 3c 8a |f.t..T..D.;D.}<.| >> 00000120 54 0d c0 e2 06 8a 4c 0a fe c1 08 d1 8a 6c 0c 5a |T.....L......l.Z| >> 00000130 8a 74 0b bb 00 70 8e c3 31 db b8 01 02 cd 13 72 |.t...p..1......r| >> 00000140 2a 8c c3 8e 06 48 7c 60 1e b9 00 01 8e db 31 f6 |*....H|`......1.| >> 00000150 31 ff fc f3 a5 1f 61 ff 26 42 7c be 7f 7d e8 40 |1.....a.&B|..}.@| >> 00000160 00 eb 0e be 84 7d e8 38 00 eb 06 be 8e 7d e8 30 |.....}.8.....}.0| >> 00000170 00 be 93 7d e8 2a 00 eb fe 47 52 55 42 20 00 47 |...}.*...GRUB .G| >> 00000180 65 6f 6d 00 48 61 72 64 20 44 69 73 6b 00 52 65 |eom.Hard Disk.Re| >> 00000190 61 64 00 20 45 72 72 6f 72 00 bb 01 00 b4 0e cd |ad. Error.......| >> 000001a0 10 ac 3c 00 75 f4 c3 00 00 00 00 00 00 00 00 00 |..<.u...........| >> 000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 24 12 |..............$.| >> 000001c0 0f 09 00 be bd 7d 31 c0 cd 13 46 8a 0c 80 f9 00 |.....}1...F.....| >> 000001d0 75 0f be da 7d e8 c9 ff eb 97 46 6c 6f 70 70 79 |u...}.....Floppy| >> 000001e0 00 bb 00 70 b8 01 02 b5 00 b6 00 cd 13 72 d7 b6 |...p.........r..| >> 000001f0 01 b5 4f e9 e0 fe 00 00 00 00 00 00 00 00 55 aa |..O...........U.| >> >> And indeed, the "eb 48" is there in my broken MBR, >> 14 bytes "too far". So it looks like I could just >> use a binary editor to remove the first 14 bytes, >> then write that back to my HDD's first sector? >> >> Not too sure about that, though. >> >> Does my broken MBR, shifted left by 14 bytes, look >> like a valid MBR for grub? >> >> Thoughts? Suggestions? How should I proceed? >> >> For the record, here are the disassembly for the >> broken MBR, and the good MBR (they do seem to differ >> in several places, I'm wondering if this is because >> I shouldn't be looking at /boot/grub/stage1) >> >> On a normal MBR, the code area ranges from 0 to 0x1b7 >> Shifted by 14 bytes, I expect range 14 to 0x1c5 >> >> http://prefetch.net/blog/index.php/2006/09/09/digging-through-the-mbr/ >> >> # cat broken_mbr.asm >> 0: 00 00 add %al,(%bx,%si) >> 2: 00 00 add %al,(%bx,%si) >> 4: 00 00 add %al,(%bx,%si) >> 6: 41 inc %cx >> 7: 01 63 74 add %sp,0x74(%bp,%di) >> a: e6 00 out %al,$0x0 >> c: 39 00 cmp %ax,(%bx,%si) >> XXX e: eb 48 jmp 0x58 >> 10: 90 nop >> 11: d0 bc 00 7c sarb 0x7c00(%si) >> 15: fb sti >> 16: 50 push %ax >> 17: 07 pop %es >> 18: 50 push %ax >> 19: 1f pop %ds >> 1a: fc cld >> 1b: be 1b 7c mov $0x7c1b,%si >> 1e: bf 1b 06 mov $0x61b,%di >> 21: 50 push %ax >> 22: 57 push %di >> 23: b9 e5 01 mov $0x1e5,%cx >> 26: f3 a4 rep movsb %ds:(%si),%es:(%di) >> 28: cb lret >> 29: bd be 07 mov $0x7be,%bp >> 2c: b1 04 mov $0x4,%cl >> 2e: 38 6e 00 cmp %ch,0x0(%bp) >> 31: 7c 09 jl 0x3c >> 33: 75 13 jne 0x48 >> 35: 83 c5 10 add $0x10,%bp >> 38: e2 f4 loop 0x2e >> 3a: cd 18 int $0x18 >> 3c: 8b f5 mov %bp,%si >> 3e: 83 c6 10 add $0x10,%si >> 41: 49 dec %cx >> 42: 74 19 je 0x5d >> 44: 38 2c cmp %ch,(%si) >> 46: 74 f6 je 0x3e >> 48: a0 b5 07 mov 0x7b5,%al >> 4b: b4 03 mov $0x3,%ah >> 4d: 02 80 00 00 add 0x0(%bx,%si),%al >> 51: 80 00 e8 addb $0xe8,(%bx,%si) >> 54: c4 0a les (%bp,%si),%cx >> 56: 00 08 add %cl,(%bx,%si) >> 58: fa cli >> 59: 90 nop >> 5a: 90 nop >> 5b: f6 c2 80 test $0x80,%dl >> 5e: 75 02 jne 0x62 >> 60: b2 80 mov $0x80,%dl >> 62: ea 59 7c 00 00 ljmp $0x0,$0x7c59 >> 67: 31 c0 xor %ax,%ax >> 69: 8e d8 mov %ax,%ds >> 6b: 8e d0 mov %ax,%ss >> 6d: bc 00 20 mov $0x2000,%sp >> 70: fb sti >> 71: a0 40 7c mov 0x7c40,%al >> 74: 3c ff cmp $0xff,%al >> 76: 74 02 je 0x7a >> 78: 88 c2 mov %al,%dl >> 7a: 52 push %dx >> 7b: f6 c2 80 test $0x80,%dl >> 7e: 74 54 je 0xd4 >> 80: b4 41 mov $0x41,%ah >> 82: bb aa 55 mov $0x55aa,%bx >> 85: cd 13 int $0x13 >> 87: 5a pop %dx >> 88: 52 push %dx >> 89: 72 49 jb 0xd4 >> 8b: 81 fb 55 aa cmp $0xaa55,%bx >> 8f: 75 43 jne 0xd4 >> 91: a0 41 7c mov 0x7c41,%al >> 94: 84 c0 test %al,%al >> 96: 75 05 jne 0x9d >> 98: 83 e1 01 and $0x1,%cx >> 9b: 74 37 je 0xd4 >> 9d: 66 8b 4c 10 mov 0x10(%si),%ecx >> a1: be 05 7c mov $0x7c05,%si >> a4: c6 44 ff 01 movb $0x1,-0x1(%si) >> a8: 66 8b 1e 44 7c mov 0x7c44,%ebx >> ad: c7 04 10 00 movw $0x10,(%si) >> b1: c7 44 02 01 00 movw $0x1,0x2(%si) >> b6: 66 89 5c 08 mov %ebx,0x8(%si) >> ba: c7 44 06 00 70 movw $0x7000,0x6(%si) >> bf: 66 31 c0 xor %eax,%eax >> c2: 89 44 04 mov %ax,0x4(%si) >> c5: 66 89 44 0c mov %eax,0xc(%si) >> c9: b4 42 mov $0x42,%ah >> cb: cd 13 int $0x13 >> cd: 72 05 jb 0xd4 >> cf: bb 00 70 mov $0x7000,%bx >> d2: eb 7d jmp 0x151 >> d4: b4 08 mov $0x8,%ah >> d6: cd 13 int $0x13 >> d8: 73 0a jae 0xe4 >> da: f6 c2 80 test $0x80,%dl >> dd: 0f 84 f0 00 je 0x1d1 >> e1: e9 8d 00 jmp 0x171 >> e4: be 05 7c mov $0x7c05,%si >> e7: c6 44 ff 00 movb $0x0,-0x1(%si) >> eb: 66 31 c0 xor %eax,%eax >> ee: 88 f0 mov %dh,%al >> f0: 40 inc %ax >> f1: 66 89 44 04 mov %eax,0x4(%si) >> f5: 31 d2 xor %dx,%dx >> f7: 88 ca mov %cl,%dl >> f9: c1 e2 02 shl $0x2,%dx >> fc: 88 e8 mov %ch,%al >> fe: 88 f4 mov %dh,%ah >> 100: 40 inc %ax >> 101: 89 44 08 mov %ax,0x8(%si) >> 104: 31 c0 xor %ax,%ax >> 106: 88 d0 mov %dl,%al >> 108: c0 e8 02 shr $0x2,%al >> 10b: 66 89 04 mov %eax,(%si) >> 10e: 66 a1 44 7c mov 0x7c44,%eax >> 112: 66 31 d2 xor %edx,%edx >> 115: 66 f7 34 divl (%si) >> 118: 88 54 0a mov %dl,0xa(%si) >> 11b: 66 31 d2 xor %edx,%edx >> 11e: 66 f7 74 04 divl 0x4(%si) >> 122: 88 54 0b mov %dl,0xb(%si) >> 125: 89 44 0c mov %ax,0xc(%si) >> 128: 3b 44 08 cmp 0x8(%si),%ax >> 12b: 7d 3c jge 0x169 >> 12d: 8a 54 0d mov 0xd(%si),%dl >> 130: c0 e2 06 shl $0x6,%dl >> 133: 8a 4c 0a mov 0xa(%si),%cl >> 136: fe c1 inc %cl >> 138: 08 d1 or %dl,%cl >> 13a: 8a 6c 0c mov 0xc(%si),%ch >> 13d: 5a pop %dx >> 13e: 8a 74 0b mov 0xb(%si),%dh >> 141: bb 00 70 mov $0x7000,%bx >> 144: 8e c3 mov %bx,%es >> 146: 31 db xor %bx,%bx >> 148: b8 01 02 mov $0x201,%ax >> 14b: cd 13 int $0x13 >> 14d: 72 2a jb 0x179 >> 14f: 8c c3 mov %es,%bx >> 151: 8e 06 48 7c mov 0x7c48,%es >> 155: 60 pusha >> 156: 1e push %ds >> 157: b9 00 01 mov $0x100,%cx >> 15a: 8e db mov %bx,%ds >> 15c: 31 f6 xor %si,%si >> 15e: 31 ff xor %di,%di >> 160: fc cld >> 161: f3 a5 rep movsw %ds:(%si),%es:(%di) >> 163: 1f pop %ds >> 164: 61 popa >> 165: ff 26 42 7c jmp *0x7c42 >> 169: be 7f 7d mov $0x7d7f,%si >> 16c: e8 40 00 call 0x1af >> 16f: eb 0e jmp 0x17f >> 171: be 84 7d mov $0x7d84,%si >> 174: e8 38 00 call 0x1af >> 177: eb 06 jmp 0x17f >> 179: be 8e 7d mov $0x7d8e,%si >> 17c: e8 30 00 call 0x1af >> 17f: be 93 7d mov $0x7d93,%si >> 182: e8 2a 00 call 0x1af >> 185: eb fe jmp 0x185 >> 187: 47 inc %di >> 188: 52 push %dx >> 189: 55 push %bp >> 18a: 42 inc %dx >> 18b: 20 00 and %al,(%bx,%si) >> 18d: 47 inc %di >> 18e: 65 6f outsw %gs:(%si),(%dx) >> 190: 6d insw (%dx),%es:(%di) >> 191: 00 48 61 add %cl,0x61(%bx,%si) >> 194: 72 64 jb 0x1fa >> 196: 20 44 69 and %al,0x69(%si) >> 199: 73 6b jae 0x206 >> 19b: 00 52 65 add %dl,0x65(%bp,%si) >> 19e: 61 popa >> 19f: 64 00 20 add %ah,%fs:(%bx,%si) >> 1a2: 45 inc %bp >> 1a3: 72 72 jb 0x217 >> 1a5: 6f outsw %ds:(%si),(%dx) >> 1a6: 72 00 jb 0x1a8 >> 1a8: bb 01 00 mov $0x1,%bx >> 1ab: b4 0e mov $0xe,%ah >> 1ad: cd 10 int $0x10 >> 1af: ac lods %ds:(%si),%al >> 1b0: 3c 00 cmp $0x0,%al >> 1b2: 75 f4 jne 0x1a8 >> 1b4: c3 ret >> ... >> !!! DATA (NOT CODE) BELOW THISPOINT (AFAIU) !!! >> 1c5: 00 dc add %bl,%ah >> 1c7: 3b dd cmp %bp,%bx >> 1c9: 3b 00 cmp (%bx,%si),%ax >> 1cb: 00 80 20 21 add %al,0x2120(%bx,%si) >> 1cf: 00 07 add %al,(%bx) >> 1d1: fe (bad) >> 1d2: ff (bad) >> 1d3: ff 00 incw (%bx,%si) >> 1d5: 08 00 or %al,(%bx,%si) >> 1d7: 00 00 add %al,(%bx,%si) >> 1d9: 00 00 add %al,(%bx,%si) >> 1db: 0a 00 or (%bx,%si),%al >> 1dd: fe (bad) >> 1de: ff (bad) >> 1df: ff 83 fe ff incw -0x2(%bp,%di) >> 1e3: ff 00 incw (%bx,%si) >> 1e5: 08 00 or %al,(%bx,%si) >> 1e7: 0a 00 or (%bx,%si),%al >> 1e9: 00 38 add %bh,(%bx,%si) >> 1eb: 04 00 add $0x0,%al >> 1ed: fe (bad) >> 1ee: ff (bad) >> 1ef: ff 82 fe ff incw -0x2(%bp,%si) >> 1f3: ff 00 incw (%bx,%si) >> 1f5: 08 38 or %bh,(%bx,%si) >> 1f7: 0e push %cs >> 1f8: 00 e8 add %ch,%al >> 1fa: 17 pop %ss >> ... >> 20b: 00 55 aa add %dl,-0x56(%di) >> >> >> # cat good_mbr.asm >> 0: eb 48 jmp 0x4a >> 2: 90 nop >> ... >> 3b: 00 00 add %al,(%bx,%si) >> 3d: 00 03 add %al,(%bp,%di) >> 3f: 02 ff add %bh,%bh >> 41: 00 00 add %al,(%bx,%si) >> 43: 80 01 00 addb $0x0,(%bx,%di) >> 46: 00 00 add %al,(%bx,%si) >> 48: 00 08 add %cl,(%bx,%si) >> 4a: fa cli >> 4b: eb 07 jmp 0x54 >> 4d: f6 c2 80 test $0x80,%dl >> 50: 75 02 jne 0x54 >> 52: b2 80 mov $0x80,%dl >> 54: ea 59 7c 00 00 ljmp $0x0,$0x7c59 >> 59: 31 c0 xor %ax,%ax >> 5b: 8e d8 mov %ax,%ds >> 5d: 8e d0 mov %ax,%ss >> 5f: bc 00 20 mov $0x2000,%sp >> 62: fb sti >> 63: a0 40 7c mov 0x7c40,%al >> 66: 3c ff cmp $0xff,%al >> 68: 74 02 je 0x6c >> 6a: 88 c2 mov %al,%dl >> 6c: 52 push %dx >> 6d: f6 c2 80 test $0x80,%dl >> 70: 74 54 je 0xc6 >> 72: b4 41 mov $0x41,%ah >> 74: bb aa 55 mov $0x55aa,%bx >> 77: cd 13 int $0x13 >> 79: 5a pop %dx >> 7a: 52 push %dx >> 7b: 72 49 jb 0xc6 >> 7d: 81 fb 55 aa cmp $0xaa55,%bx >> 81: 75 43 jne 0xc6 >> 83: a0 41 7c mov 0x7c41,%al >> 86: 84 c0 test %al,%al >> 88: 75 05 jne 0x8f >> 8a: 83 e1 01 and $0x1,%cx >> 8d: 74 37 je 0xc6 >> 8f: 66 8b 4c 10 mov 0x10(%si),%ecx >> 93: be 05 7c mov $0x7c05,%si >> 96: c6 44 ff 01 movb $0x1,-0x1(%si) >> 9a: 66 8b 1e 44 7c mov 0x7c44,%ebx >> 9f: c7 04 10 00 movw $0x10,(%si) >> a3: c7 44 02 01 00 movw $0x1,0x2(%si) >> a8: 66 89 5c 08 mov %ebx,0x8(%si) >> ac: c7 44 06 00 70 movw $0x7000,0x6(%si) >> b1: 66 31 c0 xor %eax,%eax >> b4: 89 44 04 mov %ax,0x4(%si) >> b7: 66 89 44 0c mov %eax,0xc(%si) >> bb: b4 42 mov $0x42,%ah >> bd: cd 13 int $0x13 >> bf: 72 05 jb 0xc6 >> c1: bb 00 70 mov $0x7000,%bx >> c4: eb 7d jmp 0x143 >> c6: b4 08 mov $0x8,%ah >> c8: cd 13 int $0x13 >> ca: 73 0a jae 0xd6 >> cc: f6 c2 80 test $0x80,%dl >> cf: 0f 84 f0 00 je 0x1c3 >> d3: e9 8d 00 jmp 0x163 >> d6: be 05 7c mov $0x7c05,%si >> d9: c6 44 ff 00 movb $0x0,-0x1(%si) >> dd: 66 31 c0 xor %eax,%eax >> e0: 88 f0 mov %dh,%al >> e2: 40 inc %ax >> e3: 66 89 44 04 mov %eax,0x4(%si) >> e7: 31 d2 xor %dx,%dx >> e9: 88 ca mov %cl,%dl >> eb: c1 e2 02 shl $0x2,%dx >> ee: 88 e8 mov %ch,%al >> f0: 88 f4 mov %dh,%ah >> f2: 40 inc %ax >> f3: 89 44 08 mov %ax,0x8(%si) >> f6: 31 c0 xor %ax,%ax >> f8: 88 d0 mov %dl,%al >> fa: c0 e8 02 shr $0x2,%al >> fd: 66 89 04 mov %eax,(%si) >> 100: 66 a1 44 7c mov 0x7c44,%eax >> 104: 66 31 d2 xor %edx,%edx >> 107: 66 f7 34 divl (%si) >> 10a: 88 54 0a mov %dl,0xa(%si) >> 10d: 66 31 d2 xor %edx,%edx >> 110: 66 f7 74 04 divl 0x4(%si) >> 114: 88 54 0b mov %dl,0xb(%si) >> 117: 89 44 0c mov %ax,0xc(%si) >> 11a: 3b 44 08 cmp 0x8(%si),%ax >> 11d: 7d 3c jge 0x15b >> 11f: 8a 54 0d mov 0xd(%si),%dl >> 122: c0 e2 06 shl $0x6,%dl >> 125: 8a 4c 0a mov 0xa(%si),%cl >> 128: fe c1 inc %cl >> 12a: 08 d1 or %dl,%cl >> 12c: 8a 6c 0c mov 0xc(%si),%ch >> 12f: 5a pop %dx >> 130: 8a 74 0b mov 0xb(%si),%dh >> 133: bb 00 70 mov $0x7000,%bx >> 136: 8e c3 mov %bx,%es >> 138: 31 db xor %bx,%bx >> 13a: b8 01 02 mov $0x201,%ax >> 13d: cd 13 int $0x13 >> 13f: 72 2a jb 0x16b >> 141: 8c c3 mov %es,%bx >> 143: 8e 06 48 7c mov 0x7c48,%es >> 147: 60 pusha >> 148: 1e push %ds >> 149: b9 00 01 mov $0x100,%cx >> 14c: 8e db mov %bx,%ds >> 14e: 31 f6 xor %si,%si >> 150: 31 ff xor %di,%di >> 152: fc cld >> 153: f3 a5 rep movsw %ds:(%si),%es:(%di) >> 155: 1f pop %ds >> 156: 61 popa >> 157: ff 26 42 7c jmp *0x7c42 >> 15b: be 7f 7d mov $0x7d7f,%si >> 15e: e8 40 00 call 0x1a1 >> 161: eb 0e jmp 0x171 >> 163: be 84 7d mov $0x7d84,%si >> 166: e8 38 00 call 0x1a1 >> 169: eb 06 jmp 0x171 >> 16b: be 8e 7d mov $0x7d8e,%si >> 16e: e8 30 00 call 0x1a1 >> 171: be 93 7d mov $0x7d93,%si >> 174: e8 2a 00 call 0x1a1 >> 177: eb fe jmp 0x177 >> 179: 47 inc %di >> 17a: 52 push %dx >> 17b: 55 push %bp >> 17c: 42 inc %dx >> 17d: 20 00 and %al,(%bx,%si) >> 17f: 47 inc %di >> 180: 65 6f outsw %gs:(%si),(%dx) >> 182: 6d insw (%dx),%es:(%di) >> 183: 00 48 61 add %cl,0x61(%bx,%si) >> 186: 72 64 jb 0x1ec >> 188: 20 44 69 and %al,0x69(%si) >> 18b: 73 6b jae 0x1f8 >> 18d: 00 52 65 add %dl,0x65(%bp,%si) >> 190: 61 popa >> 191: 64 00 20 add %ah,%fs:(%bx,%si) >> 194: 45 inc %bp >> 195: 72 72 jb 0x209 >> 197: 6f outsw %ds:(%si),(%dx) >> 198: 72 00 jb 0x19a >> 19a: bb 01 00 mov $0x1,%bx >> 19d: b4 0e mov $0xe,%ah >> 19f: cd 10 int $0x10 >> 1a1: ac lods %ds:(%si),%al >> 1a2: 3c 00 cmp $0x0,%al >> 1a4: 75 f4 jne 0x19a >> 1a6: c3 ret >> ... >> !!! DATA (NOT CODE) BELOW THIS POINT (AFAIU) !!! >> 1bb: 00 00 add %al,(%bx,%si) >> 1bd: 00 24 add %ah,(%si) >> 1bf: 12 0f adc (%bx),%cl >> 1c1: 09 00 or %ax,(%bx,%si) >> 1c3: be bd 7d mov $0x7dbd,%si >> 1c6: 31 c0 xor %ax,%ax >> 1c8: cd 13 int $0x13 >> 1ca: 46 inc %si >> 1cb: 8a 0c mov (%si),%cl >> 1cd: 80 f9 00 cmp $0x0,%cl >> 1d0: 75 0f jne 0x1e1 >> 1d2: be da 7d mov $0x7dda,%si >> 1d5: e8 c9 ff call 0x1a1 >> 1d8: eb 97 jmp 0x171 >> 1da: 46 inc %si >> 1db: 6c insb (%dx),%es:(%di) >> 1dc: 6f outsw %ds:(%si),(%dx) >> 1dd: 70 70 jo 0x24f >> 1df: 79 00 jns 0x1e1 >> 1e1: bb 00 70 mov $0x7000,%bx >> 1e4: b8 01 02 mov $0x201,%ax >> 1e7: b5 00 mov $0x0,%ch >> 1e9: b6 00 mov $0x0,%dh >> 1eb: cd 13 int $0x13 >> 1ed: 72 d7 jb 0x1c6 >> 1ef: b6 01 mov $0x1,%dh >> 1f1: b5 4f mov $0x4f,%ch >> 1f3: e9 e0 fe jmp 0xd6 >> ... >> 1fe: 55 push %bp >> 1ff: aa stos %al,%es:(%di) >> >> Thanks for reading this far!! ;-) >> >> Regards.
[toc] | [prev] | [next] | [standalone]
| From | Arno <me@privacy.net> |
|---|---|
| Date | 2011-10-27 15:24 +0000 |
| Message-ID | <9gtbd1F851U1@mid.individual.net> |
| In reply to | #1288 |
In comp.sys.ibm.pc.hardware.storage Noob <root@127.0.0.1> wrote: > EPILOGUE (top-posted, please delete history if replying) > Well, it was indeed a hardware problem: after weeks of correct > operation, and the occasional weirdness once in a while, port > IDE0 suddenly and completely failed, refusing to detect any > peripheral (HDD or optical drive) plugged into it. > I suppose I have three options: > 1) change the MB (I'd need to buy used, since socket 939 MBs are rare now) > 2) buy a SATA HDD, and just tape over IDE0 > 3) Configure HDD as master, DVD drive as slave on IDE1 > I'm leaning towards solution 2, until I upgrade the whole system > (well MB+CPU+RAM at least; I have decent GPU, PS, and case) You can go way 2, but it is a real possibility this is a chipset problem and will affect the SATA port as well. I had one ASUS board (they have moved to the "incompetent and stupid" model for chipset cooling some time ago), that started with failing USB then moved on to SATA port by port. There ia also option 4: Get an IDE controller. And thanks for posting the info! Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2011-10-28 11:06 +0200 |
| Message-ID | <j8dr9u$vor$1@dont-email.me> |
| In reply to | #1289 |
Arno wrote: > Noob wrote: > >> EPILOGUE >> >> Well, it was indeed a hardware problem: after weeks of correct >> operation, and the occasional weirdness once in a while, port >> IDE0 suddenly and completely failed, refusing to detect any >> peripheral (HDD or optical drive) plugged into it. >> >> I suppose I have three options: >> >> 1) change the MB (I'd need to buy used, since socket 939 MBs are rare now) >> 2) buy a SATA HDD, and just tape over IDE0 >> 3) Configure HDD as master, DVD drive as slave on IDE1 >> >> I'm leaning towards solution 2, until I upgrade the whole system >> (well MB+CPU+RAM at least; I have decent GPU, PS, and case) > > You can go way 2, but it is a real possibility this is a chipset > problem and will affect the SATA port as well. Thanks for pointing that out. I hadn't thought to incriminate the south bridge. I do hope it's still working fine, because I've just bought 2 GB of DDR1, which are useless once I finally replace the MB. > I had one ASUS board (they have moved to the "incompetent and > stupid" model for chipset cooling some time ago), that started > with failing USB then moved on to SATA port by port. My MB is an Asus A8N-E. There was an issue with the chipset fan on early models, and Asus changed the fan on later models. However, this new chipset fan was still too noisy for my taste, so I turned it off, and installed a 12-cm fan in the front of the case to blow cold air (from outside the case) on the HDD and the chipset. I monitored the chipset temperature for several months, and everything seemed well. But maybe I should have changed the chipset heatsink+fan with some custom solution, such as a Zalman ZM-NB47J passive heatsink, with the cold air from the chassis fan blowing over it... > There ia also option 4: Get an IDE controller. Thanks I hadn't thought of that either. Can the BIOS boot off a HDD plugged into a PCI-based IDE controller?
[toc] | [prev] | [next] | [standalone]
| From | Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> |
|---|---|
| Date | 2011-07-29 00:49 +0100 |
| Message-ID | <IU.D20110728.T235029.P59792.Q1@J.de.Boyne.Pollard.localhost> |
| In reply to | #821 |
> I used a Fedora 15 live CD to boot to Linux, and examine the MBR. > And yet this: > # cat broken_mbr.dump > is not a command to do that. So what command did you *actually* run to obtain the contents of your MBR?
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2011-08-01 11:27 +0200 |
| Message-ID | <j15rhl$12o$1@dont-email.me> |
| In reply to | #871 |
Jonathan de Boyne Pollard wrote: > Noob wrote: > >> I used a Fedora 15 live CD to boot to Linux, and examine the MBR. > > And yet this: > >> # cat broken_mbr.dump > > is not a command to do that. So what command did you *actually* > run to obtain the contents of your MBR? # dd if=/dev/sda of=mbr.bin bs=512 count=2 # hexdump -C mbr.bin >broken_mbr.dump Was there another (better) way to do this? Regards.
[toc] | [prev] | [next] | [standalone]
| From | Nico Kadel-Garcia <nkadel@gmail.com> |
|---|---|
| Date | 2011-08-06 10:00 -0700 |
| Message-ID | <092f1f25-787c-4b3e-8f47-a771dc45247d@glegroupsg2000goo.googlegroups.com> |
| In reply to | #880 |
You only need one block, if that's where your MBR, in fact, is recorded. The MBR is nicely broken down at http://en.wikipedia.org/wiki/Master_boot_record.
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.os.linux.setup
csiph-web