unattended upgrades nonsense
It appears that the default is to daily check & upgrade in the background. The issue here is that there is no indication that upgrades are taking place & the system will allow a restart during such activity. This can lead to an inconsistent state or even loss of ability to reboot successfully (that just happened here.
I think it's highly advised to disable this during dev..
Re: unattended upgrades nonsense
Quote:
Originally Posted by
mc4man
It appears that the default is to daily check & upgrade in the background. The issue here is that there is no indication that upgrades are taking place & the system will allow a restart during such activity. This can lead to an inconsistent state or even loss of ability to reboot successfully (that just happened here.
I think it's highly advised to disable this during dev..
+1 These upgrades caused me the same kind of trouble on Saturday.
Re: unattended upgrades nonsense
During dev you'd certainly want to be involved/aware of all updates/upgrades rather than silently. Here I also prefer to do so thru synaptic to keep an organized & straightforward history rather than overwrought logs in /var.
So am setting top option to never but because there's no guarantee that's as intended am also removing the unattended-upgrades package altogether.
Re: unattended upgrades nonsense
Quote:
Originally Posted by
mc4man
It appears that the default is to daily check & upgrade in the background. The issue here is that there is no indication that upgrades are taking place & the system will allow a restart during such activity. This can lead to an inconsistent state or even loss of ability to reboot successfully (that just happened here.
I think it's highly advised to disable this during dev..
Yea, I just got a unattended upgrade crash. I tried reporting, but didn't work.
1 Attachment(s)
Re: unattended upgrades nonsense
same here..
It also affects boot time with systemd with apt-update-service.
Setting to 'never' fixes for now.
Re: unattended upgrades nonsense
Yes, I mentioned this bug months ago. Maybe it should be a sticky post or mentioned in a sticky post?
https://ubuntuforums.org/showthread.php?t=2346439
Re: unattended upgrades nonsense
I am not an expert at this but I went into the file and added # to the beginning of:
Code:
#// "${distro_id}:${distro_codename}-updates";
#/ "${distro_id}:${distro_codename}-proposed";
#// "${distro_id}:${distro_codename}-backports";
is that sufficient to stop the upgrade like I think without causing issues?
Thanks
Re: unattended upgrades nonsense
The prolonged booting time with apt-update-service does not go away even if the package unattended-upgrades is removed.
The network-on checking during boot is done (even without unattended-upgrades) because of the new changes in the apt packages (from version 1.4.1ubuntu2 to version 1.4.2).
You get the short boot time back only by downgrading apt packages back to the version 1.4.
There is a bug report about this new setup:
https://bugs.launchpad.net/ubuntu/+s...t/+bug/1686470
Re: unattended upgrades nonsense
That bug report has a lot of good discussion already! And even an upload.
Looks like this will be FIX RELEASED in 17.10 soon.
Re: unattended upgrades nonsense
Quote:
Originally Posted by
harry332
The prolonged booting time with apt-update-service does not go away even if the package unattended-upgrades is removed.
The network-on checking during boot is done (even without unattended-upgrades) because of the new changes in the apt packages (from version 1.4.1ubuntu2 to version 1.4.2).
You get the short boot time back only by downgrading apt packages back to the version 1.4.
There is a bug report about this new setup:
https://bugs.launchpad.net/ubuntu/+s...t/+bug/1686470
@harry323,
Good eye harry! I sort of thought that was the case. Thanks for making it clear. It is sort of like hijacking the PC during boot-time. I think we can do without it in dev.