Upgrade to Ubuntu 20.04 fails on i386 packages
Я недавно обновился с 16.04 до 18.04.4 LTS, и теперь хочу снова обновить до 20.04 LTS, используя
sudo do-release-upgrade -d
Процесс завершается ошибкой с сообщением об ошибке ppas, но файлы журнала показывают, что проблема связана с конфликтами ubuntu-standard и lsof. Похоже, что он не может разрешить конфликт между lsof: amd и lsof: i386. Я пытался удалить их и переустановить, но пока ничего не получалось.
Могу ли я что-нибудь сделать или я должен подождать и надеяться, что это будет решено сопровождающими пакета?
Starting pkgProblemResolver with broken count: 1
Starting 2 pkgProblemResolver with broken count: 1
Investigating (0) ubuntu-standard:amd64 < 1.417.4 -> 1.450.1 @ii umU Ib >
Broken ubuntu-standard:amd64 Depends on lsof:amd64 < 4.89+dfsg-0.1 | 4.93.2+dfsg-1 @ii ugR >
Considering lsof:amd64 0 as a solution to ubuntu-standard:amd64 2
Added lsof:amd64 to the remove list
Fixing ubuntu-standard:amd64 via keep of lsof:amd64
MarkKeep lsof:amd64 < 4.89+dfsg-0.1 | 4.93.2+dfsg-1 @ii ugR > FU=0
Investigating (0) lsof:amd64 < 4.89+dfsg-0.1 | 4.93.2+dfsg-1 @ii ugH Ib >
Broken lsof:amd64 Conflicts on lsof:i386 < none -> 4.93.2+dfsg-1 @un umN Ib >
Considering lsof:i386 4 as a solution to lsof:amd64 0
Re-Instated lsof:amd64
Investigating (1) lsof:i386 < none -> 4.93.2+dfsg-1 @un umN Ib >
Broken lsof:i386 Conflicts on lsof:amd64 < 4.89+dfsg-0.1 -> 4.93.2+dfsg-1 @ii ugU Ib >
Considering lsof:amd64 0 as a solution to lsof:i386 4
Added lsof:amd64 to the remove list
Conflicts//Breaks against version 4.89+dfsg-0.1 for lsof but that is not InstVer, ignoring
Fixing lsof:i386 via remove of lsof:amd64
MarkDelete lsof:amd64 < 4.89+dfsg-0.1 -> 4.93.2+dfsg-1 @ii ugU Ib > FU=0
Investigating (1) ubuntu-standard:amd64 < 1.417.4 -> 1.450.1 @ii umU Ib >
Broken ubuntu-standard:amd64 Depends on lsof:amd64 < 4.89+dfsg-0.1 | 4.93.2+dfsg-1 @ii ugR >
Considering lsof:amd64 0 as a solution to ubuntu-standard:amd64 2
Added lsof:amd64 to the remove list
Fixing ubuntu-standard:amd64 via keep of lsof:amd64
MarkKeep lsof:amd64 < 4.89+dfsg-0.1 | 4.93.2+dfsg-1 @ii ugR > FU=0
Investigating (1) lsof:amd64 < 4.89+dfsg-0.1 | 4.93.2+dfsg-1 @ii ugH Ib >
Broken lsof:amd64 Conflicts on lsof:i386 < none -> 4.93.2+dfsg-1 @un umN Ib >
Considering lsof:i386 4 as a solution to lsof:amd64 0
Removing lsof:amd64 rather than change lsof:i386
MarkDelete lsof:amd64 < 4.89+dfsg-0.1 | 4.93.2+dfsg-1 @ii ugH Ib > FU=0
Investigating (2) ubuntu-standard:amd64 < 1.417.4 -> 1.450.1 @ii umU Ib >
Broken ubuntu-standard:amd64 Depends on lsof:amd64 < 4.89+dfsg-0.1 | 4.93.2+dfsg-1 @ii ugR >
Considering lsof:amd64 0 as a solution to ubuntu-standard:amd64 2
Added lsof:amd64 to the remove list
Fixing ubuntu-standard:amd64 via keep of lsof:amd64
MarkKeep lsof:amd64 < 4.89+dfsg-0.1 | 4.93.2+dfsg-1 @ii ugR > FU=0
Investigating (2) lsof:amd64 < 4.89+dfsg-0.1 | 4.93.2+dfsg-1 @ii ugH Ib >
Broken lsof:amd64 Conflicts on lsof:i386 < none -> 4.93.2+dfsg-1 @un umN Ib >
Considering lsof:i386 4 as a solution to lsof:amd64 2
Removing lsof:amd64 rather than change lsof:i386
MarkDelete lsof:amd64 < 4.89+dfsg-0.1 | 4.93.2+dfsg-1 @ii ugH Ib > FU=0
Investigating (3) ubuntu-standard:amd64 < 1.417.4 -> 1.450.1 @ii umU Ib >
Broken ubuntu-standard:amd64 Depends on lsof:amd64 < 4.89+dfsg-0.1 | 4.93.2+dfsg-1 @ii ugR >
Considering lsof:amd64 4 as a solution to ubuntu-standard:amd64 2
MarkKeep ubuntu-standard:amd64 < 1.417.4 -> 1.450.1 @ii umU Ib > FU=0
Reinst Failed because of lsof:amd64
MarkKeep ubuntu-standard:amd64 < 1.417.4 -> 1.450.1 @ii umU Ib > FU=0
Removing ubuntu-standard:amd64 rather than change lsof:amd64
...
DEBUG The package 'ubuntu-standard' is marked for removal but it's in the removal blacklist
ERROR Dist-upgrade failed: 'The package 'ubuntu-standard' is marked for removal but it is in the removal blacklist.'
РЕДАКТИРОВАТЬ: по запросу, вот вывод Политика apt-cache Стандарт ubuntu lsof lsof: i386
ubuntu-standard:
Installed: 1.417.4
Candidate: 1.417.4
Version table:
*** 1.417.4 500
500 http://ca.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
100 /var/lib/dpkg/status
1.417 500
500 http://ca.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
lsof:
Installed: 4.89+dfsg-0.1
Candidate: 4.89+dfsg-0.1
Version table:
*** 4.89+dfsg-0.1 500
500 http://ca.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
100 /var/lib/dpkg/status
lsof:i386:
Installed: (none)
Candidate: 4.89+dfsg-0.1
Version table:
4.89+dfsg-0.1 500
500 http://ca.archive.ubuntu.com/ubuntu bionic/main i386 Packages
Я также попытался обновить систему до 19.10 в качестве промежуточного шага, но эта же проблема lsof блокирует его. I have so far been able to shut down NetworkManager in Kubuntu, tried installing network-...
Is there any way to disable "Automatically connect to this network when available" permanently?
I have so far been able to shut down NetworkManager in Kubuntu, tried installing network-manager-gnome, checked the config files listed with sudo NetworkManager --print-config including the main /etc/NetworkManager/NetworkManager.conf file (adding no-auto-default=* under [main]), and the individual config files per network connection in ll /etc/NetworkManager/system-connections/. Some of these do show autoconnect=false, but I need false to be the default boolean.
There must be a template file in /etc or a config file somewhere for this. I just tried sudo grep -R 'autoconnect=true' /etc and in /usr and /var too, with no luck. Any other location suggestions to try? Or does anyone know where the actual default 'true' setting is stored? Or if there is a place to create such a setting. I realize I could create a conf file for each expected network connection, but I want it off for any and all new connections.
The problem is that it is obviously a security flaw to connect to new networks by default. Also, I want to change the 'All users may connect to this network' to on by default, to stop the KDEWallet popups from interfering with every network change in tandem with the Autoconnect default on. Lastly, bonus if you know how to unset 'Restrict to this device' by default.. why would I want to always limit every network connection to just one device?? ..Thanks!
PS, Im pretty sure this applies to all Buntus.
Edit1: a longer response to @thallers answer below..
I believe the problem is that the 'default' of not specifying is a boolean True. That is the original flaw in the logic. And it could have security problems.
For example, if I have all connection passwords stored in a root protected keyring or wallet, and an attacker gets access to user level operations, all they would have to do is create a new connection to have it be autoconnected to a nearby wifi hotspot with no open authentication.
The safest setting for a default would be False for autoconnect, but I understand the desire to onboard new Ubuntu users with easier network connections (probably important also during first installation). However, there should be at least an option to set False as a default for new profiles. Again, there must be a piece of code somewhere, that says set True if not pre-existing, even if that is deep within the OS structure.
The problem with 'no-auto-default' is you have to know the new profile name in advance is impossible say if I buy a new wifi router.
"Solution: when you drop the file, create it with the autoconnect setting unset." doesn't make logical sense..? That would also default to True..?
Again, I conceded some defaults are just not my preference, but the should be a way to set a default differently. Because of the 'no setting equals True' logic, that appears to not be possible.
Disagree that useful to tie a network to a device.. so if I plug in another wifi dongle to troubleshoot a connection, or heaven forbid just to change it, I should have to drill into a connection setting to allow that..? On the other hand, I do see a security purpose for locking it down, but again, there should be a way to set the default to allow any device. And again, there must me a piece of code for this, unless by defining a 'Restrict device' feature in terms of negative functionality, in tandem with the 'no setting equals True' logic, it is the same problem. So the possible Solution would be to create a patch for an 'Unrestrict device' feature that would default to true. The same may be for the autoconnect, although the underlying logic problem in the first bullet point is likely the root of it.
2 ответа
NetworkManager подключается только к сети, для которой у вас есть профиль. Кроме того, NetworkManager не создает профили, в том числе потому, что он не знает, какие настройки вам нужны. Таким образом, эта проблема безопасности кажется необоснованной. Да, если вы нажмете на nm-applet, gnome-shell или plasma-nm на Wi-Fi, для которого не существует никакого профиля, он будет создан. Но не нажимайте, если не хотите этого. И если вы случайно нажали, снова удалите профиль, который не кажется слишком вредным.
Существует исключение для «NetworkManager не создает профили». Если вы не настроили no-auto-default в NetworkManager.conf и если у вас есть устройство Ethernet без подходящего профиля, то NetworkManager создаст профиль с именем «Проводное соединение 1». Но если у вас есть профиль, этого не произойдет. Кроме того, если вы удалите или измените созданный профиль, NM запоминает, что в файле /var/lib/NetworkManager/no-auto-default.state.
За исключением случая без автоматического задания по умолчанию (который вы уже набрали), NetworkManager не генерирует профили. Профили подключения полностью создаются пользователем (или каким-либо клиентским инструментом NetworkManager, предположительно от имени пользователя). Я думаю, что указание, что NetworkManager имеет значения по умолчанию для свойств профиля соединения, является неправильным, и поэтому вы не можете настроить значение по умолчанию.
Обратите внимание, что есть исключение: некоторые свойства позволяют явно установить значение, которое указывает на default, и вы можете перезаписать эти значения по умолчанию в NetworkManager.conf. В этом случае свойство профиля явно говорит об использовании по умолчанию. Но это только для определенных свойств, и вряд ли имеет смысл для автоматического подключения, потому что этот тип значений по умолчанию зависит от устройства (а свойство autoconnect не зависит от устройства). Сведения о типах соединений по умолчанию см. В man NetworkManager.conf .
Конечно, при использовании определенного инструмента для создания профиля этот инструмент может иметь значение по умолчанию.
Например, если вы перетаскиваете файл в / etc / Networkmanager / system-connections и пропускаете настройку автоматического подключения, по умолчанию она имеет значение true. Решение: когда вы удаляете файл, создайте его с отключенной настройкой автоматического подключения.
Или, например, если вы используете nmcli connection add для создания профиля, будет создан новый профиль (по умолчанию) с включенным автоподключением. Решение: передайте autoconnect no в командной строке, или используйте сценарий оболочки, который вам поможет, или используйте совершенно другой инструмент.
Или, например, если вы создаете профиль с помощью nmcli device connect (который создает профиль, если его нет), он будет создан с включенным автоматическим подключением. Решение: не используйте этот способ для создания профиля или последующей настройки профиля с помощью nmcli connection modify .
Или, например, если вы создаете профиль с помощью nm-connection-editor, графический интерфейс пользователя предварительно инициализировать для автоматического подключения. Решение: снимите флажок перед тем, как нажать «Сохранить».
Конечно, обычно вы создаете профиль один раз с нужными вам настройками, а затем просто используете его. Итак, шаг создания профиля, за которым следует что-то вроде nmcli connection, изменяет автоподключение «$ PROFILE», не .
Или даже для U в $ (nmcli -g UUID connection); nocli connection изменить uuid $ U autoconnect no; сделано .
Нет, большинство инструментов (nmcli, nm-connection-editor) не позволяют вам определять значения по умолчанию для настроек при создании. Вместо этого они обычно позволяют указывать настройки при их создании. Или создайте свой собственный инструмент. Основная цель NetworkManager - предоставить API для настройки сети. Используйте этот API и создайте профиль по своему усмотрению.
Что касается того, почему большинство инструментов имеют определенное значение по умолчанию, а не другое, то ответ заключается в том, что это обычно считается более полезным, чего хочет большинство пользователей. Понятно, что значение по умолчанию ни для кого не подходит, иначе этот параметр нельзя было бы настроить с самого начала. Причины привязки профиля к определенному имени интерфейса (или MAC-адресу) не очень веские, но причина в том, что (если вы не установили соединение). multi-connect ) профиль может активироваться только один раз за раз. В этом случае представляется предпочтительным привязать профиль к устройству.
К сожалению, значение по умолчанию autoconnect=true в настоящее время нельзя переопределить, поскольку оно не определено как таковое в кодовой базе Network Manager. См. в функции init здесь [https://github.com/NetworkManager/NetworkManager/blob/master/libnm-core/nm-setting-connection.c#L1728], что priv-> autoconnect устанавливается в TRUE, несмотря ни на что.
Вы можете попросить изменить это, чтобы разрешить его переопределение конфигурацией либо в /etc/NetworkManager/NetworkManager.conf, либо, что еще лучше, что-то вроде /etc/NetworkManager/ conf.d/default-wifi-autoconnect-false.conf.
В этом файле вы должны поместить что-то вроде следующего, если хотите отменить автоматическое подключение устройств Wi-Fi по умолчанию...
[connection-wifi]
match-device=type:wifi
autoconnect=false
При наличии уважительной причины запрос может быть рассмотрен.