systemd /etc/init.d

2018-03-12 Пенетрантность sergio

Добавил в /etc/init.d файлик, написал в нём:
Default-Start: 2 3 4 5
потом сказал
# update-rc.d файлик defaults
бутнулся, сервис запущен, systemctl его показывает!

потом поменял ту строчку на
Default-Start: S
# update-rc.d файлик remove
# update-rc.d файлик defaults
бутнулся, сервис НЕ запущен, systemctl его НЕ показывает!


https://www.debian.org/doc/manuals/debian-reference/ch03.en.html
systemd offers backward compatibility features. SysV-style boot scripts
in "/etc/init.d/rc[0123456S].d/[KS]" are still parsed and
  !!!^^^!!!
telinit(8) is translated into systemd unit activation requests.

На какой пакет баг рисовать?

-- 
sergio



Re: internet radio pleer

2018-03-12 Пенетрантность sergio
On 13/03/18 04:07, sergio wrote:

> А как туда поток добавить?
> 
> % mpd add "https://...pls;
> exception: too many arguments
> 
> % mpd add http://...aac
> exception: too many arguments

mpd->mpc, буковкой ошибся


-- 
sergio



Re: internet radio pleer

2018-03-12 Пенетрантность sergio
On 13/03/18 03:15, D. H. wrote:
> On 12/03/18 06:18 PM, sergio wrote:
>> А как слушать интернет радио из консоли вечно?
> 
> mpd
> 

А как туда поток добавить?

% mpd add "https://...pls;
exception: too many arguments

% mpd add http://...aac
exception: too many arguments



-- 
sergio



Re: internet radio pleer

2018-03-12 Пенетрантность D. H.
On 12/03/18 07:20 PM, Aleksey wrote:
>> mpd
>>
> 
> Он так же затыкается, если пропадает интернет. Или это можно как-то
> починить? Кэш немного не то, он спасает только от кратковременных
> отключений интернета.
> 

Раз в сутки провайдер мне меняет адрес, соответственно соединение
отваливается. Однако я не заметил по утрам чтобы у меня радио
переставало работать. Настройки дефолтные. В плейлисте только одно
радио. Стоит воспроизводить плейлист по кругу.



Re: internet radio pleer

2018-03-12 Пенетрантность sergio
On 13/03/18 02:57, Иван Лох wrote:

> Можно поиграться с увеличением --network-timeout и размером кэша
> --cache-secs= --cache=

Кэш это хрень, а вот network-timeout да, помогает при _недолгом_
отключении линка.  то есть с network-timeout он перезапускается
и продожает играть, но перезапускается всего один раз,
а с --loop-playlist ТРИ раза

О, я знаю как надо!:
while true; do mpv --network-timeout=2 stream; done

Кстати, уже есть баг на тему:
https://github.com/mpv-player/mpv/issues/1077

P.S. если у кого есть желание воспроизвести проблему: ifdown/up eth0

-- 
sergio



Re: internet radio pleer

2018-03-12 Пенетрантность Aleksey

13.03.2018 03:15, D. H. пишет:

On 12/03/18 06:18 PM, sergio wrote:

А как слушать интернет радио из консоли вечно?


mpd



Он так же затыкается, если пропадает интернет. Или это можно как-то 
починить? Кэш немного не то, он спасает только от кратковременных 
отключений интернета.




Re: internet radio pleer

2018-03-12 Пенетрантность Иван Лох
On Tue, Mar 13, 2018 at 02:18:08AM +0300, sergio wrote:
> А как слушать интернет радио из консоли вечно?
> 
> Сейчас вот играет mpv, но при проблемах с сетью он ломается, замирает,
> перестаёт играть и приходится перезапускать его руками.

Можно поиграться с увеличением --network-timeout и размером кэша
--cache-secs= --cache=



internet radio pleer

2018-03-12 Пенетрантность sergio
А как слушать интернет радио из консоли вечно?

Сейчас вот играет mpv, но при проблемах с сетью он ломается, замирает,
перестаёт играть и приходится перезапускать его руками.

-- 
sergio



Re: Опечатки в переводе

2018-03-12 Пенетрантность Lev Lamberov
Пн 12 мар 2018 @ 17:40 "" :

> https://www.debian.org/News/2018/20180310
> directfb "основе архитектуре" -> "основе архитектуры"
> xrdp "ЦА" -> "ЦП"

Исправил. Спасибо!


Re: Краткий обзор систем резервного копирования

2018-03-12 Пенетрантность yuri . nefedov

On Mon, 12 Mar 2018, Eugene Berdnikov wrote:


On Mon, Mar 12, 2018 at 08:07:14PM +0800, yuri.nefe...@gmail.com wrote:

Victor Wagner -> debian-russian@lists.debian.org  @ Mon, 12 Mar 2018
11:59:09 +0300:
...

Лет десять назад именно Артем Чуприна научил меня пользоваться
rsnapshot. Поэтому полагаю, что под дедупликацией он имеет в виду
что-то другое, чего rsnapshot не умеет.

...
On Mon, 12 Mar 2018, Artem Chuprina wrote:


Exactly. В смысле, чего rsync не умеет. А он не умеет ни если файл
переместился, ни если у него изменилась метаинформация. И если второе ???
это ограничение вообще конструкции хардлинков (и правильно, что не
умеет, хотя на задаче бэкапа тоже хочется уметь), то первое (тоже
правильно, что не умеет, но по другой причине) временами хочется и
подправить. Когда на бэкап-клиенте :) большое поддерево переместили или
хотя бы переименовали директорию верхнего уровня, не говоря уже о
несколько более содержательной реорганизации.



  Вообще говоря всё это unison умеет. Принцип работы как у rsync,
  а синхронизацию в обратную сторону можно и запретить.


Unison не умеет ни хардлинки, ни симлинки. Может, я что-то проспал и
месяц или два назад он всему научился, но предыдущие 8 лет активного
его использования это представляло проблему. Да, unison наконец начал
понимать, что файл куда-то переместили без изменений (случилось это,
как мне кажется, полгода-год назад), он уже не качает переименованный
каталог заново, но до возможностей rsync ему ещё очень далеко.


  Хардлинки не умеет, это да, тут я поспешил.
  А симлинки всегда мог, за исключением  ntfs, где не умеет.
  Я им уже лет пять пользуюсь и перемещение файлов и папок
  он отслеживает, за что и понравился. Ну иногда тупит бывает,
  но это если его просить еще свой бекап файлов создавать.


  Правда, для полноценного бекапа как то стрёмно его пробовать.
  А вот для рабочих папок, где всякие перемещения, переименования
  и т.п. обычное дело, самое то.


Для бэкапа unison вообще не предназначен. Это средство синхронизации
с возможностью сохранять старые версии изменённых файлов.

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


  Да согласен я, согласен. Только чаше бывает, что из всего этого
  дерева нужен один файл, а время и даже название из дырявой головы
  уже утекли...
  Тут скорее что-то типа time machine маковской подошло бы.

Ю.

Re: не грузится предыдущий Debian с соседнего раздела

2018-03-12 Пенетрантность Andrey Jr. Melnikov
Gali Anikina  wrote:

[...]

> А кстати почему сейчас нет пункта в установщике "Сделать загрузочную 
> дискету с ядром"? Вот в таких ситуациях она очень помогла.
Такая дискета называется - любая флешка + образ mini.iso/netinstall.iso
При наличии винды - YUMI + любой iso.

> Помню, давным-давно, в Slackware такое было и оно очень удобно для таких 
> случаев (достаточно часто спасало в таких ситуациях + lilo). А в Debian 
> это не делается ещё на этапе установки системы (или может такой пункт 
> там есть, но запрятан далеко), а потом, когда установится система этот 
> вопрос ещё надо изучать и делать - если не закрутишься дальше по жизни и 
> забудешь о том, что надо своевременно сделать спасительную дискету.
Инсталлер умеет rescue mode.

> Может быть имел бы смысл по умолчанию предлагать ещё тогда - при 
> установке - сделать по выбору пользователя или FDD или USB или CD/DVD 
> такой диск?
Хм, а музей для утыривания оттудова FDD/CD/DVD рядом есть? Ну или хоть
помоечка.

> В посление разы -проходя с трудом через загрузку, в момент когда 
> происходит изменение разрешения в консоле (подключается графический 
> драйвер drm amdgpu kernel modesetting enabledati), в консоли появляется 
> чёрный экран и тишина ..
Дык, с amd никто и не обещал счастливой жизни. 

[...]

> Есть какие идеи?
Ядро какое?




Re: Краткий обзор систем резервного копирования

2018-03-12 Пенетрантность Eugene Berdnikov
On Mon, Mar 12, 2018 at 08:07:14PM +0800, yuri.nefe...@gmail.com wrote:
> Victor Wagner -> debian-russian@lists.debian.org  @ Mon, 12 Mar 2018
> 11:59:09 +0300:
> ...
> >> Лет десять назад именно Артем Чуприна научил меня пользоваться
> >> rsnapshot. Поэтому полагаю, что под дедупликацией он имеет в виду
> >> что-то другое, чего rsnapshot не умеет.
> ...
> On Mon, 12 Mar 2018, Artem Chuprina wrote:
> >
> >Exactly. В смысле, чего rsync не умеет. А он не умеет ни если файл
> >переместился, ни если у него изменилась метаинформация. И если второе ???
> >это ограничение вообще конструкции хардлинков (и правильно, что не
> >умеет, хотя на задаче бэкапа тоже хочется уметь), то первое (тоже
> >правильно, что не умеет, но по другой причине) временами хочется и
> >подправить. Когда на бэкап-клиенте :) большое поддерево переместили или
> >хотя бы переименовали директорию верхнего уровня, не говоря уже о
> >несколько более содержательной реорганизации.
> >
> 
>   Вообще говоря всё это unison умеет. Принцип работы как у rsync,
>   а синхронизацию в обратную сторону можно и запретить.

 Unison не умеет ни хардлинки, ни симлинки. Может, я что-то проспал и
 месяц или два назад он всему научился, но предыдущие 8 лет активного
 его использования это представляло проблему. Да, unison наконец начал
 понимать, что файл куда-то переместили без изменений (случилось это,
 как мне кажется, полгода-год назад), он уже не качает переименованный
 каталог заново, но до возможностей rsync ему ещё очень далеко.

>   Правда, для полноценного бекапа как то стрёмно его пробовать.
>   А вот для рабочих папок, где всякие перемещения, переименования
>   и т.п. обычное дело, самое то.

 Для бэкапа unison вообще не предназначен. Это средство синхронизации
 с возможностью сохранять старые версии изменённых файлов.

 Бэкап это то, из чего можно восстановить дерево каталогов по состоянию
 на определённую отметку времени, из юнисона же сделать это крайне
 проблематично.
-- 
 Eugene Berdnikov



Re: NetSurf 3.6_подскажите русских рабработчиков

2018-03-12 Пенетрантность Sohin Vyacheslav


11.03.2018 19:07, Gali Anikina пишет:
> Есть кое-какие мысли на тему улучшения. К кому из русских разработчиков
> можно обратиться?

попробуйте написать в почтовую рассылку
NetSurf Development
This mailing list is intended for developer and contributor discussion.

предварительно на нее подписавшись тут:
https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/netsurf-dev-netsurf-browser.org

Но ее наверняка читают все разработчики NetSurf, а не только русские.
Так что пишите на английском...

--
BW,
Sohin Vyacheslav



Re: Краткий обзор систем резервного копирования

2018-03-12 Пенетрантность yuri . nefedov

Victor Wagner -> debian-russian@lists.debian.org  @ Mon, 12 Mar 2018
11:59:09 +0300:
...

> Лет десять назад именно Артем Чуприна научил меня пользоваться
> rsnapshot. Поэтому полагаю, что под дедупликацией он имеет в виду
> что-то другое, чего rsnapshot не умеет.

...
On Mon, 12 Mar 2018, Artem Chuprina wrote:


Exactly. В смысле, чего rsync не умеет. А он не умеет ни если файл
переместился, ни если у него изменилась метаинформация. И если второе —
это ограничение вообще конструкции хардлинков (и правильно, что не
умеет, хотя на задаче бэкапа тоже хочется уметь), то первое (тоже
правильно, что не умеет, но по другой причине) временами хочется и
подправить. Когда на бэкап-клиенте :) большое поддерево переместили или
хотя бы переименовали директорию верхнего уровня, не говоря уже о
несколько более содержательной реорганизации.



  Вообще говоря всё это unison умеет. Принцип работы как у rsync,
  а синхронизацию в обратную сторону можно и запретить.
  Правда, для полноценного бекапа как то стрёмно его пробовать.
  А вот для рабочих папок, где всякие перемещения, переименования
  и т.п. обычное дело, самое то.

Ю.

Re: Краткий обзор систем резервного копирования

2018-03-12 Пенетрантность Artem Chuprina
Victor Wagner -> debian-russian@lists.debian.org  @ Mon, 12 Mar 2018 11:59:09 
+0300:

 >> > Для себя сделал вывод, что надежнее самопальной конструкции на базе
 >> > rsync все-таки ничего не придумали.  
 >> 
 >> > Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
 >> > надежность и простота восстановления в любом случае важнее.  
 >> 
 >> Рекомендую глянуть на rsnapshot - как раз конструкция на базе rsync,

 > Лет десять назад именно Артем Чуприна научил меня пользоваться
 > rsnapshot. Поэтому полагаю, что под дедупликацией он имеет в виду
 > что-то другое, чего rsnapshot не умеет.

Exactly. В смысле, чего rsync не умеет. А он не умеет ни если файл
переместился, ни если у него изменилась метаинформация. И если второе —
это ограничение вообще конструкции хардлинков (и правильно, что не
умеет, хотя на задаче бэкапа тоже хочется уметь), то первое (тоже
правильно, что не умеет, но по другой причине) временами хочется и
подправить. Когда на бэкап-клиенте :) большое поддерево переместили или
хотя бы переименовали директорию верхнего уровня, не говоря уже о
несколько более содержательной реорганизации.

Но всего этого хочется при условии "не потерять в надежности и не
усложнить процедуру восстановления". А описанные комбайны ими таки
жертвуют. Больше, как я понимаю, надежностью — FUSE-драйвера, которые
позволяют сохранить простоту восстановления, по крайней мере у половины
есть.

И прикрутить к имеющемуся сверху тоже можно, но это несколько
дополнительный велосипед.



Re: Краткий обзор систем резервного копирования

2018-03-12 Пенетрантность Stanislav Vlasov
12 марта 2018 г., 13:59 пользователь Victor Wagner  написал:

>> > Для себя сделал вывод, что надежнее самопальной конструкции на базе
>> > rsync все-таки ничего не придумали.
>>
>> > Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
>> > надежность и простота восстановления в любом случае важнее.
>>
>> Рекомендую глянуть на rsnapshot - как раз конструкция на базе rsync,
>
> Лет десять назад именно Артем Чуприна научил меня пользоваться
> rsnapshot. Поэтому полагаю, что под дедупликацией он имеет в виду
> что-то другое, чего rsnapshot не умеет.

Подозреваю, что тогда под дедупликацией имеется ввиду что-то вроде
дедупликации в zfs или аналогичных.
Но там, куда я могу положить бекап, сделанный rsync, я не могу
воткнуть достаточно памяти, чтоб ещё и дедупликацию в zfs сделать.
А там где могу - нельзя хранить бекапы, так как это их источник.

-- 
Stanislav


Re: Краткий обзор систем резервного копирования

2018-03-12 Пенетрантность Victor Wagner
On Mon, 12 Mar 2018 13:56:31 +0500
Stanislav Vlasov  wrote:

> 9 марта 2018 г., 20:36 пользователь Artem Chuprina 
> написал:
> 
> > Для себя сделал вывод, что надежнее самопальной конструкции на базе
> > rsync все-таки ничего не придумали.  
> 
> > Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
> > надежность и простота восстановления в любом случае важнее.  
> 
> Рекомендую глянуть на rsnapshot - как раз конструкция на базе rsync,

Лет десять назад именно Артем Чуприна научил меня пользоваться
rsnapshot. Поэтому полагаю, что под дедупликацией он имеет в виду
что-то другое, чего rsnapshot не умеет.

--  



Re: Краткий обзор систем резервного копирования

2018-03-12 Пенетрантность Stanislav Vlasov
9 марта 2018 г., 20:36 пользователь Artem Chuprina  написал:

> Для себя сделал вывод, что надежнее самопальной конструкции на базе
> rsync все-таки ничего не придумали.

> Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
> надежность и простота восстановления в любом случае важнее.

Рекомендую глянуть на rsnapshot - как раз конструкция на базе rsync,
но с дедупликацией между разными бекапами при помощи хардлинков.
В результате работы - несколько каталогов по одному на каждый бекап с
деревом каталогов внутри. Восстановление - копированием.

-- 
Stanislav


Re: kernel Call Trace_________ ________________

2018-03-12 Пенетрантность Alexander Gerasiov
Hello yuri.nefe...@gmail.com,

On Sun, 11 Mar 2018 21:33:18 +0800 (CST)
yuri.nefe...@gmail.com wrote:

> On Sun, 11 Mar 2018, Gali Anikina wrote:
> 
> ...
> > в /var/log/kernel и в messages вот такое (там больше, с указанием
> > имя материнки и далее вот это, только подлинее)
> >  
> ...
> > Mar 10 17:15:22 mikintel kernel: [ 1683.579351] Disabling IRQ #23
> >
> >
> > Методом проб и ошибок пришла к вероятной проблеме - они были
> > подключены на отдельную выносную планку USB, а она через шлейфы
> > подключается непосредственно к материнке.  
> ...
> 
>   Можно посмотреть чему соответствует IRQ #23
>   (man 5 proc)
>   > cat /proc/interrupts  
> 
>   23:  IO-APIC-fasteoi   ehci_hcd:usb1
> 
> 
>   У меня это подсистема USB1.
>   Для USB1 ограничение в длине кабеля 3м (18ns max delay).
>   Плюс, на выносной планке на конекторах набегает еще задержка.
> 
>   Правда, мне непонятно почему call trace вызывается.
>   Вполне штатная ситуация, протокол рукопожатия не прошел
>   и устройство игнорируется. Ну, видимо, игнорируется
>   маскировкой соответствующего IRQ, а при этом идет штатная
>   печать, что собственно и наблюдается в логах.

Произошло прерывание, но на момент проверки состояния аппаратуры из
irq handler'а железка стала сообщаться о себе уже что-то совсем не то
(явно решил, что это не его прерывание), получилось, "ничейное
прерывание". Похоже, что это аппаратная проблема контроллера в некоторых
экзотических случаях. Не факт, что ее реально кто-то будет пытаться
чинить. Хотя, возможно, это драйвер неправильно проверят факт
прерывания на устройстве.

Можно попытаться написать в http://www.linux-usb.org/mailing.html

-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: g...@cs.msu.su  WWW: http://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1



Re: NetSurf 3.6_подскажите русских рабработчиков

2018-03-12 Пенетрантность Sohin Vyacheslav


11.03.2018 19:07, Gali Anikina пишет:
> Ну хорошо я уже запомнила, что при просмотре локально надо вводить
> file:///, но первоначально, когда стала пользоваться netsurf, и хотела
> просмотреть локальную документацию, такая , малоговорящая простому
> пользователю, подсказка быстро отбивала желание "по быстрому просмотру
> локальной документации посредством данного браузера". Я думаю, что я не
> одна такая :-)))

А если сразу ввести слеш (/) в адресной строке вместо file:/// покажет
содержимое корня?

--
BW,
Sohin Vyacheslav



[DONE] wml://{security/2008/dsa-1673.wml}

2018-03-12 Пенетрантность Lev Lamberov
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/security/2008/dsa-1673.wml2017-11-01 10:11:09.931818654 
+0500
+++ russian/security/2008/dsa-1673.wml  2018-03-12 12:11:37.867322822 +0500
@@ -1,54 +1,55 @@
- -several vulnerabilities
+#use wml::debian::translation-check translation="1.4" maintainer="Lev Lamberov"
+несколько уязвимостей
 
- -Several remote vulnerabilities have been discovered in network traffic
- -analyzer Wireshark. The Common Vulnerabilities and Exposures project
- -identifies the following problems:
+В Wireshark, программе для анализа сетевого 
трафика, было обнаружено несколько
+удалённых уязвимостей. Проект Common Vulnerabilities 
and Exposures
+определяет следующие проблемы:
 
 
 
 https://security-tracker.debian.org/tracker/CVE-2008-3137;>CVE-2008-3137
 
- -The GSM SMS dissector is vulnerable to denial of service.
+Диссектор GSM SMS уязвим к отказу в 
обслуживании.
 
 https://security-tracker.debian.org/tracker/CVE-2008-3138;>CVE-2008-3138
 
- -The PANA and KISMET dissectors are vulnerable to denial of 
service.
+Диссекторы PANA и KISMET уязвимы к отказу в 
обслуживании.
 
 https://security-tracker.debian.org/tracker/CVE-2008-3141;>CVE-2008-3141
 
- -The RMI dissector could disclose system memory.
+Диссектор RMI может раскрывать 
содержимое системной памяти.
 
 https://security-tracker.debian.org/tracker/CVE-2008-3145;>CVE-2008-3145
 
- -The packet reassembling module is vulnerable to denial of 
service.
+Модуль перетранслирования пакетов 
уязвим к отказу в обслуживании.
 
 https://security-tracker.debian.org/tracker/CVE-2008-3933;>CVE-2008-3933
 
- -The zlib uncompression module is vulnerable to denial of 
service.
+Модуль распаковки zlib уязвим к отказу в 
обслуживании.
 
 https://security-tracker.debian.org/tracker/CVE-2008-4683;>CVE-2008-4683
 
- -The Bluetooth ACL dissector is vulnerable to denial of 
service.
+Диссектор Bluetooth ACL уязвим к отказу в 
обслуживании.
 
 https://security-tracker.debian.org/tracker/CVE-2008-4684;>CVE-2008-4684
 
- -The PRP and MATE dissectors are vulnerable to denial of 
service.
+Диссекторы PRP и MATE уязвимы к отказу в 
обслуживании.
 
 https://security-tracker.debian.org/tracker/CVE-2008-4685;>CVE-2008-4685
 
- -The Q931 dissector is vulnerable to denial of service.
+Диссектор Q931 уязвим к отказу в 
обслуживании.
 
 
 
- -For the stable distribution (etch), these problems have been fixed in
- -version 0.99.4-5.etch.3.
+В стабильном выпуске (etch) эти проблемы 
были исправлены в
+версии 0.99.4-5.etch.3.
 
- -For the upcoming stable distribution (lenny), these problems have been
- -fixed in version 1.0.2-3+lenny2.
+В готовящемся стабильном выпуске (lenny) 
эти проблемы были
+исправлены в версии 1.0.2-3+lenny2.
 
- -For the unstable distribution (sid), these problems will be fixed 
soon.
+В нестабильном выпуске (sid) эти проблемы 
будут исправлены позже.
 
- -We recommend that you upgrade your wireshark packages.
+Рекомендуется обновить пакеты wireshark.
 
 
 # do not modify the following line
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE3mumcdV9mwCc9oZQXudu4gIW0qUFAlqmKC8ACgkQXudu4gIW
0qVKcQ//XVr6foDPsS5YWao7vldEqcrMLcXP7qGpj9pYkUPHNo9PL4NMxBQMd64S
XrjVHndeASxVii9yeyAEQdmXRNDA2V8tO+QQdwj09LPjAqW1NMuaQ5m+BdknLfVe
ZZ/KR/qFuqjyLH6XR5c/NwZaH9C0nVVA/xqb6LSLpLjJttqSf0BnG1jYLeuAmkG2
0sBBbiFGeXnqmm6qwr/Gq+euyqKbXo5iK/3AsFnXC+dSw1zq68agWrVR/D20VPH/
6zMidShcz5nt3F0mQUHQnhW3dwqPfMSy7tfCc/wtyfXo2+v5YWflShRt7o6DaAOS
eFsHXl9W37X5dRxEnou7FCSsgKHQRxHrAg0E8Cm2nktajxf3lPEjDCXEG5sQ+hfp
+hdBINmaqD4fmNC/5ZCFYmqEJZx4gPifc1dOCfylEkjYjmZXNflOwdsN5uHXxaqV
6dEiKnDPguTJDpsBunEX7+1cDoKewDaN1Hpie8myQFPDga4GcCLsEZJGJ/rvM0MC
ohY2kVGXuWsBXGoh1LpiPBATSPItOSvwvISQ+bC5VuNTC2G8df4SZX0u/MEsKGsT
YAt2Fsdl4sJdqPg/IyodFV4JIXHr9RKp+s03pq7cOgSKKwkEhPf5ksJmF0JutrZi
U2bkrqtw2f9Gp/obvRzHGHs2jjjm08wqOeUdNc00aZgE+WrNBBg=
=nu/8
-END PGP SIGNATURE-



[DONE] wml://{security/2007/dsa-1318.wml}

2018-03-12 Пенетрантность Lev Lamberov
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/security/2007/dsa-1318.wml2017-11-01 10:11:09.731805616 
+0500
+++ russian/security/2007/dsa-1318.wml  2018-03-12 12:05:12.080380896 +0500
@@ -1,51 +1,52 @@
- -several vulnerabilities
+#use wml::debian::translation-check translation="1.3" maintainer="Lev Lamberov"
+несколько уязвимостей
 
- -Several remote vulnerabilities have been discovered in ekg, a console
- -Gadu Gadu client. The Common Vulnerabilities and Exposures project
- -identifies the following problems:
+В ekg, консольном клиенте Gadu Gadu, было 
обнаружено несколько
+удалённых уязвимостей. Проект Common Vulnerabilities 
and Exposures
+определяет следующие проблемы:
 
 
 
 https://security-tracker.debian.org/tracker/CVE-2005-2370;>CVE-2005-2370
 
- -It was discovered that memory alignment errors may allow remote
- -attackers to cause a denial of service on certain architectures
- -such as sparc. This only affects Debian Sarge.
+Было обнаружено, что ошибки 
выравнивания данных в памяти могут 
позволить удалённым
+злоумышленникам вызвать отказ в 
обслуживании на определённых архитектурах
, в частности
+на sparc. Эта уязвимость касается только 
Debian Sarge.
 
 https://security-tracker.debian.org/tracker/CVE-2005-2448;>CVE-2005-2448
 
- -It was discovered that several endianess errors may allow remote
- -attackers to cause a denial of service. This only affects 
- -Debian Sarge.
+Было обнаружено, что несколько ошибок, 
связанных с порядком следования байтов, 
могут
+позволить удалённым злоумышленникам 
вызвать отказ в обслуживании. Эта 
уязвимость
+касается только Debian Sarge.
 
 https://security-tracker.debian.org/tracker/CVE-2007-1663;>CVE-2007-1663
 
- -It was discovered that a memory leak in handling image messages may
- -lead to denial of service. This only affects Debian Etch.
+Было обнаружено, что утечка памяти в 
коде для обработки сообщений с 
изображениями может
+приводить к отказу в обслуживании. Эта 
уязвимость касается только Debian Etch.
 
 https://security-tracker.debian.org/tracker/CVE-2007-1664;>CVE-2007-1664
 
- -It was discovered that a null pointer deference in the token OCR code
- -may lead to denial of service. This only affects Debian Etch.
+Было обнаружено, что разыменование 
null-указателя в коде токена OCR
+может приводить к отказу в обслуживании. 
Эта уязвимость касается только Debian Etch.
 
 https://security-tracker.debian.org/tracker/CVE-2007-1665;>CVE-2007-1665
 
- -It was discovered that a memory leak in the token OCR code may lead
- -to denial of service. This only affects Debian Etch.
+Было обнаружено, что утечка памяти в 
коде токена OCR может приводить
+к отказу в обслуживании. Эта уязвимость 
касается только Debian Etch.
 
 
 
- -For the oldstable distribution (sarge) these problems have been fixed in
- -version 1.5+20050411-7. This updates lacks updated packages for the m68k
- -architecture. They will be provided later.
+В предыдущем стабильном выпуске (sarge) эти 
проблемы были исправлены в
+версии 1.5+20050411-7. В данном обновлении 
отсутствуют пакеты для архитектуры
+m68k. Пакеты для данной архитектуры будут 
предоставлены позже.
 
- -For the stable distribution (etch) these problems have been fixed
- -in version 1:1.7~rc2-1etch1.
+В стабильном выпуске (etch) эти проблемы 
были исправлены
+в версии 1:1.7~rc2-1etch1.
 
- -For the unstable distribution (sid) these problems have been fixed in
- -version 1:1.7~rc2-2.
+В нестабильном выпуске (sid) эти проблемы 
были исправлены в
+версии 1:1.7~rc2-2.
 
- -We recommend that you upgrade your ekg packages.
+Рекомендуется обновить пакеты ekg.
 
 
 # do not modify the following line
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE3mumcdV9mwCc9oZQXudu4gIW0qUFAlqmJq0ACgkQXudu4gIW
0qXKYg/7BphGMhA89saFxJB4Nbh3DVWvGWxp/XO1tPVGQXSPeG9hOVu/y5xN2jg0

не грузится предыдущий Debian с соседнего раздела

2018-03-12 Пенетрантность Gali Anikina

Не грузится предыдущий Debian с соседнего раздела.
Предистория
На sda1 установлен Debian Stable
При установке сообщил, что кажется имеется UEFI и может не загрузиться 
система (HDD уже был разбит на разделы и установить установщику свой 
UEFI не представилось возможности - всё было занято - все 15 штук sda).

Но всё обошлось и система установилась и загрузилась.
Система работала нормально.
Далее на sda2 установлен Debian Testing. Там тоже было предупреждение о 
возможной невозможности загрузки - приняли к сведению и согласились. 
Далее уже Testing загрузилась и работала нормально, НО sda1 перестал 
загружаться, несмотря на то, что grub подцепил его в своё меню. Пишет 
ошибку - не может найти раздел resume ... root и swap

Не загружается даже в режиме recovery mode.
А вот ещё - когда ставилось на sda1, swap был один раздел, а потом он 
был изменён на другой раздел.
Вообщем не видела root и swap раздела, а всё скрежетала и пыталась 
прочитать FDD.


Что только не делала, даже через chroot подправляла ядро на соседнем 
разделе - всё бестолку (об изменении uuid в fstab и initrd и в

/etc/initramfs-tools/файл на соседнем разделе я уже не говорю - делала).

А кстати почему сейчас нет пункта в установщике "Сделать загрузочную 
дискету с ядром"? Вот в таких ситуациях она очень помогла.
Помню, давным-давно, в Slackware такое было и оно очень удобно для таких 
случаев (достаточно часто спасало в таких ситуациях + lilo). А в Debian 
это не делается ещё на этапе установки системы (или может такой пункт 
там есть, но запрятан далеко), а потом, когда установится система этот 
вопрос ещё надо изучать и делать - если не закрутишься дальше по жизни и 
забудешь о том, что надо своевременно сделать спасительную дискету.
Может быть имел бы смысл по умолчанию предлагать ещё тогда - при 
установке - сделать по выбору пользователя или FDD или USB или CD/DVD 
такой диск?


В посление разы -проходя с трудом через загрузку, в момент когда 
происходит изменение разрешения в консоле (подключается графический 
драйвер drm amdgpu kernel modesetting enabledati), в консоли появляется 
чёрный экран и тишина ..

  В файле /var/log/kern.log последее такое -
Feb 27 18:00:40 tamrik kernel: [   10.033714] [drm] Initialized
Feb 27 18:00:40 tamrik kernel: [   10.102578] [drm] amdgpu kernel 
modesetting enabled.

Feb 27 18:00:40 tamrik kernel: [   10.121968] EDAC MC: Ver: 3.0.0
Feb 27 18:00:40 tamrik kernel: [   10.231010] CRAT table not found
Feb 27 18:00:40 tamrik kernel: [   10.231014] Finished initializing 
topology ret=0

Feb 27 18:00:40 tamrik kernel: [   10.231045] kfd kfd: Initialized module
Feb 27 18:00:40 tamrik kernel: [   10.232085] [drm] initializing kernel 
modesetting (POLARIS11 0x1002:0x67EF 0x1043:0x04B8 0xCF).
Feb 27 18:00:40 tamrik kernel: [   10.232110] [drm] register mmio base: 
0xFDC8
Feb 27 18:00:40 tamrik kernel: [   10.232112] [drm] register mmio size: 
262144
Feb 27 18:00:40 tamrik kernel: [   10.232121] [drm] doorbell mmio base: 
0xEFE0
Feb 27 18:00:40 tamrik kernel: [   10.232122] [drm] doorbell mmio size: 
2097152
Feb 27 18:00:40 tamrik kernel: [   10.232137] [drm] probing gen 2 caps 
for device 10de:778 = 313d02/0
Feb 27 18:00:40 tamrik kernel: [   10.232142] [drm] probing mlw for 
device 10de:778 = 313d02
Feb 27 18:00:40 tamrik kernel: [   10.232157] [drm] UVD is enabled in VM 
mode

Feb 27 18:00:40 tamrik kernel: [   10.232158] [drm] VCE enabled in VM mode
Feb 27 18:00:40 tamrik kernel: [   10.232198] amdgpu :02:00.0: 
Invalid PCI ROM header signature: expecting 0xaa55, got 0x
Feb 27 18:00:40 tamrik kernel: [   10.232606] ATOM BIOS: 
67EFHB.15.50.0.0.AS25

Feb 27 18:00:40 tamrik kernel: [   10.232621] [drm] GPU post is not needed
Feb 27 18:00:40 tamrik kernel: [   10.256946] MCE: In-kernel MCE 
decoding enabled.

Feb 27 18:00:40 tamrik kernel: [   10.264901] EDAC amd64: DRAM ECC disabled.
Feb 27 18:00:40 tamrik kernel: [   10.264911] EDAC amd64: ECC disabled 
in the BIOS or no ECC capability, module will not load.
Feb 27 18:00:40 tamrik kernel: [   10.264911]  Either enable ECC 
checking or force module loading by setting 'ecc_enable_override'.
Feb 27 18:00:40 tamrik kernel: [   10.264911]  (Note that use of the 
override may cause unknown side effects.)
Feb 27 18:00:40 tamrik kernel: [   10.281058] amdgpu :02:00.0: 
firmware: direct-loading firmware amdgpu/polaris11_mc.bin
Feb 27 18:00:40 tamrik kernel: [   10.281200] [TTM] Zone  kernel: 
Available graphics memory: 4023544 kiB
Feb 27 18:00:40 tamrik kernel: [   10.281203] [TTM] Zone   dma32: 
Available graphics memory: 2097152 kiB
Feb 27 18:00:40 tamrik kernel: [   10.281205] [TTM] Initializing pool 
allocator
Feb 27 18:00:40 tamrik kernel: [   10.281214] [TTM] Initializing DMA 
pool allocator
Feb 27 18:00:40 tamrik kernel: [   10.281245] amdgpu :02:00.0: VRAM: 
2048M 0x - 0x7FFF (2048M used)
Feb 27 18:00:40 tamrik kernel: [   10.281248] amdgpu :02:00.0: GTT: 
3929M 0x8000 -