Your system is up to date. (Solved)

[mads]

What's important to realise here, is that mintUpdate isn't designed to "alert" you in "real time". It's not a server admin tool to keep your box up to date "the minute" something is released in the repositories. Its primary function is to make it easy for people to upgrade and to prevent novice users from upgrading sensitive parts of their system (via the level system).

Note however, that if you wanted mintUpdate to find updates and alert you in real time, all you'd have to do is to create a cron job that regularly calls "apt update". This would refresh the cache for you in the background and mintUpdate would then be able to find new updates, whether it's in root mode or user mode.

You could make the following call in /etc/cron.hourly/

Code: Select all

apt-get update 2> /dev/null

viking777, I had the above quote in mind when I stated that MU is primarily there to update and not to notify.
How do you interpret it?

[viking777]

viking777, I had the above quote in mind when I stated that MU is primarily there to update and not to notify.
How do you interpret it?

I have no idea tbh - I will give it a try though.

Having said that MU has just alerted me to a couple of updates without any prompting from cron so it does work when it feels like it, just not with any noticeable regularity. so maybe cron is what it needs. I will let you know what happens tomorrow, though I have the feeling that it will be impossible to tell the difference between what cron is doing, what MU is doing, and whether there are actually any updates available or not.

[asymmetros]

The only thing that worries me regarding the current (4.2. version is that it does not keep into 'History" the first-installed packages. I ve noticed it today for the third time.
More specifically, during the "update" i got a message that 7 new packages are going to be installed:
gcc-4.6-base (4.6.0-2)
libppl-c4 (0.11.2-3)
libppl9 (0.11.2-3)
libpwl5 (0.11.2-3)
libquadmath0 (4.6.0-2)
libxext-dev (2:1.2.0-2)
x11proto-xext-dev (7.1.2-1)

When the upgrade process was completed, i restarted Mintupdate, check history but no sign of any of those packages (the 4.2.2 versions was showing that kind of info). But synaptic, has kept those additions in it's "history tab". So, you have to check into 2 places (synaptic, MU) in order to track everything. Not a deal maybe -or am i missing something?

[8oluf7]

i still believe and I wish to be proved wrong that the level policy is dangerous when applied to LMDE: we have 5 levels with 2 options each, 10 different options to get things wrongs in a rolling distribution; we already saw people here on the forum saying, after a "breakage" -"I'm going to stick only with levels 1-2"

So, at the time my bug report was classified as a wish, now i make another wish please Clem, keep improving MU, adapting it to LMDE, but until the snapshots are in place, please disable the levels in LMDE's specific MU

When discussing how something should, or should not, behave we need to remember: "There is an exception to every generalisation - including this one."

I have an IBM ThinkPad T40 which suffered the not uncommon failure to the motherboard said to be due to flexing around the large video chip. I replaced the mobo with one from a Thinkpad R51 with a much smaller Intel video chip, so said to be free of this problem. Success - BUT the latest version of the Intel driver didn't support my chip. I tried several Linux distros before finding LMDE which doesn't use a 'bleeding-edge' version of the kernel and so works properly. Provided I stick to the default MU setting, and install levels 1-3 only, all is fine and dandy. When there was a problem with MU I did the usual:

Code: Select all

sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade

which installed all the update levels and broke my system. I ended up doing a complete re-install.

So the levels can be important and people who have adopted LMDE to get a less 'bleeding-edge' environment, like me, would be upset if the ability to set them was removed.

[kmb42vt]

It has been stated before that MintUpdate with it's default levels set (1,2 and 3), even in it's current updated form, is not yet compatible with LMDE. Keeping only the certain levels enabled by default only applies to the Ubuntu based versions of Mint for now.

For myself (and I know Clem recommended this but I can't seem to find the referencing thread at the moment), I've been using either Synaptic to perform updates (when I need the extra info on what an update is going to do my system) or using the terminal and doing a "sudo apt-get dist-upgrade" (or dropping out to a command prompt and doing a "sudo apt-get dist-upgrade" there if I see a lot of "X" updates coming in). I've been updating like this from the start and only ran into a couple-three minor problems. One involving VLC being removed early on (which was fixed eventually), the changeover from OO to LO leaving a bunch of OO stuff lying around and lately with the "Mark all upgrades" button disappearing from the Synaptic toolbar due to settings being overwritten by MintSystem.

Of course that's just me and my "off-the-shelf" desktop. I know that there can be a lot of problems especially with keeping mobile type computers updated due to sometimes odd hardware configurations (many laptop MB's are custom made either by the manufacturer themselves or by a 3rd party built to the manufacturer's specifications which can make for a lot of oddball configurations). Still, there's no such thing as "safe" levels of updates using MintUpdate as far as LMDE is concerned--yet.

Just sayin'.

[zerozero]

@8oluf7,
what you're describing is a very specific hardware issue and i believe you would be better off installing LMDE and prior to any update change the sources.list to squeeze;
now, trying to use a rolling distro and hold some updates, have filters in the update manager to avoid the core-system from upgrade while the rest flows, just doesn't seem right to me: you don't see that in any other rolling distro

[kmb42vt]

8oluf7 - All we're trying to say here is that currently MintUpdate's system of levels are designed only to work with Ubuntu based versions of Linux Mint, not the Debian based versions and setting only certain "Safe" levels to enabled will not allow the correct updates through for LMDE and will also hold critical updates and dependencies back. That's why you have to do a "dist-upgrade" at certain times when MU fails which completely negates all the "Safe" updating you did via MU previously anyway.

Anyway, what ever you're comfortable with. That's the great thing about Linux, right?

Oh, on a side note. About your update code you use in the terminal?

Code: Select all

sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade

The "sudo apt-get upgrade" is necessary. You either perform a...

Code: Select all

sudo apt-get update && sudo apt-get upgrade

or a...

Code: Select all

sudo apt-get update && sudo apt-get dist-upgrade

Those are two entirely different types of upgrades and aren't supposed to be run together. Just letting you know.

[kbmaniac]

So I logged in as root, then as root

crontab -e

and added the lines ...

@reboot apt-get update
0 * * * * apt-get update

to the end of the file, so an update happens on system startup and on the hour, every hour thereafter, works a treat.

Cheers

Dave

[kbmaniac]

Found that @reboot tried to update before networking had been started and sometimes b0rked, then had to wait for the hourly update, prefer to know any updates as soon as the system boots so tweaked my config a little so ...

crontab -e

and added the lines ...

@reboot sleep 10 && apt-get update > /dev/null
0 * * * * apt-get update > /dev/null

[viking777]

Found that @reboot tried to update before networking had been started and sometimes b0rked, then had to wait for the hourly update, prefer to know any updates as soon as the system boots so tweaked my config a little so ...

crontab -e

and added the lines ...

@reboot sleep 10 && apt-get update > /dev/null
0 * * * * apt-get update > /dev/null

I tried your workround and I must say it does seem to improve things a lot. I had to make one small change though. As you had it set up I was greeted on every boot with the shield icon telling me that 'apt is already in use by another program' . This was obviously the update as started by crontab (since nothing else was running). The simple fix was to alter the start up delay in mintupdate from 30 seconds to 60 seconds, there is now no conflict and I am notified of updates straight away. (correction, make that 90 seconds, 60 seconds still caused a conflict).

I think I will mark this as solved, and to my mind it is the way mintupdate should work by default.

[clem]

I think I will mark this as solved, and to my mind it is the way mintupdate should work by default.

It's a nice workaround for people like you who value timing and want to be notified as soon as something becomes available. The problem with this is that it locks your APT cache often in root mode... and this is the reason why this cronjob isn't set in Linux Mint by default. There's a trade-off here, and to us it's not worth setting this up by default.

[viking777]

The problem with this is that it locks your APT cache often in root mode

You are quite right, and in fact my declaration that the topic was solved was a little premature, but not any more.

This is what I have now, and coupled with a 30 second sleep before starting mintupdate it works at every boot without being locked.

Code: Select all

crontab -e

@reboot sleep 10 && apt-get update && rm -f /var/cache/apt/archives/lock > /dev/null

But hey, I am not trying to twist your arm about anything. For most people it is not a big deal I agree.

[clem]

Yes. I think it was an interesting discussion to have. A few elegant workarounds were found and this highlights the beauty of Linux and how flexible it is when it comes to configuration... you can make it do more or less what you want. The default setup we have a the moment will please most people, and for those wanting more, as you pointed out, there are ways to fine-tune the system to do exactly what you want.

[kbmaniac]

OK I know this is a little off topic, but what it /var/cache/apt/archives/lock ?

On my system without the "rm ...." it is there, so some part of apt is locked yet I can use synaptic AOK. Can you guys clarify so an ageing hacker can understand a little more

Cheers

Dave

[clem]

It's a file APT creates before accessing its database... if it's already there, it returns with an error. This is its way to ensure only one instance of APT is running.

[kbmaniac]

dave@main-system ~ $ apt-get install vim
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?

Now I understand ... might just add that "rm..."

Cheers

Dave

[clem]

That's because you're calling apt-get without root privileges...

you can type "apt install vim" or "sudo apt-get install vim", but not "apt-get install vim"

[kbmaniac]

opps LOL

Dave

[CaptSaltyJack]

So, uh.. pardon me while I ask maybe the obvious question:

Linux Mint is based off (at least in part) Ubuntu. Ubuntu is able to auto-notify me when new updates are available, and very promptly I might add. So I'm having difficulty understanding why Mint is not able to do the same. Why can't Mint just do whatever Ubuntu is pulling off to make that work?

[clem]

What makes you think the Ubuntu update manager's notification is immediate?