System tar & restore Project

[mask2011]

Δοκίμασα να κάνω backup στον ξάδερφο που του έχω βάλει Arch και μου έβγαζε error.

 

Το backup θα πήγαινε κατευθείαν σε usb stick. Ορίστε και το log:

tar (child): /run/media/george/DISK_IMG/Backup Linux/Backup-17-08-2013/Backup-desktop-17-08-2013-21\:59\:46.tar.xz: Cannot open: Invalid argument
tar (child): Error is not recoverable: exiting now
tar: Removing leading `/' from member names

Ελπίζω ότι δεν έχω κάνει εγώ καμία μαλακία. Στον σκληρό που είναι το σύστημα έγινε κανονικά το backup.

 

Όταν πήγα να το βάλω στο stick έπρεπε να βγάλω από το όνομα του αρχείου την ώρα για να μπορέσω να το αντιγράψω. 

[martinoff]

αν το stick ήταν fat32 κάτι έχει να κάνει με το filename length (utf-16 ??? δεν είμαι σίγουρος) όπως και δεν βλέπει μερικούς χαρακτήρες

[tritonas00]

Υeap το fat εχει θεμα. Mε fs της προκοπης  δεν θα ειχες προβλημα.

Επεξ/σία 18 Αυγούστου 2013 από tritonas00

[mask2011]

Σε περίπτωση που είναι fat, σε τι προτείνετε να το κάνω format; Το stickακι αγοράστηκε μόνο και μόνο για το backup.

[tritonas00]

ext2

 

αν και προσεξα οταν εκανα διαφορα transfer στο φλασακι, οτι με btrfs ηταν πιο γρηγορο. Aλλα αν το κανεις btrfs απο arch, δεν θα μπορεις να το κανεις mount σε διανομες με πιο παλιο kernel. Οποτε ext2, σταθερα.

Επεξ/σία 19 Αυγούστου 2013 από tritonas00

[tritonas00]

3.6.7 is up.

 

Διορθωθηκε το αργο download στο dialog interface (και λεω γιατι αργει...γιατι αργει ), και πλεον θυμαται το url που δινουμε (dialog interface), ουτως ωστε αν κανουμε καποιο λαθος να μην χρειαζεται να το ξαναγραφουμε ολο απο την αρχη.

[tritonas00]

Πλεον χρησιμοποιείται η blkid για να παρει τα uuids, και οχι η lsblk. Η τελευταια μου εχει τυχει να μην δειχνει τιποτα (σε btrfs κυριως, bug?) με αποτελεσμα να μενει ημιτελες fstab και syslinux.cfg (στην περιπτωση του syslinux).
 
Με την blkid δεν υπαρχει προβλημα.
 
Eπισης το cli interface χρησιμοποιει την function του dialog interface (part_list_dialog) για να φτιαξει array με partitions, μιας και ηταν ιδια και ειχαμε διπλο αχρηστο κωδικα.

Οποτε martinoff αν παλι σου βγαλει προβλημα, πρεπει να ξανασκεφτουμε την λυση του war, να βαλουμε εναν ελεγχο αν εισαι εσυ να μην τρεχουν τα scripts.

[mask2011]

Για αυτό που λες στο αρχικό ποστ για την vesa. Φτάνει μόνο να βάλω αυτό στο xorg.conf που θα φτιάξω;

Section "Device"
    Identifier    "Device0"
    Driver        "vesa"
EndSection

[tritonas00]

Ναι, ή δεν χρειαζεται xorg.conf αν εχεις εγκατεστημενον μονο τον xf86-video-vesa, θα χρησιμοποιησει μονο αυτον.

[tritonas00]

Εχω ξεκινησει δειλα δειλα την συγχωνευση σε ενα script star.sh (γινεται ολιγον τι της π@@ας), οπου ρωταει στην αρχη να επιλεξουμε mode: Backup, Restore, Transfer , και πραττει αναλογα.

 

Να το προχωρησω, ή εχουμε συνηθισει ως εχει και να μην κανω τιποτις? (Θα αλλαξουν κυριως καποια arguments, θα συγχωνευθουν help pages κλπ)

 

Τι γουσταρετε?

 

[warlock9_0]

αυτό έλεγα από την αρχή, το καλύτερο!

δεν έχω χρόνο να βοηθήσω ρε γαμώτο

[mask2011]

Όλα σε ένα νοικοκυρεμένα. 

[Dr.Fuzzy]

100% από εμένα!

[tritonas00]

Το αφησα προς ωρας, θελει δουλεια πολυ η ενωση. Μπορει να το ξαναρχισω καποια στιγμη.

[tritonas00]

Εγινε merge μερος της clean_unmount_when_subvols στην clean_unmount_in και ετσι καθαρισε αρκετος κωδικας + εχουμε μια function που κανει ολη την δουλεια.

Επισης αξιοποιηθηκε παραπανω το /tmp/filelist (στην περιπτωση του Restore Mode) και ετσι το restore.sh:

- Γνωριζει την διανομη πριν ξεκινησει η ολη διαδικασια και μας την δειχνει στο summary

- Ανιχνευει αν ο bootloader που δωσαμε υπαρχει στο archived system και αν οχι δινει σχετικο error και clean_unmount_in

 

Στο git αυτα.

 

Υπαρχει τροπος να ελεγχει και αν το running και target συστημα εχουν την ιδια αρχιτεκτονικη, πριν ξεκινησει η διαδικασια? Καποιο αρχειο που να την δειχνει?