Dle plánu byl vývoj Firefoxu přesunut z Mercurialu na Git. Oficiální repozitář se zdrojovými kódy je na GitHubu.
V terminálovém multiplexoru GNU Screen byly nalezeny a v upstreamu ve verzi 5.0.1 už opraveny bezpečnostních chyby CVE-2025-23395, CVE-2025-46802, CVE-2025-46803, CVE-2025-46804 a CVE-2025-46805. Podrobnosti na blogu SUSE Security Teamu.
Training Solo (Paper, GitHub) je nejnovější bezpečnostní problém procesorů Intel s eIBRS a některých procesorů ARM. Intel vydal opravnou verzi 20250512 mikrokódů pro své procesory.
Byla vydána nová verze 25.05.11 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Svobodný elektronický platební systém GNU Taler (Wikipedie, cgit) byl vydán ve verzi 1.0. GNU Taler chrání soukromí plátců a zároveň zajišťuje, aby byl příjem viditelný pro úřady. S vydáním verze 1.0 byl systém spuštěn ve Švýcarsku.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 209. brněnský sraz, který proběhne tento pátek 16. května od 18:00 ve studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Jelikož se Brno stalo jedním z hlavních míst, kde se vyvíjí open source knihovna OpenSSL, tentokrát se OpenAlt komunita potká s komunitou OpenSSL. V rámci srazu Anton Arapov z OpenSSL
… více »GNOME Foundation má nového výkonného ředitele. Po deseti měsících skončil dočasný výkonný ředitel Richard Littauer. Vedení nadace převzal Steven Deobald.
Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Dobrý den,
četl jsem slova chvály na tento systém a prý cituji: "ext2 či ext3 je ze všech šitů futrál." Vyzkoušel jsem reiserfs na 640GB harddisku.
Nevím proč, ale po 5 minutách intenzivní práce mi zhavaruje kernel. Že by nepodporoval tak velké disky? Máte někdo nějaký nápad jak učinit reiserfs stabilní?
děkuji J.F.
Jan 18 20:32:30 F&T kernel: ------------[ cut here ]------------
Jan 18 20:32:30 F&T kernel: Kernel BUG at b01b35e3 [verbose debug info unavailable]
Jan 18 20:32:30 F&T kernel: invalid opcode: 0000 [#1]
Jan 18 20:32:30 F&T kernel: SMP
Jan 18 20:32:30 F&T kernel: Modules linked in: ntfs sis900 ipv6 it87 hwmon_vid i2c_isa i2c_core tulip bitrev atl1 crc32 mii agpgart lp parport_pc parport
Jan 18 20:32:30 F&T kernel: CPU: 1
Jan 18 20:32:30 F&T kernel: EIP: 0060:[<b01b35e3>] Not tainted VLI
Jan 18 20:32:30 F&T kernel: EFLAGS: 00010246 (2.6.21.5 #11)
Jan 18 20:32:30 F&T kernel: EIP is at reiserfs_read_bitmap_block+0x153/0x160
Jan 18 20:32:30 F&T kernel: eax: 00000000 ebx: f0864858 ecx: babda000 edx: babd9ffc
Jan 18 20:32:30 F&T kernel: esi: 00000000 edi: ba59e13c ebp: 00002a16 esp: e7f23bf4
Jan 18 20:32:30 F&T kernel: ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Jan 18 20:32:30 F&T kernel: Process mc (pid: 1530, ti=e7f22000 task=e8185030 task.ti=e7f22000)
Jan 18 20:32:30 F&T kernel: Stack: bc4c0818 00000000 b1157b20 00000001 f085a000 00000060 00002a16 e7f23cf4
Jan 18 20:32:30 F&T kernel: 00001ffc b01b3aa1 00000000 0000000f 00000003 00002a16 e7f23ecc eef22000
Jan 18 20:32:30 F&T kernel: f0864858 00000000 013d8000 00000001 00002a16 00000015 00001ffc b01b44b8
Jan 18 20:32:30 F&T kernel: Call Trace:
Jan 18 20:32:30 F&T kernel: [<b01b3aa1>] scan_bitmap_block+0x51/0x2d0
Jan 18 20:32:30 F&T kernel: [<b01b44b8>] reiserfs_allocate_blocknrs+0x798/0x12a0
Jan 18 20:32:30 F&T kernel: [<b01c24be>] reiserfs_file_write+0x99e/0x1e40
Jan 18 20:32:30 F&T kernel: [<b013c5da>] clocksource_get_next+0x3a/0x40
Jan 18 20:32:30 F&T kernel: [<b014f047>] do_generic_mapping_read+0x687/0x8c0
Jan 18 20:32:30 F&T kernel: [<b0136a30>] autoremove_wake_function+0x0/0x40
Jan 18 20:32:30 F&T kernel: [<b0297dba>] tty_write+0x22a/0x2e0
Jan 18 20:32:30 F&T kernel: [<b01a5d6d>] dnotify_parent+0x3d/0x120
Jan 18 20:32:30 F&T kernel: [<b01c1b20>] reiserfs_file_write+0x0/0x1e40
Jan 18 20:32:30 F&T kernel: [<b0170480>] vfs_write+0xf0/0x1c0
Jan 18 20:32:30 F&T kernel: [<b0170611>] sys_write+0x41/0x70
Jan 18 20:32:30 F&T kernel: [<b0102e34>] syscall_call+0x7/0xb
Jan 18 20:32:30 F&T kernel: =======================
Jan 18 20:32:30 F&T kernel: Code: c7 44 24 08 a0 e0 3e b0 c7 44 24 04 cc 51 43 b0 e8 63 81 01 00 eb 8e 0f 0b eb fe 8b 02 8b 40 0c 83 c0 01 8d 1c 28 e9 e7 fe ff ff <0f> 0b eb fe 0f 0b eb fe 90 8d 74 26 00 55 89 cd 57 56 53 83 ec
Jan 18 20:32:30 F&T kernel: EIP: [<b01b35e3>] reiserfs_read_bitmap_block+0x153/0x160 SS:ESP 0068:e7f23bf4
Jan 18 20:32:30 F&T kernel: BUG: at kernel/exit.c:861 do_exit()
Jan 18 20:32:30 F&T kernel: [<b01226c7>] do_exit+0x667/0x850
Jan 18 20:32:30 F&T kernel: [<b01048c7>] die+0x237/0x240
Jan 18 20:32:30 F&T kernel: [<b0104ed0>] do_invalid_op+0x0/0xb0
Jan 18 20:32:30 F&T kernel: [<b0104f72>] do_invalid_op+0xa2/0xb0
Jan 18 20:32:30 F&T kernel: [<b01b35e3>] reiserfs_read_bitmap_block+0x153/0x160
Jan 18 20:32:30 F&T kernel: [<b01951a2>] __find_get_block_slow+0x82/0x100
Jan 18 20:32:30 F&T kernel: [<b03e5502>] io_schedule+0x22/0x30
Jan 18 20:32:30 F&T kernel: [<b0195385>] sync_buffer+0x35/0x40
Jan 18 20:32:30 F&T kernel: [<b03e5cd8>] __wait_on_bit+0x88/0xe0
Jan 18 20:32:30 F&T kernel: [<b0195350>] sync_buffer+0x0/0x40
Jan 18 20:32:30 F&T kernel: [<b0195350>] sync_buffer+0x0/0x40
Jan 18 20:32:30 F&T kernel: [<b03e5dd8>] out_of_line_wait_on_bit+0xa8/0xc0
Jan 18 20:32:30 F&T kernel: [<b03e706c>] error_code+0x7c/0x84
Jan 18 20:32:30 F&T kernel: [<b01b35e3>] reiserfs_read_bitmap_block+0x153/0x160
Jan 18 20:32:30 F&T kernel: [<b01b3aa1>] scan_bitmap_block+0x51/0x2d0
Jan 18 20:32:30 F&T kernel: [<b01b44b8>] reiserfs_allocate_blocknrs+0x798/0x12a0
Jan 18 20:32:30 F&T kernel: [<b01c24be>] reiserfs_file_write+0x99e/0x1e40
Jan 18 20:32:30 F&T kernel: [<b013c5da>] clocksource_get_next+0x3a/0x40
Jan 18 20:32:30 F&T kernel: [<b014f047>] do_generic_mapping_read+0x687/0x8c0
Jan 18 20:32:30 F&T kernel: [<b0136a30>] autoremove_wake_function+0x0/0x40
Jan 18 20:32:30 F&T kernel: [<b0297dba>] tty_write+0x22a/0x2e0
Jan 18 20:32:30 F&T kernel: [<b01a5d6d>] dnotify_parent+0x3d/0x120
Jan 18 20:32:30 F&T kernel: [<b01c1b20>] reiserfs_file_write+0x0/0x1e40
Jan 18 20:32:30 F&T kernel: [<b0170480>] vfs_write+0xf0/0x1c0
Jan 18 20:32:30 F&T kernel: [<b0170611>] sys_write+0x41/0x70
Jan 18 20:32:30 F&T kernel: [<b0102e34>] syscall_call+0x7/0xb
Jan 18 20:32:30 F&T kernel: =======================
Jan 18 20:39:52 F&T kernel: sanitize start
Jan 18 20:39:52 F&T kernel: sanitize end
Disk je uplne novy, testoval jsem ho a to same jsem delal s NTFS, kde se data sypala bez chyb. Ze by nejaka jina komponenta byla vadna je nepravdepodobne, na tomto pocitaci jsem uz zkompiloval gigabajty nesmyslu, pouze SATA disk jsem dosud pripojen nemel.
A z logu padu to spise vypada na chybu v reiserfs. No co, testnu jeste ext2 a tim vyloucim (nebo potvrdim) chybu v HW.
pouze SATA disk jsem dosud pripojen nemel
Tam asi bude pes zakopaný - nesprávny driver na SATA v linuxovom jadre, alebo disk v BIOSe prepnutý na AHCI (v súvislosti s NTFS predpokladám, že tam kdesi na počítači sídlia aj MS Windows, ktoré to cez AHCI vedia lepšie predýchať).
Bohuzel/bohudik ne.
EXT2 funguje naprosto bez problemu pri stejne konfiguraci.
Vypada to na chybu v reiserfs. Kdyz zmenim velikost alokacni jednotky, tak k chybe vubec nedojde a vsechno je OK (kolem takoveho filesystemu s bugem je lepe chodit po spickach). Netusite alespon, kam to nareportovat?
www.namesys.com je KO.
Netusite alespon, kam to nareportovat? www.namesys.com je KO.Edward Šiškin ?
Vzali to jako bug:
----------------------------------------------------------------------------------------------
Od: Edward Shishkin <edward.shishkin(AT)gmail(DOT)com>
Hello Jaroslav,
would you please check your partition with fsck,
and, please, upgrade the kernel, if possible.
Jeff, it seems to be BUG_ONs in the old on-demand
bitmap loading code?
Edward.
> Dears,
>
> please help me how to avoid this bug. It occurs on kernel 2.6.21.5
> on HDD with size 640GB and sector size 1kB.
>
> When sector size is set to 512B the drive cannot be mounted and a driver writes
> invalid float exception.
>
> 2kB block size seems to work OK - but a bug is still present here until gets fixed.
----------------------------------------------------------------------------------------------
Dekuji za pripominky. Posledni verze reiserfsprogs-3.6.21 pise varovani pro vsechny bloky ruzne od 4096. Asi vedi proc. Bohuzel tahle verze neni prilis rozsirena http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/a8f2654af533bd52/8b3287ffe54de360?show_docid=8b3287ffe54de360
Takze pri velikosti bloku 4096 budu mit pokoj. Holt zvyk je zelezna kosile a pamatuji se jak jsem ztratil na HDD u velkych sektoru i 50% kapacity, jo to byl fat 16 a 2GB disky s 32kB sektory. U reiserfs zda se, ze velikost bloku jeste neznamena pouziti celeho bloku na jeden soubor. Takze nepotrebuji jinou velikost bloku nez defaultni.
int block_size_ok (int blocksize, int force)
{
int pagesize = getpagesize();
if (blocksize > 4096) {
reiserfs_warning (stderr, "Block sizes larger than 4k are not "
"supported on all architectures.\n");
if (blocksize > pagesize)
reiserfs_warning (stderr, "The newly created filesystem will not "
"be mountable on this system.\n");
else
reiserfs_warning (stderr, "The newly created filesystem may not "
"be mountable on other systems.\n");
check_forcing_ask_confirmation (force);
} else if (blocksize < 4096) {
reiserfs_warning (stderr, "Block sizes smaller than 4k "
"are not supported.\n");
return 0;
}
return 1;
}
Tohle mi odpovedel Shishkin. Zda se, ze nejaky saboter v namesysu povolil nestabilni kod :(
---------------------------------------------------------------------------
>
http://bugzilla.kernel.org/show_bug.cgi?id=9108
Reiserfs has never worked properly with small blocksizes, and it was
unpleasant surprise when I saw that it is enabled again in
reiserfsprogs-3.6.19.
IMHO there is no chances to make reiserfs work with 512K blocks.
Other cases should be carefully debugged. Put in longterm todo.
Edward.
Tiskni
Sdílej: