beim Kopieren wird /usr/src/linux-2.4.xx/arch ausgenommen, warum?

Warum werden beim Kopieren der /usr-Partition auf eine neue Festplatte als root, neue FP-Partition gemountet auf /mnt, mit cd /mnt; tar cf - /usr --atime-preserve -p | tar xvf - --atime-preserve -p stets das Verzeichnis "arch" in den jeweiligen linux-2.4.xx- Verzeichnissen (linux-2.4.20, linux-2.4.21, linux-2.4.21-4, linux-2.4.26) *ausgelassen*? Ich habe vor ein paar Tagen von einer 80 auf eine 160GB Festplatte gewechselt und dann mal eben alles rüberkopiert. Es scheint auch alles ordentlich zu funktionieren, die Benutzerdaten sind noch da, alles fährt hoch, nur fehlt bei allen Kerneln das Unterverzeichnis "arch". Alle anderen Unterverzeichnisse (fs, drivers, include, ...) sind kopiert worden, nur eben das "arch" nicht. Ich habe gerade per ISDN auf dem PC nachgesehen, wo jetzt meine alte 80er Festplatte Dienste tut. Dort sind tatsächlich alle "arch"-Verzeichnisse (ca 40MB Inhalt) vorhanden! Die "arch"-Verzeichnisse standen also zum kopieren bereit ... :o Reproduzieren des Fehlers: Habe die fehlenden Verzeichnisse mit md arch einfach mal ergänzt und mit touch test eine dummy-Datei erzeugt. Dann mit tar cf /usr ...... dieses Verzeichnis woanderst hinkopiert und siehe da, die arch-Verzeichnisse mit der "test"-Datei werden kopiert, der Fehler ist also *nicht* reproduzierbar. Ich bin völlig fassungslos .... Habe nach wie vor Suse 8.2. Weiß hier einer weiter? Danke schonmal Ekkard

Wahrscheinlich gelöst, defektes IDE100-Kabel! * Ekkard Gerlach (ich) schrieb:
Warum werden beim Kopieren der /usr-Partition auf eine neue Festplatte als root, neue FP-Partition gemountet auf /mnt, mit
cd /mnt; tar cf - /usr --atime-preserve -p | tar xvf - --atime-preserve -p
stets das Verzeichnis "arch" in den jeweiligen linux-2.4.xx- Verzeichnissen (linux-2.4.20, linux-2.4.21, linux-2.4.21-4, linux-2.4.26) *ausgelassen*?
habe ein Jul 29 19:03:39 rex2 kernel: hda: dma_timer_expiry: dma status == 0x24 Jul 29 19:03:39 rex2 kernel: hda: lost interrupt Jul 29 19:03:39 rex2 kernel: hda: dma_intr: bad DMA status (dma_stat=30) Jul 29 19:03:39 rex2 kernel: hda: dma_intr: status=0x50 { DriveReady SeekComplete } entdeckt nachdem ich den Test mit tar zur Reproduzierung des Fehlers durchgeführt hatte. Mit einem neuen UDMA100-Kabel habe ich diese Meldung nicht mehr. Also werde ich mal neu Installieren .... oder mir die Daten nochmal von der 80GB-FB rüberkopieren. Ekkard

* Ekkard Gerlach schrieb:
Wahrscheinlich gelöst, defektes IDE100-Kabel!
... leider doch nicht .. :-( habe das:
Jul 29 19:03:39 rex2 kernel: hda: dma_timer_expiry: dma status == 0x24 Jul 29 19:03:39 rex2 kernel: hda: lost interrupt Jul 29 19:03:39 rex2 kernel: hda: dma_intr: bad DMA status (dma_stat=30) Jul 29 19:03:39 rex2 kernel: hda: dma_intr: status=0x50 { DriveReady SeekComplete }
immer noch. Habe schon den write Cache ausgeschaltet mit hdparm -W0 /dev/hda aber das hilft nicht. HAt hier jmd auch Probleme mit einem AMD761+686B Chipsatz und großen Festplatten (160GB)? Wird im BIOS DMA33 eingestellt, dann funktioniert alles einwandfrei . Der Chipsatz ist aber erkannt: aus dmesg: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 00:07.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1 ide0: BM-DMA at 0xc400-0xc407, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xc408-0xc40f, BIOS settings: hdc:DMA, hdd:pio hda: HDS722516VLAT80, ATA DISK drive Ekkard

Ekkard Gerlach wrote:
* Ekkard Gerlach schrieb:
Jul 29 19:03:39 rex2 kernel: hda: dma_timer_expiry: dma status == 0x24 Jul 29 19:03:39 rex2 kernel: hda: lost interrupt Jul 29 19:03:39 rex2 kernel: hda: dma_intr: bad DMA status (dma_stat=30) Jul 29 19:03:39 rex2 kernel: hda: dma_intr: status=0x50 { DriveReady SeekComplete } [...]
Kernel-Version? CU, Th.
participants (2)
-
Ekkard Gerlach
-
Thomas Hertweck