Install kernel-desktop-latest.

On my system (where I'm using the server flavor) ...
[root@x3 ~]# rpm -qa kernel-server*|sort -V
kernel-server-5.15.98-1.mga8-1-1.mga8
kernel-server-5.15.101-1.mga8-1-1.mga8
kernel-server-5.15.101-2.mga8-1-1.mga8
kernel-server-devel-5.15.98-1.mga8-1-1.mga8
kernel-server-devel-5.15.101-1.mga8-1-1.mga8
kernel-server-devel-5.15.101-2.mga8-1-1.mga8
kernel-server-devel-latest-5.15.101-2.mga8
kernel-server-latest-5.15.101-2.mga8
[root@x3 ~]# urpme --auto-orphans 
No orphans to remove

CC: (none) => davidwhodgins

Yes there is something really strange on Barrys system. On my MGA8 machines i also have several desktop kernels (also devel, virtualbox and others) installed and non of them show up under urpme --auto-orphans

Additionally there seems to be a mixing of os/versions (even if Barry is the dev of rok): rok is officially not available for MGA8. Not even in backports or backports_testing...

(In reply to sturmvogel from comment #2)
> Yes there is something really strange on Barrys system. On my MGA8 machines
> i also have several desktop kernels (also devel, virtualbox and others)
> installed and non of them show up under urpme --auto-orphans
> 

Thanks, that is strange, so something odd here. This is on my laptop which only has Mga8.

> Additionally there seems to be a mixing of os/versions (even if Barry is the
> dev of rok): rok is officially not available for MGA8. Not even in backports
> or backports_testing...

Well no mixing of versions other than my own backport of rok which also runs in Mga8 without issues. I simply used it's output to demonstrate which kernels are installed and being kept.

I will do some testing on a clean Mga8 install.

It's not something that can be easily tested on a clean install however I see the same behaviour on my desktop:

                        Welcome to 'remove-old-kernels' Interactive

 System: Mageia release 8 (Official) for x86_64 | Kernels in /boot/:3 | AUTO:0 | KEEP:3  
 ==> kernel-desktop
 1   : Keep  : U   : kernel-desktop-5.15.98-1.mga8-1-1.mga8.x86_64 Sun 19 Mar 2023 23:42:50 GMT 
 2   : Keep  :     : kernel-desktop-5.15.88-1.mga8-1-1.mga8.x86_64 Mon 23 Jan 2023 13:08:39 GMT 
 3   : Keep  :     : kernel-desktop-5.15.28-1.mga8-1-1.mga8.x86_64 Tue 10 Jan 2023 13:04:52 GMT 
               U = In use now
Tap spacebar to exit
 [baz@jackodesktop ~]$

[baz@jackodesktop ~]$ urpme --auto-orphans --test
To satisfy dependencies, the following 5 packages will be removed (156MB):
(orphan packages)
  kernel-desktop-5.15.28-1.mga8-1-1.mga8.x86_64
  kernel-desktop-5.15.88-1.mga8-1-1.mga8.x86_64
  virtualbox-kernel-5.15.28-desktop-1.mga8-6.1.32-1.8.mga8.x86_64
  virtualbox-kernel-5.15.88-desktop-1.mga8-7.0.6-1.mga8.x86_64
  xtables-addons-kernel-5.15.88-desktop-1.mga8-3.23-1.2.mga8.x86_64
Remove 5 packages? (y/N) n

[baz@jackodesktop ~]$ rpm -qa|grep kernel-|sort
kernel-desktop-5.15.28-1.mga8-1-1.mga8
kernel-desktop-5.15.88-1.mga8-1-1.mga8
kernel-desktop-5.15.98-1.mga8-1-1.mga8
kernel-desktop-latest-5.15.98-1.mga8
kernel-firmware-20201218-1.mga8
kernel-firmware-nonfree-20230110-1.mga8.nonfree
kernel-userspace-headers-5.15.98-1.mga8
virtualbox-kernel-5.15.28-desktop-1.mga8-6.1.32-1.8.mga8
virtualbox-kernel-5.15.88-desktop-1.mga8-7.0.6-1.mga8
virtualbox-kernel-5.15.98-desktop-1.mga8-7.0.6-1.6.mga8
virtualbox-kernel-desktop-latest-7.0.6-1.6.mga8
xtables-addons-kernel-5.15.88-desktop-1.mga8-3.23-1.2.mga8
xtables-addons-kernel-5.15.98-desktop-1.mga8-3.23-1.8.mga8
xtables-addons-kernel-desktop-latest-3.23-1.8.mga8
[baz@jackodesktop ~]$

[baz@jackodesktop ~]$ urpmq --list-media active
Core Release (zmrepo1)
Core Updates (zmrepo3)
Nonfree Release (zmrepo11)
Nonfree Updates (zmrepo13)
Tainted Release (zmrepo21)
Tainted Updates (zmrepo23)
[baz@jackodesktop ~]$

[baz@jackodesktop ~]$ sudo urpmi --auto-update --test
medium "Core Release (zmrepo1)" is up-to-date
medium "Core Updates (zmrepo3)" is up-to-date
medium "Nonfree Release (zmrepo11)" is up-to-date
medium "Nonfree Updates (zmrepo13)" is up-to-date
medium "Tainted Release (zmrepo21)" is up-to-date
medium "Tainted Updates (zmrepo23)" is up-to-date
Packages are up to date
[baz@jackodesktop ~]$

My last mirror sync was 25mins ago 
19/03/2023-23:55: Update complete

I am baffled, it is the same on two different systems.

I have on occasion manually installed and removed kernels during rok testing on both machines, but if anything, I would expect manually installed packages to *not* be removable by urpme --auto-orphans rather than the other way round.

Have you been using dnf on that install?

Assignee: bugsquad => kernel

(In reply to Dave Hodgins from comment #5)
> Have you been using dnf on that install?

I stay away from dnf.
The only time I have used it recently was testing the PA-pipewire switching in Mga9, but not in a Mga8 system.

Why do you think this is a bug? AFAIK (both from long usage and from reading the source code) this is the intended behaviour; urpme --auto-orphans is meant to remove old kernels. It will only keep:

1. The currently running kernel.
2. The kernel required by the currently installed kernel-*-latest package.
3. Any kernels that are marked as being manually installed (i.e aren't
   listed in /var/lib/rpm/installed-through-deps.list).

I generally run urpme --auto-orphans just after installing a kernel update, which means I get to keep both the running and the latest version.

CC: (none) => mageia

(In reply to Martin Whitaker from comment #7)
> Why do you think this is a bug? AFAIK (both from long usage and from reading
> the source code) this is the intended behaviour; urpme --auto-orphans is
> meant to remove old kernels. It will only keep:
> 
> 1. The currently running kernel.
> 2. The kernel required by the currently installed kernel-*-latest package.
> 3. Any kernels that are marked as being manually installed (i.e aren't
>    listed in /var/lib/rpm/installed-through-deps.list).

OK, thanks Martin, that's interesting.
So when the kernel-*-latest package is updated and the new kernel it pulls in is rebooted, the previous kernel would be removed by --auto-orphans (if run) leaving no backup at all!
I have not noticed this behaviour previously or in Mga9 but I will check.

I have just tested this on a Mga8 server running desktop kernels.

[root@zmhost baz]# rpm -qa|grep "kernel-desktop"
kernel-desktop-latest-5.15.88-1.mga8
kernel-desktop-5.15.74-1.mga8-1-1.mga8
kernel-desktop-devel-latest-5.15.88-1.mga8
kernel-desktop-devel-5.15.88-1.mga8-1-1.mga8
kernel-desktop-5.15.88-1.mga8-1-1.mga8
kernel-desktop-devel-5.15.65-1.mga8-1-1.mga8

[root@zmhost baz]# urpme --auto-orphans --test
To satisfy dependencies, the following package will be removed (78MB):
  
(orphan package)
  kernel-desktop-5.15.74-1.mga8-1-1.mga8.x86_64
Remove 1 package? (y/N) n

This would leave only the running kernel (5.15.88), which to me would seem to be a bug.

>
> I generally run urpme --auto-orphans just after installing a kernel update,
> which means I get to keep both the running and the latest version.

Yes I can see now that 'workaround' is sensible, but not AFAIK commonly understood by many users.
The main danger sited is regarding -task packages but this is another one I had not appreciated.

I have never noticed --auto-orphans to remove kernels until recently as kernels just increased in number ad infinitum. 

The other night I wrote a bash wrapper for urpme --auto-orphans to filter out kernels
so I could remove many orphans without touching kernel packages on a Mga8 machine, leaving rok to deal with them.
Maybe this approach could be incorporated into urpme.

Another Mga8 remote machine I maintain:

 1   : Keep  : U   : kernel-desktop-5.15.88-1.mga8-1-1.mga8.x86_64 Wed 22 Feb 2023 13:53:59 GMT 
 2   : Keep  :     : kernel-desktop-5.15.74-1.mga8-1-1.mga8.x86_64 Thu 03 Nov 2022 11:25:47 GMT 
 3   : Keep  :     : kernel-desktop-5.15.35-2.mga8-1-1.mga8.x86_64 Sun 15 May 2022 13:19:02 BST 
               U = In use now
Tap spacebar to exit
[ste@localhost ~]$ urpme --auto-orphans --test
To satisfy dependencies, the following 2 packages will be removed (155MB):
  
(orphan packages)
  kernel-desktop-5.15.35-2.mga8-1-1.mga8.x86_64
  kernel-desktop-5.15.74-1.mga8-1-1.mga8.x86_64
Remove 2 packages? (y/N)

I am puzzled as to why others are not seeing this behaviour, even if it is expected, and why I have never noticed it before.

OMG I really don't understand this.
I just tested another machine and it behaves exactly as I am used to seeing:

                        Welcome to 'remove-old-kernels' Interactive

 System: Mageia release 8 (Official) for x86_64 | Kernels in /boot/:3 | AUTO:1 | KEEP:3  
 ==> kernel-desktop
 1   : Keep  : U   : kernel-desktop-5.15.98-1.mga8-1-1.mga8.x86_64 Sun 12 Mar 2023 10:43:28 GMT 
 2   : Keep  :     : kernel-desktop-5.15.88-1.mga8-1-1.mga8.x86_64 Mon 23 Jan 2023 10:45:26 GMT 
 3   : Keep  :     : kernel-desktop-5.15.82-1.mga8-1-1.mga8.x86_64 Sun 18 Dec 2022 09:56:54 GMT 
 ==> kernel-desktop-devel
 1   : Keep  :     : kernel-desktop-devel-5.15.98-1.mga8-1-1.mga8.x86_64 Sun 12 Mar 2023 10:42:58 GMT 
 2   : Keep  :     : kernel-desktop-devel-5.15.88-1.mga8-1-1.mga8.x86_64 Mon 23 Jan 2023 10:45:18 GMT 
 3   : Keep  :     : kernel-desktop-devel-5.15.82-1.mga8-1-1.mga8.x86_64 Sun 18 Dec 2022 09:56:46 GMT 
               U = In use now
[baz@acer ~]$ urpme --auto-orphans --test
No orphans to remove
[baz@acer ~]$

I am totally baffled now.

Check the output of 'grep kernel /var/lib/rpm/installed-through-deps.list'. Also check if you have other packages installed that depend on a specific kernel version.

On 'acer' which is not trying to remove them:

[baz@acer ~]$ grep kernel /var/lib/rpm/installed-through-deps.list
kernel-desktop-devel-latest
kernel-userspace-headers

All these others are trying to remove previous kernels:

On 'leno':

[baz@leno ~]$ grep kernel /var/lib/rpm/installed-through-deps.list
kernel-desktop-5.15.82-1.mga8
kernel-desktop-5.15.88-1.mga8
kernel-desktop-devel-5.15.82-1.mga8
kernel-desktop-devel-5.15.88-1.mga8
kernel-desktop-devel-5.15.98-1.mga8
kernel-desktop-devel-latest
kernel-userspace-headers
virtualbox-kernel-5.15.82-desktop-1.mga8
virtualbox-kernel-5.15.88-desktop-1.mga8
kernel-desktop-latest           (recommended)

On ste@localhost:

[ste@localhost ~]$ grep kernel /var/lib/rpm/installed-through-deps.list
kernel-desktop-5.15.35-2.mga8
kernel-desktop-5.15.74-1.mga8
kernel-userspace-headers
kernel-desktop-5.15.88-1.mga8           (required by kernel-desktop-latest-5.15.88-1.mga8.x86_64)
kernel-desktop-5.15.88-1.mga8           (required by kernel-desktop-latest-5.15.88-1.mga8.x86_64)
kernel-desktop-5.15.88-1.mga8           (required by kernel-desktop-latest-5.15.88-1.mga8.x86_64)
kernel-desktop-5.15.98-1.mga8           (required by kernel-desktop-latest-5.15.98-1.mga8.x86_64)

On zmhost:

[baz@zmhost ~]$ grep kernel /var/lib/rpm/installed-through-deps.list
kernel-desktop-5.15.74-1.mga8
kernel-desktop-devel-latest
kernel-userspace-headers
kernel-desktop-5.15.88-1.mga8           (required by kernel-desktop-latest-5.15.88-1.mga8.x86_64)

Which ones have dkms packages installed?

(In reply to Dave Hodgins from comment #13)
> Which ones have dkms packages installed?

Could you expand on that? 
Do you mean rpm -qa|grep dkms or are you meaning something in /lib/modules tree?

The first. "rpm -qa dkms*", excluding dkms and dkms-minimal. I.E. actual kmod
packages. I have ...
dkms-rtl8192eu-4.4.1-2.20210403.1.mga8
dkms-sysdig-0.27.1-4.mga8
dkms-virtualbox-7.0.6-1.mga8
dkms-xtables-addons-3.23-1.mga8

on the install where urpme --auto-orphans is not showing the kernel packages
as orphans.

(In reply to Barry Jackson from comment #12)
> On 'acer' which is not trying to remove them:
> 
> [baz@acer ~]$ grep kernel /var/lib/rpm/installed-through-deps.list
> kernel-desktop-devel-latest
> kernel-userspace-headers

So on this machine the kernels are "marked as manually installed" i.e. not listed as installed through dependencies, so --auto-orphans doesn't try to remove them. How they ended up like that is another question. What method do you use to install updates?

(In reply to Dave Hodgins from comment #15)
> The first. "rpm -qa dkms*", excluding dkms and dkms-minimal. I.E. actual kmod
> packages. I have ...
> dkms-rtl8192eu-4.4.1-2.20210403.1.mga8
> dkms-sysdig-0.27.1-4.mga8
> dkms-virtualbox-7.0.6-1.mga8
> dkms-xtables-addons-3.23-1.mga8
> 
> on the install where urpme --auto-orphans is not showing the kernel packages
> as orphans.

Ah OK

On acer which shows no orphans:

[baz@acer ~]$ rpm -qa|grep dkms
dkms-broadcom-wl-6.30.223.271-66.mga8.nonfree
dkms-2.0.19-41.mga8
dkms-minimal-2.0.19-41.mga8
[baz@acer ~]$

On zmhost which does:

[root@zmhost baz]# rpm -qa|grep dkms
[root@zmhost baz]#

On ste@localhost which does:

[ste@localhost ~]$ rpm -qa|grep dkms
[ste@localhost ~]$

So this is the reason why urpme --auto-orphans removes old kernels for some people and not others which has been discussed lots over the years - well done!

Created attachment 13746 [details]
rok -l

(In reply to Martin Whitaker from comment #16)
> (In reply to Barry Jackson from comment #12)
> > On 'acer' which is not trying to remove them:
> > 
> > [baz@acer ~]$ grep kernel /var/lib/rpm/installed-through-deps.list
> > kernel-desktop-devel-latest
> > kernel-userspace-headers
> 
> So on this machine the kernels are "marked as manually installed" i.e. not
> listed as installed through dependencies, so --auto-orphans doesn't try to
> remove them. How they ended up like that is another question. What method do
> you use to install updates?

acer is my wife's laptop, she does nothing 'admin' beyond updating using the applet when prompted. rok is installed and runs as default. log is attached.

On the other machines, do you use the applet or do you use the command line?

I think dkms is a red herring. I have it installed and building a kernel module on one of my machines where --auto-orphans removes old kernels.

(In reply to Martin Whitaker from comment #20)
> On the other machines, do you use the applet or do you use the command line?
> 
I tend not to use the applet, as I always need to check which media is enabled beforehand which I would do using rpmdrake. Recently I have been using a desktop icon which has:
Exec=su --login root -c "urpmi --auto-update --auto --exclude-media Extra"; sleep 2
which stops me accidentally doing an update with my local "Extra" repo enabled.

zmrepo and the ste@ are remote so mainly command line although I have used rpmdrake/drakupdate occasionally. Certainly never dnf on any.

> I think dkms is a red herring. I have it installed and building a kernel
> module on one of my machines where --auto-orphans removes old kernels.

Oh that's sad, it looked promising.

I noticed in the rok log in #18 that on only one occasion urpme updated the installed-through-deps.list. What triggered that I wonder on just one update? It was the first time that the cron job had removed a kernel. (Manual use is not logged).

FWIW On one machine I tested removing kernel packages from the installed-through-deps.list and none were then offered for removal by --auto-orphans.

On testing, it turns out that urpmi --auto-select adds any updated kernels to installed-through-deps.list, but drakrpm-update (and hence mgaapplet) do not. So I think that completes the explanation.

(In reply to Martin Whitaker from comment #22)
> On testing, it turns out that urpmi --auto-select adds any updated kernels
> to installed-through-deps.list,

which is the same as --auto-update (without the urpmi.update -a) so these should be kept by --auto-orphans

> but drakrpm-update (and hence mgaapplet) do
> not. So I think that completes the explanation.

Yes, however this is another bug. Surely the outcome should be the same no matter how an update is performed using Mageia tools.

My conclusion from all this is that updating kernels at present is Russian roulette, --auto-orphans may or may not remove all but the running kernel depending on which tool is used for updating, when it is run relative to an update and possibly whether certain dkms modules are installed.

I would suggest that kernels should not be added at all to installed-through-deps.list as we now have rok to remove them in a controlled manner.

Is there any potential problem with that?

Without some solution to this, continuously upgraded and updated machines with lots of orphan packages will potentially lose all backup kernels when --auto-orphans is run to clean them up.

Read in #23 para 2 "so these should NOT be kept by --auto-orphans"

(In reply to Barry Jackson from comment #23)
> (In reply to Martin Whitaker from comment #22)
> > On testing, it turns out that urpmi --auto-select adds any updated kernels
> > to installed-through-deps.list,
> 
> which is the same as --auto-update (without the urpmi.update -a) so these
> should be kept by --auto-orphans
> 
> > but drakrpm-update (and hence mgaapplet) do
> > not. So I think that completes the explanation.
> 
> Yes, however this is another bug. Surely the outcome should be the same no
> matter how an update is performed using Mageia tools.
> 
> My conclusion from all this is that updating kernels at present is Russian
> roulette, --auto-orphans may or may not remove all but the running kernel
> depending on which tool is used for updating, when it is run relative to an
> update and possibly whether certain dkms modules are installed.
> 
> I would suggest that kernels should not be added at all to
> installed-through-deps.list as we now have rok to remove them in a
> controlled manner.
> 
> Is there any potential problem with that?
> 
> Without some solution to this, continuously upgraded and updated machines
> with lots of orphan packages will potentially lose all backup kernels when
> --auto-orphans is run to clean them up.

A little bit off topic, but would all these side effects be there if we were using the old kernel naming scheme (like in mga8, where the version is also in package name) instead of the current naming kernel of mga9 which exploits the multiversion capability of rpm?

CC: (none) => ghibomgx

(In reply to Giuseppe Ghibò from comment #25)
> A little bit off topic, but would all these side effects be there if we were
> using the old kernel naming scheme (like in mga8, where the version is also
> in package name) instead of the current naming kernel of mga9 which exploits
> the multiversion capability of rpm?

This is a Mageia 8 issue. The new kernel naming scheme causes a different problem with --auto-orphans - see bug 31127.

For Mageia 8 I have written this little wrapper for urpme --auto-orphans which I have tested on several machines now.
This cleans up regular orphans without risk of wiping out kernels kept by rok.

Use at your own risk.

#!/usr/bin/bash
# urpmeao
#
# A wrapper for urpme --auto-orphans for Mageia 8 to avoid removing backup kernels.
# See https://bugs.mageia.org/show_bug.cgi?id=31699
#######################

((UID)) && { echo "Must be root to run $0"; exit 1; }

for p in $(grep kernel /var/lib/rpm/installed-through-deps.list|tr '\t' ' '|tr -s ' '|cut -d ' ' -f1|grep -Ev "latest|headers|kernels|virtualbox|xtables"); do
    # Remove kernels from installed-through-deps.list
    sed -i "/$p/d" /var/lib/rpm/installed-through-deps.list
done

# Run urpme --auto-orphans against modified installed-through-deps.list
urpme --auto-orphans
# End of script 


@Giuseppe
I have not encountered this issue in Mga9.

This is in Mageia 9 too.

$ sudo LC_ALL=C urpme --auto-orphans
writing /var/lib/rpm/installed-through-deps.list
To satisfy dependencies, the following 108 packages will be removed (417MB):
  
(orphan packages)
...
  kernel-desktop-6.3.8-1.mga9.x86_64
  kernel-desktop-6.3.8-2.mga9.x86_64
  kernel-desktop-devel-6.3.8-1.mga9.x86_64
  kernel-desktop-devel-6.3.8-2.mga9.x86_64
  kernel-desktop-devel-6.3.9-1.mga9.x86_64
...
Remove 108 packages? (y/N) y
...
Removal failed:
        kernel-devel is needed by (installed) dkms-2.0.19-46.mga9.noarch
        kernel-devel is needed by (installed) dkms-2.0.19-46.mga9.noarch
        kernel-desktop-6.3.8-2.mga9 is needed by (installed) virtualbox-kernel-6.3.8-desktop-2.mga9-7.0.8-20.mga9.x86_64
        kernel-desktop-6.3.8-1.mga9 is needed by (installed) virtualbox-kernel-6.3.8-desktop-1.mga9-7.0.8-18.mga9.x86_64
        kernel-devel is needed by (installed) dkms-2.0.19-46.mga9.noarch


remove-old-kernels say correctly
 ==> kernel-desktop
 1   : Keep  : U   : kernel-desktop-6.3.9-1.mga9.x86_64            Wed Jun 21 21:08:26 2023 
 2   : Keep  :     : kernel-desktop-6.3.8-2.mga9.x86_64            Tue Jun 20 09:06:23 2023 
 3   : Keep  :     : kernel-desktop-6.3.8-1.mga9.x86_64            Wed Jun 14 23:43:05 2023 
 ==> kernel-desktop-devel
 1   : Keep  :     : kernel-desktop-devel-6.3.9-1.mga9.x86_64      Wed Jun 21 21:08:32 2023 
 2   : Keep  :     : kernel-desktop-devel-6.3.8-2.mga9.x86_64      Tue Jun 20 09:06:30 2023 
 3   : Keep  :     : kernel-desktop-devel-6.3.8-1.mga9.x86_64      Wed Jun 14 23:43:29 2023 

----

When urpme stops because it can not remove, it renders urpme --auto-orphans not usable for cleaning unused packages at all.  (except for using the script in previous comment, or similar or manual method.)

But if it by some reason succeed (such as if i had uninstalled virtualbox or dkms)?
There are also some other packages it wants to remove which i dont it should, like lvm2, btrfs-progs, mariadb...
And that is a potential big problem if users try it.

Related bugs, possibly same cause

Bug 31382 - urpme --auto-orphans wants to uninstall too much

Bug 31127 - urpme --auto-orphans fails on kernel-latest packages

Bug 16134 - urpme --auto-orphans proposes to remove package that can't be removed

Priority: Normal => High
Whiteboard: (none) => MGA8TOO
Summary: urpmi --auto-orphans can't be used without removing all backup kernels => urpme --auto-orphans can't be used without removing all backup kernels
CC: (none) => kernel
Assignee: kernel => mageiatools
Version: 8 => Cauldron
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=31382, https://bugs.mageia.org/show_bug.cgi?id=31127, https://bugs.mageia.org/show_bug.cgi?id=16134

It have been broken long enough,

Entered in 
 https://wiki.mageia.org/en/Removing_packages#Related_bug_reports

It also deserves entry in erratas

Keywords: (none) => FOR_ERRATA8, FOR_ERRATA9

https://wiki.mageia.org/en/Mageia_9_Errata#Mageia_tools
https://wiki.mageia.org/en/Mageia_8_Errata#Miscellaneous

Keywords: FOR_ERRATA8, FOR_ERRATA9 => IN_ERRATA8, IN_ERRATA9

is there a solution to skip the current running kernel?
It still tries to remove it and fails - so this function is totally broken

CC: (none) => mageia

*** Bug 32327 has been marked as a duplicate of this bug. ***

CC: (none) => saveurlinux