gdp77

Σε αυτό συμφωνούμε ότι διαφωνούμε. Το Linux (GUI) είναι πιο idiot proof και πιο εύκολο από τα windows (για προεγκατεστημένο σύστημα μιλάμε) Και εγώ δεν παρεξηγούμαι, π.χ. για data recovery υπάρχουν πολλές GUI εφαρμογές και σε linux https://www.ubuntupit.com/top-15-linux-data-recovery-tools-the-professionals-choice/ Αν διάβασες το πρόβλημά μου από την αρχή δεν ήταν το recovery που το έφτιαξα σε ένα λεπτό με μια εντολή. Εξάλλου τα δεδομένα μου τα είχα ούτως ή άλλως και σε backup Το πρόβλημα ήταν ότι μετά τη "¨ζημιά" που έκανα στα windows δεν μπορούσα να "στρώσω" το GPT table / superblock που φαινόταν μονίμως incosistent.

Καταλαβαίνεις ότι μιλάμε για partition που έγινε ουσιαστικά deleted από άστοχο κλικ του disk management στα windows, και συζητάμε για recovery 1,5 TB δεδομένων, έτσι? Δεν μιλάμε για νορμάλ χρήση! Είναι απλό να κάνεις data recovery στα windows? Μπορεί ο απλός χρήστης? Συγγνώμη γιατί να το κάνεις αυτό? Υπάρχει το gparted. Στα windows αν το κάνεις με cli γίνεται πιο εύκολα?

Είμαι νουμπάς τέλος.... Λοιπόν όταν έφαγα το άκυρο με το initialize από τα windows, το ext4 partition φαινόταν unallocated και για να το επαναφέρω έτρεχα sudo fsck.ext4 -vy /dev/sdd Από τη στιγμή που φόρμαρα τον δίσκο και επανέφερα το backup έπρεπε να τρέχω sudo fsck.ext4 -vy /dev/sdd1 γιατί εκεί πλέον είναι το ext4 partition Αντ' αυτού ο νουμπάς συνέχιζα να εκτελώ το fsck στο sdd και λογικό να μου βγάζει bad magic block αφού εκεί δεν υπάρχει κανένα ext4 partition!!!!!! Απλά έλεος!!!!

Σηκώνω τα χέρια ψηλά... Το primary superblock δεν κατάφερα να το επαναφέρω μόνιμα, παρά μόνο μετά από fsck να έχω πρόσβαση στα δεδομένα. Αυτό μετά από κάθε boot. Τι gparted, τι gdisk, testdisk, fdisk κ.α. καμία τύχη. Κατάφερνα να έχω πρόσβαση στα δεδομένα, αλλά το partition table ήταν damaged.... To παρατάω. delete partion ---> new gpt volume ---> format ext4 και ξαναπερνάω τα δεδομένα από το backup... Λύνεται το πρόβλημα, έχω πλέον το δίσκο να λειτουργεί κανονικά. Και εκεί που λέω πειραματικά να τρέξω πάλι ένα fsck.ext4 δεν μου βρίσκει πλέον ασυνέπειες στο superblock, αλλά πολλές ασυνέπειες στο journaling με ένα σωρό inodes να παραπέμπτουν σε σκουπίδια! Πάω να κάνω repair και καταλήγω με "unformated δίσκο" ΕΛΕΟΣ δηλαδή, τι σκατά θέλει low level format; Πόσο "αθάνατο" είναι το ρημάδι το ext4???? Ξανά μανά φορμάτ (πήγαν να κάνω το αργό να γεμίσει το δίσκο μηδενικά), μου λέει 10 ώρες... ΡΕ ΔΕΝ ΠΑΣ ΝΑ..... Έκανα το γρήγορο φορμάτ, ξαναπέρασα τα δεδομένα, δεν φαίνεται να υπάρχει πρόβλημα, μέσω DISKS ο δίσκος φαίνεται undamaged. Απλά αν ξανατρέξω fsck θα βρίσκει πάλι ασυνέπειες στο journalin... Ε δεν το κάνω... ΕΛΕΟΣ Εν τω μεταξύ σε ολόκληρο μαμημένο google, παίζει να είμαι ο μοναδικός άνθρωπος στον πλανήτη με τέτοιο πρόβλημα....

Λοιπόν το status αυτή τη στιγμή είναι ότι μετά από κάθε επανεκκίνηση linux χάνω τον δίσκο καθώς υπαρχει ένα microsoft reserved partition sdd1 (το οποίο σημειωτέον δεν φαίνεται πουθενά π.χ. gparted αλλά το βλέπει το fdisk) Με fsck τα επαναφέρω αλλά το πρόβλημα παραμένει.... Απλά έλεος..... Πώς σκατά μπορώ από τα backup superblocks να ξαναγράψω το primary superblock ??? ΕΛΕΟΣ Για εκεί με βλέπω... Αλλά με έχει πιάσει το "gdp-ικό" μου τώρα να ανακαλύψω τη λύση.... Αν υπάρχει....

update 8/4/21 Απλά έλεος.... Ενώ όλα καλά, μετά από μερικά boots windows 10 και μια εκτέλεσε easus backup του win 10 συστήματος, ξαναγυρνάω σε linux και ξανά μανά τα ίδια!!! Ο δίσκος είχε ξανά ένα partition sdd1 στην αρχή windows reseved και τα δεδομένα sdd υπήρχαν αλλά σε "unformated" partition. Τρέχω ξανά fsck.ext4 και τα επαναφέρω.... Κάτι πρέπει να άφησε το intialize των windows στο gpt και οταν το βλέπουν πάνε να ανακτήσουν τον δίσκο... Τρέχοντας fdisk /dev/sdd (μετά την επαναφορά με fsck) βλέπω αυτό: george@ryzen:~$ sudo fdisk /dev/sdd [sudo] password for george: Welcome to fdisk (util-linux 2.34). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. The primary GPT table is corrupt, but the backup appears OK, so that will be used. Επομένως η υπόθεσή μου είναι σωστή, ναι μεν το fsck ανακτά τα αρχεία μου, αλλά η μαμακία στο GPT παραμένει.... Δοκίμασα fdisk -w (write new table) αλλά τώρα φαινόταν όλος ο δίσκος unformatted και τον επανέφερα ξανά με fsck Πώς διορθώνω το πρόβλημα στο GPT για να μην γίνει ξανά μαμακία στα windows???? SOS @Rusty_Cookie

Συγγνώμη αλλά "αέρας" είναι και το fiat χρήμα, καθώς η αντιστοιχία του σε χρυσό εδώ και χρόνια δεν υπάρχει

To latop μου ~ 10ετίας είναι toshiba με 1ης γενιάς i5 + radeon. Με SSD, πλέον, δουλεύει άψογα dual boot Windows 10 + Linux Mint 20 Επαυξάνω... @GriGaS Κάποιο θέμα με τους drivers της GPU... Τα windows θα είχαν κάποιους νέους, ενώ χρειάζονται οι legacy (Catalyst) λογικά... Περίεργο που δεν σε άφηνε να κάνεις αναβάθμιση BIOS ενώ το είχες στο ρεύμα... Τι πάει να πει μπαταρία 1%? Χρόνια χρησιμοποιούσα το δικό μου toshiba στο ρεύμα (πριν βρω συμβατή μπαταρία της προκοπής) και δεν είχα ποτέ τέτοιο θέμα. Επίσης κουλό που δεν μπόρεσες να αναβαθμίσεις και το BIOS με προειδοποίηση περί ασυμβατότητας! Σίγουρα κατέβασες BIOS για το σωστό laptop? Πάντως σε νιώθω, με όσα τράβηξες.... ΥΓ με live linux δοκίμασες? ? χαχαχαχαχαχα

update: ΟΛΑ ΟΚ!!!! Έτρεξα το rsync με την παράμετρο --dry-run που μου δίνει το output του συγχρονισμού, χωρίς όμως να γίνει καμία εγγραφή στο δίσκο. Πλην κάποιων διαγραφέντων αρχείων video (τα είχα σβήσει εγώ στον 3TB, αλλά δεν είχα ανανεώσει το backup, επομένως υπήρχαν στο backup), όλα τα άλλα κομπλέ!

Σωστό δεν το είχα σκεφτεί. Εννοείς κάποιο "εικονικό" rsync χωρίς να εγγραφούν δεδομένα? Υπάρχει σχετική παράμετρος που ξέρεις να μου πεις γρήγορα ή να το ψάξω? edit: το dry-run λες. Το βρήκα δοκιμάζω τώρα

Όχι δεν θεωρώ κάτι τέτοιο. Βασίζομαι στην έρευνά σου, ότι δηλαδή είναι κάποιο θέμα του router. Επομένως απευθύνεσαι στον πάροχο και ζητάς αντικατάσταση με άλλο μοντέλο router που δεν έχει το ίδιο πρόβλημα. Ή, αν είναι κάποιο θέμα ρύθμισης, τότε να το κάνουν αυτοί remotely και να μην ψάχνεις εσύ ψίλους στα άχυρα. Μιλάμε για router του παρόχου, ή δικό σου after market?

Αν όντως είναι θέμα router, επικοινωνείς με τον πάροχο και ζητάς αντικατάσταση με νεότερη εκδοχή του ίδιου router ή με άλλο router.

Ενός κακού μύρια έπονται.... Κατά τις εργασίες μου για την επαναφορά ενός laptop γνωστού προσώπου (περισσότερα εδώ), αντί να κάνω format έναν εξωτερικό SSD για να τον μετατρέψω σε bootable windows media, από miss click και βιασύνη έκανα initialize τον ext4 3TB "storage" δίσκο μου. Εκείνη τη στιγμή δεν έδωσα σημασία, καθώς θεωρούσα ότι το initialize ήταν κάτι τύπου "mount" και ότι δεν έγινε κάτι στον δίσκο. Προχώρησα με τις υπόλοιπες εργασίες μου και καθ' όλη τη διάρκεια της ημέρας δεν μπήκα καθόλου Linux λόγω τηλεκπαίδευσης και άλλων υποχρεώσεων. Σήμερα το πρωί πήρα την πρώτη ψυχρολουσία: Μπαίνοντας Linux, βλέπω κάτω δεξιά στο εικονίδιο του timeshift ότι δεν έχει γίνει mount o δίσκος storage.... WTF??? Το μυαλό μου δεν πήγε καν στο συμβάν που περιγράφω στην πρώτη παράγραφο... Ανοίγω disks και έντρομος συνειδητοποιώ τι έχει γίνει... Ο 3TB δίσκος έχει γραμμένο "Windows Reserved" partition, μάλλον MBR, μεγέθους 17MB και όλη η υπόλοιπη χωρητικότητα 3TB φαίνεται unformatted.... Τότε κατάλαβα ότι το "initialize" που είχα κάνει από το disk management των Windows δεν ήταν απλό "mount".... Υπήρχαν καλά και κακά νέα... Τα κακά ήταν ότι αυτός ο δίσκος περιέχει α) υλικό ανεκτίμητης αξίας με πρωτογενές video από τη γέννηση και τη βρεφική ηλικία του γιου μου, μέχρι και πρόσφατα, β) την ταινιοθήκη μου που περιλαμβάνει και σπάνιες ταινίες που δεν βρίσκεις εύκολα γ) τον φάκελο backup του timeshift (εξ ου και το αρχικό warning) δ) αρχειοθέτηση της δουλειάς μου των τελευταίων 15 ετών. Τα καλά νέα ήταν ότι ΕΥΤΥΧΩΣ υπήρχε backup (με rsync) του δίσκου, σε εξωτερικό δίσκο 6TB, ο οποίος μάλιστα για λόγους ασφαλείας είναι offline, δηλαδή αποσυνδεδεμένος και συνδέεται μόνο όταν παίρνω backup. Είχα πλέον μπει σε αχαρτογράφητα ύδατα, γιατί ποτέ μέχρι σήμερα δεν έχω κάνει επαναφορά backup με rsync. Απλά αντιστρέφω τα paths και λειτουργεί; Κάνω απλό copy paste; Και αν κάνω κάτι λάθος κατά την επαναφορά από τον 6TB (εξωτερικό backup) ---> 3ΤΒ (εσωτερικό storage), αργότερα, όταν θα έπαιρνα το πρώτο backup από τον δίσκο 3ΤΒ ---> 6ΤΒ backup θα είχε την πιθανότητα να χάσω αρχεία για πάντα! Έπρεπε να είμαι πολύ πολύ προσεκτικός! Άσε που επειδή το rsync αρχειοθετεί αρχεία, η επαναφορά θα χρειαζόταν ΩΡΕΣ. Τα αρχεία συνολικά στον δίσκο είναι 1.183.881 !!! Και εννοείται υπήρχε και το δίλημμα: Να επιχειρήσω recovery (αν γίνεται) ή να πάω κατευθείαν σε επαναφορά από backup; Αρχίζω το ψάξιμο και το googling, πρώτα για το πώς επαναφέρω rsync backup. Κάπου ανάμεσα σε ιστοσελίδες και εντολές τερματικού, έχω τη φαεινή ιδέα να αναζητήσω λύση σε λάθη όπως το δικό μου "accidentally initialized ext4 disk" και σκάω πάνω στην εντολή fsck. 10-15 χρόνια χρήστης linux, γνώριζα την εντολή, αλλά ποτέ δεν είχε χρειαστεί να την χρησιμοποιήσω για διόρθωση σφαλμάτων σε δίσκο, καθώς ΠΟΤΕ δεν είχε γίνει corrupted ext4 filesystem. Τόσο αξιόπιστο είναι... (δεν μπορώ να πω το ίδιο και για το NTFS που πολλές φορές έχω χρησιμοποιήσει chkdsk στα Windows). Τελικά το fsck.ext4 ήταν και η σωτηρία μου! Με την εντολή sudo fsck.ext4 -vy /dev/sdd (-v --> verbose // -y ---> "ναι σε όλα" γιατί τα prompts που σκάνε είναι πολλά λόγω της φύσης της ζημιάς) και μετά από 5-10 λεπτά διαδικασία, το fsck κατάφερε να επαναφέρει τον δίσκο, προφανώς αξιοποιώντας κάποιο αντίγραφο του superblock που για λόγους redundancy κρατάει το ext4, με όλα τα αρχεία και τους καταλόγους στη θέση τους! Φυσικά δεν μπορώ να ελέγξω τα πάντα αλλά με τυχαία ανοίγματα που έκανα σε αρχεία, όλα φαίνονται να λειτουργούν ΟΚ! storage: ***** FILE SYSTEM WAS MODIFIED ***** 2087519 inodes used (1.14%, out of 183148544) 7915 non-contiguous files (0.4%) 5256 non-contiguous directories (0.3%) # of inodes with ind/dind/tind blocks: 0/0/0 Extent depth histogram: 1971857/2504/7 285710858 blocks used (39.00%, out of 732566646) 0 bad blocks 57 large files 1183881 regular files 785491 directories 0 character device files 0 block device files 8 fifos 4398472 links 118111 symbolic links (113116 fast symbolic links) 19 sockets ------------ 6485914 files Έλεγξα και τα attributes των αρχείων καθώς και τις χρονοσφραγίδες τους και φαίνονται όλα OK, επομένως και το επόμενο backup με rsync θα λειτουργήσει κανονικά, μάλλον... Συμπεράσματα: 1) Μην βιάζεστε όταν κάνετε εργασίες με δίσκους 2) Να έχετε πάντα backup και μάλιστα backup του backup. Ένα εξ αυτών πρέπει να είναι πάντα offline. Όχι μόνο για να αποφευχθεί η όποια φυσική καταστροφή αλλά και για περιπτώσεις , όπως στη δικιά μου, λάθους του χρήστη. 3) Το fsck.ext4 είναι πανίσχυρο εργαλείο και μπορεί να σώσει τη μέρα, αλλά, βεβαίως, εφόσον υπάρχει η σιγουριά του 2 4) Πρέπει να γνωρίζετε πώς να επαναφέρετε το backup που κρατάτε. 5) Η μεγάλη εμπειρία χρήσης Η/Y δημιουργεί πολλές φορές και υπερβολική σιγουριά και λάθη. Το λάθος που έκανα, αν το έγραφε κάποιος στο forum, θα σκεφτόμουν "τι νουμπάς". Και όμως μου συνέβη...

Επίσης η MS φροντίζει και επαναφέρι το "fast startup" μετά από συγκεκριμένα updates, χωρίς να ρωτήσει κανέναν, οπότε τα όποια προβλήματα επανέρχονται και ψάχνεσαι να βρεις τι έχει συμβεί...