Paul wrote:
> On 2/10/2023 1:07 PM, Dan Purgert wrote:
>> What is the _exact_ error you're getting?  Also are you launching it
>> from terminal or from the GUI?
>>
>
> ipscan_3.9.0_amd64.deb
>
> ipscan_3.9.0_amd64.deb\data.tar\.\usr\bin\ipscan
>
> #!/bin/sh
> java=$JAVA_HOME/bin/java
> [ ! -e $java ] && java=java
> $java --add-opens java.base/java.net=ALL-UNNAMED -jar
> /usr/lib*/ipscan/ipscan*.jar "$@"
> [ $? != 0 ] && notify-send "You need Java/OpenJDK 11+ to run ipscan"
>
> It's not an error message. If the script
> does not run properly for any reason, it prints
>
>    "You need Java/OpenJDK 11+ to run ipscan"
>
> Debug as you see fit!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Rob - Do you still have $JAVA_HOME set to the Java 1.8 version?

The second line of that ipscan script:

java=$JAVA_HOME/bin/java

is explicitly using the Java installed under $JAVA_HOME if it's set (the
next line uses the default Java if $JAVA_HOME is not set). As others
have noted, $JAVA_HOME isn't usually set. It's used to force things to
use a particular version of Java. In your case, having $JAVA_HOME set
to /usr/lib/jvm/java-8-openjdk-amd64/jre/ is telling the ipscan script
to use the version of Java installed there. It's doing as it's told (by
way of setting $JAVA_HOME), and complaining that it needs a newer
version of Java than it's been told to use.

It seems you need to work out why $JAVA_HOME is being set globally on
your system (or at least under your user account). Unfortunately there
are a lot of places where that could be done. It may be that the
install script for some other package has modified the system-wide
configuration (which doesn't seem like something it should really have
done), or that you've previously followed some ill-advised instructions
to set $JAVA_HOME globally to fix a problem with something else that
required Java 1.8.

As mentioned elsewhere, some of the places $JAVA_HOME might be set include:
~/.bashrc
~/.profile
/etc/bash.bashrc
/etc/profile
/etc/profile.d/ (any files under this directory)

There are various other places it could also be set, but I'd start by
looking in those for lines like:
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/jre/

--
Mark.

On 10/02/2023 19:46, Mark Bourne wrote:
> sudo update-alternatives --config java

When I ran

ob@rob-Z97:~$ sudo update-alternatives --config java
[sudo] password for rob:
There are 2 choices for the alternative java (providing /usr/bin/java).

Selection Path Priority
Status
------------------------------------------------------------
0 /usr/lib/jvm/java-11-openjdk-amd64/bin/java 1111
auto mode
* 1 /usr/lib/jvm/java-11-openjdk-amd64/bin/java 1111
manual mode
2 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java 1081
manual mode

Press <enter> to keep the current choice[*], or type selection number: 0

As you see I opted for 0, because it was auto mode, whatever that means
as against manual mode, but it didn't make any difference to Angry IP

rob@rob-Z97:~$ java -version
openjdk version "11.0.17" 2022-10-18
OpenJDK Runtime Environment (build 11.0.17+8-post-Ubuntu-1ubuntu222.04)
OpenJDK 64-Bit Server VM (build 11.0.17+8-post-Ubuntu-1ubuntu222.04,
mixed mode, sharing)

Thanks

On 10/02/2023 19:01, Mike Easter wrote:
> Rob H wrote:
>> No such luck. I restarted my desktop, tried  to run the program, same
>> error, then un installed the said program, restarted again , then
>> installed Angry IP scan yet again, same problem!!
>
> Is your java -version still ok?
>
Yes , as far as I know it is

On 10/02/2023 19:56, Mike Easter wrote:
> Mike Easter wrote:
>> Rob H wrote:
>>> then installed Angry IP scan yet again, same problem!!
>>
>> Maybe you should uninstall the Oracle/ old java/ stuff.  Personally I
>> would use synaptic, but your call.
>>
> I would use synaptic to 'watch out for' any tendency to 'disrupt'
> important dependencies.  I don't know how to do all that w/ the command
> line.
>

Actually I used synaptic the other day to uninstall really old versions
of java, but they were still there afterwards, and still are even tho'
synaptic says they are not installed.

I have just installed openjdk17 using synaptic and now have this

rob@rob-Z97:~$ java -version
openjdk version "17.0.5" 2022-10-18
OpenJDK Runtime Environment (build 17.0.5+8-Ubuntu-2ubuntu122.04)
OpenJDK 64-Bit Server VM (build 17.0.5+8-Ubuntu-2ubuntu122.04, mixed
mode, sharing)

Still Angry IP is not happy.
As Paul said below, it's not an error message as I thought but a script

'If the script does not run properly for any reason, it prints'

"You need Java/OpenJDK 11+ to run ipscan"

So it looks like it's not going to happen.
Oh well.

Thanks

On 10/02/2023 20:15, Mark Bourne wrote:
> Paul wrote:
>> On 2/10/2023 1:07 PM, Dan Purgert wrote:
>>> What is the _exact_ error you're getting?  Also are you launching it
>>> from terminal or from the GUI?
>>>
>>
>> ipscan_3.9.0_amd64.deb
>>
>> ipscan_3.9.0_amd64.deb\data.tar\.\usr\bin\ipscan
>>
>> #!/bin/sh
>> java=$JAVA_HOME/bin/java
>> [ ! -e $java ] && java=java
>> $java --add-opens java.base/java.net=ALL-UNNAMED -jar
>> /usr/lib*/ipscan/ipscan*.jar "$@"
>> [ $? != 0 ] && notify-send "You need Java/OpenJDK 11+ to run ipscan"
>>
>> It's not an error message. If the script
>> does not run properly for any reason, it prints
>>
>>     "You need Java/OpenJDK 11+ to run ipscan"
>>
>> Debug as you see fit!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
> Rob - Do you still have $JAVA_HOME set to the Java 1.8 version?
>
> The second line of that ipscan script:
>
>   java=$JAVA_HOME/bin/java
>
> is explicitly using the Java installed under $JAVA_HOME if it's set (the
> next line uses the default Java if $JAVA_HOME is not set).  As others
> have noted, $JAVA_HOME isn't usually set.  It's used to force things to
> use a particular version of Java.  In your case, having $JAVA_HOME set
> to /usr/lib/jvm/java-8-openjdk-amd64/jre/ is telling the ipscan script
> to use the version of Java installed there.  It's doing as it's told (by
> way of setting $JAVA_HOME), and complaining that it needs a newer
> version of Java than it's been told to use.
>
> It seems you need to work out why $JAVA_HOME is being set globally on
> your system (or at least under your user account).  Unfortunately there
> are a lot of places where that could be done.  It may be that the
> install script for some other package has modified the system-wide
> configuration (which doesn't seem like something it should really have
> done), or that you've previously followed some ill-advised instructions
> to set $JAVA_HOME globally to fix a problem with something else that
> required Java 1.8.
>
> As mentioned elsewhere, some of the places $JAVA_HOME might be set include:
>   ~/.bashrc
>   ~/.profile
>   /etc/bash.bashrc
>   /etc/profile
>   /etc/profile.d/ (any files under this directory)
>
> There are various other places it could also be set, but I'd start by
> looking in those for lines like:
>   export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/jre/
>

Thanks but I have now installed an older version, 3.6, of ip scan, and
it runs fine.

On 10/02/2023 20:34, Rob H wrote:
> On 10/02/2023 19:56, Mike Easter wrote:
>> Mike Easter wrote:
>>> Rob H wrote:
>>>> then installed Angry IP scan yet again, same problem!!
>>>
>>> Maybe you should uninstall the Oracle/ old java/ stuff.  Personally I
>>> would use synaptic, but your call.
>>>
>> I would use synaptic to 'watch out for' any tendency to 'disrupt'
>> important dependencies.  I don't know how to do all that w/ the
>> command line.
>>
>
> Actually I used synaptic the other day to uninstall really old versions
> of java, but they were still there afterwards, and still are even tho'
> synaptic says they are not installed.
>
> I have just installed openjdk17 using synaptic and now have this
>
> rob@rob-Z97:~$ java -version
> openjdk version "17.0.5" 2022-10-18
> OpenJDK Runtime Environment (build 17.0.5+8-Ubuntu-2ubuntu122.04)
> OpenJDK 64-Bit Server VM (build 17.0.5+8-Ubuntu-2ubuntu122.04, mixed
> mode, sharing)
>
> Still Angry IP is not happy.
> As Paul said below, it's not an error message as I thought but a script
>
> 'If the script does not run properly for any reason, it prints'
>
>    "You need Java/OpenJDK 11+ to run ipscan"
>
> So it looks like it's not going to happen.
> Oh well.
>
> Thanks

I have installed an older version, 3.6, of ipscan and it runs fine.

On 10/02/2023 20:45, Rob H wrote:
> On 10/02/2023 20:15, Mark Bourne wrote:
>> Paul wrote:
>>> On 2/10/2023 1:07 PM, Dan Purgert wrote:
>>>> What is the _exact_ error you're getting?  Also are you launching it
>>>> from terminal or from the GUI?
>>>>
>>>
>>> ipscan_3.9.0_amd64.deb
>>>
>>> ipscan_3.9.0_amd64.deb\data.tar\.\usr\bin\ipscan
>>>
>>> #!/bin/sh
>>> java=$JAVA_HOME/bin/java
>>> [ ! -e $java ] && java=java
>>> $java --add-opens java.base/java.net=ALL-UNNAMED -jar
>>> /usr/lib*/ipscan/ipscan*.jar "$@"
>>> [ $? != 0 ] && notify-send "You need Java/OpenJDK 11+ to run ipscan"
>>>
>>> It's not an error message. If the script
>>> does not run properly for any reason, it prints
>>>
>>>     "You need Java/OpenJDK 11+ to run ipscan"
>>>
>>> Debug as you see fit!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>
>> Rob - Do you still have $JAVA_HOME set to the Java 1.8 version?
>>
>> The second line of that ipscan script:
>>
>>    java=$JAVA_HOME/bin/java
>>
>> is explicitly using the Java installed under $JAVA_HOME if it's set
>> (the next line uses the default Java if $JAVA_HOME is not set).  As
>> others have noted, $JAVA_HOME isn't usually set.  It's used to force
>> things to use a particular version of Java.  In your case, having
>> $JAVA_HOME set to /usr/lib/jvm/java-8-openjdk-amd64/jre/ is telling
>> the ipscan script to use the version of Java installed there.  It's
>> doing as it's told (by way of setting $JAVA_HOME), and complaining
>> that it needs a newer version of Java than it's been told to use.
>>
>> It seems you need to work out why $JAVA_HOME is being set globally on
>> your system (or at least under your user account).  Unfortunately
>> there are a lot of places where that could be done.  It may be that
>> the install script for some other package has modified the system-wide
>> configuration (which doesn't seem like something it should really have
>> done), or that you've previously followed some ill-advised
>> instructions to set $JAVA_HOME globally to fix a problem with
>> something else that required Java 1.8.
>>
>> As mentioned elsewhere, some of the places $JAVA_HOME might be set
>> include:
>>    ~/.bashrc
>>    ~/.profile
>>    /etc/bash.bashrc
>>    /etc/profile
>>    /etc/profile.d/ (any files under this directory)
>>
>> There are various other places it could also be set, but I'd start by
>> looking in those for lines like:
>>    export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/jre/
>>
>
> Thanks but I have now installed an older version, 3.6, of ip scan, and
> it runs fine.
>
Oh dear I spoke to soon. ipscan opens but won't run :
This is why:
java.lang.NullPointerException:Cannot invoke
"java.lang.Class.getConstructor(java.lang.ClassI])" because
"pingerClass" is null

On 10/02/2023 20:51, Rob H wrote:
> On 10/02/2023 20:45, Rob H wrote:
>> On 10/02/2023 20:15, Mark Bourne wrote:
>>> Paul wrote:
>>>> On 2/10/2023 1:07 PM, Dan Purgert wrote:
>>>>> What is the _exact_ error you're getting?  Also are you launching it
>>>>> from terminal or from the GUI?
>>>>>
>>>>
>>>> ipscan_3.9.0_amd64.deb
>>>>
>>>> ipscan_3.9.0_amd64.deb\data.tar\.\usr\bin\ipscan
>>>>
>>>> #!/bin/sh
>>>> java=$JAVA_HOME/bin/java
>>>> [ ! -e $java ] && java=java
>>>> $java --add-opens java.base/java.net=ALL-UNNAMED -jar
>>>> /usr/lib*/ipscan/ipscan*.jar "$@"
>>>> [ $? != 0 ] && notify-send "You need Java/OpenJDK 11+ to run ipscan"
>>>>
>>>> It's not an error message. If the script
>>>> does not run properly for any reason, it prints
>>>>
>>>>     "You need Java/OpenJDK 11+ to run ipscan"
>>>>
>>>> Debug as you see fit!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>
>>> Rob - Do you still have $JAVA_HOME set to the Java 1.8 version?
>>>
>>> The second line of that ipscan script:
>>>
>>>    java=$JAVA_HOME/bin/java
>>>
>>> is explicitly using the Java installed under $JAVA_HOME if it's set
>>> (the next line uses the default Java if $JAVA_HOME is not set).  As
>>> others have noted, $JAVA_HOME isn't usually set.  It's used to force
>>> things to use a particular version of Java.  In your case, having
>>> $JAVA_HOME set to /usr/lib/jvm/java-8-openjdk-amd64/jre/ is telling
>>> the ipscan script to use the version of Java installed there.  It's
>>> doing as it's told (by way of setting $JAVA_HOME), and complaining
>>> that it needs a newer version of Java than it's been told to use.
>>>
>>> It seems you need to work out why $JAVA_HOME is being set globally on
>>> your system (or at least under your user account).  Unfortunately
>>> there are a lot of places where that could be done.  It may be that
>>> the install script for some other package has modified the
>>> system-wide configuration (which doesn't seem like something it
>>> should really have done), or that you've previously followed some
>>> ill-advised instructions to set $JAVA_HOME globally to fix a problem
>>> with something else that required Java 1.8.
>>>
>>> As mentioned elsewhere, some of the places $JAVA_HOME might be set
>>> include:
>>>    ~/.bashrc
>>>    ~/.profile
>>>    /etc/bash.bashrc
>>>    /etc/profile
>>>    /etc/profile.d/ (any files under this directory)
>>>
>>> There are various other places it could also be set, but I'd start by
>>> looking in those for lines like:
>>>    export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/jre/
>>>
>>
>> Thanks but I have now installed an older version, 3.71, of ip scan, and
>> it runs fine.
>>

On 10/02/2023 20:46, Rob H wrote:
> On 10/02/2023 20:34, Rob H wrote:
>> On 10/02/2023 19:56, Mike Easter wrote:
>>> Mike Easter wrote:
>>>> Rob H wrote:
>>>>> then installed Angry IP scan yet again, same problem!!
>>>>
>>>> Maybe you should uninstall the Oracle/ old java/ stuff.  Personally
>>>> I would use synaptic, but your call.
>>>>
>>> I would use synaptic to 'watch out for' any tendency to 'disrupt'
>>> important dependencies.  I don't know how to do all that w/ the
>>> command line.
>>>
>>
>> Actually I used synaptic the other day to uninstall really old
>> versions of java, but they were still there afterwards, and still are
>> even tho' synaptic says they are not installed.
>>
>> I have just installed openjdk17 using synaptic and now have this
>>
>> rob@rob-Z97:~$ java -version
>> openjdk version "17.0.5" 2022-10-18
>> OpenJDK Runtime Environment (build 17.0.5+8-Ubuntu-2ubuntu122.04)
>> OpenJDK 64-Bit Server VM (build 17.0.5+8-Ubuntu-2ubuntu122.04, mixed
>> mode, sharing)
>>
>> Still Angry IP is not happy.
>> As Paul said below, it's not an error message as I thought but a script
>>
>> 'If the script does not run properly for any reason, it prints'
>>
>>     "You need Java/OpenJDK 11+ to run ipscan"
>>
>> So it looks like it's not going to happen.
>> Oh well.
>>
>> Thanks
>
> I have installed an older version, 3.71, of ipscan and it runs fine.

On 2/10/23 05:18, Dan Purgert wrote:
> On 2023-02-10, Rob H wrote:

>> rob@rob-Z97:~$ nmap. no java dependencies!
>> Command 'nmap.' not found, did you mean:
>> command 'nmap' from deb nmap (7.91+dfsg1+really7.80+dfsg1-2build1)
>> Try: sudo apt install <deb name>
>
>
>> I did then install nmap, but still the same error.
>
>> Thanks
>
> the command is 'nmap'; not 'nmap. no java dependencies!'
>

LOL. Oh, dear!
I had no idea how n()()b-friendly I had to be.

thx.

Dear OP (Rob H), after you install nmap, try this:
https://www.stationx.net/nmap-cheat-sheet/

stepore wrote:
> Dear OP (Rob H), after you install nmap, try this:
> https://www.stationx.net/nmap-cheat-sheet/

Also, there is a python-based graphical frontend for nmap, zenmap which
is available as a flatpak at flathub for Mint which uses flatpak;
there's no .deb or .ppa.

https://flathub.org/apps/details/org.nmap.Zenmap
v 7.93 '22 Sep

I think there used to be a .deb for previous Ub distro/s. Flatpaks seem
to have a lot of baggage. I installed it on a live LM 21.1 and it
needed a ~900 meg dl and ~ 3G of storage.

https://nmap.org/zenmap/

There is also a .rpm zenmap there I didn't see before I did the flatpak.
I would've rather checked that out.

https://nmap.org/download Optional Zenmap GUI (all platforms):
zenmap-7.93-1.noarch.rpm

--
Mike Easter

Mike Easter wrote:
> There is also a .rpm zenmap there I didn't see before I did the flatpak.
>  I would've rather checked that out.
>
> https://nmap.org/download  Optional Zenmap GUI (all platforms):
> zenmap-7.93-1.noarch.rpm

This should be easy to resolve, but I don't know how.

- the flatpak route worked ok
- rebooted the live Mint 21.1, installed nmap and alien, dl/ed the
zenmap .rpm, used alien to convert the .rpm to a .deb, tried to run
zenmap from the menu, no joy; used command for zenmap which reported

/usr/bin/env: 'python': No such file or directory

.... which is because all of my python is python3.

Oh, nevermind about that; I fixed the python problem w/ the package
python-is-python3, but now zenmap doesn't run for more complicated reasons.

I'm not going to paste all that in here; but for me, if I were going to
use zenmap in this 21.1 distro, I would use the flatpak so I don't have
to solve the coding problems from installing the alienized .rpm .deb
package.

--
Mike Easter

Mike Easter wrote:
> /usr/bin/env: 'python': No such file or directory
>
> ... which is because all of my python is python3.

Ooh. I think zenmap expects python 2.7 because the .deb package
contains a python2.7 dir.

Hmm. Reading elsewhere,

> Luckily someone has forked nmap and updated Zenmap to Python 3. You can install from this source fairly easily:

https://askubuntu.com/questions/1421263/cant-install-zenmap-on-ubuntu-22-04-due-to-dependency-issues

Apparently Kali uses kaboxer to solve the problem; presumably that is
something like flatpak.

--
Mike Easter

On 11/02/2023 16:34, Mike Easter wrote:
> Mike Easter wrote:
>> There is also a .rpm zenmap there I didn't see before I did the
>> flatpak.   I would've rather checked that out.
>>
>> https://nmap.org/download  Optional Zenmap GUI (all platforms):
>> zenmap-7.93-1.noarch.rpm
>
> This should be easy to resolve, but I don't know how.
>
>  - the flatpak route worked ok
>  - rebooted the live Mint 21.1, installed nmap and alien, dl/ed the
> zenmap .rpm, used alien to convert the .rpm to a .deb, tried to run
> zenmap from the menu, no joy; used command for zenmap which reported
>
> /usr/bin/env: 'python': No such file or directory
>
> ... which is because all of my python is python3.
>
> Oh, nevermind about that; I fixed the python problem w/ the package
> python-is-python3, but now zenmap doesn't run for more complicated reasons.
>
> I'm not going to paste all that in here; but for me, if I were going to
> use zenmap in this 21.1 distro, I would use the flatpak so I don't have
> to solve the coding problems from installing the alienized .rpm .deb
> package.
>

I don't know if you have read or seen my posts from later yesterday, but
I have solved the problem by using and older version of ipscan. Version
3.71 runs without any problems at all.

Thanks

Rob H wrote:
> I don't know if you have read or seen my posts from later yesterday, but
> I have solved the problem by using and older version of ipscan. Version
> 3.71 runs without any problems at all.

I've been reading some articles comparing the features of angryip w/
other alternatives and it comes out pretty good.

It's frustrating that the java situation is so 'jumbled'.

Is your 'original' install (before upgrading steps) 'way back' in the
past; and did you have occasion to install Oracle's java back then?

--
Mike Easter

Mike Easter wrote:
> Rob H wrote:
>>
>> I have solved the problem by using and older version of ipscan.
>> Version 3.71 runs without any problems at all.
>
> I've been reading some articles comparing the features of angryip w/
> other alternatives and it comes out pretty good.
>
Personally I don't do any kind of 'port scanning', so I don't know what
I would do w/ that ipscan, but I do install and use the parts of
'Network tools' which is available in the Mint repo/s as gnome-nettool
and includes

* ifconfig
* ping
* netstat
* traceroute
* port scanning
* DNS lookup
* finger
* whois

--
Mike Easter

On 11/02/2023 17:46, Mike Easter wrote:
> Rob H wrote:
>> I don't know if you have read or seen my posts from later yesterday,
>> but I have solved the problem by using and older version of ipscan.
>> Version 3.71 runs without any problems at all.
>
> I've been reading some articles comparing the features of angryip w/
> other alternatives and it comes out pretty good.
>
> It's frustrating that the java situation is so 'jumbled'.
>
> Is your 'original' install (before upgrading steps) 'way back' in the
> past; and did you have occasion to install Oracle's java back then?
>
>

Yes I did install oracle's java a few days ago, but it didn't help ipscan.

Rob H wrote:
> Yes I did install oracle's java a few days ago, but it didn't help ipscan.

But what v. Mint was your 'original' install? The /one/ before the last
upgrade, or sometime much prior to that?

--
Mike Easter

On 11/02/2023 19:34, Mike Easter wrote:
> Rob H wrote:
>> Yes I did install oracle's java a few days ago, but it didn't help
>> ipscan.
>
> But what v. Mint was your 'original' install?  The /one/ before the last
> upgrade, or sometime much prior to that?
>
It is 21.1, as I upgraded last week or so, before I had the problem with
ipscan

Rob H wrote:
> It is 21.1, as I upgraded last week or so, before I had the problem with
> ipscan

So your original 'fresh' install was 21.1 which worked w/ ipscan; then
you upped to 21.1, then ipscan didn't work, then you tried Oracle and so
forth since you started this thread here. That is correct?

--
Mike Easter

Wait; that can't be right. 21.1 upped to 21.1

Mike Easter wrote:
> Rob H wrote:
>> It is 21.1, as I upgraded last week or so, before I had the problem
>> with ipscan
>
> So your original 'fresh' install was 21.1 which worked w/ ipscan; then
> you upped to 21.1, then ipscan didn't work, then you tried Oracle and so
> forth since you started this thread here.  That is correct?
>
Earlier Rob H said:
> I have been using Angry IP scanner for a number of years with any problems.
> Very recently I upgraded my Linux Mint to 21.1,

My question was, how many versions since a fresh install have been on
the system?

Something preceded 21.1 (because you said you upgraded); maybe something
earlier preceded that, and so forth.

--
Mike Easter

On 11/02/2023 20:41, Mike Easter wrote:
> Wait; that can't be right. 21.1 upped to 21.1
>
> Mike Easter wrote:
>> Rob H wrote:
>>> It is 21.1, as I upgraded last week or so, before I had the problem
>>> with ipscan
>>
>> So your original 'fresh' install was 21.1 which worked w/ ipscan; then
>> you upped to 21.1, then ipscan didn't work, then you tried Oracle and
>> so forth since you started this thread here.  That is correct?
>>
> Earlier Rob H said:
>> I have been using Angry IP scanner for a number of years with any
>> problems.
>> Very recently I upgraded my Linux Mint to 21.1,
>
> My question was, how many versions since a fresh install have been on
> the system?
>
> Something preceded 21.1 (because you said you upgraded); maybe something
> earlier preceded that, and so forth.
>

Well as fas as I can remember, I have been using linux Ubuntu since
version 17 and then moved to Min at version 19. IPscan worked all the
way up to prior 21.1

On 11/02/2023 20:36, Mike Easter wrote:
> Rob H wrote:
>> It is 21.1, as I upgraded last week or so, before I had the problem
>> with ipscan
>
> So your original 'fresh' install was 21.1 which worked w/ ipscan; then
> you upped to 21.1, then ipscan didn't work, then you tried Oracle and so
> forth since you started this thread here.  That is correct?
>
No, it seemed , if you like, stopped working as soon as I upgraded to
Mint 21.1

Rob H wrote:
> moved to Min at version 19. IPscan worked all the way up to prior 21.1

gotit.

--
Mike Easter

Rob H wrote:
> Mike Easter wrote:
>> Rob H wrote:
>>> It is 21.1, as I upgraded last week or so, before I had the problem
>>> with ipscan
>>
>> So your original 'fresh' install was 21.1 which worked w/ ipscan; then
>> you upped to 21.1, then ipscan didn't work, then you tried Oracle and
>> so forth since you started this thread here.  That is correct?
>>
> No, it seemed , if you like, stopped working as soon as I upgraded to
> Mint 21.1

Yeah I think I have the whole picture now; in the beginning the Mint
install was 19 which was progressively upped w/ satisfactory performance
of ipscan up until the last up to 21.1, and 'only then' did you
experiment w/ installing Oracle's java during the thread here.

--
Mike Easter