Příspěvky

Zapomněli jsme zmínit, že v každém případě musí sedět velikost sektoru (512 vs 4096). Určitě ale bude existovat utilita, která by to přepočítala....

Co se MBR a C/H/S týká, tak se nic moc neděje i pokud partition entries neobsahují LBA a tedy zavaděč nebo OS čte z tabulky rozdělění disku C/H/S hodnoty.  Aby tedy disk bootoval nebo šel připojit stačí při nejhorším manuálně změnit C/H/S obnoveného disku v setupu BIOSu. Hodnoty se dají zjistit v setup BIOSu u nastavení původního disku (pokud je tam LBA není co řešit) nebo z tabulky rozdělení disku (C/H/S pro poslední sektor posledního oddílu) případně bývají uloženy i na souborových systémech. Navíc se to netýká linuxu, linuxové zavaděče geometrii reportovanou biosem nepoužívaly snad nikdy a u disků, které nemají v partition table LBA, IMHO použijí k přepočtu původní C/H/S geometrii. Ale i kdybych byl úplně mimo, není to nic, co by nešlo triviálně opravit testdiskem.

S GPT jsem se nikdy nesetkal, měl bych si rozšířit obzory, Palo, děkuji za vysvětlení. Nicméně podle wikipedie jsou v GPT hlavičce uloženy LBA primární i sekundární hlavičky, podle toho by snad nemělo vadit, když sekundární hlavička nebude LBA -1, nebo je to v praxi jinak?

Pokud nelze vytvořit snapshot souborového systému a musíš skutečně vytvořit kompletní zálohu, tak kromě vypnutí serveru, je alternativou všechny služby zapisující na disk zmrazit pomocí freezer subsystému cgroups, potom sync, provést zálohu a potom služby rozmrazit. Služby vypadnou tak jako tak, ale ušetříš si restart serveru. Nebo zmrazovat služby postupně - vždy jednu službu zmrazit, sync, záloha jejích dat, rozmrazit.

Nemám s tím zkušenost, ale selský rozum říká, že pokud aplikace zapisují na disk, možnosti se liší podle toho jaká data chceš mít v záloze v konzistentním stavu.

1)  chceš-li mít všechna zálohovaná data a stavy služeb v konzistentním stavu a služby neumožňují za běhu vytvářet snapshoty, případně nepoužívají nějaké vlastní journalovací metody, je nutné služby korektně vypnout a nejlépe korektně vypnout celý server a zálohu provést třeba z live distribuce nebo připojit vše readonly, tak aby po čas zálohy nedocházelo ke změně dat. Tedy server odstavit.

2) chceš-li mít zálohovaný souborový systém konzistentní (aby journal odpovídal datům na disku), ale nezáleží ti na stavu aplikací, tj. jako kdyby jsi počítač natvrdo vypnul, stačí vytvořit snapshot souborového systému (podporuje-li to) a zálohovat snapshot. Případně zjistit jestli jednotlivé aplikace (třeba ta databáze) nepodporují vytváření snapshotů a zkombinovat zálohu snapshotu souborového systému se zálohami snaphostů aplikací.  Myslím, že tohle řešení většinou stačí.

Samozřejmě může být větší. Ať už volné místo na cílovém souborovém systému, zálohuješ-li do souboru (image), nebo velikost cílového disku, zálohuješ-li přímo na nerozdělený disk.

[2]

Kód [Vybrat] Rozbalit

Xorg -configure vytvoří soubor xorg.conf v aktuálním adresáři. Buď tedy před spuštěním změň pracovní adresář na /etc/X11/, nebo vytvořený soubor následně přesuň. Xorg musí být spuštěn pod rootem především kvůli přistupu k HW.

Shazovat ostatní X servery teoreticky nemusíš, jen musíš Xorg sdělit pro jaký (nový) display se má spustit, např.

Kód [Vybrat] Rozbalit

Xorg -configure :2 pro display 2. Ale změny v konfiguraci se samozřejmě projeví až pro nové servery, takže asi je chceš stejně nejdříve vypnout. Nebo pokud se ti bude snadněji editovat xorg.conf v X kách, tak si nech původní server spuštěný, proveď editaci a potom ho restartuj nebo spusť nový server k otestování konfigurace.

Viz https://wiki.debian.org/Xorg:

Kód [Vybrat] Rozbalit

# /etc/init.d/gdm stop && /etc/init.d/gdm3 stop && /etc/init.d/kdm stop && /etc/init.d/xdm stop
$ cd /etc/X11/
# Xorg -configure

Edit: Tak nová konfigurace se vytvoří v /root/xorg.conf.new, takže ho potom musíš přesunout. Vždy jsem to tak vlastně dělal, nevím proč je to na wiki jinak. Jinak xorg -configure funguje jen pod rootem.

co něco takového:

Kód [Vybrat] Rozbalit

p=gnome; sudo aptitude -P reinstall $p $(apt-cache --installed depends $p | awk '{ORS=" ";print $NF}')

No ale ten openscad máš podle té chyby nainstalovaný v /usr/local/, to nemůže být oficiální balík, není to náhodou binární upstream verze, kterou jsi stáhl? 2013.6? Ve wheezym je verze 2011.12, v testing/unstable 2013.01 a má závislosti na libc6-2.14... ?

Jinak ten postup k aktualizaci libc6 je myslím správně, jen bych použil český mirror:

Kód [Vybrat] Rozbalit

deb http://ftp.cz.debian.org/debian/ jessie main

Na vyzkoušení by ti to mělo stačit i bez pinningu, jen pokud použiješ aptitude budeš v něm muset závislosti (určitě balíček locales) označit k aktualizaci ručně nebo po několik kroků opravovat resolver.

Ale nevím jestli ta aplikace (předpokládám, ze se jedná o upstream openscad verze 2013.06) nemá další závislosti. Se závislostmi na libc6 by si ale problém mít neměl. Mělo by jít jen o balíčky generované ze stejného zdrojového balíku jako libc6, tj. eglibc).

Ikonky jsou tříděny podle jména aplikace od 2.9.2007, kdy došlo k úplnému přepsání systray pluginu :(

V 4.10 co mám, to nejde. V jaké verzi to fungovalo, jak popisuješ?

Jak se chovalo zobrazení ikonek známých aplikací (standardně skrytých)? Přeházely se ikonky nebo se ty dosud skryté zobrazily na konci seznamu, bez ohledu na čase, kdy byla aplikace spuštěná? Kde se zobrazila skrytá ikonka aplikace po jejím odstranění ze seznamu známých, na konci nebo původním místě dle času spuštění?

Jinak to varování, je míněno skutečně vážně. Přeci jen budeš z testing instalovat knihovnu, kterou používá téměř vše v systému. Jestli je v ní chyba... Navíc přijdeš o její aktualizace nebo budeš muset nastavit pinning, aby se aktualizovala, vždy když do testing přijde nová verze. Možná by bylo lepší, přejít na testing úplně.

V závislostech uvedená je. Libc je jedna z nejdůležitějších knihoven v systému. Wheezy má 2.13, testing/unstable 2.17. Obě mají soname verzi 6, takže 2.17 je zpětně kompatibilní. Můžeš tedy zkusit nainstalovat libc6 z Jessie společně se závislostmi, to by měly být jen binární balíčky ze stejného zdrojového balíčku (eglibc), moc jich asi u tebe nebude, snad jen locales. Jiné balíky by neměly na konkrétní verzi libc6 záviset, takže by to mělo být lehce splnitelné.

Ale je to skutečně snad nejdůležitější knihovna, takže buď hodně opatrný.

[palimpsest]

Pro jistotu bych zkontroloval, zda /dev/sdb je skutečně ten externí disk, třeba pomocí palimpsest.
Potom odpoj všechny oddíly, které jsou z něho připojené (podle posledního výpisu /dev/sdb1).
Nainstaluj a spusť na něm testdisk .

Kód [Vybrat] Rozbalit


sudo umount /dev/sdb*
sudo apt-get install testdisk
sudo testdisk /dev/sdb


Testdisk najde na disku smazané oddíly (quick search nebo pokud nic nenajde, tak následované deeper search), umožní se podívat do souborových systému na nalezených oddílech a oddíly obnovit.

Kdyby oddíly již nebyl schopen najít, můžeš pro obnovení souborů použít třeba photorec (neobnoví názvy souborů a adresářovou strukturu, takže to budeš muset protřídit nějakým skriptem - podle přípony nebo mime typu - a názvy souborů obnovit pomocí metadat vydolovaných ze souborů např. pomocí utility extract).

Tak mě napadlo, jestli nejsi za chybně nastavenou proxy. Třeba transparentní? Nebo neinstaluješ nějakou proxy v těch distribucích?

Nebo ovladačem síťovky, ty distribuce mají různá jádra? Nebo firewallem?

Nevím čím by to mohlo být, chybu bych nehledal v prohlížeči, ale někde dál. Ručně ty soubory stáhnout jdou? Musím říct, že jsem s tímhle nikdy nesetkal.

Protože ti to dělají všechny prohlížeče na různých systémech, tak to jsou pravděpodobně chyby sítě (třeba se ztrácejí pakety a ve windows si to prohlížeče tahají z cache).  Prověř si připojení  a nainstaluj si do iceweaselu/firefoxu firebug a v něm se podívej do záložky Síť, zda se soubory se styly skutečně natáhly.  Uvidíš tam chybový status nebo zda se na soubory pořád čeká. V chromiu může použít lištu vývojářských nástrojů. Nebo zkus wireshark.

1. Jaký je obsah $jsonFile a file_get_contents($url)? Chyba znamená, že $jsonFile není objekt, nejspíš bude null, protože  file_get_contents($url) není validní JSON.
2. $dirlisting[2] není definován.