HD Install :: cfdisk cannot recognize 6/60GB HDD on a AMD266Mhz

Repost in the right forum.

UPDATE1: Booting with "dsl 2" cheatcode for console;
Did a "sudo fdisk -l" ; found that the HDD was listed as "hdb" & without a partition table. (The HDD/partitions were fine under PuppyLinux/cfdisk2.12q & VectorLinux)
Then "sudo cfdisk /dev/hdb" got me control to create partitions.
Then "write" command made DSL hang & requires a reboot.
2 more tries (on both 6GB Quantum HDD & 60GB Maxtor HDD); same result.

I think this is kernel related, cos DSL is kernel2.4; while Puppy & VectorL is kernel2.6

Going to try DSL-N (kernel2.6) now.
DSL-N has cfdisk v2.12; but "write" command still hangs DSL-N & requires a reboot.

I am stumped. for now.
Going to go kick the puppy around to see if i can solve the serial mouse detection problem.

*******************************
Hi all & KUDOS on DSL.

I have test installed DSL3.2 on 4 notebooks & 3 desktops in the past month, & DSL works great.

Just wanted to point out a problem I encountered from my testing with DSL3.2 & 3.3rc1. I can't detect IDE HDDs (a 6GB & a 60GB) on an old AMDK2/266Mhz (PC100 Mobo); using cfdisk ver2.11z.

But using PuppyLinux or VectorLinux, I can detect the HDDs. The reason why I want to use DSL is because of legacy hardware support (serial mouse). PuppyLinux's detection of my serial mouse is 50% of the time only (other 50% detects as PS/2 and won't work). VectorL is 0%.

The difference is DSL 3.2/3.3rc1 is using cfdisk ver2.11z ; while puppylinux is using cfdisk ver2.12q .

I also tried using QTParted v0.4.4 (from myDSL) and it detected the HDDs & properties. But when I tried to remake the partition table, DSL3.2 hanged & required a reboot. 2nd try, same result.

*Just wondering if a newer version of cfdisk will be included in DSL3.3 or if there is a workaround.

Thanks,
Kore

Quote (kore @ Mar. 02 2007,08:58)

Repost in the right forum.

UPDATE1: Booting with "dsl 2" cheatcode for console;
Did a "sudo fdisk -l" ;

You can run fdisk -l without root privilege. At least I can.

Quote

found that the HDD was listed as "hdb" & without a partition table. (The HDD/partitions were fine under PuppyLinux/cfdisk2.12q & VectorLinux)

You wrote that the partitions were fine. By what measure? What's the actual output of fdisk -l now? Please paste it in and note what partitions you had previously and how you attempted to repartition.

Quote

Then "sudo cfdisk /dev/hdb" got me control to create partitions.
Then "write" command made DSL hang & requires a reboot.
2 more tries (on both 6GB Quantum HDD & 60GB Maxtor HDD); same result.

How long did you wait before rebooting? You could face serious trouble with your drive if you shut it down in middle of writing your partitions.

Quote

I think this is kernel related, cos DSL is kernel2.4; while Puppy & VectorL is kernel2.6

I disagree (vehemently) and the successful experience of many others using DSL's 2.4.26 kernel suggests otherwise. I don't know why people always go back to blaming 2.4 kernels for their problems. I use much smaller and much older kernels and fdisk/cfdisk works just fine. Kernel version is an entirely irrelevant issue, and the kernel configuration in DSL works quite well for fdisk/cfdisk.

Nobody likes to hear it, but it's true. User error is the prime reason for (re-)partitioning failure.

Quote

Going to try DSL-N (kernel2.6) now.
DSL-N has cfdisk v2.12; but "write" command still hangs DSL-N & requires a reboot.

The kernel version is irrelevant. What is relevant is constantly rebooting while writing partitions. You risk toasting your drives when you do stuff like that and especially so when you repeat the same errors over and over -- if they're not already toasted. Take a breath and do some diagnostic work to figure out what the status of your partitions is now, what the physical status of each drive is, and determine if there's a hardware (drive) reason for the software (cfdisk) failure.

Before you try arguing about that, just remember that your hardware settings can change from a variety of factors: incomplete shutdown, electrical charge, power surge, proximity to magnetic fields, being dropped, etc. You also can encounter serious problems when repartitioning if you don't know exactly what you're doing or if you do but aren't paying very close attention to everything you do. I've been trying to help someone in another thread whose partitioning was butchered (to put it very mildly).

If the drives are physically okay, then you can try repartitioning using whatever distro or OS you want. The kernel, though, is wholly irrelevant.

BTW, have you edited xorg.conf in either Vector or puppy? It should be pretty easy to get a serial mouse working with either. Look in the section of xorg.conf for mouse set up. There are two lines you probably need to change (OLD is what may or may not be in it, NEW is what should do the trick).

OLD: Option "Protocol" "something_here"
NEW: Option "Protocol" "microsoft"

OLD: Option "Device" "/dev/something_here"
NEW: Option "Device" "/dev/ttyS0"

excellent reply lucky,
I apologize for the kernel comment & if the text carried over badly

. I humbly take it back.

1. I noticed some newbies comment in that way...without knowing the history/background/implication of the loose comments. No malicious intention & didn't mean any disrespect. Just newbie ignorance & buckshot-blaming. I agree user-error is the prime reason for most problems (everywhere).

2. I agree the partitioning process is delicate. The HDDs are the same state as before and after the DSL fdisk/cfdisk testing. After each reboot (consequence of remaking the partition table, and the subsequent hang); the drives remain in the same state after checking with "fdisk -l" & cfdisk. *Letme get on the puppy machine to post the "fdisk -l" output.

(After latest puppy install-current state).
Disk /dev/hda: 61.4 GB, 61492838400 bytes
16 heads, 63 sectors/track, 119150 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Device Boot Start End Blocks Id System
/dev/hda1 1 969 488344+ 82 Linux swap / Solaris
/dev/hda2 * 970 10657 4882752 83 Linux
/dev/hda3 10658 30974 10239768 83 Linux
/dev/hda4 30975 119150 44440704 83 Linux
sh-3.00#

3. I rechecked with puppy's gparted & cfdisk; and the HDDs are good & partitions remained the same state as before the DSL fdisk/cfdisk testing. I then repartitioned, reformat & reinstalled via puppy.
Thus I am back at the serial mouse problem (in puppy).

I searched the puppy resources & found the exact advice you gave about "protocol""microsoft" & "/dev/ttyS0".
http://www.murga-linux.com/puppy....t=15567

While I have to use Xvesa (Nvidia TNT 64PCI), I did initialise the xorg.conf, via Xorg (so the Section "Input Device" is written). I modified the Protocol & /dev/ttyS0 lines. Restart Xwindow or Reboot gives the same result. No movement of the cursor.

*The problem is puppyserialdetect (at bootup) is detecting the serial mouse as ps/2, 50% of the time.

4. I have found an interim solution - After bootup, select the mouse wizard (Alt+F1 + arrows) to select "Serial Mouse". It works after I restart X-Window. But, I can't get the mouse setting to stick.

kore
(Still the newbie & again apologize for any disrespect shown unintendedly)

**p.s. Before puppy, I installed Vector & also modified /etc/X11/XF86Config-4.in to try to wake the serial mouse, but failed. I didn't spend much time there, cos I had puppy & DSL as alternatives.
*p.s. A weird observation:- the mobo is about 9 years old & the BIOS won't recognize a 60GB HDD. I had to cap it (via jumper) to 30Gb.
WinExplorer showed 30GB in WinXP.
When I boot up, BIOS shows 30GB.
But in puppy/vectorl cfdisk, the drive is 60GB.
**p.s. Due to this testing, I have also learned more about Linux. Thankyou.

UPDATE 2.
- SERIAL MOUSE PROBLEM - SOLVED.
- HDD detection - LAID TO REST.

1. I found the solution to the buggy mouse detection (in my puppy installation) in my case, which kept (50%) detecting my serial mouse as a ps/2 mouse.

I created a symlink named /dev/psaux, which linked to /dev/ttyS0 (which is where the serial mouse is). Thus, even when the false ps/2 mouse is detected, my serial mouse still works

.

I think the problem was not so much "puppyserialdetect", but the type of serial mouse I was using. Not all old/new hardware are compatible with each other.

2. Concerning the inability of detecting my HDDs in DSL, I think it's a unique case & might not be faced by anyone else. Also, a large contributing factor is that I pieced this CPU together from used spare parts. Not including the fact that it's nearly a 10year old mobo. Therefore, I lay this case to rest.

Sorry if this wasn't the correct forum.

Thanks again,
kore :laugh:

Quote (kore @ Mar. 02 2007,13:06)

excellent reply lucky,
I apologize for the kernel comment & if the text carried over badly

. I humbly take it back.

No problem and no apologies necessary.

Quote

I know everyone's at a different position on the learning curve, and that some people move along the curve a lot faster than others. I'm only trying to help people regardless of where they are. I didn't take any offense or misinterpret your remark about the kernel. I only wanted you to know that c/fdisk both work without much regard for kernel version (how a kernel and its modules are configured is a different story).

Quote

...*Letme get on the puppy machine to post the "fdisk -l" output.

(After latest puppy install-current state).
Disk /dev/hda: 61.4 GB, 61492838400 bytes
16 heads, 63 sectors/track, 119150 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Device Boot Start End Blocks Id System
/dev/hda1 1 969 488344+ 82 Linux swap / Solaris
/dev/hda2 * 970 10657 4882752 83 Linux
/dev/hda3 10658 30974 10239768 83 Linux
/dev/hda4 30975 119150 44440704 83 Linux
sh-3.00#

Hmmm, I've used DSL many times to partition devices (hard drives, various USB devices, etc.). How were you running DSL when you tried to partition? (cheatcodes?)

Quote

At least you know the drives are good. You should also be able to install DSL with the drive repartitioned, if that was what you intended. I still don't know why you had problems partitioning under DSL.

Quote

Thus I am back at the serial mouse problem (in puppy).

You may find someone here able to help you, but puppy has its own forums. And I should be candid: I'm not a fan of puppy (I think the overall plan is worthwhile, but I just don't care for the rather, ummm, peculiar execution of it even though I know their target audience is Windows users who need to ease into Linux; it's just a little goofy to me -- no Disney puns intended).

Quote

I searched the puppy resources & found the exact advice you gave about "protocol""microsoft" & "/dev/ttyS0".

That's what should work since xorg pretty much works the same regardless of distro.

Quote

*The problem is puppyserialdetect (at bootup) is detecting the serial mouse as ps/2, 50% of the time.

I don't know if Puppy has any cheatcodes, much less if there's one for setting up a serial mouse. You might want to check that out. You might also want to see if that's an issue its developers care to tackle in their (auto)configuration -- especially if their script isn't consistently detecting something like that.

Quote

4. I have found an interim solution... But, I can't get the mouse setting to stick.

Check with their forums. I've spent less than an hour fiddling with puppy and (as you can tell from above) I really haven't cared enough about it to see how it saves its settings.

Quote

**p.s. Before puppy, I installed Vector & also modified /etc/X11/XF86Config-4.in to try to wake the serial mouse, but failed.

Did you change the same two lines? It should've worked unless you have some weird mouse that's not even MS-compatible (maybe that's why puppy gets it right only sometimes?), but then it most likely wouldn't work in other distros, either, if they use xorg since its configuration is going to be the same (so long as you have the right drivers for your hardware).

Quote

**p.s. Due to this testing, I have also learned more about Linux. Thankyou.

No problem. That's what the forums are for, and "testing" is the fun part of the learning curve (once you get past any frustration, and you will get past it if you try).

Next Page...
original here.