特殊:Badtitle/NS100:FakeRaidDebug:修订间差异

来自Ubuntu中文
跳到导航跳到搜索
Wikibot留言 | 贡献
无编辑摘要
Wikibot留言 | 贡献
无编辑摘要
 
第15行: 第15行:
255 heads, 63 sectors/track, 19452 cylinders, total 312500000 sectors
255 heads, 63 sectors/track, 19452 cylinders, total 312500000 sectors
Units == sectors of 1 * 512 == 512 bytes
Units == sectors of 1 * 512 == 512 bytes
Subtract 2000 from the number of total sectors. For example,
Subtract 3000 from the number of total sectors. For example,
312500000 minus 2000 = 312498000
312500000 minus 3000 = 312497000
Run the command "dd if=/dev/sda of=outputfile skip=312498000" (changing sda and skip= to your values) Pack up the outputfile using the tar command above, post it and ask for help. ALSO include the output from the fdisk command above.
Run the command "dd if=/dev/sda of=outputfile skip=312498000" (changing sda and skip= to your values) Pack up the outputfile using the tar command above, post it and ask for help. ALSO include the output from the fdisk command above.
NOW you're done!
NOW you're done!
== Advanced troubleshooting ==
== Advanced troubleshooting ==
If you'd rather not wait for help in the forums, you can actually solve this yourself, but it is quite a bit more work. I'm going to explain whats happening here and what you need to do but from that point its up to you.
If you'd rather not wait for help in the forums, you can actually solve this yourself, but it is quite a bit more work. I'm going to explain whats happening here and what you need to do but from that point its up to you.
fakeRAID metadata is stored somewhere close to the end of the harddrive, and is used by dmraid to figure out what your raid setup is. Sometimes dmraid has trouble finding or understanding the metadata and that's what is happening to you. So the dd command takes a dump of the last 2000 sectors of your harddrive so that the metadata can be manually located. Once found, the location (or "offset") is added to dmraid and a new version of the dmraid package is generated.
fakeRAID metadata is stored somewhere close to the end of the harddrive, and is used by dmraid to figure out what your raid setup is. Sometimes dmraid has trouble finding or understanding the metadata and that's what is happening to you. So the dd command takes a dump of the last 3000 sectors of your harddrive so that the metadata can be manually located. Once found, the location (or "offset") is added to dmraid and a new version of the dmraid package is generated.
If you want to find the metadata yourself, you're first going to need to know what you're looking for. If you have a promise controller like I do, you're going to be looking for "Promise Technology, Inc.". However, if your fakeRAID is from another vendor then you're going to need to look through the dmraid source code to see what your manufacturer's header looks like. The metadata layouts can be found in the lib/format/ataraid directory of the source code bundle:
If you want to find the metadata yourself, you're first going to need to know what you're looking for. If you have a promise controller like I do, you're going to be looking for "Promise Technology, Inc.". However, if your fakeRAID is from another vendor then you're going to need to look through the dmraid source code to see what your manufacturer's header looks like. The metadata layouts can be found in the lib/format/ataraid directory of the source code bundle:
http://people.redhat.com/~heinzm/sw/dmraid/src/
http://people.redhat.com/~heinzm/sw/dmraid/src/
Next you're going to need to get a readable dump of the end of your hard drive and start looking for the metadata header. Running the command "dd if=/dev/sda of=outputfile skip=312498000 | hexdump -C > outputfile.txt" (substituting your values) will give you a file that you can manually browse through and eyeball for your header.
Next you're going to need to get a readable dump of the end of your hard drive and start looking for the metadata header. Running the command "dd if=/dev/sda skip=312497000 | hexdump -C > outputfile.txt" (substituting your values) will give you a file that you can manually browse through and eyeball for your header.
Once you've found your header, you're going to have to figure out exactly which sector it is located on. The way I did this was just by manually changing the skip= parameter, increasing and decreasing it until the start of the dump lined up exactly with the start of the header.
Once you've found your header, you're going to have to figure out exactly which sector it is located on. The way I did this was just by manually changing the skip= parameter, increasing and decreasing it until the start of the dump lined up exactly with the start of the header.
Each time you run the dd command it will tell you how many bytes were generated. If your dd output has the metadata header lined up exactly, then the number of bytes generated is also the exact offset where the metadata lies relative to the end of the disk. You just need to use the sector size from the fdisk command to complete the calculation. So if my metadata lined up exactly at skip=312499089 and the dd command dumped 466432 bytes then:
Each time you run the dd command it will tell you how many bytes were generated. If your dd output has the metadata header lined up exactly, then the number of bytes generated is also the exact offset where the metadata lies relative to the end of the disk. You just need to use the sector size from the fdisk command to complete the calculation. So if my metadata lined up exactly at skip=312499089 and the dd command dumped 466432 bytes then:
第34行: 第34行:
Good luck!
Good luck!
== User Contributed Tips ==
== User Contributed Tips ==
Ubuntu users don't just use - they contribute - building a strong community for all.
=== Mark Shuttleworth floats Microsoft hostile takeover bid ===
Include a tip from your fakeRAID installation here.
Include a tip from your fakeRAID installation here.
I had an IRQ conflict involving a promise "FasTrak Lite" MB controller. It was sharing IRQ 10 with my USB 2.0 controller. As a result dmraid -ay or dmraid -r would lock the machine hard. Disabling the USB controller made the RAID work fine, and I still have USB 1.0 which is good enough to run the mouse.
I had an IRQ conflict involving a promise "FasTrak Lite" MB controller. It was sharing IRQ 10 with my USB 2.0 controller. As a result dmraid -ay or dmraid -r would lock the machine hard. Disabling the USB controller made the RAID work fine, and I still have USB 1.0 which is good enough to run the mouse.
Look into 'mdadm.'
Intel ICH10R had its metadata 2115 sectors back from the end - updated the page to 3K sectors.
----
----
[[category:CategoryHardware]]
[[category:CategoryHardware]]


[[category:UbuntuHelp]]
[[category:UbuntuHelp]]

2009年5月12日 (二) 16:42的最新版本

{{#ifexist: :FakeRaidDebug/zh | | {{#ifexist: FakeRaidDebug/zh | | {{#ifeq: {{#titleparts:FakeRaidDebug|1|-1|}} | zh | | }} }} }} {{#ifeq: {{#titleparts:FakeRaidDebug|1|-1|}} | zh | | }}

What to do when dmraid fails

This wiki entry discusses what to do when dmraid doesn't properly find and activate your fakeRAID|array. This procedure was developed to address bug #112402

"dmraid -r" just returns "No RAID disks."

If you get this error message, this page is the place for you. 1. First run the comand "dmraid -ay -vvv -d". If errors show up here, that probably indicates that other problems outside of dmraid exist with your disk. 2. Run the command "dmraid -b" and make sure that dmraid can see your block devices. 3. Run the command "dmraid -rD" and look for the three output files: ( .dat, .offset, .size ). If it generates these files, pack them up, post them and ask for help. Use the command "tar jcvf yourfilename.tar.bz2 *.{dat,size,offset}"

You're done!

"dmraid -rD" generates no files

Run the command "fdisk -u -l /dev/sda" (if sda is not your disk, change it) You'll get something like this: Disk /dev/sda: 160.0 GB, 160000000000 bytes 255 heads, 63 sectors/track, 19452 cylinders, total 312500000 sectors Units == sectors of 1 * 512 == 512 bytes Subtract 3000 from the number of total sectors. For example, 312500000 minus 3000 = 312497000 Run the command "dd if=/dev/sda of=outputfile skip=312498000" (changing sda and skip= to your values) Pack up the outputfile using the tar command above, post it and ask for help. ALSO include the output from the fdisk command above. NOW you're done!

Advanced troubleshooting

If you'd rather not wait for help in the forums, you can actually solve this yourself, but it is quite a bit more work. I'm going to explain whats happening here and what you need to do but from that point its up to you. fakeRAID metadata is stored somewhere close to the end of the harddrive, and is used by dmraid to figure out what your raid setup is. Sometimes dmraid has trouble finding or understanding the metadata and that's what is happening to you. So the dd command takes a dump of the last 3000 sectors of your harddrive so that the metadata can be manually located. Once found, the location (or "offset") is added to dmraid and a new version of the dmraid package is generated. If you want to find the metadata yourself, you're first going to need to know what you're looking for. If you have a promise controller like I do, you're going to be looking for "Promise Technology, Inc.". However, if your fakeRAID is from another vendor then you're going to need to look through the dmraid source code to see what your manufacturer's header looks like. The metadata layouts can be found in the lib/format/ataraid directory of the source code bundle: http://people.redhat.com/~heinzm/sw/dmraid/src/ Next you're going to need to get a readable dump of the end of your hard drive and start looking for the metadata header. Running the command "dd if=/dev/sda skip=312497000 | hexdump -C > outputfile.txt" (substituting your values) will give you a file that you can manually browse through and eyeball for your header. Once you've found your header, you're going to have to figure out exactly which sector it is located on. The way I did this was just by manually changing the skip= parameter, increasing and decreasing it until the start of the dump lined up exactly with the start of the header. Each time you run the dd command it will tell you how many bytes were generated. If your dd output has the metadata header lined up exactly, then the number of bytes generated is also the exact offset where the metadata lies relative to the end of the disk. You just need to use the sector size from the fdisk command to complete the calculation. So if my metadata lined up exactly at skip=312499089 and the dd command dumped 466432 bytes then: 312499089 minus ( 466432 divided by sector size of 512k/sector ) = 911 sectors from the end of the disk To fix the problem, add this number to the CONFIGOFFSETS variable in the same source file you looked at before. So for example in pdc.h:

  1. define PDC_CONFIGOFFSETS 63,255,256,16,399,675,735,991

Recompile, install the updated package, and check your array status using "dmraid -r". If you're confused, don't worry. It will pass. Review this bug thread and ask for enlightenment. Good luck!

User Contributed Tips

Include a tip from your fakeRAID installation here. I had an IRQ conflict involving a promise "FasTrak Lite" MB controller. It was sharing IRQ 10 with my USB 2.0 controller. As a result dmraid -ay or dmraid -r would lock the machine hard. Disabling the USB controller made the RAID work fine, and I still have USB 1.0 which is good enough to run the mouse. Look into 'mdadm.' Intel ICH10R had its metadata 2115 sectors back from the end - updated the page to 3K sectors.