Re: [RndTbl] drive partitioning for Linux install
It turns out that my BIOS and ATA interface cannot handle HDs bigger than 137 GB, so I am switching my new larger drives to another computer and using its drives in the P3 - ie, lots of copying drives and partitions. The dd command has worked well, and saves me a lot of time compared to copying in DOS. Thanks. I have 2 other problems: 1) I need to copy a primary partition on one drive to a logical partition on another. I assume that if I do something like this: # dd if=/dev/hdc3 of=/dev/hda7 bs=1M that the boot sector of the primary will overwrite partition info in the boot sector of the logical partition, destroying extended partition info. Is there a way around this? If I create the logical partition with Partition Magic under DOS and copy into it, skipping the first sector, will that work? 2) I also installed Linux in my P4. When Linux complained it couldn't read the partition tables for sda, I let it rewrite them, thinking this was the new drive I put in. Instead, it was my serial ATA drive array. I have it configured to show up as one large drive under Windows. A large number of ATI video files were stored on the drive, which shows up in Linux as 2 drives (unallocated) and continues to show up in Windows as 1 drive - but now unallocated. The original drive was partitioned as a single FAT32 partition for the whole drive. My guess is that the data is still intact, and could be recovered if I put the right partition info onto the boot sector. Is there a simple way to recover this? If I created a new FAT32 partition in the "unallocated" space using Partition Magic in DOS or Windows, is that likely to recover the data? Also having some boot problems, but I think I can get around that. As a newbie, I'm getting into a little more than what Disk Druid can handle for me. John Lange wrote:
There was a lot of detail there but I think if I understand your problem correctly you are trying to occationally replicate data between 2 partitions?
The linux command "dd" is typically used for these kinds of applications. I think someone mentioned it in a previous email on this topic?
dd does not care what data is on the drive, if its mounted or in use, or about partitions or anything of the sort. The only time dd will fail is when it encounters an error while trying to read or write.
So, a brief example would be:
# dd if=/dev/hda2 of=/dev/hdb2 bs=1M
-- -Dan Dr. Dan Martin, MD, CCFP, BSc, BCSc (Hon) GP Hospital Practitioner Computer Science grad student ummar143@cc.umanitoba.ca (204) 831-1746 answering machine always on
On Tue, 2005-10-04 at 22:03 -0500, Dan Martin wrote:
It turns out that my BIOS and ATA interface cannot handle HDs bigger than 137 GB, so I am switching my new larger drives to another computer and using its drives in the P3 - ie, lots of copying drives and partitions.
I could be wrong here, its been a while, but, so long as your first primary partition was below the maximum size your bios allows I think you should be able to boot from it. Once linux takes over it will be able to see beyond the bios limit. Hopefully someone else on this list can provide better information.
The dd command has worked well, and saves me a lot of time compared to copying in DOS. Thanks.
I have 2 other problems:
1) I need to copy a primary partition on one drive to a logical partition on another. I assume that if I do something like this:
# dd if=/dev/hdc3 of=/dev/hda7 bs=1M
that the boot sector of the primary will overwrite partition info in the boot sector of the logical partition, destroying extended partition info. Is there a way around this? If I create the logical partition with Partition Magic under DOS and copy into it, skipping the first sector, will that work?
No, dd moves the raw data between any two character devices. /dev/hdc3 does not have a "boot sector", only /dev/hdc does. Moving data between partitions regardless if they are logical or primary should be fine. However, if you instead did # dd if=/dev/hdc of=/dev/hda7 bs=1M then you would have a problem since you are moving between a raw device and a partition. I don't think /dev/hda7 would be mountable at that point (never tried it). But you would be able to reverse the process and it would be usable. Its like creating a "ghost" image of a whole drive. But if thats what you have in mind then normally you would do it to a file instead and it wouldn't surprise me if there was a way to mount it using some kind of linux trick similar to how ISO files are mounted as file systems. Anyhow it would look like something like this: # dd if=/dev/hda of=drive.img bs=1M You could then do the opposite: # dd if=drive.img of=/dev/hdc bs=1M And hdc could then be placed into another machine and it would boot as an exact duplicate of the original drive. People pay lots of money for "ghosting" software for windows and meanwhile *nix systems have had this built in just as a regular command forever. Side note: there is also a version of dd that is specifically designed for backups etc. It employs some smart compression to dramatically speed up the process. Normally dd moves EVERY byte even if its empty so a large drive takes the same time regardless how much actual data is on it. The advanced version only moves actual data so you might want to look into it if you are doing this frequently. Even more cool, it can be done over the network! This page goes into detail on how this network dd can be done: http://www.rajeevnet.com/hacks_hints/os_clone/os_cloning.html For the life of me I can't find the alternate version of dd which only moves non-sparse data. If anyone knows it please post it to the list. Please note: before you mess with your data all of the above comes with a HUGE disclaimer! You are treading into areas I'm not that familiar with since I rarely have occasion to do those kinds of tricks. Hopefully someone else here can verify before you try.
2) I also installed Linux in my P4. When Linux complained it couldn't read the partition tables for sda, I let it rewrite them, thinking this was the new drive I put in. Instead, it was my serial ATA drive array. I have it configured to show up as one large drive under Windows. A large number of ATI video files were stored on the drive, which shows up in Linux as 2 drives (unallocated) and continues to show up in Windows as 1 drive - but now unallocated. The original drive was partitioned as a single FAT32 partition for the whole drive. My guess is that the data is still intact, and could be recovered if I put the right partition info onto the boot sector. Is there a simple way to recover this? If I created a new FAT32 partition in the "unallocated" space using Partition Magic in DOS or Windows, is that likely to recover the data?
First of all, you should use LVM (making two drives appear as one) with extreme caution. If EITHER of the drives fail there is a good chance you will loose all your data on both drives. Second, I really can't answer this question regarding how it works in Windows but I will offer this; when you alter the partition scheme it doesn't affect any of the data on the drives. Assuming you can put the partitions back to exactly the way they were everything still be there. I've done it with single drives before (accidentally re-partitioned the wrong drive), scary moment... but I got everything back. If it was Linux LVM I believe it would be trivial to rebuild the array but I have no idea how Windows operates.
Also having some boot problems, but I think I can get around that.
As a newbie, I'm getting into a little more than what Disk Druid can handle for me.
Never mind disk druid, your starting to do things i've never even contemplated ;) -- John Lange
John Lange wrote:
There was a lot of detail there but I think if I understand your problem correctly you are trying to occationally replicate data between 2 partitions?
The linux command "dd" is typically used for these kinds of applications. I think someone mentioned it in a previous email on this topic?
dd does not care what data is on the drive, if its mounted or in use, or about partitions or anything of the sort. The only time dd will fail is when it encounters an error while trying to read or write.
So, a brief example would be:
# dd if=/dev/hda2 of=/dev/hdb2 bs=1M
John Lange wrote:
On Tue, 2005-10-04 at 22:03 -0500, Dan Martin wrote:
It turns out that my BIOS and ATA interface cannot handle HDs bigger than 137 GB, so I am switching my new larger drives to another computer and using its drives in the P3 - ie, lots of copying drives and partitions.
I could be wrong here, its been a while, but, so long as your first primary partition was below the maximum size your bios allows I think you should be able to boot from it. Once linux takes over it will be able to see beyond the bios limit.
Hopefully someone else on this list can provide better information.
I believe this is true, at least for the newer kernels. However, I can't see more than 137GB with Mandrake 8.1 (a 2.4 kernel) nor Windows 2000 pro sp3. I turns out there are tweaks to be made to Windows to get it to work which I did not make on that system. I suspect, however, that the main problem is my ATA interface. In fact, I was ordering a BIOS but I was advised by a technician (from esupport.com) that this would not solve my problem.
1) I need to copy a primary partition on one drive to a logical partition on another. I assume that if I do something like this:
# dd if=/dev/hdc3 of=/dev/hda7 bs=1M
that the boot sector of the primary will overwrite partition info in the boot sector of the logical partition, destroying extended partition info. Is there a way around this? If I create the logical partition with Partition Magic under DOS and copy into it, skipping the first sector, will that work?
No, dd moves the raw data between any two character devices. /dev/hdc3 does not have a "boot sector", only /dev/hdc does. Moving data between partitions regardless if they are logical or primary should be fine.
I believe primary partitions do have boot sectors, containing a stage 1 loader for whatever OS might be on the partition. There is only boot code, no partition tables since they are contained in the MBR.
However, if you instead did
# dd if=/dev/hdc of=/dev/hda7 bs=1M
then you would have a problem since you are moving between a raw device and a partition. I don't think /dev/hda7 would be mountable at that point (never tried it).
But you would be able to reverse the process and it would be usable.
The reverse would overwrite the MBR. To restate the question: Primary partitions have a boot sector that may or may not containing loading instructions (in fact I think there is a whole track at the start which is not part of the filesystem proper). Logical partitions may start with such code as well, but they also "contain" a partition table like that of the MBR, but with only 2 records filled to indicate the address of the partition and that of the next logical partition in the chain. It would be disastrous to overwrite this table by copying a primary partition into it, or even a (incorrect) table from another logical partition. Therefor, I assume that "hda7" starts after the partition table adjacent to the partition table associated with hda7, and will not be overwitten by copying another device's characters into it. Is this true? I didn't take a chance - I used Partition Magic to transform a primary partition into a logical one. This process took approximately 16 hours for a 75GB partition!
2) I also installed Linux in my P4. When Linux complained it couldn't read the partition tables for sda, I let it rewrite them, thinking this was the new drive I put in. Instead, it was my serial ATA drive array. I have it configured to show up as one large drive under Windows. A large number of ATI video files were stored on the drive, which shows up in Linux as 2 drives (unallocated) and continues to show up in Windows as 1 drive - but now unallocated. The original drive was partitioned as a single FAT32 partition for the whole drive. My guess is that the data is still intact, and could be recovered if I put the right partition info onto the boot sector. Is there a simple way to recover this? If I created a new FAT32 partition in the "unallocated" space using Partition Magic in DOS or Windows, is that likely to recover the data?
First of all, you should use LVM (making two drives appear as one) with extreme caution. If EITHER of the drives fail there is a good chance you will loose all your data on both drives.
I believe I did this in hardware, not Windows LVM, but Linux does not seem to recognize it.
Second, I really can't answer this question regarding how it works in Windows but I will offer this; when you alter the partition scheme it doesn't affect any of the data on the drives. Assuming you can put the partitions back to exactly the way they were everything still be there.
I'm going to try repartitioning in PM under Windows (which sees this as a single drive), and hope it doesn't do even rudimentary formatting of my "new" partiiton. -- -Dan Dr. Dan Martin, MD, CCFP, BSc, BCSc (Hon) GP Hospital Practitioner Computer Science grad student ummar143@cc.umanitoba.ca (204) 831-1746 answering machine always on
I installed Fedora Core 4 to a pentium 3. When I try to boot it I get a picture of Tux and an error to this effect: ACPI: BIOS age (2000) fails cutoff (2001). acpi=force rqd to enable ACPI The IDE drive light comes on briefly after that, then it doesn't do anything as far as I can tell. I had no problem with the installation, and I don't recall setting any power management options. Suggestions? -- -Dan Dr. Dan Martin, MD, CCFP, BSc, BCSc (Hon) GP Hospital Practitioner Computer Science grad student ummar143@cc.umanitoba.ca (204) 831-1746 answering machine always on
On 8 Oct, Dan Martin wrote:
I installed Fedora Core 4 to a pentium 3. When I try to boot it I get a picture of Tux and an error to this effect:
ACPI: BIOS age (2000) fails cutoff (2001). acpi=force rqd to enable ACPI
Did you try booting with acpi=force in the boot command line? In the grub menu hit e to edit the options and add that to the end of the main linux command line (middle line I think?). If that works then add it to the proper lines in grub.conf.
Trevor Cordes wrote:
On 8 Oct, Dan Martin wrote:
I installed Fedora Core 4 to a pentium 3. When I try to boot it I get a picture of Tux and an error to this effect:
ACPI: BIOS age (2000) fails cutoff (2001). acpi=force rqd to enable ACPI
Did you try booting with acpi=force in the boot command line? In the grub menu hit e to edit the options and add that to the end of the main linux command line (middle line I think?). If that works then add it to the proper lines in grub.conf.
I tried adding acpi=force in the "kermel" command line of the Grub menu. It makes no difference. However, I have trouble booting Mandrake as well on that drive - I think there may be other issues not relevant to the error message. -- -Dan Dr. Dan Martin, MD, CCFP, BSc, BCSc (Hon) GP Hospital Practitioner Computer Science grad student ummar143@cc.umanitoba.ca (204) 831-1746 answering machine always on
On 4 Oct, Dan Martin wrote:
It turns out that my BIOS and ATA interface cannot handle HDs bigger than 137 GB, so I am switching my new larger drives to another computer and using its drives in the P3 - ie, lots of copying drives and partitions.
The easiest way to get big drives working on even ancient computers is get a PCI IDE card. Many options are available in the $40-$60 range and they almost all work with linux OOB. As for SATA, I've had nothing but grief with cheap SATA cards and would recommend staying away from them, esp if you're using FC which seems to be the worst for SATA.
On October 8, 2005 09:05 pm, Trevor Cordes wrote this amazing epistle:
On 4 Oct, Dan Martin wrote:
It turns out that my BIOS and ATA interface cannot handle HDs bigger than 137 GB, so I am switching my new larger drives to another computer and using its drives in the P3 - ie, lots of copying drives and partitions.
The easiest way to get big drives working on even ancient computers is get a PCI IDE card. Many options are available in the $40-$60 range and they almost all work with linux OOB. As for SATA, I've had nothing but grief with cheap SATA cards and would recommend staying away from them, esp if you're using FC which seems to be the worst for SATA.
The USB solution I mentioned a while ago works on fairly new machines. It may work on older machines as well (I haven't tried it yet). A friend running M$ said he tried a 200GB drive under ME and it would only see 137 GB as well. He ended up returning it for a 120. Later he got another 200 (internal this time) ME only saw the 137 GB like before, but Chris and I managed to get Linux installed on the rest of the drive. It worked until he had to reinstall ME. Since 137 GB seems to be common, there may be a possibility putting the big drive in a USB box (again around $40.00) could get around the limitation of the BIOS as long as it's not a M$ drive. Drop by with the machine (or pick me up to go to the machine) and we can test it out with mine. It's not going to be terribly fast but it does for storage and watching video. Later Mike -- +----------------------------------------------------------------------+ |Call-A.P.P.L.E. and the Digital Civilization http://www.callapple.org | | http://members.shaw.ca/pfaiffer = Mike Pfaiffer (B.A., B.Sc.) | +----------------------------------------------------------------------+ ----- BEGIN GEEK CODE BLOCK ----- Version: 3.12 GCS/G/IT/PA/SS d s+:- a? C++ UL L++ W++ N++ o+ K- w(---) O+@ M++@ V PS+ PE !PGP t+ 5+ X R tv b+ DI+++ D++ G e++* h! r-- !y-- UF++ ------ END GEEK CODE BLOCK ------
Trevor Cordes wrote:
On 4 Oct, Dan Martin wrote:
It turns out that my BIOS and ATA interface cannot handle HDs bigger than 137 GB, so I am switching my new larger drives to another computer and using its drives in the P3 - ie, lots of copying drives and partitions.
The easiest way to get big drives working on even ancient computers is get a PCI IDE card. Many options are available in the $40-$60 range and they almost all work with linux OOB.
I may end up doing that if I'm not sure my present IDE is working. It will also cost me $40 - $70 to reflash my BIOS - unless the new card will be able to bypass it (don't know how it would do that while booting other OS's).
As for SATA, I've had nothing but grief with cheap SATA cards and would recommend staying away from them, esp if you're using FC which seems to be the worst for SATA.
The RAID that FC couldn't read and insisted on reformatting used SATA drives. The damage is already done. -- -Dan Dr. Dan Martin, MD, CCFP, BSc, BCSc (Hon) GP Hospital Practitioner Computer Science grad student ummar143@cc.umanitoba.ca (204) 831-1746 answering machine always on
The easiest way to get big drives working on even ancient computers is get a PCI IDE card. Many options are available in the $40-$60 range and they almost all work with linux OOB.
I may end up doing that if I'm not sure my present IDE is working. It will also cost me $40 - $70 to reflash my BIOS - unless the new card will be able to bypass it (don't know how it would do that while booting other OS's).
A new PCI IDE card has its own BIOS for the drives it controls and can overcome any BIOS limitation. That's why I said you could get a $40 card and use a 400GB drive in a P1 75MHz box! Of course, that takes care of the drive size problem. Other BIOS problems like Y2K issues will need other solutions, but shouldn't be too hard to overcome. I've run FC on lots of boxes that were pre-Y2K, like 1994 P1's.
participants (4)
-
Dan Martin -
John Lange -
Mike Pfaiffer -
Trevor Cordes