[gentoo-user] He's baaaaaack!

[gentoo-user] He's baaaaaack!

[maxim wexler]

Hello everybody,

You may recall my tussle with an Sempron/Asus K8N-e
box: first it wouldn't boot but I fixed that and then
the entire unit died.

The tech at Asus suggested I *reverse* the CMOS
battery for a few seconds. I was skeptical but it
seems to have done the trick. 

However LBA remains 'off' for my Maxtor120G HD in the
POST even though it's listed as LBA-capable in the
BIOS and LBA is also set to 'auto' in the BIOS.

Also gentoo boots but not WinXP.

To recap: I moved all my boot stuff to a 200M HD,
mounted as Pri-Master. The Maxtor 120G(Pri-Slave) was
split nearly in two with WinXP on the first half,
gentoo on the 2nd.

When I try to boot WinXP I get:

rootnoverify (hd1,0)#2nd drive,first partition,right?
makeactive
chainloader +1

then the cursor advances a couple of lines and just
sits there blinking.

Does WinXP absolutely have to be the first partition
on the first drive? What if I made the 200M the slave
and re-did grub, could I still boot from it.

-mw


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] He's baaaaaack!

[Martins Steinbergs]

had same problem, solved rebuilding mbr
check fdisk, if same problem (16 heads instead of 255 heads) this will help

http://www.mail-archive.com/gentoo-user%40lists.gentoo.org/msg07969.html

On Monday 25 July 2005 03:39, maxim wexler wrote:
> Hello everybody,
>
> You may recall my tussle with an Sempron/Asus K8N-e
> box: first it wouldn't boot but I fixed that and then
> the entire unit died.
>
> The tech at Asus suggested I *reverse* the CMOS
> battery for a few seconds. I was skeptical but it
> seems to have done the trick.
>
> However LBA remains 'off' for my Maxtor120G HD in the
> POST even though it's listed as LBA-capable in the
> BIOS and LBA is also set to 'auto' in the BIOS.
>
> Also gentoo boots but not WinXP.
>
> To recap: I moved all my boot stuff to a 200M HD,
> mounted as Pri-Master. The Maxtor 120G(Pri-Slave) was
> split nearly in two with WinXP on the first half,
> gentoo on the 2nd.
>
> When I try to boot WinXP I get:
>
> rootnoverify (hd1,0)#2nd drive,first partition,right?
> makeactive
> chainloader +1
>
> then the cursor advances a couple of lines and just
> sits there blinking.
>
> Does WinXP absolutely have to be the first partition
> on the first drive? What if I made the 200M the slave
> and re-did grub, could I still boot from it.
>
> -mw
>
>
>
> ____________________________________________________
> Start your day with Yahoo! - make it your home page
> http://www.yahoo.com/r/hs
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] He's baaaaaack!

[maxim wexler]

--- Martins Steinbergs <mar@ml.lv> wrote:

> had same problem, solved rebuilding mbr
> check fdisk, if same problem (16 heads instead of
> 255 heads) this will help
> 
>
http://www.mail-archive.com/gentoo-user%40lists.gentoo.org/msg07969.html
> 

hmm, yes it *is* 16 heads. But before I try this thing
can you recall trying to boot WinXP after running
(win95)fdisk /mbr? In my case the boot.ini file on the
c:\ drive actually opens giving me a choice of WinXP
and the Recovery Console but clicking one or the other
just leads to a blank screen. Seems if I can reach
boot.ini all should be OK windows-wise.

-mw


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] He's baaaaaack!

[Martins Steinbergs]

On Monday 25 July 2005 07:35, maxim wexler wrote:
> --- Martins Steinbergs <mar@ml.lv> wrote:
> > had same problem, solved rebuilding mbr
> > check fdisk, if same problem (16 heads instead of
> > 255 heads) this will help
>
> http://www.mail-archive.com/gentoo-user%40lists.gentoo.org/msg07969.html
>
>
> hmm, yes it *is* 16 heads. But before I try this thing
> can you recall trying to boot WinXP after running
> (win95)fdisk /mbr? In my case the boot.ini file on the
> c:\ drive actually opens giving me a choice of WinXP
> and the Recovery Console but clicking one or the other
> just leads to a blank screen. Seems if I can reach
> boot.ini all should be OK windows-wise.
>
> -mw
>

there were no succesful winxp boot, because bios didnt enable LBA seting. i 
dont think (win95)fdisk wil work with linux partitions.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] He's baaaaaack!

[maxim wexler]

> 
> there were no succesful winxp boot, because bios
> didnt enable LBA seting. i 
> dont think (win95)fdisk wil work with linux
> partitions.

Right, but booting a win95/98 CD and running fdisk
/mbr from the DOS prompt will usually restore a WinXP
boot sector. What's so bizarre in this case is that it
should only partially restore(so it seems)
bootability. Can you or anyone explain what this
16/255 controversy has to do with it? True, LBA is
'off', but WinXP starts at the beginning of /dev/hdb
and *doesn't* boot, whereas gentoo starts at the 60G
point and it *does* boot. Also FWIW all WinXP files
are readable from gentoo once it's up.

Even when I eliminate the first drive, the 200M drive
where grub resides, and install the 120G HD as
pri-master and try to boot, boot.ini opens up giving
me the choices of WinXP and Recovery Console as I said
before; only problem: neither goes anywhere, just
hangs. 

-mw

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] He's baaaaaack!

[Martins Steinbergs]

log to linux, erase partition table, get those heads corect, write new 
partition table --> reboot, LBA is on and win is booting. none of dos/win 
apps worked for me to fix partition table.

i asume LBA is needed only for win itself, not vfat or ntfs partitions, 
therefore files are accesible from linux

martins


On Monday 25 July 2005 08:42, maxim wexler wrote:
> > there were no succesful winxp boot, because bios
> > didnt enable LBA seting. i
> > dont think (win95)fdisk wil work with linux
> > partitions.
>
> Right, but booting a win95/98 CD and running fdisk
> /mbr from the DOS prompt will usually restore a WinXP
> boot sector. What's so bizarre in this case is that it
> should only partially restore(so it seems)
> bootability. Can you or anyone explain what this
> 16/255 controversy has to do with it? True, LBA is
> 'off', but WinXP starts at the beginning of /dev/hdb
> and *doesn't* boot, whereas gentoo starts at the 60G
> point and it *does* boot. Also FWIW all WinXP files
> are readable from gentoo once it's up.
>
> Even when I eliminate the first drive, the 200M drive
> where grub resides, and install the 120G HD as
> pri-master and try to boot, boot.ini opens up giving
> me the choices of WinXP and Recovery Console as I said
> before; only problem: neither goes anywhere, just
> hangs.
>
> -mw
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] He's baaaaaack!

[Richard Fish]

Martins Steinbergs wrote:

>log to linux, erase partition table, get those heads corect, write new 
>partition table --> reboot, LBA is on and win is booting. none of dos/win 
>apps worked for me to fix partition table.
>
>i asume LBA is needed only for win itself, not vfat or ntfs partitions, 
>therefore files are accesible from linux
>
>martins
>
>  
>

Um, if you do this, you will more than likely destroy the filesystems as 
well, because the new partitions will not line up exactly with the old ones.

Anyway I don't think this is the problem.  Afterall, WinXP booted fine 
before on this drive with LBA disabled, so something else is up.  If you 
already made the right changes to the boot.ini file, then I suspect that 
a "fixboot" from the recovery mode of the WinXP CD will be necessary.  
This should not overwrite the MBR, only the boot loader that is at the 
beginning of the windows partition.

-Richard

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] He's baaaaaack!

[Martins]

>
>Um, if you do this, you will more than likely destroy the filesystems as 
>well, because the new partitions will not line up exactly with the old ones.
>
>Anyway I don't think this is the problem.  Afterall, WinXP booted fine 
>before on this drive with LBA disabled, so something else is up.  If you 
>already made the right changes to the boot.ini file, then I suspect that a 
>"fixboot" from the recovery mode of the WinXP CD will be necessary.
>This should not overwrite the MBR, only the boot loader that is at the 
>beginning of the windows partition.
>
>-Richard
>
>--
>gentoo-user@gentoo.org mailing list

there is no worry, writing new partition table give it the same values 
(partition start, end, type, order) as before and not a single bit is lost

this is kind of fedora installer bug, since i have amd64 box i was moving 
from mandrake to some more amd64 distro at that point, and befor gentoo i 
checked fedora. and problems started when i upgraded bios. 

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] He's baaaaaack!

[Richard Fish]

Martins wrote:

>
>>
>> Um, if you do this, you will more than likely destroy the filesystems 
>> as well, because the new partitions will not line up exactly with the 
>> old ones.
>>
>> Anyway I don't think this is the problem.  Afterall, WinXP booted 
>> fine before on this drive with LBA disabled, so something else is 
>> up.  If you already made the right changes to the boot.ini file, then 
>> I suspect that a "fixboot" from the recovery mode of the WinXP CD 
>> will be necessary.
>> This should not overwrite the MBR, only the boot loader that is at 
>> the beginning of the windows partition.
>>
>> -Richard
>>
>> -- 
>> gentoo-user@gentoo.org mailing list
>
>
> there is no worry, writing new partition table give it the same values 
> (partition start, end, type, order) as before and not a single bit is 
> lost
>

What I am saying is that this is not possible with fdisk, because fdisk 
will insist on creating the new partitions aligned on cylinder 
boundaries, which will have moved in terms of logical sectors.  Example:

Let's say you want a 100MB partition, or about 200000 512-byte sectors:

With non-LBA geometry, the math is 200000 sectors / (63 sectors/track * 
16 heads) = 198.41 cylinders. Now round down to 198 cylinders and you 
get 199584 sectors in your partition

With LBA geometry, the math is 200000 / (63 sectors/track * 255 heads) = 
12.449 cylinders.  Again, round down to 12, and you get 192780 sectors 
in your partition.  You can round up to 13 and get 208845, but you 
*cannot* get 199584.  Possibly with another partitioning tool that 
allows you to specify the starting and ending heads as well as 
cylinders, but not with fdisk.

It is *possible* for this to work if you have just one huge partition, 
or if your partitions happen to end at even multiples of both (63 * 255) 
and (63 * 16).

And just for the sake of accuracy, the cylinder alignment thing is true 
for all partitions except:

- Cylinder 0, head 0 is reserved for the MBR, so any partition starting 
at cylinder 0 actually starts at head 1.
- Logical partitions actually start at head 0, sector 1, because the 
first sector contains another partition table that points to the next 
partition.

-Richard

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] He's baaaaaack!

[Martins]

it is possible with fdisk, i did it and it worked, and this is steps i 
followed, step 7 wasnt necesary for me:

Fix for the XP dual boot problem

* From: Radu Cornea <ccradu yahoo com>
* To: For testers of Fedora Core development releases <fedora-test-list 
redhat com>
* Subject: Fix for the XP dual boot problem
* Date: Tue, 18 May 2004 22:37:57 -0700 (PDT)

Like other people on this list I was affected by the bug which makes the
XP partition in a dual boot configuration inaccessible after installing
Fedora. Below are the steps I used to restore the partition table to its
original configuration.

Some people mentioned a fix that involved setting the hard disk
configuration to LBA in the BIOS, but that may not work in some cases (I
have an old IBM Thinkpad which does not allow it).

By looking at the partition information as printed by fdisk after the
partition is corrupted, it seems that the bug affects only the C/H/S
values, the LBA are still correct. Even the fdisk manual specifies that
"DOS uses C/H/S only, Windows uses both [C/H/S and LBA], Linux never uses
C/H/S". This means that the correct information is still there but just
one copy is correct, the LBA one (most people affected said they could
access the Windows partition from Linux just fine). The procedure below
attempts to regenerate the MBR from scratch using the LBA values. In most
cases the original disk geometry had 255 (or 240) as number of heads
initially and was changed to 16 after the partition was corrupted by FC2.

More info about the bug can be found here:
https://bugzilla.redhat.com/bugzill...g.cgi?id=115980
https://bugzilla.redhat.com/bugzill...g.cgi?id=113201

This did work for me. I don't guarantee it will work for everyone, use it
at your own risk...

You need a bootable Linux CD (e.g. Knoppix) and a DOS system disk with
fdisk on it.
Here are the steps I followed:

1. boot from Knoppix or other bootable Linux CD (using the Fedora rescue
CD or booting in the newly installed system in single mode, ro mounted
may work too, but I haven't tried)

2. save the content of the MBR (and possibly all the boot sectors from
the partitions). This is important in case something goes wrong and you
want to restore later:
$ dd if=/dev/hda of=mbr.img bs=512 count=1

3. run fdisk, go into expert mode and write down (or save into a file)
the starting sector (NOT block), end sector and type for each partition
(example below):
$ fdisk /dev/hda
Command: u (change units to sectors)
Command: p (print)
Example output:

Device Boot Start End Blocks Id System
/dev/hda1 * 63 33732719 16866328+ 7 HPFS/NTFS
/dev/hda2 74692800 78140159 1723680 1c Hidden W95 FAT32
(LBA)
/dev/hda3 35834400 74692799 19429200 83 Linux
/dev/hda4 33732720 35834399 1050840 82 Linux swap

4. completely erase the MBR by writing zeros to it (you may skip this
step, I am not sure if it is really needed, but this way it worked for
me):
$ dd if=/dev/zero of=zero.img bs=512 count=1
$ dd if=zero.img of=/dev/hda

5. force the original number of heads. In my case (20Gb in a Thinkpad)
this was 240, but in most other cases it would be 255. See this post for
more info:

http://groups.google.com/groups?hl=....bofh.it&rnum=4

Using fdisk this will also create a new DOS partition table and restore
the original partitions:

$ fdisk -H 255 /dev/hda # or 240 for some configurations
Command: o (create new partition table)

6. by now you have a newly generaed partition table, with the original
disk geometry. Recreate the partitions as they were before:

Command: n (new partition)
Primary partition (p)
Partition number: 1
First cylinder: 63 # beginning of first partition
Last cylinder or +size[...]: 33732719 # end of first partition

Command: t (change type)
Partition number: 1
Hex code: 07 # they type of the partition

Repeat for all 4 partitions. Verify at the end that the start/end/id are
correct:

Command: p (print)

If everything is correct, write the partition table to the disk and exit:

Command: w (write)
Command: q (quit)

7. in my case, I had to run an extra "fdisk /mbr" using the DOS bootdisk
(may work with a XP installation CD too, but I haven't tried). After
that, everything worked fine, the partition table was back to the
original configuration.

If you have the GRUB in the MBR, the "fdisk /mbr" will overwrite it so
you may want to restore it later (but use the Knoppix CD, not FC2,
otherwise you may end up where you started if the bug is in grub). On my
machine GRUB was installed in the Linux partition so it wasn't affected.

You can return to the original MBR at any time by writing the saved image
to the disk (in case this fix does not work for you) as long as you only
make changes to the MBR:

$ fdisk if=mbr.img of=/dev/hda

This is it, I hope it works for others, if it does please let me know.


-- 
Radu


At 21:25 2005.07.25., you wrote:
>Martins wrote:
>
>>
>>>
>>>Um, if you do this, you will more than likely destroy the filesystems as 
>>>well, because the new partitions will not line up exactly with the old ones.
>>>
>>>Anyway I don't think this is the problem.  Afterall, WinXP booted fine 
>>>before on this drive with LBA disabled, so something else is up.  If you 
>>>already made the right changes to the boot.ini file, then I suspect that 
>>>a "fixboot" from the recovery mode of the WinXP CD will be necessary.
>>>This should not overwrite the MBR, only the boot loader that is at the 
>>>beginning of the windows partition.
>>>
>>>-Richard
>>>
>>>--
>>>gentoo-user@gentoo.org mailing list
>>
>>
>>there is no worry, writing new partition table give it the same values 
>>(partition start, end, type, order) as before and not a single bit is lost
>
>What I am saying is that this is not possible with fdisk, because fdisk 
>will insist on creating the new partitions aligned on cylinder boundaries, 
>which will have moved in terms of logical sectors.  Example:
>
>Let's say you want a 100MB partition, or about 200000 512-byte sectors:
>
>With non-LBA geometry, the math is 200000 sectors / (63 sectors/track * 16 
>heads) = 198.41 cylinders. Now round down to 198 cylinders and you get 
>199584 sectors in your partition
>
>With LBA geometry, the math is 200000 / (63 sectors/track * 255 heads) = 
>12.449 cylinders.  Again, round down to 12, and you get 192780 sectors in 
>your partition.  You can round up to 13 and get 208845, but you *cannot* 
>get 199584.  Possibly with another partitioning tool that allows you to 
>specify the starting and ending heads as well as cylinders, but not with fdisk.
>
>It is *possible* for this to work if you have just one huge partition, or 
>if your partitions happen to end at even multiples of both (63 * 255) and 
>(63 * 16).
>
>And just for the sake of accuracy, the cylinder alignment thing is true 
>for all partitions except:
>
>- Cylinder 0, head 0 is reserved for the MBR, so any partition starting at 
>cylinder 0 actually starts at head 1.
>- Logical partitions actually start at head 0, sector 1, because the first 
>sector contains another partition table that points to the next partition.
>
>-Richard
>
>--
>gentoo-user@gentoo.org mailing list

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] He's baaaaaack!

[Richard Fish]

Martins wrote:

> it is possible with fdisk, i did it and it worked, and this is steps i 
> followed, step 7 wasnt necesary for me:
>
>
> More info about the bug can be found here:
> https://bugzilla.redhat.com/bugzill...g.cgi?id=115980
> https://bugzilla.redhat.com/bugzill...g.cgi?id=113201


Note that whatever web browser and method you are using to cut and paste 
URLs is producing broken links.  Fortunately, at least the bug ID was 
intact so I was able to lookup the bugs.

I don't see how either bug applies to Maxim, as he didn't get this after 
installing FC2, changing from kernel 2.4 to 2.6, or doing anything to 
his partiton table.  He just moved the disk from primary master to 
(primary slave?).  Also, AFAIK this has not been a problem for any 
Gentoo user using fdisk to partition his drives.

> Device Boot Start End Blocks Id System
> /dev/hda1 * 63 33732719 16866328+ 7 HPFS/NTFS
> /dev/hda2 74692800 78140159 1723680 1c Hidden W95 FAT32
> (LBA)
> /dev/hda3 35834400 74692799 19429200 83 Linux
> /dev/hda4 33732720 35834399 1050840 82 Linux swap
>
So I recreated this partition table on a spare 100Gb USB disk:


Command (m for help): p

Disk /dev/sda: 100.0 GB, 100030242816 bytes
16 heads, 63 sectors/track, 193821 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1       33465    16866328+  83  Linux
/dev/sda2           74101       77520     1723680   83  Linux
/dev/sda3           35551       74100    19429200   83  Linux
/dev/sda4           33466       35550     1050840   83  Linux

Command (m for help): u
Changing display/entry units to sectors

Command (m for help): p

Disk /dev/sda: 100.0 GB, 100030242816 bytes
16 heads, 63 sectors/track, 193821 cylinders, total 195371568 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63    33732719    16866328+  83  Linux
/dev/sda2        74692800    78140159     1723680   83  Linux
/dev/sda3        35834400    74692799    19429200   83  Linux
/dev/sda4        33732720    35834399     1050840   83  Linux


>
> $ fdisk -H 255 /dev/hda # or 240 for some configurations
> Command: o (create new partition table)
>
> 6. by now you have a newly generaed partition table, with the original
> disk geometry. Recreate the partitions as they were before:
>
> Command: n (new partition)
> Primary partition (p)
> Partition number: 1
> First cylinder: 63 # beginning of first partition
> Last cylinder or +size[...]: 33732719 # end of first partition
>

This doesn't work, because we are still working in cylinders:

Partition number (1-4): 1
First cylinder (1-12161, default 1): 63
Last cylinder or +size or +sizeM or +sizeK (63-12161, default 12161): 
33732719
Value out of range.

But I assume what you really meant is to switch to sectors.  After 
recreating all of the partitions in sector mode, I have:

Disk /dev/sda: 100.0 GB, 100030242816 bytes
255 heads, 63 sectors/track, 12161 cylinders, total 195371568 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63    33732719    16866328+  83  Linux
/dev/sda2        74692800    78140159     1723680   83  Linux
/dev/sda3        35834400    74692799    19429200   83  Linux
/dev/sda4        33732720    35834399     1050840   83  Linux

Ok, so this seems to work.  I didn't know about the 'u' command for 
fdisk, so thanks for that.

But I still have a problem with this from a sanity standpoint.  Note the 
output of sfdisk for the 16-heads vs 255-heads tables:

carcharias rjf # sfdisk -l /dev/sda

Disk /dev/sda: 193821 cylinders, 16 heads, 63 sectors/track
Units = cylinders of 516096 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sda1          0+  33464   33465-  16866328+  83  Linux
/dev/sda2      74100   77519    3420    1723680   83  Linux
/dev/sda3      35550   74099   38550   19429200   83  Linux
/dev/sda4      33465   35549    2085    1050840   83  Linux

Disk /dev/sda: 12161 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sda1          0+   2099-   2100-  16866328+  83  Linux
/dev/sda2       4649+   4863     215-   1723680   83  Linux
/dev/sda3       2230+   4649-   2419-  19429200   83  Linux
/dev/sda4       2099+   2230-    131-   1050840   83  Linux

Notice all of the extra '+' and '-' signs...those mean that the 
partitions do not line up with cylinder boundaries, and we probably 
should have left the partition table at 16-heads.  Fdisk may (now) 
handle this ok, but it is not standard and less intelligent partition 
tools are likely to throw a fit.  Actually, this is what most of the bug 
reports regarding parted and disk druid are about...they couldn't handle 
the misalignment.

Anyway, my information about fdisk was defintely out of date...the last 
time I had a direct problem with 255 vs 16 heads was in 1999 or so.  
Thanks for pointing out that fdisk has more capability that I had given 
it credit for.

-Richard

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] He's baaaaaack!

[Zac Medico]

Richard Fish wrote:
> Martins Steinbergs wrote:
> 
>> log to linux, erase partition table, get those heads corect, write new 
>> partition table --> reboot, LBA is on and win is booting. none of 
>> dos/win apps worked for me to fix partition table.
>>
>> i asume LBA is needed only for win itself, not vfat or ntfs 
>> partitions, therefore files are accesible from linux
>>
>> martins
>>
>>  
>>
> 
> Um, if you do this, you will more than likely destroy the filesystems as 
> well, because the new partitions will not line up exactly with the old 
> ones.
> 

In most cases, with such a misalignment, wouldn't the filesystem driver see that the superblock (or whatever signature it uses) is misplaced and refuse to mount?

I have destroyed an ext3 partition due to improper geometry settings for an external usb hard drive.  Something about a computer I plugged it into (bad bios?) caused this.  From the Large Disk HOWTO I learned to manually specify the C,H,S as a kernel parameter sda=24321,255,63 in order to correct the problem.

Good "fdisk -l" output:

	Disk /dev/sda: 200.0 GB, 200049647616 bytes
	255 heads, 63 sectors/track, 24321 cylinders
	Units = cylinders of 16065 * 512 = 8225280 bytes

Bad "fdisk -l" output:

	Disk /dev/sda: 137.4 GB, 137438952960 bytes
	255 heads, 63 sectors/track, 16709 cylinders
	Units = cylinders of 16065 * 512 = 8225280 bytes

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] He's baaaaaack!--SOLVED

[maxim wexler]

> a "fixboot" from the recovery mode of the WinXP CD
> will be necessary.  
> This should not overwrite the MBR, only the boot
> loader that is at the 
> beginning of the windows partition.

The problem was two-fold:

1. WinXP boot sector was bad(my best guess).

2. Recovery Console suffered from obscure bug that
prevented the use of admin password -- even though the
correct password was used. To top it off, Macro$haft
expects its drones to _pay_ for the patch to fix
_their_own_ mistake!

I just re-installed XP-Pro, this time the one w/ the
integrated SP1 which fixes the bug.

Then I edited grub to map the drive up a notch and now
everything <knocking on wood> is cool!

-mw

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] He's baaaaaack!--SOLVED

[Richard Fish]

maxim wexler wrote:

>everything <knocking on wood> is cool!
>
>  
>

Very cool indeed....now you can do what we all got computers for in the 
first place...to play solitaire. ;-)

-Richard

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] He's baaaaaack!

[maxim wexler]

--- Martins Steinbergs <mar@ml.lv> wrote:

> log to linux, erase partition table, get those heads
> corect, write new 
> partition table --> reboot, LBA is on and win is

What does this mean? LBA was off before and now it's
on? Where? In the POST? dmesg? In the BIOS? fdisk? dos
or unix?

Also note: as I've said elsewhere, even when the big
drive(/dev/hdb) is installed alone as master WinXP is
accessible, otherwise how could boot.ini open? But
both available options, WinXP or Recovery Console(by
which I had hoped to use fixboot etc.) lead to system
hangs.

The method you propose seems rather drastic. I'd like
to be sure before proceeding



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] He's baaaaaack!

[Richard Fish]

maxim wexler wrote:

>--- Martins Steinbergs <mar@ml.lv> wrote:
>
>  
>
>>had same problem, solved rebuilding mbr
>>check fdisk, if same problem (16 heads instead of
>>255 heads) this will help
>>
>>
>>    
>>
>http://www.mail-archive.com/gentoo-user%40lists.gentoo.org/msg07969.html
>  
>
>
>hmm, yes it *is* 16 heads. But before I try this thing
>can you recall trying to boot WinXP after running
>(win95)fdisk /mbr? In my case the boot.ini file on the
>c:\ drive actually opens giving me a choice of WinXP
>and the Recovery Console but clicking one or the other
>just leads to a blank screen. Seems if I can reach
>boot.ini all should be OK windows-wise.
>
>  
>

Did you fix the disk references in boot.ini?  For example, my boot.ini:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP 
Professional" /fastdetect /NoExecute=OptIn

I am pretty sure that those disk(0) options need to be changed to 
disk(1).  Although, I don't actually know what the rdisk(0) means, so 
you may need to play with both.

-- 
gentoo-user@gentoo.org mailing list