Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
dd if=/dev/sda1 of=/shares/internal/backup
Chtel jsem se posleze vratit k puvodnimu stavu takze jsem provedl - opet dle navodu :
dd if=/shares/internal/backup of=/dev/sda1
Pote co to dobehlo jsem jeste provedl
# e2fsck -yf /dev/sda1
e2fsck 1.38 (30-Jun-2005)
/dev/sda1: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda1: 9508/368000 files (0.1% non-contiguous), 71220/734944 blocks
Jenze pak jsem najednou skoncil s read-only pripojenym systemem :
<2>EXT3-fs error (device md1): ext3_readdir: bad entry in directory #289136: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
<3>Aborting journal on device md1.
<2>EXT3-fs error (device md1): ext3_readdir: bad entry in directory #289181: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
<2>ext3_abort called.
<2>EXT3-fs error (device md1): ext3_journal_start_sb: Detected aborted journal
<2>Remounting filesystem read-only
No a po pravde moc nevim co s tim ted, zarizeni totiz bezi jako raid1 dvou disku a mam pocit ze v tom je problem.
Jeste prikladam vypis fstab
# /etc/fstab: static file system information.
#
# < file system> < mount pt> < type> < options> < dump> < pass>
/dev/root / ext3 rw,noauto,noatime 0 1
proc /proc proc defaults 0 0
devpts /dev/pts devpts defaults,gid=5,mode=620 0 0
sys /sys sysfs defaults 0 0
/dev/md2 none swap defaults 0 0
/dev/md3 /var ext3 defaults,noatime 0 2
/dev/md4 /shares/internal ext3 defaults,noatime 0 2
Kdyby mi nekdo poradil jak SPRAVNE udelat obnovu systemu z te image budu moc rad.
Deiky predem K
# cat /proc/mdstat
Personalities : [linear] [raid1]
md1 : active raid1 sdb1[0] sda1[1]
2939776 blocks [2/2] [UU]
md2 : active raid1 sdb2[0] sda2[1]
104320 blocks [2/2] [UU]
md3 : active raid1 sdb3[0] sda3[1]
987904 blocks [2/2] [UU]
md4 : active linear sdb4[1] sda4[0]
968655104 blocks 64k rounding
Toto je stzav pote co jsem prehral zalohu na /dev/sda1 a pak spoustel nejake ty e2fsck
Chtel jsem se posleze vratit k puvodnimu stavu takze jsem provedl - opet dle navodu :
dd if=/shares/internal/backup of=/dev/sda1
Pote co to dobehlo jsem jeste provedl
Z jakého systému to běželo ve chvili restaurace? ta záloha systému ze systému, který běži by nemusela dopadnou hůře, než situace kdy by vám vypadlo
napájení a byl jste bez UPS a to systém často přežije i když se opravuje. Ale pokud tohle znamená, že vám systém běžel na /dev/sda1
a vy jste
mu začal přepisovat jeho partišnu, tak se mu to hodně nemuselo líbit.
Zkusil bych nabootovat z live distribuce, připojit do ni to raid pole, a prohlédnout to z ní.
ls -l /dev/rootZdar Max
# ls -l /dev/root
/dev/root: No such file or directory
a jeste
# mount
/dev/root on / type ext3 (ro,noatime,data=ordered)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw)
sys on /sys type sysfs (rw)
/dev/md3 on /var type ext3 (rw,noatime,data=ordered)
/dev/md4 on /shares/internal type ext3 (rw,noatime,data=ordered)
usbfs on /proc/bus/usb type usbfs (rw)
Me by hlavne zajimalo co s tim ted. Mam tu image vytvorenou jak jsem popisoval na zacatku (vytvorenou za behu systemu). Lze s ni neco podniknout nebo mam radsi cely system udelat uplne znovu ? (coz je bohuzel dost pracne a zdlouhave)
Nebo lze - treba po pripojeni toho disku ktery chci obnovit na externi pocitac - s tou image system obnovit ?
at se zachova formatovani...
i kdybys to vzkrisil, doporucil bych to prelejt nacisto...
# fdisk -l
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 4 369 2939895 fd Linux raid autodetect
/dev/sda2 370 382 104422+ fd Linux raid autodetect
/dev/sda3 383 505 987997+ fd Linux raid autodetect
/dev/sda4 506 60801 484327620 fd Linux raid autodetect
Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 4 369 2939895 fd Linux raid autodetect
/dev/sdb2 370 382 104422+ fd Linux raid autodetect
/dev/sdb3 383 505 987997+ fd Linux raid autodetect
/dev/sdb4 506 60801 484327620 fd Linux raid autodetect
V cem je hlavni zadrhel ? Ze ta image byla vytvarena ze systemu za behu nebo ze jsem se ji snazil za behu obnovit ?
A kdybych zkousel obnovit ten system z /dev/sda1 popripojeni jednotek na jiny pocitac jak mam postupovat ? System je udelany jako raid0 - strip
V cem je hlavni zadrhel ? Ze ta image byla vytvarena ze systemu za behu nebo ze jsem se ji snazil za behu obnovit ?V tom, že byla vytvářená za běhu. dd totiž postupovalo od začátku ke konci disku, ale systém během zálohy dělal změny - takže například supernode není konzistentní se skutečným obsahem disku, protože po záloze supernode se na konci disku něco změnilo. Když už potřebuješ systém zálohovat za běhu, zálohuj na úrovni souborů, ne na úrovni souborového systému. Pokud to uděláš rsyncem a ten rsync spustíš víckrát po sobě (aby se během jeho běhu provedlo co nejméně změn), není problém systém obnovit - maximálně si stěžují některé programy, že nebyly korektně ukončeny, ale systém bez problémů naběhne.
fsck /dev/md1NN
#Záloha : sfdisk -d /dev/sda > sda_table_backup # obnova : sfdisk /dev/sda < sda_table_backupObnova by pak probíhala tak, že by jsi obnovil tabulku rozdělení disků :
sfdisk /dev/sda < sda_table_backuppartition naformátoval :
mke2fs -J /dev/sda1 mke2fs -J /dev/sda2 mke2fs -J /dev/sda3 ...Obnovil na ní data a ve finále zapsal boot loader.
Tiskni Sdílej: