Linux drive in a Windows box
Derek Atkins
warlord at MIT.EDU
Tue Feb 24 14:05:37 EST 2004
It depends how the drive failed. If the onboard disk controller
failed then you wont be able to talk to the disk no matter what
state the platters are in. You could have a perfectly 100%
normal platter and drive mechanism but if the controller is
dead, you're SOL.
Unfortunately there are about 4 billion ICs in the world waiting
to fail due to a bad batch of epoxy resin or some such. You should
talk to your disk manufacturers, and make sure you keep backups!
-derek
Anand A Rao <arao at honnu.com> writes:
> I had the exact same issue , My hard disk had died and connecting
> this hdd to the system prevented the main ( running) HDD to be
> recognized by the BIOS. Felt it was strange. I found my HDD disks
> was not even spinning. I did Lose some data on that HDD.
> -Anand
> Warren E. Agin wrote:
>
>>My firm's linux webserver recently crashed (really and truly gone - wouldn't
>>boot). Matt Vilates was helpful enough to get me through it and gave me the
>>useful advice of rebuilding the machine using a new hardrive.
>>
>>I have the old harddrive, and software for mounting it on a Windows box so I
>>can examine the file system and try to retreive some non-backed-up items. I
>>installed the drive as a second drive on another computer and, strangely,
>>when I boot up the BIOS won't recognize any of the drives (not even the main
>>drive). I am pretty sure I have the cables set up properly.
>>
>>Any thoughts.
>>
>>-Warren Agin
>> ----- Original Message -----
>>From: "Dan Barrett" <nullpointer at pobox.com>
>>To: <discuss at blu.org>
>>Sent: Tuesday, February 24, 2004 1:17 PM
>>Subject: cvs + xinetd setgid problem
>>
>>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>Folks,
>>I'm trying to run a cvs respository on my Gentoo box. I've got xinetd
>>running, with the cvspserver config (/etc/xinetd.d/cvspserver) looking like
>>so:
>>
>>service cvspserver
>>{
>> disable = no
>> socket_type = stream
>> wait = no
>> user = cvs
>> group = cvs
>> log_type = FILE /var/log/cvspserver
>> protocol = tcp
>> env = HOME=/var/cvsroot
>> log_on_failure += USERID
>> port = 2401
>> server = /usr/bin/cvs
>> server_args = -f --allow-root=/var/cvsroot pserver
>>}
>>
>>
>>Nothing special. Meanwhile, /etc/xinetd.conf looks like this:
>>
>>defaults
>>{
>> only_from = localhost
>> instances = 60
>> log_type = SYSLOG authpriv info
>> log_on_success = HOST PID
>> log_on_failure = HOST
>> cps = 25 30
>>}
>>
>>Great -- everything is locked down just the way I need it. I can login just
>>fine using `cvs login`, but when I execute any other command (for instance,
>>an initial import into the new repository), metalog shows me this:
>>
>>[cvs] setgid to 100 failed (Operation not permitted): real 1005/415,
>>effective
>>1005/415
>>
>>So cvs is trying to setgid to the "users" group, even though the calling
>>user
>>(me) has newgrp'ed to the "coders" group:
>>
>>uid=500(barretda) gid=411(coders)
>>
>>According to /etc/xinetd.d/cvspserver, the cvs binary should be running as
>>user cvs, group cvs. What am I missing?
>>
>>Best,
>>d.
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1.2.4 (GNU/Linux)
>>
>>iD8DBQFAO5U/sIjNiQTGkXARAnEMAJwOk+mbkhufwdazicWc9iXpFPdeUwCfcG/4
>>S0h8ohyu5rzfIRLUI32MhC0=
>>=pnLl
>>-----END PGP SIGNATURE-----
>>
>>_______________________________________________
>>Discuss mailing list
>>Discuss at blu.org
>>http://www.blu.org/mailman/listinfo/discuss
>>
>>
>>_______________________________________________
>>Discuss mailing list
>>Discuss at blu.org
>>http://www.blu.org/mailman/listinfo/discuss
>>
>>
>>
>>
>>
>
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://www.blu.org/mailman/listinfo/discuss
>
>
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord at MIT.EDU PGP key available
More information about the Discuss
mailing list