V pátek 20. února 2025 se v pražské kanceláři SUSE v Karlíně uskuteční 6. Mobile Linux Hackday, komunitní setkání zaměřené na Linux na mobilních zařízeních, kernelový vývoj a uživatelský prostor. Akce proběhne od 10:00 do večera. Hackday je určen všem, kteří si chtějí prakticky vyzkoušet práci s linuxovým jádrem i uživatelským prostorem, od posílání patchů například pomocí nástroje b4, přes balíčkování a Flatpak až po drobné úpravy
… více »Evropská rada vydavatelů (EPC) předložila Evropské komisi stížnost na americkou internetovou společnost Google kvůli její službě AI Overviews (AI souhrny), která při vyhledávání na internetu zobrazuje shrnutí informací ze zpravodajských serverů vytvořená pomocí umělé inteligence (AI). Evropská komise již v prosinci oznámila, že v souvislosti s touto službou začala firmu Google vyšetřovat. Google obvinění ze strany vydavatelů
… více »Ubuntu 26.04 (Resolute Raccoon) už nebude v desktopové instalaci obsahovat GUI nástroj 'Software & Updates'. Důvodem jsou obavy z jeho složitosti pro běžné uživatele a z toho plynoucích bezpečnostních rizik. Nástroj lze doinstalovat ručně (sudo apt install software-properties-gtk).
Thomas Dohmke, bývalý CEO GitHubu, představil startup Entire - platformu pro spolupráci vývojářů a agentů umělé inteligence. Entire získalo rekordních 60 milionů dolarů na vývoj databáze a nástrojů, které mají zefektivnit spolupráci mezi lidmi a agenty umělé inteligence. Dohmke zdůrazňuje potřebu přepracovat tradiční vývojové postupy tak, aby odpovídaly realitě, kdy většinu kódu produkuje umělá inteligence.
Toyota Connected North America oznámila vývoj open-source herního enginu Fluorite, postaveného na frameworku Flutter. Pro renderování grafiky využívá 3D engine Filament od společnosti Google a dle svého tvrzení cílí na konzolovou kvalitu her. Fluorite je zřejmě navržen tak, aby fungoval i na méně výkonném hardware, což naznačuje možnost použití přímo v ICE systémech vozidel. Zdrojový kód zatím zveřejněný není.
Byl vytvořen nástroj a postup pro překonání věkového ověření platforem Discord, Kick, Twitch, Snapchat (a možná dalších), kód je open-source a dostupný na GitHubu. Všechny tyto sítě používají stejnou službu k-ID, která určuje věk uživatele scanem obličeje a na původní server posílá pouze šifrovaná metadata, ty ale sociální síť už nedokáže sama nijak validovat, 'útok' spočívá ve vygenerování a podstrčení legitimně vypadajících ověřovacích metadat.
Jihokorejská kryptoměnová burza Bithumb přiznala vážné selhání interních systémů, které ji vystavilo riziku sabotáže a nezabránilo chybné transakci v hodnotě přes 40 miliard dolarů (814 miliard Kč). Druhá největší kryptoměnová burza v Koreji minulý týden při propagační akci omylem rozeslala zákazníkům zhruba 620 000 bitcoinů místo 620 000 wonů (8700 Kč). Incident vyvolal pokles ceny bitcoinu o 17 procent. Většinu
… více »Google Chrome 145 byl prohlášen za stabilní. Nejnovější stabilní verze 145.0.7632.45 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Zpátky je podpora grafického formátu JPEG XL, viz Platform Status. Odstraněna byla před třemi lety. Nový dekodér JPEG XL jxl-rs je napsán v Rustu. Zobrazování JPEG XL lze vyzkoušet na testovací stránce. Povolit lze v nastavení chrome://flags (Enable JXL image format).
Byla vydána nová verze 1.26 programovacího jazyka Go (Wikipedie). Přehled novinek v poznámkách k vydání.
CrossOver, komerční produkt založený na Wine, byl vydán ve verzi 26. Přehled novinek v ChangeLogu. CrossOver 26 vychází z Wine 11.0, D3DMetal 3.0, DXMT 0.72, Wine Mono 10.4.1 a vkd3d 1.18. Do 17. února lze koupit CrossOver+ se slevou 26 %.
Disk /dev/vda: 60 GiB, 64 424 509 440 bajtů, 125 829 120 sektorů Jednotky: sektorů po 1 * 512 = 512 bajtech Velikost sektoru (logického/fyzického): 512 bajtů / 512 bajtů Velikost I/O (minimální/optimální): 512 bajtů / 512 bajtů Typ popisu disku: dos Identifikátor disku: 0x7864cbf8 Zařízení Zaveditelný Začátek Konec Sektory Velikost ID Druh /dev/vda1 * 2048 999423 997376 487M 83 Linux /dev/vda2 1001470 62912511 61911042 29,5G 5 Rozšířený /dev/vda3 62912515 125829119 62916605 30G 83 Linux /dev/vda5 1001472 62912511 61911040 29,5G 8e Linux LVM Diskové oddíly jsou chybně seřazeny.cat /proc/partitions
major minor #blocks name 252 0 62914560 vda 252 1 498688 vda1 252 2 1 vda2 252 3 31458302 vda3 252 5 30955520 vda5 253 0 58212352 dm-0 253 1 4194304 dm-1pvdisplay
--- Physical volume --- PV Name /dev/vda5 VG Name vm25539-vg PV Size 29,52 GiB / not usable 0 Allocatable yes (but full) PE Size 4,00 MiB Total PE 7557 Free PE 0 Allocated PE 7557 PV UUID Sa3XK9-76WJ-8WXk-lS1n-12f1-4lIE-KBpJuF --- Physical volume --- PV Name /dev/vda3 VG Name vm25539-vg PV Size 30,00 GiB / not usable <5,00 MiB Allocatable yes (but full) PE Size 4,00 MiB Total PE 7679 Free PE 0 Allocated PE 7679 PV UUID pvuaGf-Wizd-0cM9-hoAB-trcj-Penw-y0QiJclvdisplay
--- Logical volume --- LV Path /dev/vm25539-vg/root LV Name root VG Name vm25539-vg LV UUID 6mWASA-zGo3-80uE-UTbW-nLo8-q6Uh-8uwVoB LV Write Access read/write LV Creation host, time vm25539, 2018-08-16 14:30:48 +0200 LV Status available # open 1 LV Size <55,52 GiB Current LE 14212 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0 --- Logical volume --- LV Path /dev/vm25539-vg/swap_1 LV Name swap_1 VG Name vm25539-vg LV UUID 96Pg8P-PTZP-dSI5-rAlI-HMNK-8kmB-srP7Mk LV Write Access read/write LV Creation host, time vm25539, 2018-08-16 14:30:48 +0200 LV Status available # open 2 LV Size 4,00 GiB Current LE 1024 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:1Dokázal by mi někdo nakopnout jak mám postupovat pro resize?
lsblk -pf # čitelné pro lidi) lsblk -pfJ # čitelné pro stroje
Tam^^^ je to všechno.
NAME FSTYPE LABEL UUID MOUNTPOINT
/dev/vda
├─/dev/vda1 ext2 69722149-47d2-4375-a3de-ee6a0277771f /boot
├─/dev/vda2
├─/dev/vda3 LVM2_m pvuaGf-Wizd-0cM9-hoAB-trcj-Penw-y0QiJc
│ └─/dev/mapper/vm25539--vg-root
│ ext4 0e74732a-ff32-4ecb-9ac3-b838a7e1fe18 /
└─/dev/vda5 LVM2_m Sa3XK9-76WJ-8WXk-lS1n-12f1-4lIE-KBpJuF
├─/dev/mapper/vm25539--vg-root
│ ext4 0e74732a-ff32-4ecb-9ac3-b838a7e1fe18 /
└─/dev/mapper/vm25539--vg-swap_1
swap 20821e9b-0966-47e0-b502-0e8c7e7ff874 [SWAP]
resize2fs. Ten po vás pravděpodobně bude chtít check fs a napíše vám i konkrétní příkaz (pravděpodobně e2fsck, v článku je uveden fsck.ext3 pro konkrétní fs, řiďte se tím, co po váš chce resize2fs). Až potom zmenšete LV. A dávejte si velký pozor na zobrazované jednotky (tj abyste LVM nezmenšil na menší velikost, než jste zmenšil fs). Pochopitelně je dobré mít zálohu. A připravte se na to, že to může trvat hodně dlouho (nevím, kolik dat tam máte).
Disk /dev/vda: 60 GiB, 64 424 509 440 bajtů, 125 829 120 sektorů Jednotky: sektorů po 1 * 512 = 512 bajtech Velikost sektoru (logického/fyzického): 512 bajtů / 512 bajtů Velikost I/O (minimální/optimální): 512 bajtů / 512 bajtů Typ popisu disku: dos Identifikátor disku: 0x7864cbf8 Zařízení Zaveditelný Začátek Konec Sektory Velikost ID Druh /dev/vda1 * 2048 999423 997376 487M 83 Linux /dev/vda2 1001470 62912511 61911042 29,5G 5 Rozšířený /dev/vda3 62912515 125829119 62916605 30G 83 Linux /dev/vda5 1001472 62912511 61911040 29,5G 8e Linux LVM Diskové oddíly jsou chybně seřazeny. Disk /dev/mapper/vm25539--vg-root: 55,5 GiB, 59 609 448 448 bajtů, 116 424 704 sektorů Jednotky: sektorů po 1 * 512 = 512 bajtech Velikost sektoru (logického/fyzického): 512 bajtů / 512 bajtů Velikost I/O (minimální/optimální): 512 bajtů / 512 bajtů Disk /dev/mapper/vm25539--vg-swap_1: 4 GiB, 4 294 967 296 bajtů, 8 388 608 sektorů Jednotky: sektorů po 1 * 512 = 512 bajtech Velikost sektoru (logického/fyzického): 512 bajtů / 512 bajtů Velikost I/O (minimální/optimální): 512 bajtů / 512 bajtů
Pak jsem to ověřil přes fdisk a je to stále stejný:No samozřejmě, protože resize2fs zmenší jen fs a nikoliv jeho kontejner a už vůbec ne kontejner toho kontejneru. Teď musíte zmenšit příslušně LV (lvreduce), potom, pokud máte dostatek místa v VG (vgs) odebrat PV na tom disku vda3 (pvmove, vgreduce, pvremove) a až potom odstranit oddíl vda3 z mbr (fdisk).
dd if=/dev/vda of=/mnt/zaloha/img bs=velikost bloku count=pocet bloku
Pokud se divám správně a je to bez záruky, tak 512B bloky a 62912511bloků (tj konec oddílu vda2 i extended vda5).
(Pokud to chcete optimalizovat na větší bloky, aby disk měl méně práce, tak si najděte takovou kombinaci větších bloků a počtu, aby to přesně celočíselně vyšlo na celkovou velikost).
A na server2 potom uz jen cat /mnt/zaloha/img > /dev/vda
Takže dd if=/dev/vda of=/mnt/zaloha/img bs=velikost bloku count=pocet bloku
iflag=fullblock!!! Jinak když read vrátí jenom část dat (což se zejména u větších bloků může v pohodě stát) tak se to celé rozbije.
A jinak není potřeba to odměřovat, stačí to kopírovat na cílový disk (pokud dělám dump do souboru tak schválně vzít o trochu víc) a ono se to samo zastaví až dojde místo.
A jinak není potřeba to odměřovat, stačí to kopírovat na cílový disk (pokud dělám dump do souboru tak schválně vzít o trochu víc) a ono se to samo zastaví až dojde místo.Jasně, ale pořád si potřebuješ být jistej, že máš novej disk minimálně stejně tak velkej jako zdrojová data a taky potřebuješ vědět jak velká jsou zdrojová data. Proto to do těch komentářů pišu. Je hezké, že disk má 30GB, ale kolik to vlastně je? To, co potřebuješ skutečně vědět je kde přesně končí tvoje partišna a v jakých jednotkách se to číslo udává. Jako já to dělám taky úplně jinak. Zmenším na míň než je skutečně potřeba (třeba 24GB) a zkopíruju na 32GB disk a udělám resize na max. Tj nějaký konkrétní velikosti taky moc neřeším. Možností je mnoho. Ale tady to bylo komplikováno poněkud zvláštním rozdělením.
No způsob přes clonezillu mi radila technická podpora.Hmm. Z celého tohoto vlákna mám takový pocit, že asi vím, o jakou podporu se jedná. 1) Přijde mi velmi zvláštní, že někdo tohle celé podstupuje k vůli 30GB. 30GB dneska stojí koruny měsíčně. To by nikdo neřešil. 2) Před časem nás požádal jeden náš zákazník o něco velmi podobného. Tři měsíce jsme s ním řešili to, že nechce přidat disk ke svému vmku u "někoho". A (možná jen shodou okolností) se taky jednalo o poměrně zanedbatelnou velikost do 100GB. A přes to mu přišlo výhodnější nám zaplatit 3 měsíce práce, než aby to platil u svého provozovatele. Na jeho podporu se raději ani neobrátil.
Jedná se o 150k souborů 12GB a bude to trvat celkem dlouho.To je docela zvláštní na to, že by to mělo běžet nad ssd.
Nový server měl stejnou verzi jádra jako starý. Na tom novém jsem smazal systémový oddíl a boot zatím nechal, mám v plánu to tak nechat, ale asi bude potřeba nějak opravit, nebo to najede bez problémů?Pravděpodobně nenajede. Bude potřeba opravit bootování. Buď je root v parametru jádra nastaven na lvm path, v tom případě, pokud se nezměnila, to může bez problémů nabootovat, nebo je nastaven na UUID filesystému a v tom případě bude jiné a nenabootuje to. Taky možná bude potřeba přegenerovat initrd.
Tiskni
Sdílej: