Стал у меня в начале (склероз: не этого, прошлого) года сбоить EVO870 на терабайт. Заметил по периодическим сбоям на ровном месте, оказывается — ошибки чтения. На нём была только сама ОС и игры, так что заменил без особых потерь. Симптомы простые — в нескольких местах на диске обнаружились локации, откуда ничего не читалось без ошибки. Т.е. никаких этих вот «ssd сбоит, но даёт прочитать хотя бы» — нет, тупо битые файлы, копирование виснет, а «187 Reported_Uncorrect» растёт как на дрожжах. Часть этих зон пришлась на файлы с играми, а некоторые на содержимое /usr. Но поскольку ничего ключевого затронуто не было, то я долго думал, что просто Steam лажает, например.

Если посмотреть SMART, то было примерно так:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   045   045   010    Pre-fail  Always       -       606
  9 Power_On_Hours          0x0032   098   098   000    Old_age   Always       -       9136
 12 Power_Cycle_Count       0x0032   098   098   000    Old_age   Always       -       1995
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       3
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   045   045   010    Pre-fail  Always       -       606
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   045   045   010    Pre-fail  Always       -       606
187 Reported_Uncorrect      0x0032   098   098   000    Old_age   Always       -       14609
190 Airflow_Temperature_Cel 0x0032   064   055   000    Old_age   Always       -       36
195 Hardware_ECC_Recovered  0x001a   199   199   000    Old_age   Always       -       14609
199 UDMA_CRC_Error_Count    0x003e   099   099   000    Old_age   Always       -       3
235 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       9
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       4293672984

Error 14609 occurred at disk power-on lifetime: 9135 hours (380 days + 15 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 90 69 47 40

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  e1 00 0f 00 00 00 40 00      01:22:44.593  IDLE IMMEDIATE
  ef 03 46 00 00 00 40 00      01:22:44.593  SET FEATURES [Set transfer mode]
  ef 02 00 00 00 00 40 00      01:22:44.593  SET FEATURES [Enable write cache]
  e1 00 02 00 00 00 40 00      01:22:44.593  IDLE IMMEDIATE
  ec 00 01 00 00 00 40 00      01:22:44.593  IDENTIFY DEVICE

Error 14608 occurred at disk power-on lifetime: 9135 hours (380 days + 15 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  00 51 01 10 00 00 00  Error:  at LBA = 0x00000010 = 16

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 08 00 90 69 47 00 00      01:22:44.005  READ FPDMA QUEUED
  60 08 00 88 69 47 00 00      01:22:44.005  READ FPDMA QUEUED
  60 08 00 80 69 47 00 00      01:22:44.005  READ FPDMA QUEUED
  60 08 00 78 69 47 00 00      01:22:44.005  READ FPDMA QUEUED
  60 08 00 70 69 47 00 00      01:22:44.005  READ FPDMA QUEUED

Error 14607 occurred at disk power-on lifetime: 9135 hours (380 days + 15 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  00 51 08 00 6a 47 40  Error:  at LBA = 0x00476a00 = 4680192

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 00 00 00 69 47 40 00      01:22:11.833  READ FPDMA QUEUED
  60 00 08 00 68 47 40 01      01:22:11.833  READ FPDMA QUEUED
  60 00 00 00 67 47 40 00      01:22:11.833  READ FPDMA QUEUED
  60 00 00 00 66 47 40 00      01:22:11.833  READ FPDMA QUEUED
  60 00 00 00 65 47 40 00      01:22:11.833  READ FPDMA QUEUED

Self-test execution status:      ( 121)	The previous self-test completed having
					the read element of the test failed.

...

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       80%      9137         10544288
# 2  Extended offline    Completed: read failure       90%      9137         10544288
# 3  Extended offline    Completed: read failure       90%      9136         10544288
# 4  Short offline       Completed: read failure       80%      9136         10544288
# 5  Short offline       Completed: read failure       80%      9136         10544288

smacker@Ideapad510 ~ $ sudo badblocks -v /dev/sdc
Checking blocks 0 to 976762583
Checking for bad blocks (read-only test): 5272132
5272144
5272145
5272146
5272147
5274296
5274297
5274298
5274299
5274516
5274517
5274518
5274519
5276096
5276097
5276098
5276099
5279436
...

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%      9139         -
# 2  Short offline       Completed without error       00%      9138         -
# 3  Short offline       Completed: read failure       80%      9137         10544288
# 4  Short offline       Completed: read failure       80%      9137         10544288
# 5  Extended offline    Completed: read failure       90%      9137         10544288
# 6  Extended offline    Completed: read failure       90%      9136         10544288
# 7  Short offline       Completed: read failure       80%      9136         10544288
# 8  Short offline       Completed: read failure       80%      9136         10544288

Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   045   045   010    Pre-fail  Always       -       606
  9 Power_On_Hours          0x0032   098   098   000    Old_age   Always       -       9139
 12 Power_Cycle_Count       0x0032   098   098   000    Old_age   Always       -       1996
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       4
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   045   045   010    Pre-fail  Always       -       606
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   045   045   010    Pre-fail  Always       -       606
187 Reported_Uncorrect      0x0032   098   098   000    Old_age   Always       -       15972
190 Airflow_Temperature_Cel 0x0032   070   047   000    Old_age   Always       -       30
195 Hardware_ECC_Recovered  0x001a   199   199   000    Old_age   Always       -       15972
199 UDMA_CRC_Error_Count    0x003e   099   099   000    Old_age   Always       -       3
235 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       10
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       6251131313

13 сентября без фанфар и барабанного боя вышла очередная, пятая по счёту, бета-версия OC Haiku. Однако совместимость её с BeOS R5 теперь сохраняется только в рамках 32-битных сборок.

( читать дальше... )

>>> Примечания к релизу

Адовый угар swatting-а докатился и до наших пенатов. На живущего в Германии разработчика линукса Рене Ребе кто-то натравил местную полицию. Неизвестно, что именно было написано в анонимном электронном письме, присланном на адрес полиции, но полиция тут же прислала наряд на квартиру Ребе и заковала его в наручники. Домой вернуться он смог только через час.

Ходят слухи, что это месть от любителей самого доброго, разумного и хорошего языка Rust, про включение которого в ядро линукса Ребе критически высказался на стриме до этого.

https://youtu.be/FIEwcTKUFCA

Попался мне в руки маленький свитч на гигабит, Mercusys MS105GS. Ну вот захотелось. И на третий день мне стало скучно и решил я посмотреть «что у ей внутре». Неонки не обнаружил, а обнаружил зато 5 нераспаянных пятачков в ряд на плате под интригующим обозначением J4. Вот так: https://imgur.com/a/MmTKwRT

Помню, у adsl-модема DSL-2500U я такие уже видел, и там к ним можно было подлючаться для доступа к консоли. И в целом раза три я пины на всяких девайсах от тп-линка под это распаивал. Но у меня-то в руках неуправляемый свитч, и там рулить-то нечем. Более того, на моделях типа SG1005D, где с помощью разных грязных хаков и тонкого паяльника таки можно внедрить управляемость, нет никаких разъёмов для консоли. А тут вот вроде как есть.

Что думаете?

Вот какие замечательные новости дошли до меня сегодня. Дуалбутчики всего мира были в августе осчастливлены мелкомятыми очередным «обновлением безопасности» (KB5041571 OS Build 26100.1457), которое поломало им загрузку линукса.

https://www.bleepingcomputer.com/news/microsoft/august-windows-security-updat...

https://forums.linuxmint.com/viewtopic.php?t=427297

https://askubuntu.com/questions/1523683/bootloading-ubuntu-24-04-iso-error-sb...

Arstechnica утверждает, что на разработку патчка было 2 (два, Карл!) года: https://arstechnica.com/security/2024/08/a-patch-microsoft-spent-2-years-prep...

И вроде как мелкомятые утверждают, что именно дуал бут ломаться не должен, но отзывы благодарных пользователей говорят об обратном. А простой набор из бритвы Оккама и классического вопроса «что делать» «cui prodest» вполне очевидно подталкивают нас к выводу, что это не баг обновления, а самая настоящая фича. Мы, конечно, давно знали, что все эти secure boot и tpm не нужны, но всё-таки как-то неприятно получилось.

«Совпадение? Не думаю.»

На старости лет открыл для себя контейнеры. Конкретно — LXC, конкретнее — совсем ванильный LXC, безо всякого LXD (ибо snap). И возник вопрос: а как по науке организовывать взаимодействие контейнеров со внешним миром, учитывая ограниченность «ванильного» решения? Для LXD, а тем более proxmox/docker/incus советов навалом, а про ванильные контейнеры как-то не особо.

Пока что мне на ум приходит только фиксирование IP за конкретными контейнерами через настройки LXC и создание правил файрволла для маршрутизации на основе тех же номеров портов средствами штатного файрволла системы, но тогда всё равно придётся дублировать порт-форвардинг на маршрутизаторе нормальной сети. Другой вариант — выставить контейнеры наружу через реальный физический интерфейс и сетевой мост, и всю переадресацию повесить уже на маршрутизатор сети, который им же и адреса назначит, и всё что нужно. Варианты с проксированием и macvlan — это уже из LXD.

По идее, даже в локальном применении правил файрволла нет ничего криминального, если принять аксиоматически, что контейнеры создаются с серьёзными целями: скажем, один и вполне конкретный — будет веб сервером, другой — торренты обслуживать, третий ещё что-то конкретное делать. И тогда нет проблем их всех «прибить гвоздями» через правила файрволла и статические ip в собственной локальной сетке, создаваемой LXC. Но всё-таки как-то гложет сомнение. А как «идеологически правильно» это сделать, в условиях, опять-таки, применения сугубо средств LXC и штатных средств ОС?

В общем, лорчик, суть такова: я осознал, что страдаю манией опингвинивать слабые компы. Вот прямо хочется взять какой-нибудь мини-пк на алике, или слабенький ноут по нижнему прайсу, и поставить на него линукс, чтобы смотреть и радоваться — как же хорошо получилось! Как же славно работает! На винде он бы помер, а под линуксом жив-живёхонек и сто лет проживёт! Смотрю уценку DNSа на предмет того, не попадётся ли там по дешёвке днищенское железо, а то руки чешутся что-то опингвинить. Вот недавно взял себе таким макаром 14 дюймовый недобук и опингвинил. Долго радовался. Сначала объяснял это себе, что мне нужен резервный ноутбук, который ничего особо не должен делать, кроме как помещаться в маленькую сумку и работать в течение часов 6-8. А сейчас понял, что хочу ещё. Как бороться с этой навязчивой идеей?

Пока мы помышляем о мировом господстве и ждём, со дня на день, пришествия обетованного Года Линукса на Десктопе, надо бы заиметь торжественную музыку на этот случай. Моё скромное предложение:

https://www.dropbox.com/scl/fi/mgu4ba5sa1m4c2qy092q1/Wenn-die-Pingvinen.mp3?r...

После нескольких дней, когда на зеркалах потихоньку стали появляться образы ISO для новой версии, проект Linux Mint официально объявил о выходе 22 версии дистрибутива (основан на Ubuntu 24.04) под собственным названием «Вилма».

Из новшеств разработчики отмечают улучшение поддержки различных языков, переход на 6 версию ядра (для начала 6.8), pipewire для звука (но, конечно, можно откатиться и к pulseaudio), темы оформления стали поддерживать GTK4, добавлена поддержка формата DEB822, улучшена поддержка HiDPI-дисплеев во время загрузки.

( читать дальше... )

>>> Сайт дистрибутива Linux Mint

Ото кака фигня, малята: https://mathstodon.xyz/@bremner/112615591101488528

systemd-tmpfiles, deleting /home

TIL (thankfully second hand) that running «systemd-tmpfiles --purge» will delete /home in systemd 256 [1]. Apparently if you think linux is mainly for running cloud services, this seems reasonable to you. Or something.

[1] tested with systemd-tmpfiles --dry-run --purge on debian. I guess it _could_ be a Debian addition, but I'm guessing not.

4 июня стабильная 14 версия FreeBSD получила своё первое обновление.

( читать дальше... )

https://www.FreeBSD.org/releases/14.1R/relnotes/
https://www.FreeBSD.org/releases/14.1R/errata/

>>> Подробности

Потихоньку-полегоньку, несколько дней назад вышел релиз 9.4 проекта Rocky Linux — дистрибутива, организованного Грегори Курцером в ответ на прекращение классических релизов CentOS и переход к CentOS Stream. Грегори Курцер, будучи разработчиком CentOS, решил начать всё заново, и запустил проект Rocky Linux, который должен был делать всё то же самое, что раньше делал CentOS, но теперь уже отдельно от Red Hat.

( читать дальше... )

>>> Официальный анонс релиза

Тихо и незаметно вышла версия 9.8.0 менеджера архивов PeaZip. В новой версии добавлена функция избирательного извлечения отдельных файлов из архива в конкретные локации в закладках и т.д. напрямую, без дополнительных телодвижений. Была добавлена пара тем оформления, подчищен код, и проект был переведён на компиляцию с помощью Lazarus 3.2, хотя должен по-прежнему собираться и версиями 2.х, что должно обрадовать ценителей языка Паскаль. Была сделана пара улучшений интерфейса и исправлено три бага.

В остальном же PeaZip по-прежнему остаётся свободным и кросс-платформенным гибридом многофункционального менеджера архивов и полноценного файлового менеджера с поддержкой 234 типов файлов, шифрования данных, тем оформления, и переведённый на 30 языков. Он может оказаться очень сподручным инструментом для тех, кому в силу рабочих обязанностей или жизненных обстоятельств приходится регулярно иметь дело с зоопарком архивных файлов.

>>> Подробности

1 мая вышла версия 9.4 дистрибутива RHEL. По утверждениям компании, упор в нём сделан на облегчение работы и управления облачными вычислениями, в т.ч. с вовлечением ИИ, и на автоматизацию различных процессов. По своей задумке, так они пытаются отвечать чаяниям большей части своих клиентов, 88% из которых отметили в последнее время резкий рост сложности своих вычислительных систем и управления ими.

( читать дальше... )

>>> Подробности на DistroWatch

Как сообщает блог It's FOSS, в свежей долгоиграющей Убунте обнаружилась странная особенность: как будто по недосмотру, в рамках DE пакеты DEB перестали быть по умолчанию ассоциированы с какой-либо программой для их установки. При этом даже если выбрать «открыть в App Center» (а ничего другого подходящего там и нет) через контекстное меню, App Center просто зависает и не позволяет ничего сделать с пакетом.

И это не первая ласточка: начиная с 20.04 действием по умолчанию для DEB пакетов оказалось открытие в менеджере архивов, каковое положение вещей сохраняется и по сию пору по крайней мере в режиме Live OS (см. скриншот). А аналогичная нынешней ситуация воспроизводилась ещё в 23.10, но только сейчас оказалсь «канонизирована» в рамках релиза LTS, хотя вопрос был поднят в виде баг-репорта к 23.10 уже более полугода назад. Но с точки зрения Canonical, это вопрос крайне неприоритетный, и в рамках релиза LTS 24.04 решать они его не собираются. «Живите теперь с этим» фактически является официальной позицией — как пояснил один из разработчиков, к решению этой «фундаментальной проблемы» они обратятся только «в следующем цикле» в силу якобы нехватки ресурсов для её решения прямо сейчас.

Возникает логичное объяснение случившемуся: это ничто иное как очередное свидетельство того, что Canonical взяли курс на отказ от построения системы вокруг DEB пакетов в пользу Snap. И делая установку DEB пакетов ещё несколько более муторной для пользователя (само собой, можно поставить ту же gdebi и привязать к ней действие по умолчанию для DEB пакетов — но это нужно делать специально; ну и, конечно, установка через apt в терминале по-прежнему работает), они постепенно «отучают» пользователей от использования DEB, создавая искусственные неудобства с ними на пустом месте.

Скриншот: www.linux.org.ru/images/21237/original.png

Подробности на It's FOSS: https://news.itsfoss.com/ubuntu-24-04-disappointment/

Подробности на «It's FOSS»


Перемещено hobbit из ubuntu

У многих из нас нет привычки выбрасывать старые ПК, и некоторые могут достать из закромов устройства, которые застали живым даже Андропова. Однако каков же сборный портрет самого «дохленького» компьютера, на котором благодаря Линуксу ещё теплится жизнь в привычном нам понимании? Давайте попробуем это узнать!

Под «работает» будем понимать возможность зайти на ЛОР, хотя бы и в текстовом браузере. Если компьютер может это, то и другие полезные вещи тоже осилит. Под «в распоряжении» будем подразумевать готовность к эксплуатации: взять с полки, подключить к сети (в обоих смыслах), включить. Если компьютер теоретически можно собрать из деталей в коробке под столом — не считается. Если на компьютер можно гипотетически установить Linux, но его там нет — не считается. Если за ним надо ехать на дачу тёщи в Псковскую область и искать в погребе между соленьями — не считается. Если это виртуальная машина или удалённый сервер — не считается.

К сожалению, я и так развёл много категорий, так что конкретные модели процессоров, частоты, типы памяти, размеры экрана и т.п. подробности можно обозначить в комментариях.

Чота я запарился искать такую штуковину. Мне б в файлопомойку на атоме не помешало добавить USB 3 (раз уж eSATA/eSATAp склеили ласты), но все контроллеры на PCIe, а там как раз один слот обычного PCI. А специального идентификатора для «обычного» PCI просто нет, так что при поиске никак не отделить зёрна от плевел, а агнцев от козлищ, и на том же али меня заваливает контроллерами на PCIe, если там и есть что на PCI, так мне этого никак не раскопать. А они вообще есть? Может, я зря ищу-то?

Настал момент такой, что надо бы поменять термопасту в паре мест. И вроде как есть остатки MX-4, который умудрился не засохнуть за 10 лет, так что по идее могу и на дедовских запасах, так сказать, прожить. Но решил почитать, что нонча пишуть в антернетах. И к каждой второй, если не первой, термопасте постоянно претензии — густая, плохо липнет, трудно намазывается и т.д. и т.п.
А я, стало быть, от жизни-то отстал. Не знаю, как оно чё нынче. Чем таперича принято мазать бутерброд проц? Нормально ли (и правда ли), что все через одну термопасты нынче густые, и даже MX-5 уже не торт?

К текстовому редактору (конечно же, vim) или imagemagick-у в консоли все привыкли, этим никого особо не удивишь. Аналогично, moc или calcurse тоже, наверное, нельзя назвать неожиданным поворотом мысли. А вот какие программы приходят вам на ум, если нужно называть самые необычные/неожиданные/удивительные варианты? В духе «вот уж не ожидал, что кто-то такое всерьёз напишет, а потом этим ещё и можно будет пользоваться»?

У меня это sc-im (vim-подобные электронные таблицы) и visidata (верный друг дата-сайентолога).

Хочу странного: определить концептуальный тип накопителя, подключенного по USB (флешка, карта памяти, внешний жёсткий диск, внешний ssd, оптический привод). Уповал на ROTA в lsblk для разделения внешних жёстких и флешек, но он, подлец, рапортует «1» для всех USB устройств, и т.о. работает только для локальных SATA/PATA приводов. Можно в lsblk задетектить rom через тип устройства, и т.о. определить оптический привод, но неизвестно, насколько надёжно, но пока пусть будет так. Остальные устройства друг от друга ничем вроде бы не отличаются. Идея угадывать (читай: регекспами) по названию девайса мне кажется изначально порочной. Есть какой-нибудь способ это сделать по-человечески (и без привилегий рута)?

UPD: отличать оптику/hdd/ssd можно через специфические записи в выводе udevadm info. С флешками и картами памяти в кард-ридерах сложнее. Кроме того, lsblk помечает внешние usb диски как несъёмные, так что нужно ориентироваться на HOTPLUG.