Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.setup > #821 > unrolled thread

Help, the dog ate my MBR (Linux/Windows dual boot)

Back to article view | Back to comp.os.linux.setup

Contents

  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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#843

Noob <root@127.0.0.1> writes:
>[ Please note that I've added comp.sys.ibm.pc.hardware.storage
>to the list of newsgroups ]
>
>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?

This has all the classic signatures of bad memory.   How did you
test your memory?   Has it ECC?  Registered or unbuffered?

s

[toc] | [prev] | [next] | [standalone]

#852

Scott Lurndal wrote:

> 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?
>
> This has all the classic signatures of bad memory.   How did you
> test your memory?   Has it ECC?  Registered or unbuffered?

I tested the RAM using memtest86+ v4.10 on the Fedora 15 live CD.
I let the test run for two hours. It completed the first pass in
35 minutes, while the second took much longer. Is that expected?

(It didn't report any error.)

Moreover, I don't have any strange behavior once the OS (either
Linux or Windows) has booted up, so I'm having a hard time buying
the "faulty RAM" theory.

The motherboard is an ASUS A8N-E (AMD socket 939).
The RAM is 2x1GB DDR1 201 MHz 3-4-4-8, no ECC, unbuffered
(Corsair Value Select in dual channel configuration)
memtest86+ reports 2209 MB/s bandwidth
(which is quite far from the theoretical 3200 MB/s)

Regards.

[toc] | [prev] | [next] | [standalone]

#857

Noob wrote:

> The motherboard is an ASUS A8N-E (AMD socket 939).
> The RAM is 2x1GB DDR1 201 MHz 3-4-4-8, no ECC, unbuffered
> (Corsair Value Select in dual channel configuration)
> memtest86+ reports 2209 MB/s bandwidth
> (which is quite far from the theoretical 3200 MB/s)

In fact, AFAIU, dual-channel DDR-400 should even reach 6400 MB/s.

[toc] | [prev] | [next] | [standalone]

#858

In comp.sys.ibm.pc.hardware.storage Noob <root@127.0.0.1> wrote:
[...]
> I tested the RAM using memtest86+ v4.10 on the Fedora 15 live CD.
> I let the test run for two hours. It completed the first pass in
> 35 minutes, while the second took much longer. Is that expected?

> (It didn't report any error.)

Passes should take the ame time, unless your hardware is dying
(e.g. the CPU ECCing like crazy in first-level cache or CPU
intermittendly trotheling because of overheating).
Also, 2 hours is far too short. Let it at least run a
full day.

> Moreover, I don't have any strange behavior once the OS (either
> Linux or Windows) has booted up, so I'm having a hard time buying
> the "faulty RAM" theory.

Effects from fauly RAM can be higly dependen on where the faults are.

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]

#866

Arno wrote:

> In comp.sys.ibm.pc.hardware.storage Noob wrote:
> 
>> I tested the RAM using memtest86+ v4.10 on the Fedora 15 live CD.
>> I let the test run for two hours. It completed the first pass in
>> 35 minutes, while the second took much longer. Is that expected?
> 
>> (It didn't report any error.)
> 
> Passes should take the ame time, unless your hardware is dying
> (e.g. the CPU ECCing like crazy in first-level cache or CPU
> intermittendly trotheling because of overheating).
> Also, 2 hours is far too short. Let it at least run a
> full day.

I ran memtest86+ for 20 hours.

No errors were reported (over 18 passes).

I would think that the problem (the system being unable
to read the first sector of the HDD) was a freak accident,
like cosmic rays, or radioactive spiders, or something
equally rare; except that it happened TWICE in a week.

However, it has not happened since.

What am I doing differently?
I've stopped using Windows' "hibernate" feature.
I haven't played any games in a while.
(Nothing else relevant comes to mind.)

>> Moreover, I don't have any strange behavior once the OS (either
>> Linux or Windows) has booted up, so I'm having a hard time buying
>> the "faulty RAM" theory.
> 
> Effects from faulty RAM can be higly dependent on where the faults are.

If the problem occurs again, would I gain any insight
by running memtest after swapping the (two) DIMMs?

I could also put the system in single channel mode,
which would prevent interleaving, right?

Regards.

[toc] | [prev] | [next] | [standalone]

#867

Noob wrote:
> Arno wrote:
> 
>> In comp.sys.ibm.pc.hardware.storage Noob wrote:
>>
>>> I tested the RAM using memtest86+ v4.10 on the Fedora 15 live CD.
>>> I let the test run for two hours. It completed the first pass in
>>> 35 minutes, while the second took much longer. Is that expected?
>>> (It didn't report any error.)
>> Passes should take the ame time, unless your hardware is dying
>> (e.g. the CPU ECCing like crazy in first-level cache or CPU
>> intermittendly trotheling because of overheating).
>> Also, 2 hours is far too short. Let it at least run a
>> full day.
> 
> I ran memtest86+ for 20 hours.
> 
> No errors were reported (over 18 passes).
> 
> I would think that the problem (the system being unable
> to read the first sector of the HDD) was a freak accident,
> like cosmic rays, or radioactive spiders, or something
> equally rare; except that it happened TWICE in a week.
> 

Running memtest wont show a bus error caused by (in Intel architecture) 
a lazy decode of an IO chip.


Since memtest wont be doing any IO instructions.

Things that might cause such a bus collsion include

overheating.
failing peripheral chip
Bad peripheral card.

The problem is that its almost reproducible by running a software test.

[toc] | [prev] | [next] | [standalone]

#868

Noob <root@127.0.0.1> writes:

>I've stopped using Windows' "hibernate" feature.

Now this seems to be a likely candidate.  I could easily imagine
windows modifying the MBR to short-circuit the recovery from
hibernation.

I assume this is a dual boot system and you're using grub to boot
both linux and windows?

scott

[toc] | [prev] | [next] | [standalone]

#869

Scott Lurndal wrote:

> Noob wrote:
> 
>> I've stopped using Windows' "hibernate" feature.
> 
> Now this seems to be a likely candidate.  I could easily imagine
> windows modifying the MBR to short-circuit the recovery from
> hibernation.

I don't think Windows XP modifies the MBR because I always
get the GRUB2 menu when I boot up, whether I halt XP or send
it to hibernation (aka suspend to disk).

Moreover, as far as I could tell, the MBR had not been
modified, it had been shifted by 14 (?!) bytes...

> I assume this is a dual boot system and you're using grub
> to boot both linux and windows?

Yes I have Windows XP, Fedora 13 (must upgrade), and a swap
partition, all managed by GRUB2.

Regards.

[toc] | [prev] | [next] | [standalone]

#870

> Now this seems to be a likely candidate.
>
Not really.

> I could easily imagine windows modifying the MBR to short-circuit the 
> recovery from hibernation.
>
Imagination doesn't create truth.  The hibernation resumption is simply 
an alternative to the normal kernel loader, winresume.exe instead of 
winload.exe.  It is invoked by the Microsoft  Boot Manager, that is 
itself run long after the MBR has been involved in the bootstrap 
process, at the point where it would normally invoke the kernel loader.  
Hibernation resumption is not very different to an ordinary BCD entry, 
in fact.

It is, as usual, Linux not Windows that has its dirty little fingers 
into M. Noob's MBR.  Xe has GRUB there.

[toc] | [prev] | [next] | [standalone]

#844

On 07/23/11 02:25 AM, Noob wrote:
>
> 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".

How did you test the RAM, memtest86?  The symptoms do point to a memory 
problem.

If you have several GB of RAM it can take a long time to test.  I'd 
leave it to run over night.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#845

On Fri, 22 Jul 2011 16:25:28 +0200, Noob <root@127.0.0.1> put finger
to keyboard and composed:

>> 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.
>
>> 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?

ISTM that you are confusing the real, "good" MBR (ie physical sector
0) with GRUB's "bad" MBR. The latter appears to be relocated to some
other LBA(s), not LBA 0.

I expect that the code in the "good" MBR (ie the "real" MBR at LBA 0)
is executed at bootup, after which control is transferred to code in
the "bad" MBR. 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.

1B0                                            24 12               $.
1C0  0F 09 00 BE BD 7D 31 C0-CD 13 46 8A 0C 80 F9 00 .....}1...F.....
1D0  75 0F BE DA 7D E8 C9 FF-EB 97 46 6C 6F 70 70 79 u...}.....Floppy
1E0  00 BB 00 70 B8 01 02 B5-00 B6 00 CD 13 72 D7 B6 ...p.........r..
1F0  01 B5 4F E9 E0 FE 00 00-00                      ..O......

As you can see, the unassembled code has INT 13 instructions.

See http://en.wikipedia.org/wiki/INT_13H

-u 1be 1d9
01BE 2412          AND     AL,12
01C0 0F            DB      0F
01C1 0900          OR      [BX+SI],AX
01C3 BEBD7D        MOV     SI,7DBD
01C6 31C0          XOR     AX,AX
01C8 CD13          INT     13

- INT 13 (AH=0) -> Reset Disk Drives

01CA 46            INC     SI
01CB 8A0C          MOV     CL,[SI]
01CD 80F900        CMP     CL,00
01D0 750F          JNZ     01E1
01D2 BEDA7D        MOV     SI,7DDA
01D5 E8C9FF        CALL    01A1
01D8 EB97          JMP     0171


-u 1e1 1f8
01E1 BB0070        MOV     BX,7000
01E4 B80102        MOV     AX,0201
01E7 B500          MOV     CH,00
01E9 B600          MOV     DH,00
01EB CD13          INT     13

The above code reads 1 sector from sector 0, track 0, head 0, drive 0
to a memory buffer at address 0x7000.

01ED 72D7          JB      01C6
01EF B601          MOV     DH,01
01F1 B54F          MOV     CH,4F
01F3 E9E0FE        JMP     00D6

Location 0xD6 contains an INT 13 opcode. Therefore, AFAICT, the above
code reads 1 sector from sector 0, track 79 (=0x4F), head 1, drive 0
to a buffer at address 0x7000.

- Franc Zabkar
-- 
Please remove one 'i' from my address when replying by email.

[toc] | [prev] | [next] | [standalone]

#846

Franc Zabkar wrote:
> On Fri, 22 Jul 2011 16:25:28 +0200, Noob <root@127.0.0.1> put finger
> to keyboard and composed:
> 
>>> 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.
>>
>>> 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?
> 
> ISTM that you are confusing the real, "good" MBR (ie physical sector
> 0) with GRUB's "bad" MBR. The latter appears to be relocated to some
> other LBA(s), not LBA 0.
> 
> I expect that the code in the "good" MBR (ie the "real" MBR at LBA 0)
> is executed at bootup, after which control is transferred to code in
> the "bad" MBR. 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.
> 
> 1B0                                            24 12               $.
> 1C0  0F 09 00 BE BD 7D 31 C0-CD 13 46 8A 0C 80 F9 00 .....}1...F.....
> 1D0  75 0F BE DA 7D E8 C9 FF-EB 97 46 6C 6F 70 70 79 u...}.....Floppy
> 1E0  00 BB 00 70 B8 01 02 B5-00 B6 00 CD 13 72 D7 B6 ...p.........r..
> 1F0  01 B5 4F E9 E0 FE 00 00-00                      ..O......
> 
> As you can see, the unassembled code has INT 13 instructions.
> 
> See http://en.wikipedia.org/wiki/INT_13H
> 
> -u 1be 1d9
> 01BE 2412          AND     AL,12
> 01C0 0F            DB      0F
> 01C1 0900          OR      [BX+SI],AX
> 01C3 BEBD7D        MOV     SI,7DBD
> 01C6 31C0          XOR     AX,AX
> 01C8 CD13          INT     13
> 
> - INT 13 (AH=0) -> Reset Disk Drives
> 
> 01CA 46            INC     SI
> 01CB 8A0C          MOV     CL,[SI]
> 01CD 80F900        CMP     CL,00
> 01D0 750F          JNZ     01E1
> 01D2 BEDA7D        MOV     SI,7DDA
> 01D5 E8C9FF        CALL    01A1
> 01D8 EB97          JMP     0171
> 
> 
> -u 1e1 1f8
> 01E1 BB0070        MOV     BX,7000
> 01E4 B80102        MOV     AX,0201
> 01E7 B500          MOV     CH,00
> 01E9 B600          MOV     DH,00
> 01EB CD13          INT     13
> 
> The above code reads 1 sector from sector 0, track 0, head 0, drive 0
> to a memory buffer at address 0x7000.
> 
> 01ED 72D7          JB      01C6
> 01EF B601          MOV     DH,01
> 01F1 B54F          MOV     CH,4F
> 01F3 E9E0FE        JMP     00D6
> 
> Location 0xD6 contains an INT 13 opcode. Therefore, AFAICT, the above
> code reads 1 sector from sector 0, track 79 (=0x4F), head 1, drive 0
> to a buffer at address 0x7000.
> 
> - Franc Zabkar

So can someone translate this for me ?

WHY would a disk be set up this way, with what
*altruistic* objective ?

And WHAT software can we expect, to be mucking about in this way ?
The "rootkit of the month" club perhaps ? :-)

    Paul

[toc] | [prev] | [next] | [standalone]

#848

On Fri, 22 Jul 2011 20:58:01 -0400, Paul <nospam@needed.com> put
finger to keyboard and composed:

>Franc Zabkar wrote:
>> On Fri, 22 Jul 2011 16:25:28 +0200, Noob <root@127.0.0.1> put finger
>> to keyboard and composed:
>> 
>>>> 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.
>>>
>>>> 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?
>> 
>> ISTM that you are confusing the real, "good" MBR (ie physical sector
>> 0) with GRUB's "bad" MBR. The latter appears to be relocated to some
>> other LBA(s), not LBA 0.
>> 
>> I expect that the code in the "good" MBR (ie the "real" MBR at LBA 0)
>> is executed at bootup, after which control is transferred to code in
>> the "bad" MBR. 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.
>> 
>> 1B0                                            24 12               $.
>> 1C0  0F 09 00 BE BD 7D 31 C0-CD 13 46 8A 0C 80 F9 00 .....}1...F.....
>> 1D0  75 0F BE DA 7D E8 C9 FF-EB 97 46 6C 6F 70 70 79 u...}.....Floppy
>> 1E0  00 BB 00 70 B8 01 02 B5-00 B6 00 CD 13 72 D7 B6 ...p.........r..
>> 1F0  01 B5 4F E9 E0 FE 00 00-00                      ..O......
>> 
>> As you can see, the unassembled code has INT 13 instructions.
>> 
>> See http://en.wikipedia.org/wiki/INT_13H
>> 
>> -u 1be 1d9
>> 01BE 2412          AND     AL,12
>> 01C0 0F            DB      0F
>> 01C1 0900          OR      [BX+SI],AX
>> 01C3 BEBD7D        MOV     SI,7DBD
>> 01C6 31C0          XOR     AX,AX
>> 01C8 CD13          INT     13
>> 
>> - INT 13 (AH=0) -> Reset Disk Drives
>> 
>> 01CA 46            INC     SI
>> 01CB 8A0C          MOV     CL,[SI]
>> 01CD 80F900        CMP     CL,00
>> 01D0 750F          JNZ     01E1
>> 01D2 BEDA7D        MOV     SI,7DDA
>> 01D5 E8C9FF        CALL    01A1
>> 01D8 EB97          JMP     0171
>> 
>> 
>> -u 1e1 1f8
>> 01E1 BB0070        MOV     BX,7000
>> 01E4 B80102        MOV     AX,0201
>> 01E7 B500          MOV     CH,00
>> 01E9 B600          MOV     DH,00
>> 01EB CD13          INT     13
>> 
>> The above code reads 1 sector from sector 0, track 0, head 0, drive 0
>> to a memory buffer at address 0x7000.
>> 
>> 01ED 72D7          JB      01C6
>> 01EF B601          MOV     DH,01
>> 01F1 B54F          MOV     CH,4F
>> 01F3 E9E0FE        JMP     00D6
>> 
>> Location 0xD6 contains an INT 13 opcode. Therefore, AFAICT, the above
>> code reads 1 sector from sector 0, track 79 (=0x4F), head 1, drive 0
>> to a buffer at address 0x7000.
>> 
>> - Franc Zabkar
>
>So can someone translate this for me ?
>
>WHY would a disk be set up this way, with what
>*altruistic* objective ?
>
>And WHAT software can we expect, to be mucking about in this way ?
>The "rootkit of the month" club perhaps ? :-)
>
>    Paul

In the days of Disk Drive Overlays, eg MaxBlast, the MBR would contain
a dummy partition table. This table would be set up for a 20MB drive,
with 17 sectors per track. The DDO code would call additional code
which hid within the first track, before sector 63. This code would
install itself in memory and provide the needed INT 13 extensions that
were missing from the BIOS. The actual MBR and a full sized partition
table would hide elsewhere within track 0. This is the MBR that the OS
would see.

In any case, one would have to ask, why is the OP's MBR code loading
sector 0, head 1, track 79? What code is in that particular sector?

- Franc Zabkar
-- 
Please remove one 'i' from my address when replying by email.

[toc] | [prev] | [next] | [standalone]

#874

> In any case, one would have to ask, why is the OP's MBR code loading sector 0, head 1, track 79? What code is in that particular sector?

M. Noob's MBR code is *not* doing that.  Again, go and read the GRUB2 
source.  Read the floppy_probe routine in grub-core/boot/i386/pc/boot.S 
.  Even the name alone is a bit of  a giveaway as to what the routine's 
purpose is.

[toc] | [prev] | [next] | [standalone]

#850

On Fri, 22 Jul 2011 20:58:01 -0400, Paul <nospam@needed.com> put
finger to keyboard and composed:

>So can someone translate this for me ?
>
>WHY would a disk be set up this way, with what
>*altruistic* objective ?
>
>And WHAT software can we expect, to be mucking about in this way ?
>The "rootkit of the month" club perhaps ? :-)
>
>    Paul

Sorry, I just realised where I made my mistake.

The OP confused me by saying that one day his MBR was bad, whereas on
the next day it was good. He then posted two MBR dumps. I assumed that
the good dump was from his hard drive. Instead it appears to be a
standard MBR template for a floppy diskette. Once again my previous
experience with DDOs led me astray. Seagate's EZ-Drive, for example,
gives you a window of opportunity during the HDD boot process to
select the floppy drive as your boot device (using Ctrl-S, IIRC). This
enables the DDO to load itself into RAM (and enable INT 13 extensions)
before the floppy drive boots.

BTW, I found this article very informative:
http://thestarman.pcministry.com/asm/mbr/GRUB.htm

- Franc Zabkar
-- 
Please remove one 'i' from my address when replying by email.

[toc] | [prev] | [next] | [standalone]

#875

> So can someone translate this for me ?
>
You can translate it for yourself.  Indeed you can read the untranslated 
original and save yourself even that effort.  GRUB2 is free software.  
Its source code, complete with comments explaining what it is doing, is 
there for the reading.  The file to read is  grub-core/boot/i386/pc/boot.S .

> WHY would a disk be set up this way, with what *altruistic* objective ?
>
Hint: The clue to its quite benign objective is the very name of the 
routine.

> And WHAT software can we expect, to be mucking about in this way ?  
> The "rootkit of the month" club perhaps ? :-)
>
One may think of GRUB2 in those terms if one likes.  It certainly (in 
this case) is installed in the place where MBR computer viruses live.

[toc] | [prev] | [next] | [standalone]

#849

On Sat, 23 Jul 2011 10:05:47 +1000, Franc Zabkar
<fzabkar@iinternode.on.net> put finger to keyboard and composed:

>01ED 72D7          JB      01C6
>01EF B601          MOV     DH,01
>01F1 B54F          MOV     CH,4F
>01F3 E9E0FE        JMP     00D6
>
>Location 0xD6 contains an INT 13 opcode. Therefore, AFAICT, the above
>code reads 1 sector from sector 0, track 79 (=0x4F), head 1, drive 0
>to a buffer at address 0x7000.

Doh! There is an obvious reason for the existence of the "Floppy" text
string.

Drive 0 is the floppy drive (A:).

Track 79 is the last track of an 80-track diskette.

The drive would have two heads, 0 and 1.

- Franc Zabkar
-- 
Please remove one 'i' from my address when replying by email.

[toc] | [prev] | [next] | [standalone]

#853

Franc Zabkar wrote:

> 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.
>>
>>> 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?
>
> ISTM that you are confusing the real, "good" MBR (ie physical sector
> 0) with GRUB's "bad" MBR. The latter appears to be relocated to some
> other LBA(s), not LBA 0.

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?

My partition table is

80 20 21 00 07 fe ff ff 00 08 00 00 00 00 00 0a
00 fe ff ff 83 fe ff ff 00 08 00 0a 00 00 38 04
00 fe ff ff 82 fe ff ff 00 08 38 0e 00 e8 17 00

[toc] | [prev] | [next] | [standalone]

#859

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?

I'm not a Linux user, but that seems OK to me (it's listed in
Wikipedia as one of the examples). In fact I wondered how you were
capturing these data because often such an offset is the result of the
application adding its own header information. In such cases the file
size would be 1038 (= 2 x 512 + 14), rather than 1024 bytes.

>My partition table is
>
>80 20 21 00 07 fe ff ff 00 08 00 00 00 00 00 0a
>00 fe ff ff 83 fe ff ff 00 08 00 0a 00 00 38 04
>00 fe ff ff 82 fe ff ff 00 08 38 0e 00 e8 17 00

Yes, I understood that from your original post. It's just that you
posted a "good" MBR dump that wasn't your own. That's what led me
astray. Sorry.

Some people have suggested that there may be a problem with your
system RAM, or with the drive's own SDRAM cache.

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

Maxtor Diamondmax 10 Product Manual:
http://www.seagate.com/staticfiles/maxtor/en_us/documentation/manuals/diamondmax_10_product_manual_pata.pdf

- Franc Zabkar
-- 
Please remove one 'i' from my address when replying by email.

[toc] | [prev] | [next] | [standalone]

#860

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 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.

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.

scott

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.os.linux.setup

csiph-web