Running AMD-box installation of amd64 on Intel box
Hi
I have changed motherboard/CPU/GPU from
Gigabyte 890FXA/Phenom II 1075T/2 x Zotac GTX-580
to
Gigabyte X79-UD3/i7-3930k/2 x Zotac GTX-680
trying to boot with the two HDs (Debian amd64 wheezy software-RAID1)
of the Phenom II installation. The monitor, after data for the
motherboard, directly reported "filesystem not recognized". Nothing
else. What I had expected was that, after the usual error for not
finding the floppy, grub2 would be accessed. Whether the difference
between Intel and AMD is the reported failure is normal behavior,
defeats my knowledge.
amd64 info: /boot ext2 for grub2, i.e., on master record (the system
should boot from each disk, even when the other one is damaged, which
I proved by attaching one of the HDs to the dismantled previous
motherboard on the table). RAID1 LVM root home usr opt swap tmp var,
all ext3.
I was by a vendor, where, typically for my country, Linux is pretty
unknown. I forgot to bring with both Knoppix, to analyze mdadm, and
the installation disk. Having to go back to the vendor tomorrow to try
to solve the issue by myself (I succeeded in stopping the vendor to
activate raid from bios and format the disks accordingly!), what do
you suggest as a procedure to circumvent the need of a fresh, complete
installation of amd64? It seems that the vendor used the correct SATA
ports 0-5, not GSATA3 6-9 SATA ports (^%*!# Marvell 88SE9172
controllers), though I have to check that.
Incidentally, there are rumors that the promised two x16 lanes at PCIe
3.0 are not real 3.0. If true, the GTX-680 (with a bandwidth of
224bytes/s) will be slower than my previous GTX-580 (bandwidth
384bytes/s). In fact, the code I use for molecular dynamics requires a
direct talk between GPU and CPU at every step (currently, developers
are unable to get energy computed by the GPU, where the bigger task of
computing bonded and non-bonded interactions is carried out).
I could not stick to AMD because developers of molecular dynamics code
remain - for well known commercial reasons - to CUDA, instead of
shifting to OpenCL. The only exception if the Dutch code, but it is
still at the difficult OpenMM.
Thanks a lot
francesco pietra
chiendarret
Reply to: