[avrn]

Tervist.
Ubuntu server 18.04.5 64bit.
On crontabis seadistatud välja lülitamine kl. 2.10. Selline rida:

[mega]

proovi

[avrn]

Aga see on ju käsk restartimiseks ?

[olavsu1]

sudo halt lülitas masina välja.

[serxx]

ka nii saab teha shutdowni
init 0

või restardi
init 6

[napoleon]

Ma millegipärast arvan, et kõhus teevad kõik need käsud üht ja sama.
Puusalt tulistades ma kahtlustaks, et masin teebki shutdowni, aga miski tarkvara või riistvara äratab ta üles jälle

[avrn]

[napoleon]

Täpselt ei tea kuna ise linuxit desktopina ei kasuta ja serverid nagunii käivad 7x24.
Aga kiirelt googeldades esimene vaste
https://unix.stackexchange.com/questions/132115/how-to-find-reason-a-notebook-wakes-up

[Dirty Harry]

Messages logist näed, kui arvuti käima läheb. St vaata, mis toimub peale Su shutdowni, kas mingi aja pärast läheb käima (ning kuidas läheb).

[Dogbert]

Pole otseselt Ubuntu küsimus, vaid selle 'ema', Debiani teemal. Samas ei tohiks suurt erinevust olla.
Probleem on selline, et masina UEFI on nii sõnnik, et unustab ketaste bootimise järjekorra iga kord, kui bootimisel avastab, et vahepeal on mõni ketas lahti ühendatud, asendatud või lisatud.
Vahel väga harva õnnestub bootida pärast seda ilma USB pealt rescue käimatõmbamise ja efibootmgr abil uue järjekorra loomiseta käsitsi.

Emaplaat on vana ASUS P8H67-M EVO kõige uuema saadaoleva UEFI BIOS-iga.

Masina enda UEFI ei suuda GPT kettalt EFI partitsiooni üles leida automaatselt ja vana järjekorra 'unustab' ehmatusega, et kõik kettad ei ole täpselt samad masina küljes, mis varem seal leidusid.
Kas võib probleem olla selles, et selle pooletoobine UEFI ei otsi EFI faili kaugemalt kui esimeselt partitsioonilt? Ja kui esimene pole FAT32 EFI, siis lihtsalt loobub.
Kuskil pole öeldud, et EFI peab olema esimene, aga kuna Windows teeb ta esimeseks, siis võib ehk mõni UEFI-t kirjutav codemonkey eeldada, et EFI on alati esimene?

Hetkel on EFI kolmandal partitsioonil. Esimene partitsioon on mdadm RAID1 boot ext2 formaadis, teine on igaks juhuks legacy bootimiseks tehtud bios_grub (2MiB) ja EFI FAT32 on alles kolmas.

Mõtlesin lisada kolmanda ketta ja teha sellel partitsioonid teises järhekorras, lükates EFI esimeseks, selle sappa bios_grub ja alles siis RAID süsteemipartitsioonid. Kui seda õnnestub ilma debiani live pulgata käivitada, siis teen teiste ketastega sama.

Vanasti ettejuhtunud masinatel ei ole sellist jama kohanud. Oskasid ise bootida BIOS-i järjekorras järgmise ketta pealt, kui esimene käest kadus.
Sama oskab teha natuke uuem, aga kehvem MSI emaplaat EFI bootimisega. Süsteem ei jää bootimata isegi kui EFI on kolmas partitsioon ja üks ketas, mille pealt varem bootimine toimus, vahepeal küljest 'kaob'.
Aga see ASUS on üks kuramuse ikaldus.

Oh, ma vist praegu leidsin midagi, mida tasub enne proovida:
https://unix.stackexchange.com/questions/360305/uefi-not-recognising-efi-partition-no-booting-options

Et ASUS-e UEFI ei oska EFI faili leida, kui EFI partitsioonil ei ole kausta nimi mitte 'boot' vaid on midagi muud.
Debianil on see muidugi 'debian' vaikimisi. Tasub ilmselt ära proovida.

[napoleon]

Dogbert, mulle tundub, et sul on siiski probleem selle masina BIOS-ga mitte debianiga. Mina olen EFI alati esimeseks teinud, aga noh, saan aru et kui süsteem juba on paigaldatud nii nagu ta on, siis hiljem on üsna tülikas partitsioonide järjekorda muuta.

[Dogbert]

Aga seda ma kirjutasingi, et probleem on masina UEFI BIOS-iga ja otsin võimalust Debiani sellega lepitada kuidagimoodi.
Ma ei kirjutanud kusagil, et Debian oleks probleemne.

Debianis otsin lahendust UEFI ebastandardsetele veidrustele.

Partitsioonide järjekorra muutmine mdadm RAID1 süsteemis on tegelikult suhteliselt lihtne, ühel kettal tunduvalt keerulisem.
Põhimõtteliselt saab seda teha live süsteemis, kordagi rebootimata.

Praegu on Debian kahe kettaga RAID1-i peal. Lisan kolmanda, kuhu teen partitsioonid uues järjekorras (ja boot partitsiooni pean ka suurendama, 200MiB kipub kitsaks jääma kahe kerneli olemasolu korral).
Lisan kolmanda ketta partitsioonid RAID1 massiividele, mis asuvad kahe olemasoleva ketta peal.
Paigaldan grubi lisatud kettale.

Nüüd on aeg tulemust katsetada ja rebootimisest ei pääse. Power off.
Ühendan algsed kaks ketast masinast lahti ja üritan värskelt lisatud kettalt bootida.
Kui nüüd suudab masina UEFI kettalt EFI partitsiooni üles leida, siis = pidu.

Juhul kui katse oli edukas, kopeerin partitsioonitabeli ka teisele kettale, lisan vajalikud partitsioonid töötavatele RAID massiividele ja paigaldan grubi.
Siis teen sama kolmanda kettaga. Hiljem võib kolmanda ketta eemaldada. Või alles jätta.

Aga alustan kõige lihtsamast - EFI partitsioonil kaustanime muutmisest debianist boot-iks.

Homme.
___________________

Lahendus:

Debiani EFI bootimise fail EFI partitsioonil: \EFI\debian\grubx64.efi

lähed EFI partitsioonil EFI kataloogi ja kopeerid kogu 'debian' kataloogi 'BOOT' nimeliseks kataloogiks,
grubx64.efi faili nimetad bootx64.efi failiks (ainult x64 süsteemis muidugi. Muu arhitektuuriga süsteemides peavad olema muud liited: vt link allpool)

(parandus) EFI partitsioon peab siiski olema esimene.

Sel juhul toimub bootimine igast asendist, esimese ettejuhtuva ketta pealt, millelt EFI partitsioon \EFI\BOOT\bootx64.efi failiga leitakse.

https://www.rodsbooks.com/efi-bootloaders/installation.html#alternative-naming Using a Fallback Filename

[XeStAiSy]

Kas ubuntudel on ikka see mure peale oma asja tööle saamist kukub kokku.

[napoleon]

Täpsusta mis kokku kukub. Üldiselt töötab ilusti, uuendused, isegi versiooniuuendused teeb ka enamasti üsna muretult.

[Dirty Harry]

[AboveOneAboveAll]

Kas Radeon iGPU 680M + nVidia RTX 3070 on liiga palju peavalu viimase Ubuntu jaoks?
Või oleks RTX 4060 parem mõte?

4060 või 3070 kasutaks vaid Blenderis renderdamiseks.

[Supiplex]

Ametlikud nVidia draiverid lubavad toetada mõlemat RTX kiibistikku: https://www.nvidia.com/Download/driverResults.aspx/199656/en-us/
AMD oma väidetavalt ka töötab: https://www.phoronix.com/review/amd-radeon-680m
Mõlemat korraga vaevalt töötavad. Pigem saad valida kas üks või teine, ja kui näiteks väline HDMI või DP port juhtub olema kindla kaardi külge keeviatud, siis saadki välise monitoriga ainult seda kasutada.

[asjameez]

Jooksutad kõike vaikimisi AMD peal ja kui tahad Blenderit või mõnda nõudlikumat mängu Nvidia peal jooksutada, siis `prime-run` käsule ette (`prime-run blender`).

[Vael]

Uskumatult kiireks on Ubuntu uuendused muutunud. Upgrade ver+1 teeb sama kiiresti nagu windoosa mingit suva uuendust uimab.
Kerneli pätsud teeb ka kiiresti ja vanad koristab ka nüüd automaagiliselt ära.
ID kaardi need webid pluginad läksid ka muretult peale.

[avrn]

Tervist.
Üritan siin Ubuntu server 18.04 peal Raid1 ehitada, kuid ei õnnestu. Kaks 6TB ketast.
Teeb raid-member`iks vaid ühe ketta. Kaks korda juba proovinud.
Olen lähtunud õpetusest, mis sel lehel:
https://www.digitalocean.com/community/tutorials/how-to-create-raid-arrays-with-mdadm-on-ubuntu-18-04
sudo mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc

Tulemus:

Spoiler

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
NAME SIZE FSTYPE TYPE MOUNTPOINT
sda 3,7T disk
└─sda1 3,7T ext4 part /mnt/salv
sdb 5,5T disk
sdc 5,5T linux_raid_member disk
sr0 1024M rom
nvme0n1 238,5G disk
├─nvme0n1p1 476M vfat part /boot/efi
├─nvme0n1p2 46,6G ext4 part /
└─nvme0n1p3 167,7G ext4 part /home
........................................................................
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md127 : inactive sdc[1](S)
5860390488 blocks super 1.2

unused devices: <none>

Saan ma millestki valesti aru ja teen midagi valesti?
Tänan ette näpunäidete eest.

[napoleon]

Mulle tundub, et peaks olema nii hoopis
sudo mdadm --create --verbose /dev/md0 /dev/sdb /dev/sdc --level=1 --raid-devices=2

aga võib-olla sööb mõlemat pidi.
Kas mõlemad kettad on tühjad ja pole kuhugi mount-tud?
Tapa see md127 maha, kasvõi toote jõuga kui ketastel andmeid pole(nendest jääd sel meetodil ilma)
sudo cat /dev/zero > /dev/sdb
oota natuke ja ctrl-c
sudo cat /dev/zero > /dev/sdc
oota natuke ja ctrl-c

ja siis restart ja uuesti see array luua.

Miskit on sul seal nihu, see md127 tekib üldiselt siis, kui paned külge teisest masinast võetud ketta, kus enne raid oli. Kui ongi nii, et ketas polnud enne tühi, siis võib see kurja juur olla.
Kas see mdadm --create käsk mingeid vigu ei andnud?

[avrn]

Kettad on uued. Andmeid peal ei ole.
Ühe veateate olen saanud, kohe alguses, kui kogemata mõlemad kettad /dev/sdb panin.
Tegin nagu juhendasid ja proovin uuesti:

Spoiler

mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=0.90
mdadm: size set to 5860390464K
mdadm: automatically enabling write-intent bitmap on large array
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
....................................................
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdc[1] sdb[0]
5860390464 blocks super 1.2 [2/2] [UU]
[>....................] resync = 0.2% (16878464/5860390464) finish=532.9min speed=182748K/sec
bitmap: 44/44 pages [176KB], 65536KB chunk

unused devices: <none>

Sedasi on väljundid enne ka olnud, kui mälu ei peta.
Homme selgub .

[napoleon]

Võid --assume-clean parameetrit ka proovida, tegelt pole array loomisel vaja resynci teha kui tead, et kettad on korras.

Aga kui nüüd nii tegema hakkas, siis kahtlustan, et tekib mingi kamm kuskil.
Vaata mis dmesg näitab kui lõpetanud on. Võimalik, et ühe või mõlema kettaga on miski error.

btw, see array ise peaks sul praegu ka kasutatav olema kui sinna mingi fs ka tekitad.

[avrn]

No praegu igatahes näitab nii:

Spoiler

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
NAME SIZE FSTYPE TYPE MOUNTPOINT
sda 3,7T disk
└─sda1 3,7T ext4 part /mnt/salv
sdb 5,5T linux_raid_member disk
└─md0 5,5T ext4 raid1
sdc 5,5T linux_raid_member disk
└─md0 5,5T ext4 raid1
sr0 1024M rom
nvme0n1 238,5G disk
├─nvme0n1p1 476M vfat part /boot/efi
├─nvme0n1p2 46,6G ext4 part /
└─nvme0n1p3 167,7G ext4 part /home
.......................................................................
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdc[1] sdb[0]
5860390464 blocks super 1.2 [2/2] [UU]
[=>...................] resync = 5.3% (311195392/5860390464) finish=586.0min speed=157819K/sec
bitmap: 43/44 pages [172KB], 65536KB chunk

unused devices: <none>

Tasapisi edeneb. Näis, mis valmis teeb.
Failisüsteemi sai peale teha, tegin prooviks mõned kaustad ka, olid täitsa olemas.
Praegu rohkem ei torgi, las toimetab omaette.

[napoleon]

dmesg või sudo dmesg väljundit võid ka jälgida
sinna peaks näitama kui miski selle resync juures katki läheb
Võid praegu ka vaadata, ega see miskit ei torgi, lihtsalt näitab teateid.
või siis vaadata /var/log/syslog seal võib ka miskit olla

[avrn]

Niisiis, on valmis teinud. Aga md0-ist on saanud md127 taaskord, osalisteks nüüd mõlemad kettad.
demesg-ist leidsin sellised read, mida nende ketastega oskan seostada:

Spoiler

scsi 4:0:0:0: Direct-Access ATA WDC WD60EFAX-68J 0A83 PQ: 0 ANSI: 5
[ 4.937543] sd 4:0:0:0: Attached scsi generic sg2 type 0
[ 4.937544] sd 4:0:0:0: [sdb] 11721045168 512-byte logical blocks: (6.00 TB/5.46 TiB)
[ 4.937545] sd 4:0:0:0: [sdb] 4096-byte physical blocks
[ 4.937550] sd 4:0:0:0: [sdb] Write Protect is off
[ 4.937551] sd 4:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 4.937559] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 4.937625] scsi 5:0:0:0: Direct-Access ATA WDC WD60EFAX-68J 0A83 PQ: 0 ANSI: 5
[ 4.937725] sd 5:0:0:0: [sdc] 11721045168 512-byte logical blocks: (6.00 TB/5.46 TiB)
[ 4.937726] sd 5:0:0:0: [sdc] 4096-byte physical blocks
[ 4.937731] sd 5:0:0:0: [sdc] Write Protect is off
[ 4.937732] sd 5:0:0:0: Attached scsi generic sg3 type 0
[ 4.937733] sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[ 4.937740] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 4.970381] sd 4:0:0:0: [sdb] Attached SCSI disk
[ 4.971801] sd 5:0:0:0: [sdc] Attached SCSI disk
[ 5.043617] md/raid1:md127: not clean -- starting background reconstruction
[ 5.043618] md/raid1:md127: active with 2 out of 2 mirrors
[ 5.046240] random: fast init done
[ 5.049591] md127: detected capacity change from 0 to 6001039835136

Ei enamat. Samas ketastega tundub minu silma jaoks kõik õige olevat, kui see nimemuutus välja arvata.

Spoiler

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
NAME SIZE FSTYPE TYPE MOUNTPOINT
sda 3,7T disk
└─sda1 3,7T ext4 part /mnt/salv
sdb 5,5T linux_raid_member disk
└─md127 5,5T ext4 raid1
sdc 5,5T linux_raid_member disk
└─md127 5,5T ext4 raid1
sr0 1024M rom
nvme0n1 238,5G disk
├─nvme0n1p1 476M vfat part /boot/efi
├─nvme0n1p2 46,6G ext4 part /
└─nvme0n1p3 167,7G ext4 part /home
....................................................................................
sudo mdadm --detail /dev/md127
/dev/md127:
Version : 1.2
Creation Time : Sun Feb 18 15:56:18 2024
Raid Level : raid1
Array Size : 5860390464 (5588.90 GiB 6001.04 GB)
Used Dev Size : 5860390464 (5588.90 GiB 6001.04 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent

Intent Bitmap : Internal

Update Time : Mon Feb 19 05:45:06 2024
State : clean, resyncing (PENDING)
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Consistency Policy : bitmap

Name : tvserver0:0 (local to host tvserver0)
UUID : 21bddd64:b85d3ce4:7c2f3c21:2d9f10be
Events : 71540

Number Major Minor RaidDevice State
0 8 16 0 active sync /dev/sdb
1 8 32 1 active sync /dev/sdc

Ununes mainida, et masinas oli enne ka Raid1 väiksemate ketastega. fstabist vaatasin oli mountitud md0-na. Selle ma lammutasin ära eespool juba lingitud õpetuse järgi. Ehk võis sellest midagi maha jääda, mis anomaaliaid põhjustas?

[kaabakas]

See md0, md127 misiganes nimi ei ole väga püsiv, ära sellesse kiindu. Kasuta massiivi UUID, mitte nime järgi.
Mis seal lõppeks täpselt sassi läks, kes seda enam siin telefonimänguga kindlaks teeb.

[Dogbert]

Minu tagasihoidlike kogemuste järgi, kui ma õigesti mäletan, genereerib mdadm sellise nimega massiive automaatselt, kui leiab (bootimisel?) mingeid tundmatuid või hüljatud, aga superblocki sisaldavaid partitsioone. Ta võib neid äkki hüljatuks või tundmatuks pidada ehk ka siis, kui neid initrd.img sees sisalduvast mdadm.conf-ist ei leia bootimisel. Ei mäleta kahjuks nii detailselt.

Kui genereeritud /etc/mdadm/mdadm.conf failis on olemas kõik massiivid oma õigete nimede ja UUID-dega

Ja kustutad kasutamata partitsioonidelt superblockid, siis uuendad initramfs-i: update-initramfs -u

Siis vist selliseid kummitusi rohkem ei tekkinud...

Ahh, sa teed RAID-iks terved füüsilised kettad. Ma ei märganud seda.
Ma tavaliselt teen partitsioonidest.
Mitte et see midagi oluliselt muudaks.

[avrn]

Pole paar päeva olnud mahti tegelda .....
Kui ma seda /etc/mdadm/mdadm.conf uurisin, ei leidunud massiivide kohta mingit juttu.
Kas sellist infot hoitakse veel kuskil?

Seni olen jah terved kettad teinud raidiks. Kas ses mõttes on mingi vahe ka, kas teha kettad või partitsioonid? On emmal-kummal mingi eelis/miinus?

[napoleon]

/etc/mdadm.conf võiks miskit sellist sisaldada. See on näide, ära seda copy-paste kuna see ei tööta sul
ARRAY /dev/md0 metadata=1.2 name=ubuntu-server:0 UUID=cace0f92:58852682:b77b5e10:544425b0
ARRAY /dev/md1 metadata=1.2 name=ubuntu-server:1 UUID=910a2f03:6a9bd74d:e9b3109a:b05ec65e
ARRAY /dev/md2 metadata=1.2 name=ubuntu-server:2 UUID=10944e5d:61664682:624e7c53:093c7d22

mdadm --detail /dev/md0 või siis hetkel mdadm --detail /dev/md127 võiks sulle selle UUID anda, mis sinna käima peaks. (sudo ette kui vaja, ma ise ei viitsi enamasti käsureal nii toimetada, et iga käsu ette sudo panna kuna muud asja kui masina konfi näppima mul sinna nagunii pole väga)

[avrn]

Nüüd on jälle md0-ks tagasi keeranud end. Vahepeal on masin paar shutdowni ja starti üle elanud.

Lisan: Nüüd on igatahes ilusti toimetanud, rohkem pole end võõra nimega maskeerinud. Arvuti tunneb massiivi õigesti ära, väljajagatud kaustad on kenasti olemas ja kättesaadavad seal, kus vaja. Vaikselt asustan videomaterjaliga. Võib vist joone alla tõmmata.
Tänan kõiki, kes nõu andsid ja kaasa mõtlesid.

[Dogbert]

Automaatselt genereerib terve mdadm.conf faili skript /usr/share/mdadm/mkconf

/etc/mdadm/mdadm.conf ongi mdadm-i "mälu", kus ta muuhulgas massiivide nimesid hoiab. Kui seda ei salvesta, siis püsib loodud mdadm seadistus vaid järgmise rebootimiseni. Seejuures peab see konf sisalduma ka initramfs-is.
Bootimisel üritab mdadm avastatud superblockide järgi massiivi automaatselt taastada ja annab talle automaatselt nime, kui ta initramfs-ist konfi ei leia, kus avastatud superblockidega seadmed on nimetatud.

mkconf skripti väljund tuleb stdout-i, nii et pead ise selle õigesse faili suunama. Läbi sudo peab kasutama, muidu ei saa mdadm infot kätte.

Ma tavaliselt enne teen mdadm.conf-ist backupi, siis genereerin uue faili ja vaatan ta üle. Kuna mul on RAID massiivid tehtud ainult partitisioonidest, siis realt #DEVICE partitions eemaldan kommentaarimärgi. See peaks teoreetiliselt kiirendama bootimist, kui mujalt superblocke otsima ei pea automaatselt. Vaikimisi skännitakse ka konteiner-massiive (nagu ma aru saan, siis massiive, mille sees on teised massiivid, nagu vene matrjoška).
Sina võid sama teha, sest DEVICE partitions skännib ka füüsilisi kettaid

[avrn]

Väga põhjalik selgitus. Aitäh.
Tegelikult pakub mulle huvi tõesti ka OS-i enda peeglis ketastele paigaldamine. Seni ainult andmekettaid nii kasutanud. Tõsi, kunagi sai üks XP niimoodi käima pandud, küll riistvaralise Raid-kontrolleriga.
Kõneksoleva masina OS on juba vana (Ubuntu 18) ja peaks ehk uuemale liikuma.
Aga sellega kannatab, ootab 24-väljalaske ära, siis suve või sügise poole vaatab seda asja. Enne peab mõne vana masina peal katsetama.

[napoleon]

do-release-upgrade peaks upgrade suht valutult tegema. Kuigi nii vana puhul ei tea ka, võib kobiseda miskit.
OS kettad peeglisse saad installeriga isegi. ZFS puhul muidugi käsitöö, aga tavalise md softraid saad küll suht lihtsalt.

[Dogbert]

Ma mõtlesin, et OS on ka RAID peal. Kui ainult data, siis on lihtsam muidugi.

Aga ei ole väga keeruline töötavat Linuxit ka RAID mirrori peale kolida. Downtime põhimõtteliselt ainult rebootimise aeg.
Ma tegelikult olengi kõik RAID 1 pealt töötavad Debianid sedasi paigaldanud, et mdadm-i paigaldan alles siis kui OS on juba funktsionaalne. On kuidagi sedasi läinud lihtsalt...

Esimesel korral tegin puhtalt veebis oleva juhendi järgi, järgneval paaril korral oli ka juhend igaks juhuks kõrval, et mõnd etappi ei unustaks.

Võin homme juhendi üles otsida, seda enamasti uuendatakse iga uue Debiani releasi puhul või vähemalt üle ühe. Aga ega seal aastatega midagi muud muutunud ei olegi kui MBR-ilt ja BIOS-ilt GPT ja UEFI peale minek, nii et ainult partitsioneerimine ja GRUB paigaldus erinevad. Mdadm ja rsync on ikka samad ning need on selle protsessi juures peamised töövahendid.

Põhimõttelised etapid töötava süsteemi RAID 1-le migreerimisel on:

• teise füüsilise ketta lisamine ja süsteemiketta partitsioonitabeli kloonimine (või uue loomine uuele kettale), lisatud kettal kloonitud partitsioonide tüübi muutmine Linuxist RAID-iks
  
• mdadm paigaldus töötavasse süsteemi ja lisatud ketta partitsioonidest RAID 1 puuduva elemendiga massiivide moodustamine ning mdadm algse seadistuse salvestamine
  
• RAID 1 massiivide formaatimine ja mountimine ajutisse kataloogi samal viisil nagu nad on töötavas süsteemis, pm chroot ettevalmistuse etapp
  
• rsynciga töötava süsteemi kopeerimine lisatud RAID kettale, chroot kopeeritud süsteemi ja uuele kettale kopeeritud süsteemi /etc/fstab failis partitsioonide UUID-de muutmine RAID partitsioonide omaks
  
• chrootis GRUB paigaldus RAID kettale ja initrd värskendamine sealsamas
  
• poweroff ja süsteemiketta lahtiühendamine, bootimine RAID kettalt
  
• kui kõik sai tehtud õigesti, siis hakkab süsteem tööle
  
• uuelt RAID kettalt partitsioonitabeli kloonimine vanale kettale
  
• mdadm-is puuduva elemendiga RAID partitsioonidele puuduvate elementide lisamine vanal kettal asuvate partitsioonide näol. Mdadm sünkib need automaatselt.
  
• GRUB paigaldus/uuendamine ka vanale kettale
  
• mdadm uue konfi salvestamine ja GRUB ja initrd uuendamine
  
• reboot täieliku RAID 1 pealt süsteemi bootimise testimiseks
  
• poweroff ja uue ketta lahtiühendamine, ainult vanalt kettalt bootimise testimine
  
• uue ketta tagasiühendamine, RAID elementide tagasiühendamine/sünkimine mdadm-is
  

[Scott]

Ubuntus (konkreetselt juhtus Lubuntuga) tähtsaid faile välisele andmekandjale liigutades ei tohi kasutada cut and paste käsku, kui pole lisakoopiaid.

Liigutasin videofaile USB-adapteri abil välisele kettale, umbes poole peal korraks unmountis logiseva USB-mini ühenduse tõttu, jäi seisma ja aitas uuesti ühendamine. Aga seni liigutatud failid olid kustunud nii arvuti kettalt kui ka välisele kettale polnud salvestunud. Mis veel liigutamata, need olid arvutis alles.

Otsisin ja lugesin netist juhendeid, kuidas taastada, aga enam kusagil failidest jälge pole. Windowsis jäävad failid näha ja saab cut-käsu eemaldada ning failid ei kustu lähtekohast.

Mõned lingid:

https://askubuntu.com/questions/1263209/how-to-recover-files-lost-during-cut-and-paste
https://askubuntu.com/questions/132638/lost-some-files-after-i-cut-and-pasted-in-ubuntu-12-04
https://askubuntu.com/questions/25311/best-tool-to-recover-removed-files

https://www.itprotoday.com/software-development/how-undelete-files-ubuntu-3-tools-linux-data-recovery
https://medium.com/@prasanthmaverick/how-to-recover-deleted-files-in-ubuntu-254b0db19cb9
https://www.cgsecurity.org/wiki/TestDisk

[Dogbert]

Ei ole see move (ehk cut&paste) Windowsis ka eriti turvaline failide liigutamise meetod. NTFS-i pealt kustutatud faile taastada on natuke rohkem lootust küll, aga SSD peal asuvalt ehk mitte niiväga.

Ja välisele kettale mingi logiseva USB otsas move'iga faile liigutada on ise endale häda kaelatõmbamine täitsa sõltumata OS-ist.

[Scott]

Lahendasin nii, et panin SATA-juhtmega otse emaplaadi külge. Ja kui faili ülekanne katkeb või unmountib, tuleb dialoogiaknas Cancel vajutada ja igaks juhuks ka hiireklikk failidel. Siis lähevad hallid failiikoonid tumedaks tagasi ning failid säilivad algasukohas.


...


Üks teine mure ka. Lubuntuga ketas hakkab vigaseks minema ja peale kinnikiilumist on üks suur tekstifail katki . Just mõni minut enne lisasin sinna rea ja salvestasin ära. Proovisin igasuguseid taastevariante ja vaatasin hex-is, kuid sisu on jura täis ning üle 10000 reaga failist on alles 400+ rida, kuigi failisuurus on üle 100kB. Varasem koopia on olemas, kuid umbes poole aasta lisandused on läinud. Lugesin, et teoreetiliselt peaks kusagil olema eelmised versioonid laiendiga .old, kuid ei oska neid otsida.
On mingi lootus kasvõi nädalavanune koopia kätte saada või kas saab vigase faili taastada? Viimases kahtlen, sest hex-editoris pole algsest sisust jälgegi.

[kaabakas]

Häda sul on jamada nende vigaste ketastega. Play stupid games. Win stupid prizes.

[Scott]

kaabakas, päev kohe korda läinud, kui teise hädale on lajatatud Lootsin uut vastust nähes, et on ehk midagi abiks. Ja kust sa loed välja, et vigaste ketaste ladu mul siin on Üks ja ainus ning asjade migreerimine oli pooleli.

https://en.wikipedia.org/wiki/Foremost_(software) ei installeerunud. Extundelete tuleb teisele kettale panna ja siis uuritavat skannida.

Aga vist on lootusetu üritus. Muu on kõik alles, ainult see õnnetu tekstifail. Mitte miskit eluliselt tähtsat, vaid poole aasta jagu huvipakkuvate laulude nimesid ja mitu meetrit nalju ja häid ütlemisi kommentaariumitest ja foorumipostitustest.

[Supiplex]

[kaabakas]

Sul on kaks erinevat katkise ketta probleemi järjest, nii et kisub lao poole küll. Vaadates aastaid pealt, kuidas inimesed oma ketastest ja andmetest ei hooli, siis minu lähenemine kisub tõepoolest sinnapoole, et lajatada. Muu ei paista aitavat. Teisisõnu, abiks saab sulle olla sellega, et ehk tuleb õppetund ikkagi ära ja sa endale sama jama kolmandat korda ei korralda.
Kui failitabel katki on, siis on võimalus, et faili sisu on ketta peal ikkagi korras. Kui fail ise katki on, ja varukoopiaid pole, siis pole midagi teha. No põhimõtteliselt on ssd puhul lootus, et faili ei korrumpeerunud kettal seistes, vaid kirjutati prahiga üle ja sisu on alles puhtaks kirjutamata varusektorites. Kas ja kuidas nendest variantidest midagi õnnestuma saab on korraliku joppamise, nähtava vaeva, ja makstava raha küsimus.

[Scott]

Supiplex, kasutasin FeatherPad proget, see on lihtne proge põhiliste käskudega. Avasin ka LibreOfficega, kuid selle muudatuste halduse filtrilehel on vanemate versioonide valik hall ehk neid pole. Failiotsing kettalt andis vaid selle katkise faili (peidetud ja süsteemikaustad olid lubatud).

Kui faili vaatan, siis alguses on mitukümmend lehekülge trelle, kusjuures viies märk on mustas kestas valge küsimärk. Edasi hakkab segane tekst kooskorduva partitionkey sõnaga ja veebiaadressidega, mida olen külastanud, kuid mis ei sisaldunud algses failis (v.a. Youtube jms).
Viga sai alguse sellest, et hakkas Firefoxi lehitsedes jäätuma, kui mõni raskem leht avada ja mitmeid tabe korraga lahti oli. Resetiga tuli jälle üles, mõned korrad tegi Busybox failisüsteemi taastust. Ohu märk oli see, kui paar päeva tagasi brauseri detsembri seisu taastas. Eile õhtul jooksis samamoodi kinni. See tekstifail sai arvatavasti seepärast pihta, et olin sinna faili just lisanud ühe rea ja faili salvestanud, kuid mitte sulgenud.
Ketas on täis, kuid mitte pungil. Kahtlustan, et on vigaseid sektoreid ja brauser kirjutas failile peale.

kaabakas, ole hea, näita, kus see nö esimene ketta probleem mul on?

[Supiplex]

See FeatherPad mingit varukoopiat ei tee, seega pole failisüsteemist suurt mõtet otsida.

Sinu kirjeldusest järeldan ma, et see ketas on väga, väga perses. Kahjuks SSD puhul ei pääse tegelikult allolevale Flashile ligi, selle ees seisab SSD firmware mis otsustab ainuisikuliselt kuhu füüsilisse kiipi ja lehele andmeid kirjutatakse. Kui see enam oma tööga hakkama ei saa, pole suurt lootust et failisüsteemi recovery töötaks, sest ta peab samuti selle firmware käest asju küsimas käima.

Üldiselt tasub SSD-de puhul arvestada, et nad surevad üsna vähese etteteatamisega ja üsna lootusetu on sealt pärast midagi kätte saada. Mu eelmine Linuxi ketas, 480 GB Sandisk õnneks hoiatas ette - kernel leidis sealt mingeid I/O erroreid ja kupatas kogu failisüsteemi read-only režiimi. Veidi alla 10 aasta pidas kenasti vastu. Peale uue ketta ostmist panin ma igapäevase backupi käima

[napoleon]

Mida ext4(eeldan et kasutusel on see kuna Ubuntu puhul vist default) teeb kui mingi sektor loetamatuks muutub?
Üritab parandada ja keerab asja veel hullemini tuksi või teatab, et ei saa lugeda?

Muide tekstifaili puhul on päris suur lootus miskit üles leida kui mingeid sõnu/fraase mäletad ja nende järgi ketast skännima hakata

[Scott]

HDD on, mitte SDD.

Kettatuli jääb punaseks, veebilehed hanguvad. Oodata pole mõtet, teen reseti ja hakkab uuesti tööle. Mõned korrad on Busybox failisüsteemi taastanud ja kõik on alles jäänud. Aga nüüd on fail katki. Fail iseenesest pole ju kadunud, sisu on tuksis.

[XeStAiSy]

Linux on selline asi kui arvutil midagi viga siis linux ei toimeta windows on see mis peidab vead ära. HDD tänapäeval ei tasu osta kui juba SSD ilmus muutusid HDDd päris nigelaks. Eks see minemas HDD on. Või tõesti on mingi minemas USB mis kurja teeb.

[Scott]

USB antud juhtumis asjaosaline ei olnud, lihtsalt mõni siin loeb üle rea ja siis teeb "järeldusi".
HDD on vana ja kasutatud, süsteem sai tegelikult ajutiselt katsetamiseks pandud, aga nagu ikka, ajutisus kestis mitmeid aastaid. Ja nüüd, kui mõned videofailid kettale kirjutasin, leidis süsteem vigased kettasektorid üles ning kirjutas vajaliku faili katkisele kohale või pigem brauseri data tekstifaili peale.

[pppd]

ütleme nii, et tavakasutaja oskuste ja vahenditega on suht ebatõenäoline sealt midagi rohkem kätte saada, ketas ning failisüsteem on ilmselt mõlemad pihta saanud, imeväel (või mingi supersalajase käsu abil) neid ära enam ei paranda, ainuke mõistlik tee edasi oleks selle ketta edasisest piinamisest loobuda, ettevaatlikult üritada andmed maha kopeerida (soovitavalt vastava tehnikaga, hädapärast ddrescue, mõlemad nõuavad kogemusi) ja siis proovida klooni pealt võimalikult palju taastada. Kui andmetel on reaalne väärtus, siis pakutakse ka vastavat teenust, aga see on suht kallis ja mingit garantiid loomulikult ei anta. Kui aega palju ja viitsib nikerdada, siis loomulikult võib ka ise näpuvahel proovida.

[mina634]