[SuSE 9.1] NTFS partitie beschadigd na install

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • Billie
  • Registratie: Januari 2003
  • Laatst online: 16-09 20:27
Hallo,

Vol goede moed begon ik aan de installatie van SuSE 9.1. Alles geconfigureerd, Install, Are you sure? Yes! So far so good. :) YaST begont met mijn NTFS partitie te resizen, ik zal even een overzicht geven:

Voor installatie:

Totaal 80 GB, 1 partitie van 20 GB en eentje van 60 GB. Beiden NTFS. Via YaST had ik gekozen de 60 GB partitie te resizen naar 45 GB, 14.5 GB voor SuSE, 500 MB voor swap.

Ik heb zeker 10 minuten moeten wachten voordat YaST klaar was met resizen, is dat wel normaal? :X Maar goed, hij begon eindelijk aan de installatie en alles ging goed. Hij reboot, ik kies Linux uit mijn o zo sjieke grub menu, en warempel! SuSE boot! \o/

Alleen geen internet (ziet USB modem niet, maar dat kwam ooit nog wel dacht ik), dus dan maar gewoon even rondkijken. Op /dev/hda1 (de 20 GB NTFS partitie waar XP opstaat) kon ik vrolijk rondbladeren, niks aan het handje. Hetzelfde probeerde ik daarna met mijn 45 GB NTFS partitie. Error. :| Ik vreesde meteen het ergste, boot naar XP, en ja hoor. :'( "De schijf in station D is niet geformateerd. Wilt u hem nu formateren?"

Ik heb geen flauw idee wat ik doen moet, behalve UTFS, en dat heb ik dus ook gedaan.

http://portal.suse.com/sd...indows_not_booting91.html

Hier heb ik niet echt veel aan volgens mij (kan zijn dat ik ernaast zit? :?), want windows boot nog wel, maar ik zou graag bij al mijn data willen komen. :Y)

Toen kwam ik hier dus uit. Dit heb ik aandachtig gelezen, en dan met name dit stukje:
If you created your partition on a 2.6 Linux kernel then recreate it on a 2.4 kernel. Unfortunately 2.6 kernels report bogus disk geometry and this caused a lot of problems for many users.
Staat alleen geen oplossing bij? :? :'(

Ik las ook over de commando's fixmbr/fixboot in de recovery console van xp, maar maak ik het daar niet alleen erger mee?

Ik ben hier dus een beetje gestrand, en ik ben echt de sigaar als ik niet bij die partitie kan komen. Als jullie meer info nodig hebben (output van bepaalde commando's? :?), hoor ik het graag, maar wees a.u.b. lievv voor deze linuxnoob. :P

Edit:

Inhoud van /etc/fstab (Het HDD gedeelte dan)

/dev/hda7	/		reiserfs	ACL, user_xatrr					1 1
/dev/hda1	/windows/C	ntfs		Ro, users, gid=users, umask=0002, nls=utf8	0 0
/dev/hda5	/windows/D	ntfs		Ro, users, gid=users, umask=0002, nls=utf8	0 0
/dev/hda6	swap		swap		pri=42


Exacte foutmelding van Konqueror:

Error - KIO_DEVICES_MOUNTHELPER

Mount: Slechte bestandssysteem soort, slechte optie, slecht superblok op /dev/hda5 of teveel aangekoppelde bestandssystemen.

Please check that the disk is entered correctly.

[ Voor 13% gewijzigd door Billie op 24-08-2004 17:24 ]


Acties:
  • 0 Henk 'm!

  • Billie
  • Registratie: Januari 2003
  • Laatst online: 16-09 20:27
Echt helemaal niemand? :X

Acties:
  • 0 Henk 'm!

  • Xander
  • Registratie: Oktober 2002
  • Laatst online: 23:25
Tja.... ik kan het zovaak zeggen, backups maken :X Zeker als je partities gaat resizen.

Maargoed, daar heb je nu niet veel meer aan. Ik denk dat er geen manier is om dit even ongedaan te maken, lijkt me in iedergeval niet.
Je kunt natuurlijk nog proberen data te herstellen, daarvoor kun je het beste in de OM FAQ kijken lijkt me...

PC specs!---Pulse mee voor GoT!
[22:49:37] <@Remy> ik wil een opblaasbare dSLR :+


Acties:
  • 0 Henk 'm!

  • Belial_666
  • Registratie: November 1999
  • Laatst online: 30-07 20:58
JE PARTITIE'S ZIJN NIET (waarschijnlijk ) VERDWENEN !!!!

alleen de index is weg

Geen gekke dingen doen of in paniek raken.

ik zoek ffhet artikel met de fix

Jul 9, 2004 WARNING! Be careful when partitioning on Linux 2.6 kernels! Partitioning softwares using Parted or libparted MIGHT corrupt the partition table, that MIGHT break the Windows boot process, moreover you MIGHT even lose access to your data from all installed or rescue operating systems. This problem is not NTFS related, we mention this because of the severity and because many people incorrectly believe it is NTFS or NTFS resizing related. These problems can happen using FAT32 or any other filesystem too, or if one just creates new partitions. If your NTFS was resized beforehand then your data is intact. The problems caused by the disk geometry detection code of the Linux 2.6 kernels are recoverable without data loss. Reports are from users of Mandrake 10, SUSE 9.1, Fedora 2, Debian, Gentoo, MEPIS but all other Linux distributions have the same problem using Linux 2.6 and Parted or libparted unless it was independently resolved. Please see more details below.

It's not as easy to destroy all data as usually thought. In theory, three things might go wrong during resizing an NTFS partition and setting it up for dual boot,
NTFS resizing by ntfsresize.
Repartitioning by fdisk, cfdisk, Parted, QTParted, DiskDrake, YaST, etc.
Boot manager setup using LILO, GRUB, etc.

In all cases, we have met, the problem was introduced in either step 2 or step 3 and not by the use of ntfsresize. In most cases this means, your data is still intact but you can't access it.

Most often a Windows boot problem occurs if one edited the partition table by Parted or a libparted based partitioning tool. This is especially true if a Linux 2.6 kernel was used. The 2.6 kernels incorrectly report different disk geometries as previously for the same disk therefore fooling softwares like Parted. Unluckily many partitioning tools weren't adjusted accordingly thus in some cases they might render Windows unbootable and even your data inaccessible by saving an incorrect partition table. Known major distributions having this problem are but not limited to Mandrake 10, SUSE 9.1, Fedora 2.

If you used a distribution having this problem then please check your vendors errata or see below for possible recovery solutions. We'd like to emphasize again, this is not an NTFS related problem and it is not caused by the usage of ntfsresize.

The first thing to do is, check out the state of your NTFS. You can do this also with ntfsresize because it has extensive checks and it will diagnose consistency and other problems. To do so you must use the --info and --force options together. Let's see the potential problems, reasons and solutions.

ntfsresize can't find NTFS on the given partition:


# ntfsresize --info --force /dev/hda1
ntfsresize v1.7.1
ERROR(22): ntfs_mount failed: Invalid argument
Apparently device '/dev/hda1' doesn't have a valid NTFS. Maybe you selected
the whole disk instead of a partition (e.g. /dev/hda, not /dev/hda1)?

The reasons for this can be either of
The starting disk sector (cylinder) of the partition is incorrectly set during repartitioning:

If you made the mistake then just recreate the partition start with the original value and everything will be fine. Don't forget to set the partition type to 7 and the bootable flag.

If a partitioning tool using ntfsresize made this mistake then please report it to its respective author.

In either case, if you didn't write down or save the original partition table then TestDisk or Gpart might help you to find the correct starting sector (cylinder) of the NTFS volume. Unfortunately none of these work always, moreover Gpart isn't maintained anymore. Don't panic if they failed to recovery your correct partition table. NTFS was designed to be robust enough to aid this type of recovery ... in the worst case doing it by manually ...

The original NTFS partition got renumbered by the partitioning tool.

Use 'fdisk -l device' to find out where its current location is.

The partition ends in the middle of NTFS:


# ntfsresize --info --force /dev/hda1
ntfsresize v1.7.1
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 62841106432 bytes (62842 MB)
Current device size: 31453438464 bytes (31454 MB)
ERROR: Current NTFS volume size is bigger than the device!
Corrupt partition table or incorrect device partitioning?

This means the partition is smaller than the NTFS, that is the partition end was made in the middle of NTFS during repartition. What can you do?
If you made the mistake then just recreate the partition to be bigger than the size of NTFS. Don't forget to set the partition type to 7 and the bootable flag as well.

If a partitioning tool using ntfsresize caused this problem then please report it to its respective author. This is a very serious bug because if the "freed" disk space was taken in use then your data was quite probably overwritten. If you didn't use that space yet then recreate the partition to be bigger than the size of NTFS.

ntfsresize doesn't report any error:

Your NTFS partition and data must be healthy, you could even mount the partition with the Linux NTFS driver and check everything is in place. So something should be wrong with the boot process. Some possibilities, solutions:
During repartitioning the partition type wasn't set to NTFS, i.e. type 7.

During repartitioning the partition's bootable flag wasn't set as before.

The partitions got renumbered. Windows, just like Linux, expects the boot partition number won't change. The Windows boot partition is defined in the BOOT.INI file. Microsoft has a document how to edit BOOT.INI from a Recovery Console. Linux fdisk also has a command 'f' for fixing partition order in its extra functionality mode (choose 'x' in the main menu).

If your BIOS has CHS or AUTO mode then try LBA mode.

If you created your partition on a 2.6 Linux kernel then recreate it on a 2.4 kernel. Unfortunately 2.6 kernels report bogus disk geometry and this caused a lot of problems for many users.

Using FIXBOOT and/or FIXMBR from the Microsoft Recovery Console might solve the boot problem as well.

Consult the GRUB or LILO documentation what could be wrong.

If you still have problem, you might restore the original partition table, supposed you saved or wrote it down to a paper. For example, restoring the former saved, original partition table of /dev/hda,


# sfdisk /dev/hda < hda.pt

or for the MBR of /dev/hda:


# dd if=hda.mbr of=/dev/hda

Suc6
http://mlf.linux.rulez.or...sresize.html#troubleshoot

[ Voor 170% gewijzigd door Belial_666 op 25-08-2004 22:25 ]


  • Billie
  • Registratie: Januari 2003
  • Laatst online: 16-09 20:27
Hmm, laat die partitie weer bruikbaar maken maar zitten. :X Met Filescavenger pro heb ik al mijn files naar een andere hdd weten te kopieren. :) (of iig, de belangrijke dan.) Nu alleen nog SuSE & grub eraf zien te krijgen, alles formateren en dan maar een verse XP install. Jammer, misschien dat ik linux ooit nog eens probeer als het wat beter om kan gaan met NTFS. :) ;(

Verwijderd

Je kan natuurlijk ook tijdens de install van Xp al 15GB vrij/overlaten om later suse op te zetten of anders met partitionmagic of iets dergelijks de disk vast voorbereiden op linux.

  • Flydude
  • Registratie: Mei 2003
  • Laatst online: 22:16

Flydude

Mighty pirate

Billie schreef op 26 augustus 2004 @ 00:47:
Hmm, laat die partitie weer bruikbaar maken maar zitten. :X Met Filescavenger pro heb ik al mijn files naar een andere hdd weten te kopieren. :) (of iig, de belangrijke dan.) Nu alleen nog SuSE & grub eraf zien te krijgen, alles formateren en dan maar een verse XP install. Jammer, misschien dat ik linux ooit nog eens probeer als het wat beter om kan gaan met NTFS. :) ;(
Zonde, vooral omdat het niet echt aan SuSE ligt. Het feit dat Linux überhaupt met NTFS kan omgaan is al heel wat. Windows met andere filesystemen kan je niet echt zeggen.

Als je die 60GB toch leeg hebt, kan je natuurlijk ook met fdisk wat partitities aanmaken en deze gebruiken voor de installatie.

Laat je niet ontmoedigen door een (relatief) kleine tegenslag. Het resizen van partitities blijft 'gevaarlijk' werk, en jij hebt de pech dat het bij jou fout ging.

I am rubber, you are glue

Pagina: 1