Moving an HD from one comp to another

Tyler Aviss tjaviss-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Thu Jan 7 15:25:48 UTC 2010


On Wed, Jan 6, 2010 at 9:17 AM, Lennart Sorensen
<lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org> wrote:
> On Wed, Jan 06, 2010 at 11:49:28AM -0500, Giles Orr wrote:
>> I have a 60Gb USB external 1.8" HD on which I've made a bootable
>> Debian testing installation.  It's intended for my Acer Aspire One,
>> which has a very small (8Gb) and slow SSD on-board.  This isn't a
>> great solution, but it makes some interesting things possible.  The
>> onboard SSD has a fully functional Debian testing install on it.
>>
>> I did the external HD install on another laptop because arranging the
>> install on the AAO was just too much of a pain (it doesn't have a
>> DVD/CD drive and I didn't want to download netinst and make a bootable
>> USB key etc. etc.).  When I plug the external drive into the AAO it
>> boots up fine and everything works great ... except for the wired
>> Ethernet card.  The appropriate kernel modules appear to be loaded (I
>> compared it against the module list from the working install on the
>> AAO internal HD), but "ifconfig eth0 up" gets this response: "eth0:
>> ERROR while getting interface flags: No such device."  The main
>> difference in the modules list is that three unneeded firewire modules
>> load (the laptop that I did the install on has firewire).  Unloading
>> them doesn't remedy the situation.
>
> Check the udev rules.  Quite likely the eth of the original machine is
> listed as eth0 (when detected) and the new machine is probably now eth1.
> You can fix that up.  Usually found in /etc/udev/rules.d/*persistent*net*
> (I forget the exact name).
>
>> Is there a simple way to convince the install to re-run the checks for
>> what modules to load, and/or to do the NIC set-up again?  Or is there
>> some other way to solve this?  Thanks.
>
> See above.
>
>> For the curious, the external HD is noticeably but not hideously
>> slower than the internal SSD.  What I'm mostly doing this for is so
>> that I have the room to compile a custom kernel for the system.
>
> USB is slow and very cpu intensive compared to pretty much any other
> interface you could connect a disk to.
>
> firewire, SATA, UDMA IDE, etc all have DMA to offload the cpU.
>
> Given netbooks usually use atom CPUs, you don't have much cpu available
> to begin with.  Also 1.8" disks are generally rather slow compared to
> bigger disks.  Also the SSD has the advantage of no access time to worry
> about, while a 1.8" disk will have a rather long access time because of
> the low rotation speed.
>
> --
> Len Sorensen
> --
> The Toronto Linux Users Group.      Meetings: http://gtalug.org/
> TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
>

/etc/udev/rules.d/70-persistent-net.rules

I ran into the same issue when those particular rules were first
introduced. Had a small LAN-server box die, moved the drives, and
everything worked except the NIC which in some places was eth0 and
others eth3. Seems that the persistent net rules like to reserve the
old eth0/etc names for whatever cards used to exist and cause all
sorts of havoc on a switch. Nuking them and reboot worked for me too
:-)
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list