Sounds pretty straight forward. I’ll give it a shot this evening after work and post back.
Check the symlinks carefully in your /boot directory; make sure the pointers are still correct. There should be three, one for vmlinuz, one for initrd, and one for a boot within /boot (which circularly loops back thru /boot).
The first partition can be formatted with either FAT32 or NTFS. XP will default to NTFS. Some argue that FAT is preferable because that makes it accessible to bootable emergency repair tools which cannot load NTFS. The main differences between the two are irrelevant on the system volume.
Be sure you have set the first partition as active (i.e., the bootable flag) before installing XP, and that no other partitions have the flag set (cfdisk handles this nicely). IIRC XP will then automatically place the boot files, and most importantly the boot sector, in that partition.
I just noticed a potential issue for you. For XP to address >137GB requires 48-bit LBA, which was provided in Service Pack 1. Note that this is the outside limit, i.e., a partition which begins inside but ends beyond 137GB will not be reliably writeable and in particular not installable without SP 1. It appears that your sda8 will fall outside the limit.
If your XP installation media already has SP1 or SP2, you are fine. If it does not, you have several options I can see: (1) Create a slipstreamed installation, which integrates a service pack into the base install. SP1 is downloadable. There are numerous howto’s on the web. (2) Size down sda5 to permit a 5GB sda8 XP partition inside 137GB; after applying the service pack the partition could be enlarged or a sda9 could be added for Windows to use. (3) Switch sda5 with sda8. That is, create sda8, move the sda5 data to sda8, size down sda5 under 137GB, use it for XP.
Good luck.
It was going so well, until MS entered the mix…
I set sda1 as the only bootable partition, ensured that my XP install DVD had SP2 and booted to the XP disk. I choose the partition for install and had windows format it to NTFS. I got through the format and copying setup files bit, then the system reboots. On reboot I get a disk error. Any thoughts?
OK, I just tried the install again, but I installed to sda1 instead of sda8 (mainly to reformat under windows) and it rebooted and brought me to the setup screen. I’m a bit confused, I was expecting an error because sda1 is only 1.5 gig. I’ll let you know what happens.
That could be a consequence of this:
I get a bit wary of fat32 partitions made in Linux. I’d re-format them if you can with the windows partitioner…
The installation to sda1 seems to have worked. According to windows, XP has installed itself on a 1.5 gig partition (1.56 actually) with 607 MB to spare. Either the MS compression tools have advanced by light years, or something is amiss.
When I boot up, I’m given the choice of 2 XP installs. One boots to the incredibly efficient 1.5 gig partition and the other go into the setup screen (from the failed attempt at the sda8 install, I assume). I miss my Suse!!!
This is my hunch now: perhaps the partition error was due to Linux making fat32 partitions that windows didn’t like. That’s over now because both sda1 and sda8 have been formatted by windows. So you could go back and reinstall windows on sda8 and perhaps it would work OK. Or you could stick with the windows on sda1 and clean up sda8 and make it a storage partition for the branch in the windows filesystem that begins with “Docs and Settings” (waste of space IMHO). I think chances are good that you could reinstall to sda8 now.
Whatever — when finished with windows do this to get Suse back, assuming root is on sda2:
Boot off the install DVD and select the menu item “rescue system”
Boot up to the prompt and login as root
enter the command grub
check that sda2 is the root partition with this command:
find /boot/grub/menu.lst
It should return this Grub speak for sda2: (hd0,1)
enter: root (hd0,1)
it returns: Filesystem type ext2, etc 0x83
enter: setup (hd0)
returns: checkiny …yes, blah blah … succeeded
enter: quit
enter: reboot
end of story (I hope)
I appreciate your sense of humor . . .
Yes, something is not right. I’ve done a heckuva lot of XP installs, can’t remember any fitting in ~900MB. So I checked a vanilla XP install I have in a vm, no apps installed yet, and it’s ~1.8GB in the Windows directory and 2.4GB in C with the diff mostly in the 600MB pagefile. That’s 2x what you have, w/o a pagefile.
IIRC, the way setup is supposed to work is you choose the boot volume (sda8) and, given that a primary is required for the system volume and given that such a partition is available and marked active, the OS is installed (in this case, to sda8) and the boot files are installed to the boot partition (system volume).
When you installed did you notice that the entire disk was seen by setup? Having partially written storage is one of several possible symptoms of the 137GB problem, i.e., you can get the writes, but they are intermittent. Doesn’t seem like the whole OS is there. Perhaps you could compare what you have installed to another XP instance?
I wonder what might happen if you deleted sda1 and sda8, leaving unallocated space, and allowed setup to create the partitions? But again, you need to be sure the whole disk is being seen by setup.
@mingus725, what about this: repair Suse bootloader and boot Suse. Mount sda1 and sda8 writable in Suse. Delete all files on sda1 and sda8 with:
rm -Rf /mount_point/*
Reboot to the windows install CD – but now the partitions sda1 and sda8 are both NTFS and both empty. Tell XP to install on sda8 and it should work just fine, using sda8 for the system files and sda1 for the boot files automatically. What do you think?
@roguedog, first I think we need to be conclusive that the entire disk is seen by the XP setup - what does setup in the partitioning step show? The previous install looks incomplete, which should not be able to happen - setup should refuse or should fail. As ref’d prev, erratic or incomplete writes matches a symptom of the LBA problem. What is the type of disk and how is it attached?
@swerdna, I guess that could work, as long as sda1 is the active primary. That would clear out the files, but XP setup will want to reformat anyway. It may be more important to let XP create the physical partitions.
Another possibility . . .
Remove the active flag from sda1. Install XP to sda8 (I think setup will let you delete sda8 and then re-create the partition; if that’s possible, do it). Boot openSUSE, mount sda8 and sda1, delete any files on sda1, copy the three boot files from sda8 to sda1, make sda1 the active primary, boot from the XP CD into the Recovery Console, use the XP command fixboot to install the XP boot sector in sda1 and the command bootcfg to rebuild ntldr’s boot.ini file. This method ensures the system volume (sda1) is properly set up for booting; if the OS is intact on sda8, and there is no LBA issue, the system should boot.
OK, I got XP installed. I finished the setup on sda8 then used win rescue from the XP dvd and chose the sda8 install to get to a command prompt (that was fun to find). Once there I did format c: /FS:FAT32 to format sda1 with FAT32. This, of course, hosed the installation on sda8. So I reinstalled XP to sda8 and the Billster finally smiled on me and granted me a working bootable install on sda8 (2.8 gigs worth even). There must be some reason that you can only format the drive you’re installing to in the windows setup, I just have no idea what it could be.
On to the grub bit and, unfortunately, another chapter…
I followed the steps laid out by swerdna and got back the expected responses. After the reboot, I was prompted for the root password then received a prompt that I have never seen before - (repair filesystem) #
Up the screen a bit I see a few problems (failed).
Activating swap-devices in /etc/fstab…
Unable to find swap-space signature
mount: according to mtab, /dev/sda2 is already mounted on /
and
Waiting for /dev/disk/by-id/scsi-SATA_WDC_WD2500JB-00_WD-WMANK3202020-part8 . no more events
Checking file systems…
fsck 1.40.8 (13-Mar-2008)
bootsplash: status on console 0 changed to on
fsck.ext3: Bad magic number in superblock while trying to open /dev/disk/by-id/scsi-SATA_WDC_WD2500JB-00_WD-WMANK3202020-part7
/dev/disk/by-id/scsi-SATA_WDC_WD2500JB-00_WD-WMANK3202020-part7:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
I goes on to say:
fsck failed for a least one file system (not /).
Please repair manually and reboot.
The root filesystem is already mounted read-write.
I have no idea what a superblock is, but a bad magic number doesn’t sound good.
I really appreciate the time both of you are taking to help me out.
I ran /sbin/fdisk -l and it looks like the ever helpful ms has renamed my partitions. They’re all nice and orderly(but still not in order) now, sda1 - sda7. Unfortunately, there is a message after the entry for sda4 that says ‘Partition 4 does not end on a cylinder boundary.’
sda2 is still sta2 /
sda6 is now sda5 swap
sda7 is now sda6 /home
Seems to me that the problem is that the swap partition is not where it once was. How do I see and edit grub from cli?
Try the automatic method. Reboot off the Suse install DVD and select item 3 “repair installed system” and then from the options select Expert Tools → repair filesystem. That should fix the filesystem errors in fstab. Then when that’s finished try to reboot. If Grub was affected by the windows shenanigans then do the repair again selecting this time Expert Tools → Install new bootloader
If @swerdna’s suggestion did not remedy the problem, please post back the output of:
cat /etc/fstab
fdisk -l -u
Don’t mind the “partition doesn’t end on cylinder boundary” message. Linux doesn’t use cylinders; they are not a real physical dimension anyway.
By the way, fdisk will list the partitions in the order they are numbered in the table, not in the physical sequence on the disk.
The superblock is literally a block (1024 bytes) at the front of the file system which holds ~50 parameters that describe the file system and are required for it to work. The magic number is one of those parms, which describes the type of file system. There are backups of the superblock placed at specific intervals through the partition; this is what the “-b 8193” argument with e2fsck is for - it restores the superblock from the first backup copy. There are probably additional backups. To see its state and where the backups are, do:
dumpe2fs /dev/sdx ## where x is the partition number
oops . . . obviously, that should be sda<x>
Sorry for the formatting on this - I can’t copy and paste.
Device Boot Start End Blocks ID System
/dev/sda1 * 63 3277259 1638598+ b W95 FAT32
/dev/sda2 3277260 54540674 25631707+ 83 Linux
/dev/sda3 54540675 488392064 216925695 f W95 Ext’d (LBA)
/dev/sda4 232814043 371230082 69208020 c W95 FAT32 (LBA)
Partition 4 does not end on cylinder boundry.
/dev/sda5 54540801 60838154 3148677 82 Linux swap/Solaris
/dev/sda6 60838218 165710474 52436128+ 83 Linux
/dev/sda7 371230146 488392064 58580959+ 7 HPFS/NTFS
After following swerdna’s advice, I get to the login screen. I can login to a console session, but not KDE. a box pops up stating: Could not start kstartupconfig. Check your installation.
I am able to login and get to kde as root. The only home directory is root. All of my user accounts are still listed in Yast - Users.
When I open the partitioner in Yast a dialog box pops up stating:
The partitioning on disk /dev/sda is not readable by the partitioning tool parted, which is used to change the partition table.
You can use the partitions on disk /dev/sda as they are. You can format them and assign mount points to them, but you cannot add, edit, resize, or remove partitions from that disk with this tool.
I also tried to mount /dev/sda7 (my home partition) and got the following message: ntfs-3g-mount: mount failed: Device or resource busy
Your /home is now sda6, not sda7. Probably your fstab is wrong, too. This is why you got the mount and file system errors before. Also what was sda6 is now sda5, sda5 is now sda4. Look at the partitions in the table by the sector addresses; they were renumbered in the table.
I’m not surprised that Parted doesn’t want to play with this table. There is a 34GB gap between sda6 and sda4. And there are 126 sectors between the start of sda3 and sda5; there should be 63. I would stress-test XP and that sda4 FAT32 partition. Run chkdsk against it with low-level checking. PartitionMagic might be able to expand sda4 to reclaim the lost space, but frankly, if you try to change anything you’re at risk of losing the entire partition table. Don’t do anything without a verified backup of everything. And don’t touch sda8 with anything.