unable to boot after installing minix

here is what i did:

i resized my windows partition using gparted from a live cd. i left
about 2 Gigs of unused space at the end of the disk. with that unused
space, i used gparted to create a new partition and formatted it with
an ext2 filesystem even though i knew that i would just overwrite that
filesystem when i installed minix.

i booted up minix and installed it to the new partition. (did setup,
followed the prompts and installed to the new partition. then did a
shutdown. after shutdown, even used minix boot monitor to boot back
into minix. then did a shutdown and from the minix boot monitor that
time, i did an 'exit' )

when i rebooted my computer, nothing booted. i made a bootable grub
cd, and i can boot that and i get a grub shell.

so i am in the grub shell and type

'rootnoverify (hd0,'

then i press TAB and it gives me this:

'Possible partitions are:
Partition num: 0, Filesystem type unknown, partition type 0x7
Partition num: 1, Filesystem type unknown, partition type 0x81'

I selected partition 1, so my command was

'rootnoverify (hd0,0)'

then i type

'chainloader +1'

then i type

'boot'

and then it just prints

'Starting up ...'

and it hangs. on my other laptop where i have xp and ubuntu setup for
dual boot, if i boot with the same cd to get a grub shell, the same
commands boot xp just fine (except the partition number is
differrent). I have also tried using 'root' instead of
'rootnoverify', and i have also tried the command 'makeactive' before
i boot.

when i use the commands 'rootnoverify (hd0,1)', 'chainloader +1', and
'boot' in that order, i can boot my minix partition no problem. so i
just don't get what happened? i just can't figure out why i can't
xp. i didn't think the minix installation overwrote any of the MBR?
any ideas, clues or suggestions?

jbholman escreveu:
[color=blue]
> when i use the commands 'rootnoverify (hd0,1)', 'chainloader +1', and
> 'boot' in that order, i can boot my minix partition no problem. so i
> just don't get what happened? i just can't figure out why i can't
> xp. i didn't think the minix installation overwrote any of the MBR?
> any ideas, clues or suggestions?[/color]

Apparently, the MBR is just fine, for you were able to chainload the Minix
partition.

Try the following: boot from a DOS boot disk that includes a fdisk
implementation. Mark the partition as active if it's not already. Then,
from a shell prompt, issue "fdisk /mbr". This will re-install the default
master boot record used by windows, who just chainloads the active
partition.

The FreeDOS boot CD does the job. Burn it to a CD-RW if you don't want to
lose a CD.

--
João Jerónimo

"Computer are composed of software, hardware, and other stuff terminated
in "ware", like firmware, tupperware, (...)" - by JJ.

João Jerónimo escreveu:
[color=blue][color=green]
>> when i use the commands 'rootnoverify (hd0,1)', 'chainloader +1', and
>> 'boot' in that order, i can boot my minix partition no problem. so i
>> just don't get what happened? i just can't figure out why i can't
>> xp. i didn't think the minix installation overwrote any of the MBR?
>> any ideas, clues or suggestions?[/color][/color]

To be honest, now I remember that the windowssetup always refuses to use a
small portion of the hard disk, that is supposely used for boot purposes.

--
João Jerónimo

"Computer are composed of software, hardware, and other stuff terminated
in "ware", like firmware, tupperware, (...)" - by JJ.

João Jerónimo escreveu:
[color=blue][color=green][color=darkred]
>>> when i use the commands 'rootnoverify (hd0,1)', 'chainloader +1', and
>>> 'boot' in that order, i can boot my minix partition no problem. so i
>>> just don't get what happened? i just can't figure out why i can't
>>> xp. i didn't think the minix installation overwrote any of the MBR?
>>> any ideas, clues or suggestions?[/color][/color]
>
> To be honest, now I remember that the windowssetup always refuses to use a
> small portion of the hard disk, that is supposely used for boot purposes.[/color]

I mean: there are chances you overwrote this information when formating the
partition.

--
João Jerónimo

"Computer are composed of software, hardware, and other stuff terminated
in "ware", like firmware, tupperware, (...)" - by JJ.

En news:9f133258-cdbc-451d-9b78-b540b40b1880@a1g2000hsb.googlegroups.com,
jbholman va escriure:[color=blue]
> here is what i did:[/color]

I did not see from your description where you installed some new boot loader
(what I see is that something in the installation broke the previous boot
loading scheme).

If you feel you did not, and did not intent to, install some new boot
loader, the standard repairing tools for Windows should do the job fine
(like booting in the recovery console and using bootcfg or perhaps fixmbr or
fixboot). At any rate, booting in the recovery console at this point is a
useful thing to do, it will show you how much of the NTFS booting structure
is damaged.


OTOH if your problem is that you are not able to boot directly into Minix,
since doing it by hand (grub's rootnoverify0,1+chainloader) apparently
works, it should be only a matter to activate Minix partition if it is not,
and perhaps also restore the MBR if this is the one which is damaged.


If you are still reading, then you are really asking for another
possibility, which is that you really want to have dual-booting capability
(I cannot assert it from our post); then as you probably know, you have to
choose and then install some dual-boot-able boot loading tool, since you
have at least three at hand (Ntldr, Grub, and the Minix boot monitor) but
only one is needed.

From your explanations I guess:
- that the masterboot code (whichever it is) is either faulty (which should
be easy for you to check and repair, so I presume it is not), or it is
behaving correctly since it does not emit any visual indication otherwise
- similarly, that the partition table is healthy; I shall also guess/assume
that the NTFS volume is _and_ was in the first slot, which is also the
"active" one
- so the MBR code should load the NTFS boot record code OK (which has two
stages, one is a 512-byte bootstrap and then there is a 7.5KiB complement in
sectors 1-15 of the NTFS volume, it is known as $Boot from NTFS' view; you
can use `dd bs=512 count=16` from Minix to save a copy of it, and fixboot
from the recovery console to "repair" it to its normal state); there is
usually no visual indication if that code works OK or not; this stage is
auto-relocating using only the datas from the NTFS boot record (you can find
the gory details at [url]http://mirror.href.com/thestarman/asm/mbr/NTFSBR.htm[/url]),
so perhaps you would inspect the datas there to double check that gparted
did not put incorrect values at some place; for the sake of the explanation
I shall assume this stage is OK
- next stage is that this code loads NTLDR from the root directory of the
NTFS volume; clearly this is the end of the path (if NTLDR boots correctly
you would see the BOOT.INI menu, screen would flash etc. many things you did
not describe, so this does not happen); again, with the recovery console you
can inspect the root directory of the NTFS volume to check if it is clean,
check if BOOT.INI is indeed present, and perhaps restore NTLDR from Windows
CD if you suspect it was damaged.
As I said, giving the recovery console a try is most probably the best
option you have.


Also have a look at [url]http://www.woodhull.com/newfaq/faq/NT-2K.html[/url] and
news:qsrqlf.rui.ln@jetsam.cs.vu.nl (on this group, dated Jan 6th from Kees
Bot).


Antoine

> I did not see from your description where you installed some new boot loader[color=blue]
> (what I see is that something in the installation broke the previous boot
> loading scheme).[/color]

me neither. After looking through the /bin/setup script and the /usr/
src/tools/Makefile and /usr/src/tools/mkboot script, I really don't
see any way I could have messed up the first sector of the hard drive
or even the first sector of the first partition of the hard drive.[color=blue]
>
> If you feel you did not, and did not intent to, install some new boot
> loader, the standard repairing tools for Windows should do the job fine
> (like booting in the recovery console and using bootcfg or perhaps fixmbr or
> fixboot). At any rate, booting in the recovery console at this point is a
> useful thing to do, it will show you how much of the NTFS booting structure
> is damaged.[/color]

I tried this. Tried using bootcfg, fixmbr and fixboot alone and
different combinations of the two. I tried changing my boot.ini file
manually. Then I tried directly copying ntldr from the cd to c:\ on
partition 1. none of this worked. oh well...... Then I tried to
install XP using the "repair" method where it reinstalls an existing
installation. that did not work either. so i just installed xp again
from scratch and deleted all my old partitions before doing so. this
worked for "recovering" windows. now it runs much faster, but i lost
some programs ..... on my gf's computer.

Thanks to all for the responses. I'm still not sure what happened,
but I think that something probably went wrong when I used gparted to
resize the ntfs partition. I just installed minix on my laptop, and
am triple-booting with no problem, so I'll just stick to using my
laptop for now.

jbholman <jbholman@gmail.com> wrote:[color=blue][color=green]
>> I did not see from your description where you installed some new boot loader
>> (what I see is that something in the installation broke the previous boot
>> loading scheme).[/color][/color]
[color=blue]
> me neither. After looking through the /bin/setup script and the /usr/
> src/tools/Makefile and /usr/src/tools/mkboot script, I really don't
> see any way I could have messed up the first sector of the hard drive
> or even the first sector of the first partition of the hard drive.[/color]

As long as you point Minix' setup script to the right partition (which you
did, because you could chainload Minix from the partition you intended)
Minix should indeed not touch anything else.
[color=blue][color=green]
>> If you feel you did not, and did not intent to, install some new boot
>> loader, the standard repairing tools for Windows should do the job fine
>> (like booting in the recovery console and using bootcfg or perhaps fixmbr or
>> fixboot). At any rate, booting in the recovery console at this point is a
>> useful thing to do, it will show you how much of the NTFS booting structure
>> is damaged.[/color][/color]
[color=blue]
> I tried this. Tried using bootcfg, fixmbr and fixboot alone and
> different combinations of the two. I tried changing my boot.ini file
> manually. Then I tried directly copying ntldr from the cd to c:\ on
> partition 1. none of this worked. oh well...... Then I tried to
> install XP using the "repair" method where it reinstalls an existing
> installation. that did not work either. so i just installed xp again
> from scratch and deleted all my old partitions before doing so. this
> worked for "recovering" windows. now it runs much faster, but i lost
> some programs ..... on my gf's computer.[/color]

Ouch...
[color=blue]
> Thanks to all for the responses. I'm still not sure what happened,
> but I think that something probably went wrong when I used gparted to
> resize the ntfs partition. I just installed minix on my laptop, and
> am triple-booting with no problem, so I'll just stick to using my
> laptop for now.[/color]

It's amazing how partition managers still manage to mess up your disks. A
friend of mine recently lost all his data because ParitionMagic fubar'ed
halfway through the process of creating an extra partition to try out
Vista (yeah, bad idea...). The operation required some shrinking and
moving around to get a contiguous block of a couple Gigs, but the result
was an inconsistent partition table and no way to tell where the old data
had ended up on disk... Too bad you have to use a laptop now, those things
are usually cramped with "weird" (read: poorly supported) hardware, but
good luck playing around!

Regards,

Jens

--
Jens de Smit
Student Computer Science | Vrije Universiteit Amsterdam
[email]jfdsmit@few.vu.nl[/email] | [url]http://www.few.vu.nl/~jfdsmit[/url]
"[In the end, people] get furious at IT that the goddamn magic isn't working"
-- Stewart Dean

En news:a6f3d633-2e31-408d-a422-afcabdb85589@79g2000hsk.googlegroups.com,
jbholman va escriure:[color=blue]
> so i just installed xp again from scratch and deleted all my old
> partitions before doing so. this worked for "recovering" windows.
> now it runs much faster, but i lost some programs .....
> on my gf's computer.[/color]

I am sorry for you and her.

[color=blue]
> Thanks to all for the responses. I'm still not sure what happened,
> but I think that something probably went wrong when I used gparted to
> resize the ntfs partition.[/color]

I have still two suspects on my list:

- one is certainly gparted, so it raises a question: did you reboot
(successfully) _after_ resizing the ntfs volume and _before_ passing to the
Minix setup part? if yes, it would mean that gparted is most probably
unguilty...

- the second is LBA48, if by any chance the hard disk exceeds the 137 GB
barrier; this barrier is very naughty, particularly on 160 or 250GB drive:
all is well and good, until some program tries to write beyond the barrier
(which could be the case when you installed Minix at the higher end of the
drive); worse, the problem did not manifest itself right at this moment, the
write occurs really at the beginning of the disk (lacking LBA48 support
means that the upper bits are effectively ignored while writing), but every
thing looks correct... unless you reboot in the other OS which stood at the
beginning of the drive and was erased by the faulty program...
Unfortunately, this scheme shows many similarities from what I got of your
relation :-(


Antoine

> *- one is certainly gparted, so it raises a question: did you reboot[color=blue]
> (successfully) _after_ resizing the ntfs volume and _before_ passing to the
> Minix setup part? if yes, it would mean that gparted is most probably
> unguilty...
>[/color]

Well.......no I didn't try to reboot successfully after resizing the
ntfs volume. I just stuck the Minix CD in and installed. Probably
should've checked things out first, huh?
[color=blue]
> *- the second is LBA48, if by any chance the hard disk exceeds the 137 GB
> barrier; this barrier is very naughty, particularly on 160 or 250GB drive:
> all is well and good, until some program tries to write beyond the barrier
> (which could be the case when you installed Minix at the higher end of the
> drive); worse, the problem did not manifest itself right at this moment, the
> write occurs really at the beginning of the disk (lacking LBA48 support
> means that the upper bits are effectively ignored while writing), but every
> thing looks correct... unless you reboot in the other OS which stood at the
> beginning of the drive and was erased by the faulty program...
> Unfortunately, this scheme shows many similarities from what I got of your
> relation :-(
>[/color]

Hmmmm. I will check next time I go over there, but I think her drive
was either 100 GB or 120 GB. That is definitely good to know for the
future!

Thanks!

J.F. de Smit escreveu:
[color=blue]
> The operation required some shrinking and
> moving around to get a contiguous block of a couple Gigs, but the result
> was an inconsistent partition table and no way to tell where the old data
> had ended up on disk... Too bad you have to use a laptop now, those things
> are usually cramped with "weird" (read: poorly supported) hardware, but
> good luck playing around![/color]

Yes, but partition management does not depend on weird hardware...

--
João Jerónimo

"Computer are composed of software, hardware, and other stuff terminated
in "ware", like firmware, tupperware, (...)" - by JJ.

Antoine Leca escreveu:
[color=blue]
> drive); worse, the problem did not manifest itself right at this moment,
> the write occurs really at the beginning of the disk (lacking LBA48
> support means that the upper bits are effectively ignored while writing),
> but every thing looks correct...[/color]

Who lacks LBA48 support? Minix or the hard drive?

--
João Jerónimo

"Computer are composed of software, hardware, and other stuff terminated
in "ware", like firmware, tupperware, (...)" - by JJ.

Jo??o Jer??nimo <j_j_b_o_j@yahoo.com.br.nospam> wrote:[color=blue]
> J.F. de Smit escreveu:[/color]
[color=blue][color=green]
>> The operation required some shrinking and
>> moving around to get a contiguous block of a couple Gigs, but the result
>> was an inconsistent partition table and no way to tell where the old data
>> had ended up on disk... Too bad you have to use a laptop now, those things
>> are usually cramped with "weird" (read: poorly supported) hardware, but
>> good luck playing around![/color][/color]
[color=blue]
> Yes, but partition management does not depend on weird hardware...[/color]

My point was that he is now running Minix on another laptop (the triple
boot system), which will make it harder for him to get all of Minix up and
running.

Regards,

Jens

--
Jens de Smit
Student Computer Science | Vrije Universiteit Amsterdam
[email]jfdsmit@few.vu.nl[/email] | [url]http://www.few.vu.nl/~jfdsmit[/url]
"[In the end, people] get furious at IT that the goddamn magic isn't working"
-- Stewart Dean