Firma X zaslala předžalobní výzvu vývojáři projektu Nitter (Wikipedia), open-source alternativního frontendu k sociální síti X (ex-Twitter), a provozovatelům instancí jako XCancel, které umožňovaly číst příspěvky bez přihlášení, reklam a javascriptu. Údajně se dopouštějí „sběru dat“. Zdrojový kód Nitteru vývojář archivoval. Vývoj již dříve přerušil v roce 2024 po tehdejším omezení API X. X je dceřiná společnost SpaceXAI Elona Muska, provozující mj. kontroverzního chatbota Grok.
Bylo vydáno Ubuntu 26.04.1 LTS, tj. první opravné vydání Ubuntu 26.04 LTS s kódovým názvem Resolute Raccoon. Přehled novinek a oprav na Discourse.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal Zprávu o stavu kybernetické bezpečnosti ČR za rok 2025 (pdf). Incidentů ubylo, sofistikovanost útočníků roste.
Open source softwarový stack AMD ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán v nové major verzi 10.0. S ROCm.AI. Přehled novinek v aktualizované dokumentaci.
Finanční skupina Partners se stala minulou neděli obětí kybernetického útoku, při kterém se útočníci dostali k některým osobním údajům klientů. Společnost o tom informovala ve čtvrtek. Ujišťuje, že peníze klientů nejsou v ohrožení. „Kybernetický útok zasáhl část IT infrastruktury naší společnosti. Ihned po zjištění útoku jsme s pomocí externích bezpečnostních odborníků začali intenzivně pracovat na minimalizaci škod. Útočníci se
… více »Americká technologická společnost Meta Platforms se dohodla, že zaplatí až zhruba 18 miliard dolarů (asi 373 miliard Kč) za mimosoudní urovnání sporu o závislosti dětí na sociálních sítích a provede významné změny pro jejich používání mladistvými. Téměř tři desítky států USA firmu v roce 2023 obvinily z toho, že sítě Facebook a Instagram vědomě navrhla tak, aby u dětí vyvolávaly závislost, a zatajovala tyto dopady před veřejností. Firma se
… více »Byl publikován aktuální přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Blíží se vydání podporující čipy M3. Vývojáře lze podpořit na GitHub Sponsors a Open Collective.
Kancelářský balík LibreOffice byl vydán ve verzi 26.8. Mimo jiné vylepšuje typografii a kompatibilitu s formáty MS Office, více v poznámkách k vydání.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 26.8. Přehled novinek v poznámkách k vydání.
Byla vydána nová verze 23.1.0, tj. první stabilní verze z nové řady 23.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools, Libc++, Polly a Flang.
Řešení dotazu:
Připadá mi, že tohle je spíš otázka pro placenou podporu jmenovaného closed-source paskvilu, který poškození způsobuje… A ta podpora by takovou otázku rozhodně dostávat měla, pokud možno co nejčastěji.
Je tam EFI, secure boot je vypnutý.
Off-topic, ale stejně si říkám, že je dobré to zmínit: S Fedorou bude Secure Boot bez problémů fungovat a může být i ve striktním režimu. Fedora používá svůj podepsaný "pre-boot-loader" zvaný shim, který ověří a načte GRUB atd., takže Secure Boot opravdu funguje a plní svůj účel. Není nutné ani žádoucí ho vypínat.
search.fs_uuid d190ed6d-c96b-4bf8-bfcb-c4ab052ebba9 root hd0,gpt5 set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg
tak pak je "jasne" ze Win ten cfg muzou smazat kdyz jim hrabne, tim ze je v EFI/FAT kam hrabou a muzou... root@NT-Olomouc:/boot/efi/EFI/ubuntu# ls fw fwupx64.efi grub.cfg grubx64.efi root@NT-Olomouc:/boot/efi/EFI/ubuntu# cat grub.cfg search.fs_uuid d190ed6d-c96b-4bf8-bfcb-c4ab052ebba9 root hd0,gpt5 set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg root@NT-Olomouc:/boot/efi/EFI/ubuntu#Podle mě právě zda si windows nemyslí že je FS toho efi oddílu poškozená a snaží se mazat ten link a kdoví jak to dopadá viz jeho FSCK0000.REC soubory kde jsou data z toho souboru grub.cfg
Ten súbor /boot/efi/EFI/ubuntu/grub.cfg ale nie je symlink, FAT používaný pre EFI zavádzanie nepodporuje symlinky.Přesně tak. Na tenhle soubor právě odkazuje symlink /etc/grub2-efi.cfg.
Vôbec by som sa nedivil keby sa jednalo o kombinované rozdelenie disku cez GPT, aj s kompatibilitou pre MBR ktorá nesedí. A niečo pri štarte alebo pripájaní disku odreže údaje z FAT za oblasťou disku keďže rozdelenie disku nie je v tomto probléme zhodné pri MBR a GPT.To je zajímavá teorie. Mám to takhle
GPT fdisk (gdisk) version 1.0.4 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sda: 976773168 sectors, 465.8 GiB Model: WDC WDS500G2B0A- Sector size (logical/physical): 512/512 bytes Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 976773134 Partitions will be aligned on 2048-sector boundaries Total free space is 2029 sectors (1014.5 KiB) Number Start (sector) End (sector) Size Code Name 1 2048 923647 450.0 MiB 2700 Basic data partition 2 923648 1128447 100.0 MiB EF00 EFI System Partition 3 1128448 1161215 16.0 MiB 0C01 Microsoft reserved ... 4 1161216 419842047 199.6 GiB 0700 Basic data partition 5 419842048 436619263 8.0 GiB 8200 6 436619264 976773119 257.6 GiB 8300Nevidím tady nic špatně. Navíc gdisk by myslím i vypsal, že se mu něco nelíbí. Nebo čím to ještě zkontrolovat?
V ubuntu taky mám v efi konfigurák grubu jenže v něm je pouze odkaz kde má hledat skutečný konfigurák....To by mi ale nic nevyřešlo, protože by to pak umázlo tenhle malý soubor ve kterém je odkaz na skutečný konfigurák.
V ubuntu taky mám v efi konfigurák grubu jenže v něm je pouze odkaz kde má hledat skutečný konfigurák....zvlastni, ja ho v dvou Ubuntu (18.04) nemam ani v jednomroot@NT-Olomouc:/boot/efi/EFI/ubuntu# ls fw fwupx64.efi grub.cfg grubx64.efi
root@t420s:/boot/efi/EFI/ubuntu# ls fw fwupx64.efi grubx64.efi
1) Dell Latitude 5280
2) GPT
3)
Device Start End Sectors Size Type /dev/sda1 2048 923647 921600 450M Windows recovery environment /dev/sda2 923648 1128447 204800 100M EFI System /dev/sda3 1128448 1161215 32768 16M Microsoft reserved /dev/sda4 1161216 419842047 418680832 199.7G Microsoft basic data /dev/sda5 419842048 436619263 16777216 8G Linux swap /dev/sda6 436619264 976773119 540153856 257.6G Linux filesystem / # ls -l /etc/grub2-efi.cfg lrwxrwxrwx. 1 root root 31 23. led 2018 /etc/grub2-efi.cfg -> ../boot/efi/EFI/fedora/grub.cfg / # findmnt /boot/efi TARGET SOURCE FSTYPE OPTIONS /boot/efi /dev/sda2 vfat rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro
Asi máš nějak divoce nastavené příznaky pro boot v EFI oddílu.
root@NT-Olomouc:/boot/efi# efibootmgr
BootCurrent: 0001
Timeout: 35 seconds
BootOrder: 0001,0000
Boot0000 Windows Boot Manager
Boot0001* ubuntu
Nenacpal jsi ty soubory do složky k windows skoukni přílohu tak to mám já a windows nic zatím nemažou.
/ # efibootmgr BootCurrent: 0001 Timeout: 2 seconds BootOrder: 0001,0004,0006,0007,0008,0009 Boot0000* Windows Boot Manager Boot0001* Fedora Boot0002* Diskette Drive Boot0003* Internal HDD Boot0004* USB Storage Device Boot0005* CD/DVD/CD-RW Drive Boot0006* Onboard NIC Boot0007* Diskette Drive Boot0008* Internal HDD Boot0009* CD/DVD/CD-RW Drive
/boot/efi # ls -l celkem 40 drwx------. 4 root root 1024 26. říj 15.00 df9cc9ab651b46dbb67eabd8d572930e drwx------. 6 root root 1024 9. lis 09.25 EFI -rwx------. 1 root root 1024 1. led 1980 FSCK0000.REC -rwx------. 1 root root 7168 1. led 1980 FSCK0001.REC -rwx------. 1 root root 7168 1. led 1980 FSCK0002.REC -rwx------. 1 root root 6144 1. led 1980 FSCK0003.REC -rwx------. 1 root root 1024 1. led 1980 FSCK0004.REC -rwx------. 1 root root 7168 1. led 1980 FSCK0005.REC -rwx------. 1 root root 7168 1. led 1980 FSCK0006.REC -rwx------. 1 root root 34 3. srp 2017 mach_kernel drwx------. 3 root root 1024 5. lis 2017 SystemJe vidět, že to má nějaké "nulové" datumy. To odkazuje na nějaký hodně jednoduchý "fsck" program, který si nedělá hlavu s tím pod jakým datem ty soubory zapíše. Takže se mi to jeví jako něco z toho EFI. Že by součástí bootu byl i nějaký "fsck". Ale stává se to jen tehdy když občas vlezu do Windows. A není to pokaždé. Jako by to bylo jen když je nějaká větší aktualizace Windows, která upraví něco v efi oddílu. Pak to možná pokazí až po rebootu něco v EFI. Jenže proč je to "vždycky" grub.cfg? To by znamenalo, že si "fsck" myslí, že chyba je v tom souboru grub.cfg.
Mám relativně malé disky (pod 2TB) a mám dost paměti takže nepotřebuji swap. Chci na nich tedy mít pouze jeden diskový oddíl s Btrfs v raid1. Jsou to SSD disky, takže nějaká geometrie disku nechraje vůbec žádnou roli. Data jsou stejně rozházená všude možně. V takové situaci místo GPT použiju MS-DOS tabulku a jádro pro GRUB2 instaluji na všechny disky, pro případ, že by jeden z nich chcípnul. Pokud bych chtěl bootovat přes UEFI, tak bych musel mít navíc jeden malý blbý diskový oddíl s tím nejstupidnějším FS co znám. Tak na jednu stranu si tady někdo hraje na bezpečnost a pak použije umístění tak důležitých souborů souborový systém FAT32, který sám o sobě není schopen detekovat, že se mu ztrácí data, a to až do chvíle, než něco najednou nepřestane bootovat. Není to paradox?Měl jsem při jeho psaní na zřeteli právě takovou situaci, do jaké jsi se dostal ty.
Ale stává se to jen tehdy když občas vlezu do Windows. A není to pokaždé. … Jenže proč je to "vždycky" grub.cfg? To by znamenalo, že si "fsck" myslí, že chyba je v tom souboru grub.cfg.Je to jen taková blbost, ale napadlo mě – jak edituješ ten grub.cfg v linuxu? V takovém případě by mohly widle (možná) vyhodnotit jako chybu, že ten soubor nemá korektní konce řádků Když na takový soubor koukneš z linuxu, tak má pak na konci ^M. Bohužel, pokud je to skutečně příčina problému, tak tomu neunikneš jinak, než že vypneš v MS Windows automatickou kontrolu disku kde sedí UEFI, jenže to absolutně netuším kde se dá udělat. Jde o to, že i kdybys ten soubor zeditoval přes MS Windows, tak ti to grub-mkconfig stejně při nejbližší aktualizaci přepíše.
Jo jsou tam Windows10 a do toho fastboot jsem nešahal, takže tam je.Rozmýšľam, či sa oplatí k tomu čokoľvek dodať. Asi už nie.
Dík, normálně funkční, ale ten fast boot se mi vypnout nepodařilo. 
Jo jsou tam Windows10 a do toho fastboot jsem nešahal, takže tam je.[...]
Jenže proč je to "vždycky" grub.cfg? To by znamenalo, že si "fsck" myslí, že chyba je v tom souboru grub.cfg.Muze to byt ten problematickej "win fast boot", protoze on si zahibernuje stav, ty/fedora to(grub.cfg) JINDE upravis a win pri pusteni/odfasthibernobani vidi/povazuje_za nekonzistenci a pusti na to svuj chkdsk nastroj...
Tiskni
Sdílej: