Greg Kroah-Hartman začal používat AI asistenta pojmenovaného gkh_clanker_t1000. V commitech se objevuje "Assisted-by: gkh_clanker_t1000". Na social.kernel.org publikoval jeho fotografii. Jedná se o Framework Desktop s AMD Ryzen AI Max a lokální LLM.
Ubuntu 26.10 bude Stonking Stingray (úžasný rejnok).
Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.3.0. S experimentální podporou FLTK 1.4. S příkazem dilloc pro ovládání prohlížeče z příkazové řádky. Vývoj prohlížeče se přesunul z GitHubu na vlastní doménu dillo-browser.org (Git).
Byl publikován přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Vývojáři v přehledu vypíchli vylepšenou instalaci, podporu senzoru okolního světla, úsporu energie, opravy Bluetooth nebo zlepšení audia. Vývoj lze podpořit na Open Collective a GitHub Sponsors.
raylib (Wikipedie), tj. multiplatformní open-source knihovna pro vývoj grafických aplikací a her, byla vydána ve verzi 6.0.
Nové verze AI modelů. Společnost OpenAI představila GPT‑5.5. Společnost DeepSeek představila DeepSeek V4.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 164 (pdf) a Hello World 29 (pdf).
Bylo oznámeno, že webový prohlížeč Opera GX zaměřený na hráče počítačových her je už také na Flathubu and Snapcraftu.
Akcionáři americké mediální společnosti Warner Bros. Discovery dnes schválili převzetí firmy konkurentem Paramount Skydance za zhruba 110 miliard dolarů (téměř 2,3 bilionu Kč). Firmy se na spojení dohodly v únoru. O část společnosti Warner Bros. Discovery dříve usilovala rovněž streamovací platforma Netflix, se svou nabídkou však neuspěla. Transakci ještě budou schvalovat regulační orgány, a to nejen ve Spojených státech, ale také
… více »Canonical vydal (email, blog, YouTube) Ubuntu 26.04 LTS Resolute Raccoon. Přehled novinek v poznámkách k vydání. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 11. vydání s dlouhodobou podporou (LTS).
Ne, nechci si stěžovat na Linux, MD RAID nebo LVM . Berte tenhle článek jako terapii na svou ... řekněme schopnost přehlédnout zjevné a taky jako návod jak věci nedělat.
Včera jsem si totiž zařídil adrenalinové odpoledne. Vezmu to popořadě.
Do serveru s touto konfigurací disků:
### Partitions
# sfdisk -l /dev/sd[abc]
Disk /dev/sda: 9039 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System
/dev/sda1 * 0+ 24 25- 200781 fd Linux raid autodetect
/dev/sda2 25 9038 9014 72404955 fd Linux raid autodetect
/dev/sda3 0 - 0 0 0 Empty
/dev/sda4 0 - 0 0 0 Empty
Disk /dev/sdb: 9039 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System
/dev/sdb1 * 0+ 24 25- 200781 fd Linux raid autodetect
/dev/sdb2 25 9038 9014 72404955 fd Linux raid autodetect
/dev/sdb3 0 - 0 0 0 Empty
/dev/sdb4 0 - 0 0 0 Empty
Disk /dev/sdc: 9039 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System
/dev/sdc1 * 0+ 24 25- 200781 fd Linux raid autodetect
/dev/sdc2 25 9038 9014 72404955 fd Linux raid autodetect
/dev/sdc3 0 - 0 0 0 Empty
/dev/sdc4 0 - 0 0 0 Empty
### MD RAID
# cat /proc/mdstat
Personalities : [raid1] [raid5]
md1 : active raid5 sdc2[2] sdb2[1] sda2[0]
144809472 blocks level 5, 256k chunk, algorithm 2 [3/3] [UUU]
md0 : active raid1 sdc1[2] sdb1[1] sda1[0]
200704 blocks [3/3] [UUU]
unused devices: none
### LVM
# pvs
PV VG Fmt Attr PSize PFree
/dev/md1 vg_md0 lvm2 a- 138.09G 0
# vgdisplay
--- Volume group ---
VG Name vg_md0
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 11
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 8
Open LV 8
Max PV 0
Cur PV 1
Act PV 1
VG Size 138.09 GB
PE Size 32.00 MB
Total PE 4419
Alloc PE / Size 4419 / 138.09 GB
Free PE / Size 0 / 0
VG UUID SheYak-jYvW-zW3D-s5Lr-1P4P-5B3c-8Penzj
# lvs
LV VG Attr LSize Origin Snap% Move Log Copy%
lv_backup vg_md0 -wi-ao 31.12G
lv_data vg_md0 -wi-ao 30.00G
lv_home vg_md0 -wi-ao 30.00G
lv_root vg_md0 -wi-ao 4.91G
lv_swap vg_md0 -wi-ao 5.88G
lv_tmp vg_md0 -wi-ao 1.97G
lv_usr vg_md0 -wi-ao 4.91G
lv_var vg_md0 -wi-ao 29.31G
jsem potřeboval přidat další tři disky (po 500G). Na lv_data prostě docházelo místo a na ostatních to nebylo jinak. Server jsem haltnul, přidal jsem disky a nabootoval.
Následující postup byl:
### vytvoření MD RAID
# mdadm -C /dev/md2 -l 5 -n 3 /dev/sd[def]
# cat /proc/mdstat
Personalities : [raid1] [raid5]
md2 : active raid5 sdd[0] sdf[2] sde[1]
976772992 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
md1 : active raid5 sdc2[2] sdb2[1] sda2[0]
144809472 blocks level 5, 256k chunk, algorithm 2 [3/3] [UUU]
md0 : active raid1 sdc1[2] sdb1[1] sda1[0]
200704 blocks [3/3] [UUU]
unused devices: none
# pvcreate /dev/md2
Physical volume "/dev/md2" successfully created
# vgextend vg_md0 /dev/md2
Volume group "vg_md0" successfully extended
# vgdisplay vg_m0
--- Volume group ---
VG Name vg_md0
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 12
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 8
Open LV 8
Max PV 0
Cur PV 2
Act PV 2
VG Size 1.04 TB
PE Size 32.00 MB
Total PE 34227
Alloc PE / Size 4419 / 138.09 GB
Free PE / Size 29808 / 931.50 GB
VG UUID SheYak-jYvW-zW3D-s5Lr-1P4P-5B3c-8Penzj
Všechno šlo jako nadrátku, takže můžu začít zvětšovat LVM logické svazky. No radši rebootuji abych měl jistotu, že je vše v pořádku.
A ouha ... Kernel panic : Can not mount root filesystem.V čem je chyba?
Kdo to najde první tomu pošlu virtuálního panáka ...
V pokračování popíšu proč se to stalo a jak se tomu vyhnout při instalaci nových serverů.
Tiskni
Sdílej:
Že by to fakt na holém disku bez partition typu fd nejelo...?
Dedukuji, že rootfs je na /dev/md0. Pak ale chybí zásadní informace, jestli se používá jaderná autodetekce raidu (jedna zastaralá a nedoporučovaná věc), nebo jestli se to staví ručně přes initrd (další zastaralá nedoporučovaná věc) nebo přes initramfs (jediná správné řešení), a v druhém/třetím případě, jak vypadají startovací skripty (které disky jsou zapojeny do scanu, jestli se pole identifikuje pres UUID atd.).
A ještě tu může být trapná chyba se zpřeházenými názvy disků, kdy jste si přepsal běžící systém.
Co je na jaderné autodetekci raidu špatného? Docela by mně to zajímalo - rád se přiučím něčemu novému. Initrd je dneska už opravdu staré a initramfs používám pouze v případě, kdy není schopen kernel získat informace o raidu právě tou autodetekci.
This approach can cause problems in several situations (imagine moving part of an old array onto another machine before wiping and repurposing it: reboot and watch in horror as the piece of dead array gets assembled as part of the running RAID array, ruining it); kernel autodetect is correspondingly deprecated.
Pak jsem ještě něco zahlédnul v jaderné dokumentaci.
no, z grubu se oboje nahrava jako initrd - jestli se da zaintegrovat initramfs do jadra, pak je to docela dobra featurka, nadruhou stranu se mi zda docela lepsi, ze pouze pregeneruju initrd image (at uz je to image na loopu nebo cpio), ale nemusim menit kernel. Oboje je ale nejaky maly system, ktery nastartuje zakladni veci a pak spusti hlavni init na pripojenem skutecnem root device. Takze si nejsem jistej, jaky by byl rozdil nahazovani RAID z initrd nebo z initramfs. V obojim by se to startoval zrejme pomoci mdadm a pak se nahodi VG a LV, pripoji a privot_rootem spusti system, nebo ne?
No, ja mel na mysli prave ten rozdil pri spousteni. A ten neni zadnej. Proste se nahraje do pameti, pripravi, spusti linuxrc, pripravi root system, prepne do nej a spusti init. At v initrd nebo v initramfs.
Mezi initrd a initramfs je výrazný rozdíl z hlediska toho, jak je to uděláno v jádře. V podstatě initramfs je integrální částí jádra a i když jej vědomě nepoužíváte, tak tam stále je (reliktem je záznam /dev/rootfs v /proc/mounts). Initramfs se nekopíruje dva krát (rychlejší boot), nespouští se z něj /linuxrc, ale /sbin/init, změna rootfs se už neprovádí přes chroot+pivot_root, ale přes switchroot (v podstatě smazání obsahu initramfs, chroot a exec těžkého /sbin/init), initramfs už nelze odmountovat.
Z hlediska správy je výhoda, že je to součástí obrazu jádra, takže řešíte jediný soubor. Taktéž výroba tohoto cpio archivu je v režii přímo kompilačního skriptu jádra, takže stačí make v /usr/src/linux a je to. Tím že se to vyrábí spolu s jádrem, tak máte jistotu, že se vám nebudou bít různé verze udevu busyboxu aj. s jaderným API.
Přečtete si k tomu jadernou dokumentaci k initramfs (je to tam pěkně popsáno).
Z hlediska sestavování diskového pole ten rozdíl proti initrd není. To jsem chtěl jen autora popíchnout, aby přestal používat zastaralé postupy.
To by mě opravdu zajímalo, proč k tomu došlo. Kdy se dočkáme toho slíbeného pokračování?