A few weeks ago, all of my Appimages stopped working. When I click on
any of them, I am getting an error with the following message:

Failed to register AppImage in AppImageLauncherFS: could not open map file.

While I can get by if some of the Apps don't work, there are others I
need to have working so would appreciate any assistance to correct this.

Thanks in advance,
Wayne S

18.04 is quite old and partially out of support, maybe upgrade to
22.04 and then try again.

On 8/31/22 14:50, Marco Moock wrote:
> 18.04 is quite old and partially out of support, maybe upgrade to
> 22.04 and then try again.
>

Interesting, was going to try going with 20 first but says not enough
space on /. Not sure what's taking that up. Does / signify places like
the desktop too as I have a lot of stuff on the desktop? I tried the
apt clean as suggested but no difference and nothing in the trash.

On 8/31/2022 3:32 PM, wAYNE wrote:
> On 8/31/22 14:50, Marco Moock wrote:
>> 18.04 is quite old and partially out of support, maybe upgrade to
>> 22.04 and then try again.
>>
>
> Interesting, was going to try going with 20 first but says not enough space on /.  Not sure what's taking that up.  Does / signify places like the desktop too as I have a lot of stuff on the desktop?  I tried the apt clean as suggested but no difference and nothing in the trash.

I use "df" command for a quick review. "df" is Disk Free.

The "gnome-disks", for mounted volumes, graphically shows how
full mounted partitions are, when you click on the partition
in the GUI.

You can expand the partition... if there is room to the right.
You can use gparted, with a LiveDVD as the booted OS, to
do some disk editing.

A typical giant waste of space, is if you are a QEMU
user and wave around one or two QCOWs for fun :-) Since
the QCOW files are hidden in a root-owned location, you
have to run your disk-listing programs as root.

Analysis of disk contents (the slash partition) can
be done with one of the dirstat programs, like kdirstat
or qdirstat. sudo qdirstat / is an example of a command
for this job.

While this picture is not an entire recipe, I can tell
you that when I used gparted to resize and move around
the materials for this, it took the whole damned day
to do it :-) The partition started at maybe 35GB, but
ended up a lot larger.

[Picture]

https://i.postimg.cc/SKZ39NRp/make-space-with-gparted.gif

Paul

Am Mittwoch, 31. August 2022, um 15:32:09 Uhr schrieb wAYNE:

> Interesting, was going to try going with 20 first but says not enough
> space on /. Not sure what's taking that up. Does / signify places
> like the desktop too as I have a lot of stuff on the desktop? I
> tried the apt clean as suggested but no difference and nothing in the
> trash.

Use df and du -h to find the big folders.
You need ~10 GB free on partition that provides /.

On 8/31/22 16:34, Paul wrote:
> On 8/31/2022 3:32 PM, wAYNE wrote:
>> On 8/31/22 14:50, Marco Moock wrote:
>>> 18.04 is quite old and partially out of support, maybe upgrade to
>>> 22.04 and then try again.
>>>
>>
>> Interesting, was going to try going with 20 first but says not enough
>> space on /.  Not sure what's taking that up.  Does / signify places
>> like the desktop too as I have a lot of stuff on the desktop?  I tried
>> the apt clean as suggested but no difference and nothing in the trash.
>
> I use "df" command for a quick review. "df" is Disk Free.
>
> The "gnome-disks", for mounted volumes, graphically shows how
> full mounted partitions are, when you click on the partition
> in the GUI.
>
> You can expand the partition... if there is room to the right.
> You can use gparted, with a LiveDVD as the booted OS, to
> do some disk editing.
>
> A typical giant waste of space, is if you are a QEMU
> user and wave around one or two QCOWs for fun :-) Since
> the QCOW files are hidden in a root-owned location, you
> have to run your disk-listing programs as root.
>
> Analysis of disk contents (the slash partition) can
> be done with one of the dirstat programs, like kdirstat
> or qdirstat. sudo qdirstat / is an example of a command
> for this job.
>
> While this picture is not an entire recipe, I can tell
> you that when I used gparted to resize and move around
> the materials for this, it took the whole damned day
> to do it :-) The partition started at maybe 35GB, but
> ended up a lot larger.
>
>    [Picture]
>
>    https://i.postimg.cc/SKZ39NRp/make-space-with-gparted.gif
>
>   Paul
>
This is a dual boot system. Win 10 or Ubuntu selected at start up. I
did reboot with the Live CD and took a look at the partitions with
gparted. I believe the partition in question is a 19 GB one with 17 GB
being used, which is why I can't upgrade because there isn't enough
space. The one right next to it is the home partition. I tried
shrinking that, allowing free space, but then I was unable to resize the
19 GB partition any larger.
Initially, I had a lot of kernals from prior updates and went in and
deleted those except one prior kernal just in case things go wrong with
the current kernal. However, while in the past this always freed up
enough space, it didn't work this time.
Seems like a lot of extra work just trying to get these Appimages to
work again! Is there no other solution? I tried downloading some
Appimage updates and got the same error message when clicked on.
Someone else suggested reinstalling the latest Ubuntu version from
scratch. With a dual boot system, this won't be easy and not desired at
this point.
As a last resort, I do have a back up of my current system from a month
ago before the Appimages would no longer work. That would be the
easiest way to get them going again, but still doesn't solve the issue
of why they stopped working in the first place. I think some sort of
update did it, so most likely would repeat itself once again at some
point.

On 9/1/22 02:44, Marco Moock wrote:
> Am Mittwoch, 31. August 2022, um 15:32:09 Uhr schrieb wAYNE:
>
>> Interesting, was going to try going with 20 first but says not enough
>> space on /. Not sure what's taking that up. Does / signify places
>> like the desktop too as I have a lot of stuff on the desktop? I
>> tried the apt clean as suggested but no difference and nothing in the
>> trash.
>
> Use df and du -h to find the big folders.
> You need ~10 GB free on partition that provides /.
>

Ok, I looked at that, and also looked with gparted, but didn't help
much. As an experiment, I transferred over 10 GB of data from the
desktop to a spare hard drive and didn't make any difference, so I
assume the desktop data didn't matter. Maybe try the same thing with
home next, not sure.

In the past, I always had to delete previous kernals and it would solve
this issue. I had a lot of kernals this time as well that I deleted,
but didn't help.

On 8/31/22 17:05, Sativa GNutella wrote:
> I recommend backup of everything now it's easier to do.

My last back up was from a month ago, so pretty good there.

>
> Try LTS Ubuntu like 22 clean install afterwards.
>
> Upgrade path would have to much bloating and uncertainty.
>
> Although upgrade would be possible it's likely an uncertain system.
>
> Since you use appimage the snap can be scheduled once a week e.g.
>
> Don't mix flatpack with snaps, flatpack turns your Ubuntu into a
> hybrid Fedora system .
>
> Although flatpack is very fast.
>
> Snaps are bizarre slow, I don't understand why.

You lost me with the terms flatpack and snap. I assume they have
something to do with the appimages. All I ever did with appimages is
download and try them. If they worked, I kept them. If not, deleted.
It's only since they all stopped working with the same error message
that something had to be done.

An entire system upgrade from scratch is something I can't do at this
point as there's not enough time. As a last resort, if I can't find an
easier way to repair the appimage error issue, I will restore my system
from the back up when the appimages were still working, then go from
there.

Am Donnerstag, 01. September 2022, um 09:50:49 Uhr schrieb wAYNE:

> Ok, I looked at that, and also looked with gparted, but didn't help
> much. As an experiment, I transferred over 10 GB of data from the
> desktop to a spare hard drive and didn't make any difference, so I
> assume the desktop data didn't matter. Maybe try the same thing with
> home next, not sure.
>
> In the past, I always had to delete previous kernals and it would
> solve this issue. I had a lot of kernals this time as well that I
> deleted, but didn't help.

The partition that provides / is almost full. /home can, but doesn't
have to , be a separate partition.
Please run

cat /etc/fstab | grep -v '^#'
df

On 9/1/2022 9:46 AM, wAYNE wrote:
> On 8/31/22 16:34, Paul wrote:
>> On 8/31/2022 3:32 PM, wAYNE wrote:
>>> On 8/31/22 14:50, Marco Moock wrote:
>>>> 18.04 is quite old and partially out of support, maybe upgrade to
>>>> 22.04 and then try again.
>>>>
>>>
>>> Interesting, was going to try going with 20 first but says not enough space on /.  Not sure what's taking that up.  Does / signify places like the desktop too as I have a lot of stuff on the desktop?  I tried the apt clean as suggested but no difference and nothing in the trash.
>>
>> I use "df" command for a quick review. "df" is Disk Free.
>>
>> The "gnome-disks", for mounted volumes, graphically shows how
>> full mounted partitions are, when you click on the partition
>> in the GUI.
>>
>> You can expand the partition... if there is room to the right.
>> You can use gparted, with a LiveDVD as the booted OS, to
>> do some disk editing.
>>
>> A typical giant waste of space, is if you are a QEMU
>> user and wave around one or two QCOWs for fun :-) Since
>> the QCOW files are hidden in a root-owned location, you
>> have to run your disk-listing programs as root.
>>
>> Analysis of disk contents (the slash partition) can
>> be done with one of the dirstat programs, like kdirstat
>> or qdirstat. sudo qdirstat / is an example of a command
>> for this job.
>>
>> While this picture is not an entire recipe, I can tell
>> you that when I used gparted to resize and move around
>> the materials for this, it took the whole damned day
>> to do it :-) The partition started at maybe 35GB, but
>> ended up a lot larger.
>>
>>     [Picture]
>>
>>     https://i.postimg.cc/SKZ39NRp/make-space-with-gparted.gif
>>
>>    Paul
>>
>
> This is a  dual boot system.  Win 10 or Ubuntu selected at start up.  I did reboot with the Live CD and took a look at the partitions with gparted.  I believe the partition in question is a 19 GB one with 17 GB being used, which is why I can't upgrade because there isn't enough space.  The one right next to it is the home partition.  I tried shrinking that, allowing free space, but then I was unable to resize the 19 GB partition any larger.
>
> Initially, I had a lot of kernals from prior updates and went in and deleted those except one prior kernal just in case things go wrong with the current kernal.  However, while in the past this always freed up enough space, it didn't work this time.
>
> Seems like a lot of extra work just trying to get these Appimages to work again!  Is there no other solution?  I tried downloading some Appimage updates and got the same error message when clicked on.
>
> Someone else suggested reinstalling the latest Ubuntu version from scratch.  With a dual boot system, this won't be easy and not desired at this point.
>
> As a last resort, I do have a back up of my current system from a month ago before the Appimages would no longer work.  That would be the easiest way to get them going again, but still doesn't solve the issue of why they stopped working in the first place.  I think some sort of update did it, so most likely would repeat itself once again at some point.
>

When you shrank /home, you were supposed to move that to the right.

+-----+----------+---------------------+
| MBR | Full | Donor | Shrink the Donor
+-----+----------+---------------------+

+-----+----------+-----------+---------+
| MBR | Full | Donor |<unalloc>| Now, move Donor to the right
+-----+----------+-----------+---------+

+-----+----------+---------+-----------+
| MBR | Full |<unalloc>| Donor | Expand the Full partition, into space
+-----+----------+---------+-----------+

+-----+--------------------+-----------+
| MBR | Full | Donor | Do Upgrade
+-----+--------------------+-----------+

Paul

On 9/1/2022 9:55 AM, wAYNE wrote:
> On 8/31/22 17:05, Sativa GNutella wrote:
>> I recommend backup of everything now it's easier to do.
>
> My last back up was from a month ago, so pretty good there.

I do a backup, right before I do an Upgrade.

Paul

On 01/09/2022 16:50, wAYNE wrote:
> On 9/1/22 02:44, Marco Moock wrote:
>> Am Mittwoch, 31. August 2022, um 15:32:09 Uhr schrieb wAYNE:
>>
>>> Interesting, was going to try going with 20 first but says not enough
>>> space on /.  Not sure what's taking that up.  Does / signify places
>>> like the desktop too as I have a lot of stuff on the desktop?  I
>>> tried the apt clean as suggested but no difference and nothing in the
>>> trash.
>>
>> Use df and du -h to find the big folders.
>> You need ~10 GB free on partition that provides /.
>>
>
> Ok, I looked at that, and also looked with gparted, but didn't help much.  As an experiment, I transferred over 10 GB of
> data from the desktop to a spare hard drive and didn't make any difference, so I assume the desktop data didn't matter.
> Maybe try the same thing with home next, not sure.
>
> In the past, I always had to delete previous kernals and it would solve this issue.  I had a lot of kernals this time as
> well that I deleted, but didn't help.
From my undertanding, because Appimages are constructed to contain all and any libraries they might need, the disk
space they consume is many multiples of a dynamically-linked binary program.
Also I would suspect that cleaning apt would have little effect on Appimages. Basically you would be cleaning up old
*.deb files.
What is the reason you chose to go the Appimage route? The added convenience comes at a cost, definitely of disk space,
and probably of complication in the longer run.
If your /home is (as is recommended) on a separate partition, removing files from /home/$USER/Desktop or Downloads will
make no difference to the free space on /
Could you make the effort of transferring your Ubuntu system to a separate possibly larger hard disk or SSD? Lots of
"How tos" on Google.

On 9/1/22 10:49, Paul wrote:
> On 9/1/2022 9:46 AM, wAYNE wrote:
>> On 8/31/22 16:34, Paul wrote:
>>> On 8/31/2022 3:32 PM, wAYNE wrote:
>>>> On 8/31/22 14:50, Marco Moock wrote:
>>>>> 18.04 is quite old and partially out of support, maybe upgrade to
>>>>> 22.04 and then try again.
>>>>>
>>>>
>>>> Interesting, was going to try going with 20 first but says not
>>>> enough space on /.  Not sure what's taking that up.  Does / signify
>>>> places like the desktop too as I have a lot of stuff on the
>>>> desktop?  I tried the apt clean as suggested but no difference and
>>>> nothing in the trash.
>>>
>>> I use "df" command for a quick review. "df" is Disk Free.
>>>
>>> The "gnome-disks", for mounted volumes, graphically shows how
>>> full mounted partitions are, when you click on the partition
>>> in the GUI.
>>>
>>> You can expand the partition... if there is room to the right.
>>> You can use gparted, with a LiveDVD as the booted OS, to
>>> do some disk editing.
>>>
>>> A typical giant waste of space, is if you are a QEMU
>>> user and wave around one or two QCOWs for fun :-) Since
>>> the QCOW files are hidden in a root-owned location, you
>>> have to run your disk-listing programs as root.
>>>
>>> Analysis of disk contents (the slash partition) can
>>> be done with one of the dirstat programs, like kdirstat
>>> or qdirstat. sudo qdirstat / is an example of a command
>>> for this job.
>>>
>>> While this picture is not an entire recipe, I can tell
>>> you that when I used gparted to resize and move around
>>> the materials for this, it took the whole damned day
>>> to do it :-) The partition started at maybe 35GB, but
>>> ended up a lot larger.
>>>
>>>     [Picture]
>>>
>>>     https://i.postimg.cc/SKZ39NRp/make-space-with-gparted.gif
>>>
>>>    Paul
>>>
>>
>> This is a  dual boot system.  Win 10 or Ubuntu selected at start up.
>> I did reboot with the Live CD and took a look at the partitions with
>> gparted.  I believe the partition in question is a 19 GB one with 17
>> GB being used, which is why I can't upgrade because there isn't enough
>> space.  The one right next to it is the home partition.  I tried
>> shrinking that, allowing free space, but then I was unable to resize
>> the 19 GB partition any larger.
>>
>> Initially, I had a lot of kernals from prior updates and went in and
>> deleted those except one prior kernal just in case things go wrong
>> with the current kernal.  However, while in the past this always freed
>> up enough space, it didn't work this time.
>>
>> Seems like a lot of extra work just trying to get these Appimages to
>> work again!  Is there no other solution?  I tried downloading some
>> Appimage updates and got the same error message when clicked on.
>>
>> Someone else suggested reinstalling the latest Ubuntu version from
>> scratch.  With a dual boot system, this won't be easy and not desired
>> at this point.
>>
>> As a last resort, I do have a back up of my current system from a
>> month ago before the Appimages would no longer work.  That would be
>> the easiest way to get them going again, but still doesn't solve the
>> issue of why they stopped working in the first place.  I think some
>> sort of update did it, so most likely would repeat itself once again
>> at some point.
>>
>
> When you shrank /home, you were supposed to move that to the right.
>
>       +-----+----------+---------------------+
>       | MBR |   Full   |        Donor        |  Shrink the Donor
>       +-----+----------+---------------------+
>
>       +-----+----------+-----------+---------+
>       | MBR |   Full   |   Donor   |<unalloc>|  Now, move Donor to the
> right
>       +-----+----------+-----------+---------+
>
>       +-----+----------+---------+-----------+
>       | MBR |   Full   |<unalloc>|   Donor   |  Expand the Full
> partition, into space
>       +-----+----------+---------+-----------+
>
>       +-----+--------------------+-----------+
>       | MBR |         Full       |   Donor   |  Do Upgrade
>       +-----+--------------------+-----------+
>
>    Paul
>
I'll take a look at it again once my back up from a month ago is
finished. First step will be to determine, after I again update Ubuntu
once again, whether or not the appimages are still working. Then, I
might consider the upgrade and test it out once I have made a current
back up once again.
I had some problems in that there was I believe a small partition in
between, so I couldn't expand the partition in question. And I couldn't
delete the partition. It's used while Ubuntu is in operation, I'll be
darned if I can think of the name now.... serves the same purpose as a
"scratch" drive for certain programs.
I'm afraid if I start moving things around too much that I won't be able
to boot either OS. Once the back up is finished, everything is again
working, updated, and backed up again, I'll take another look at the
upgrade.

On Thu, 1 Sep 2022 11:37:37 -0400, wAYNE wrote:

> I'll take a look at it again once my back up from a month ago is
> finished. First step will be to determine, after I again update Ubuntu
> once again, whether or not the appimages are still working. Then, I
> might consider the upgrade and test it out once I have made a current
> back up once again.
>
> I had some problems in that there was I believe a small partition in
> between, so I couldn't expand the partition in question. And I couldn't
> delete the partition. It's used while Ubuntu is in operation, I'll be
> darned if I can think of the name now.... serves the same purpose as a
> "scratch" drive for certain programs.

Yep, moving stuff around while in use is a good way to create problems.

For partition work, I use gparted from a systemrescue cd or live cd
That way you can dismount a partition on the target system.

See http://www.sysresccd.org/Download for latest release.

On 8/31/22 12:10, wAYNE wrote:
> A few weeks ago, all of my Appimages stopped working.  When I click on
> any of them, I am getting an error with the following message:
>
> Failed to register AppImage in AppImageLauncherFS: could not open map file.
>
> While I can get by if some of the Apps don't work, there are others I
> need to have working so would appreciate any assistance to correct this.
>
> Thanks in advance,
> Wayne S
Good news and bad news. Restoring back up from a month ago worked fine
and any appimages worked normally. I then updated the software and all
the appimages stopped working. So it was definitely the updating that
broke them. The question I wonder is what from the update caused the
errors to appear?
I think I finally figured out /. I was able to clear out a bit more
space, but still just over 1 GB needed. I just don't know how to get
more space. Looking the the directory, I see a bunch of folders.....
from "bin" to "var." Home is included in this but nothing I try to
remove from home and place to a back up drive makes any difference in
space. Tmp seems to have some files, but only about 540 kb worth, so
not worth trying to delete anything there. Are there any specific
folders I should be looking at here that might make a difference? I see
my latest and one prior kernal in the boot folder. I read someone
mentioning snap in one of the responses. In that folder, there's other
folders like bare, bin, core..... gnome and wine platform (no, I don't
currently have wine installed but used to).
Any other suggestions welcome because I'm stumped. No point in
restoring this all again if, after the first update, all the appimages
are going to end up broken anyway so might as well stick with the way it
is now.

On 9/1/2022 12:09 PM, Bit Twister wrote:
> On Thu, 1 Sep 2022 11:37:37 -0400, wAYNE wrote:
>
>> I'll take a look at it again once my back up from a month ago is
>> finished. First step will be to determine, after I again update Ubuntu
>> once again, whether or not the appimages are still working. Then, I
>> might consider the upgrade and test it out once I have made a current
>> back up once again.
>>
>> I had some problems in that there was I believe a small partition in
>> between, so I couldn't expand the partition in question. And I couldn't
>> delete the partition. It's used while Ubuntu is in operation, I'll be
>> darned if I can think of the name now.... serves the same purpose as a
>> "scratch" drive for certain programs.
>
> Yep, moving stuff around while in use is a good way to create problems.
>
> For partition work, I use gparted from a systemrescue cd or live cd
> That way you can dismount a partition on the target system.
>
> See http://www.sysresccd.org/Download for latest release.
>

He should also have the media he used to install Ubuntu,
which is sufficient for a gparted session.

Paul

On 9/1/22 10:49, Paul wrote:
> On 9/1/2022 9:46 AM, wAYNE wrote:
>> On 8/31/22 16:34, Paul wrote:
>>> On 8/31/2022 3:32 PM, wAYNE wrote:
>>>> On 8/31/22 14:50, Marco Moock wrote:
>>>>> 18.04 is quite old and partially out of support, maybe upgrade to
>>>>> 22.04 and then try again.
>>>>>
>>>>
>>>> Interesting, was going to try going with 20 first but says not
>>>> enough space on /.  Not sure what's taking that up.  Does / signify
>>>> places like the desktop too as I have a lot of stuff on the
>>>> desktop?  I tried the apt clean as suggested but no difference and
>>>> nothing in the trash.
>>>
>>> I use "df" command for a quick review. "df" is Disk Free.
>>>
>>> The "gnome-disks", for mounted volumes, graphically shows how
>>> full mounted partitions are, when you click on the partition
>>> in the GUI.
>>>
>>> You can expand the partition... if there is room to the right.
>>> You can use gparted, with a LiveDVD as the booted OS, to
>>> do some disk editing.
>>>
>>> A typical giant waste of space, is if you are a QEMU
>>> user and wave around one or two QCOWs for fun :-) Since
>>> the QCOW files are hidden in a root-owned location, you
>>> have to run your disk-listing programs as root.
>>>
>>> Analysis of disk contents (the slash partition) can
>>> be done with one of the dirstat programs, like kdirstat
>>> or qdirstat. sudo qdirstat / is an example of a command
>>> for this job.
>>>
>>> While this picture is not an entire recipe, I can tell
>>> you that when I used gparted to resize and move around
>>> the materials for this, it took the whole damned day
>>> to do it :-) The partition started at maybe 35GB, but
>>> ended up a lot larger.
>>>
>>>     [Picture]
>>>
>>>     https://i.postimg.cc/SKZ39NRp/make-space-with-gparted.gif
>>>
>>>    Paul
>>>
>>
>> This is a  dual boot system.  Win 10 or Ubuntu selected at start up.
>> I did reboot with the Live CD and took a look at the partitions with
>> gparted.  I believe the partition in question is a 19 GB one with 17
>> GB being used, which is why I can't upgrade because there isn't enough
>> space.  The one right next to it is the home partition.  I tried
>> shrinking that, allowing free space, but then I was unable to resize
>> the 19 GB partition any larger.
>>
>> Initially, I had a lot of kernals from prior updates and went in and
>> deleted those except one prior kernal just in case things go wrong
>> with the current kernal.  However, while in the past this always freed
>> up enough space, it didn't work this time.
>>
>> Seems like a lot of extra work just trying to get these Appimages to
>> work again!  Is there no other solution?  I tried downloading some
>> Appimage updates and got the same error message when clicked on.
>>
>> Someone else suggested reinstalling the latest Ubuntu version from
>> scratch.  With a dual boot system, this won't be easy and not desired
>> at this point.
>>
>> As a last resort, I do have a back up of my current system from a
>> month ago before the Appimages would no longer work.  That would be
>> the easiest way to get them going again, but still doesn't solve the
>> issue of why they stopped working in the first place.  I think some
>> sort of update did it, so most likely would repeat itself once again
>> at some point.
>>
>
> When you shrank /home, you were supposed to move that to the right.
>
>       +-----+----------+---------------------+
>       | MBR |   Full   |        Donor        |  Shrink the Donor
>       +-----+----------+---------------------+
>
>       +-----+----------+-----------+---------+
>       | MBR |   Full   |   Donor   |<unalloc>|  Now, move Donor to the
> right
>       +-----+----------+-----------+---------+
>
>       +-----+----------+---------+-----------+
>       | MBR |   Full   |<unalloc>|   Donor   |  Expand the Full
> partition, into space
>       +-----+----------+---------+-----------+
>
>       +-----+--------------------+-----------+
>       | MBR |         Full       |   Donor   |  Do Upgrade
>       +-----+--------------------+-----------+
>
>    Paul
>
Ok, so resized and moved and now 20.04 is attempting to install.
However, it has been sitting at "refreshing snap core18" for a long time
now with no progress being made. Don't know if that's normal or not.
What happens if it doesn't go beyond this I might ask?

On 9/1/22 17:37, wAYNE wrote:
> On 9/1/22 10:49, Paul wrote:
>> On 9/1/2022 9:46 AM, wAYNE wrote:
>>> On 8/31/22 16:34, Paul wrote:
>>>> On 8/31/2022 3:32 PM, wAYNE wrote:
>>>>> On 8/31/22 14:50, Marco Moock wrote:
>>>>>> 18.04 is quite old and partially out of support, maybe upgrade to
>>>>>> 22.04 and then try again.
>>>>>>
>>>>>
>>>>> Interesting, was going to try going with 20 first but says not
>>>>> enough space on /.  Not sure what's taking that up.  Does / signify
>>>>> places like the desktop too as I have a lot of stuff on the
>>>>> desktop?  I tried the apt clean as suggested but no difference and
>>>>> nothing in the trash.
>>>>
>>>> I use "df" command for a quick review. "df" is Disk Free.
>>>>
>>>> The "gnome-disks", for mounted volumes, graphically shows how
>>>> full mounted partitions are, when you click on the partition
>>>> in the GUI.
>>>>
>>>> You can expand the partition... if there is room to the right.
>>>> You can use gparted, with a LiveDVD as the booted OS, to
>>>> do some disk editing.
>>>>
>>>> A typical giant waste of space, is if you are a QEMU
>>>> user and wave around one or two QCOWs for fun :-) Since
>>>> the QCOW files are hidden in a root-owned location, you
>>>> have to run your disk-listing programs as root.
>>>>
>>>> Analysis of disk contents (the slash partition) can
>>>> be done with one of the dirstat programs, like kdirstat
>>>> or qdirstat. sudo qdirstat / is an example of a command
>>>> for this job.
>>>>
>>>> While this picture is not an entire recipe, I can tell
>>>> you that when I used gparted to resize and move around
>>>> the materials for this, it took the whole damned day
>>>> to do it :-) The partition started at maybe 35GB, but
>>>> ended up a lot larger.
>>>>
>>>>     [Picture]
>>>>
>>>>     https://i.postimg.cc/SKZ39NRp/make-space-with-gparted.gif
>>>>
>>>>    Paul
>>>>
>>>
>>> This is a  dual boot system.  Win 10 or Ubuntu selected at start up.
>>> I did reboot with the Live CD and took a look at the partitions with
>>> gparted.  I believe the partition in question is a 19 GB one with 17
>>> GB being used, which is why I can't upgrade because there isn't
>>> enough space.  The one right next to it is the home partition.  I
>>> tried shrinking that, allowing free space, but then I was unable to
>>> resize the 19 GB partition any larger.
>>>
>>> Initially, I had a lot of kernals from prior updates and went in and
>>> deleted those except one prior kernal just in case things go wrong
>>> with the current kernal.  However, while in the past this always
>>> freed up enough space, it didn't work this time.
>>>
>>> Seems like a lot of extra work just trying to get these Appimages to
>>> work again!  Is there no other solution?  I tried downloading some
>>> Appimage updates and got the same error message when clicked on.
>>>
>>> Someone else suggested reinstalling the latest Ubuntu version from
>>> scratch.  With a dual boot system, this won't be easy and not desired
>>> at this point.
>>>
>>> As a last resort, I do have a back up of my current system from a
>>> month ago before the Appimages would no longer work.  That would be
>>> the easiest way to get them going again, but still doesn't solve the
>>> issue of why they stopped working in the first place.  I think some
>>> sort of update did it, so most likely would repeat itself once again
>>> at some point.
>>>
>>
>> When you shrank /home, you were supposed to move that to the right.
>>
>>        +-----+----------+---------------------+
>>        | MBR |   Full   |        Donor        |  Shrink the Donor
>>        +-----+----------+---------------------+
>>
>>        +-----+----------+-----------+---------+
>>        | MBR |   Full   |   Donor   |<unalloc>|  Now, move Donor to
>> the right
>>        +-----+----------+-----------+---------+
>>
>>        +-----+----------+---------+-----------+
>>        | MBR |   Full   |<unalloc>|   Donor   |  Expand the Full
>> partition, into space
>>        +-----+----------+---------+-----------+
>>
>>        +-----+--------------------+-----------+
>>        | MBR |         Full       |   Donor   |  Do Upgrade
>>        +-----+--------------------+-----------+
>>
>>     Paul
>>
>
> Ok, so resized and moved and now 20.04 is attempting to install.
> However, it has been sitting at "refreshing snap core18" for a long time
> now with no progress being made.  Don't know if that's normal or not.
> What happens if it doesn't go beyond this I might ask?
Well, after it stayed stuck there for about 2 hours, I decided to try
shutting down and rebooting. Instead of shutting down, I was logged
out. I logged back in and then selected software update. Was informed
that a partial upgrade had been completed and asked for permission to
finish. Appears to be all done now. I hope everything is ok. That was
a strange way of doing things. At least all my appimages are working
again. I think this had something to do with snap. After the log out
and back on and continuing updates, it was able to refresh snap. I'll
try it out for a while just to be sure everything is working and then
back up. It did ask while upgrading if I wanted to go to 22 (instead of
20) instead, but decided to hold off for now.

On 9/1/2022 6:34 PM, wAYNE wrote:
> On 9/1/22 17:37, wAYNE wrote:
>> On 9/1/22 10:49, Paul wrote:
>>> On 9/1/2022 9:46 AM, wAYNE wrote:
>>>> On 8/31/22 16:34, Paul wrote:
>>>>> On 8/31/2022 3:32 PM, wAYNE wrote:
>>>>>> On 8/31/22 14:50, Marco Moock wrote:
>>>>>>> 18.04 is quite old and partially out of support, maybe upgrade to
>>>>>>> 22.04 and then try again.
>>>>>>>
>>>>>>
>>>>>> Interesting, was going to try going with 20 first but says not enough space on /.  Not sure what's taking that up.  Does / signify places like the desktop too as I have a lot of stuff on the desktop?  I tried the apt clean as suggested but no difference and nothing in the trash.
>>>>>
>>>>> I use "df" command for a quick review. "df" is Disk Free.
>>>>>
>>>>> The "gnome-disks", for mounted volumes, graphically shows how
>>>>> full mounted partitions are, when you click on the partition
>>>>> in the GUI.
>>>>>
>>>>> You can expand the partition... if there is room to the right.
>>>>> You can use gparted, with a LiveDVD as the booted OS, to
>>>>> do some disk editing.
>>>>>
>>>>> A typical giant waste of space, is if you are a QEMU
>>>>> user and wave around one or two QCOWs for fun :-) Since
>>>>> the QCOW files are hidden in a root-owned location, you
>>>>> have to run your disk-listing programs as root.
>>>>>
>>>>> Analysis of disk contents (the slash partition) can
>>>>> be done with one of the dirstat programs, like kdirstat
>>>>> or qdirstat. sudo qdirstat / is an example of a command
>>>>> for this job.
>>>>>
>>>>> While this picture is not an entire recipe, I can tell
>>>>> you that when I used gparted to resize and move around
>>>>> the materials for this, it took the whole damned day
>>>>> to do it :-) The partition started at maybe 35GB, but
>>>>> ended up a lot larger.
>>>>>
>>>>>     [Picture]
>>>>>
>>>>>     https://i.postimg.cc/SKZ39NRp/make-space-with-gparted.gif
>>>>>
>>>>>    Paul
>>>>>
>>>>
>>>> This is a  dual boot system.  Win 10 or Ubuntu selected at start up. I did reboot with the Live CD and took a look at the partitions with gparted.  I believe the partition in question is a 19 GB one with 17 GB being used, which is why I can't upgrade because there isn't enough space.  The one right next to it is the home partition.  I tried shrinking that, allowing free space, but then I was unable to resize the 19 GB partition any larger.
>>>>
>>>> Initially, I had a lot of kernals from prior updates and went in and deleted those except one prior kernal just in case things go wrong with the current kernal.  However, while in the past this always freed up enough space, it didn't work this time.
>>>>
>>>> Seems like a lot of extra work just trying to get these Appimages to work again!  Is there no other solution?  I tried downloading some Appimage updates and got the same error message when clicked on.
>>>>
>>>> Someone else suggested reinstalling the latest Ubuntu version from scratch.  With a dual boot system, this won't be easy and not desired at this point.
>>>>
>>>> As a last resort, I do have a back up of my current system from a month ago before the Appimages would no longer work.  That would be the easiest way to get them going again, but still doesn't solve the issue of why they stopped working in the first place.  I think some sort of update did it, so most likely would repeat itself once again at some point.
>>>>
>>>
>>> When you shrank /home, you were supposed to move that to the right.
>>>
>>>        +-----+----------+---------------------+
>>>        | MBR |   Full   |        Donor        |  Shrink the Donor
>>>        +-----+----------+---------------------+
>>>
>>>        +-----+----------+-----------+---------+
>>>        | MBR |   Full   |   Donor   |<unalloc>|  Now, move Donor to the right
>>>        +-----+----------+-----------+---------+
>>>
>>>        +-----+----------+---------+-----------+
>>>        | MBR |   Full   |<unalloc>|   Donor   |  Expand the Full partition, into space
>>>        +-----+----------+---------+-----------+
>>>
>>>        +-----+--------------------+-----------+
>>>        | MBR |         Full       |   Donor   |  Do Upgrade
>>>        +-----+--------------------+-----------+
>>>
>>>     Paul
>>>
>>
>> Ok, so resized and moved and now 20.04 is attempting to install. However, it has been sitting at "refreshing snap core18" for a long time now with no progress being made.  Don't know if that's normal or not. What happens if it doesn't go beyond this I might ask?
>
> Well, after it stayed stuck there for about 2 hours, I decided to try shutting down and rebooting.  Instead of shutting down, I was logged out.  I logged back in and then selected software update.  Was informed that a partial upgrade had been completed and asked for permission to finish.  Appears to be all done now.  I hope everything is ok.  That was a strange way of doing things.  At least all my appimages are working again.  I think this had something to do with snap.  After the log out and back on and continuing updates, it was able to refresh snap.  I'll try it out for a while just to be sure everything is working and then back up.  It did ask while upgrading if I wanted to go to 22 (instead of 20) instead, but decided to hold off for now.

It's good to hear you made "forward progress" without more
of my bumbling :-)

One of the frustrations of working with AppImage, was not finding
the usual quality of information about it. I was following some
bugtracker-like material, and it would appear to a large extent,
they expect noobs to read the source code.

Wikipedia has an article with the history, so at least from that,
I could see that it's a technique that's had some name changes.

First, I couldn't find a sample to use. But I downloaded an OpenShot,
something that would have lots of curve balls in it to expose issues.

The AppImage seems to look like this:

+-----------------+----------------------------------+
| ELF executable | ISO File (like a CD in a way) | some.AppImage
+-----------------+----------------------------------+

^ 32KB offset, 0x8000 hex

The ELF executable part, would be responsible for mounting the file
system on the trailing end of the ELF. You can, for example, do loopback
mounts (-o loop) with a byte offset as a pointer to the mounter, telling
it to ignore the first 32KB of stuff.

Before "appimagelauncherfs" or the like came along, AppImage used some
sort of userspace file system (FUSE).

https://github.com/AppImage/AppImageKit/wiki/FUSE

sudo apt install fuse libfuse2 # Note, for 22.04, recipe changes, DONT FUSE.
sudo modprobe fuse # Follow instructions on that web page!
sudo groupadd fuse

user="$(whoami)"
sudo usermod -a -G fuse $user # Allows unelevated users to make this work

That chunk of stuff, and its web page, allow you to do this from Terminal.

./some.AppImage # With FUSE support, now it launches.

This means that the material in the 32KB ELF code header of the AppImage,
works the levers for a fuse mount, then "jumps" into the executable
on the CD image part. The user "Probono" may have written this, and
the AppImageKit (for making AppImages).

https://github.com/AppImage/AppImageKit

*******

A second kind of support happens, if you use the package written
by TheAssassin. My guess is, TheAssassin ignores the 32KB part
of the AppImage, and just used the CD part. To do this, you could
treat the file as a "data file" of sorts. If The Assassin uses a GUI
technique for dealing with the file, perhaps this prevents the
OS from running the ELF part and screwing up his grand plan.

+-----------------+----------------------------------+
| <ignored> | ISO File (like a CD in a way) | some.AppImage
+-----------------+----------------------------------+

https://github.com/TheAssassin/AppImageLauncher/issues/286

I have appimaged, appimagelauncher and AppImageUpdate installed.

sudo systemctl --user status appimagelauncherfs

Now, the "fs" is a hint, that TheAssassin could be creating
a custom filesystem which is just an ISO with 32KB of stuff to
be ignored. I looked at the source, and while the "shared"
folder code came the closest to using the word "mount",
I could not see an actual mount in there.

On 9/1/22 22:32, Paul wrote:

>
> It's good to hear you made "forward progress" without more
> of my bumbling :-)

-------apologetic cut--------------------------------

Thanks for further info. A lot of that is too technical for me, but it
was an interesting read. Obviously you are far more into the
programming and command side of things than I am.

I switched over to Ubuntu probably a decade ago after growing tired of
Windows by constantly having to have viral scanners and such, plus I
found that Windows would get less and less functional the more it was
updated unless one bought a new PC. Plus, many of the virus programs I
used tended to slow things down too much.

I had examined several Linux options (distros I believe is the correct
term if I'm not mistaken) and settled on Ubuntu. I tried several of
them on virtual machines first. I sort of liked Debian, but found that
it was far too basic. There were others close in functionality and user
friendliness to Ubuntu, but finally settled on Ubuntu.

I hadn't realized that a degree of Linux programming knowledge was
actually needed after the switchover, unlike Win where everything is
plug and play. At first I scoffed at this, but didn't take me long to
realize the advantages of it. So I tried to learn what I could at a
very basic level. What I can't figure things out, as is often the case,
I found several user friendly Linux based groups like this one, all of
which have helped tremendously when I have encountered hitches.

For example, a friend of mine came onto this group a couple of years
back. He liked to listen to what is called online SDRs. These are
software defined radios (SDR) that are accessible to anyone who has
online access. I'm not really all that interested in it, but he wanted
to be able to record many of these stations simultaneously as he was
looking for some very specific radio signals. He was trying to use
python and scripts to set up recording times, number of stations and
such and had no idea how to proceed. He posted an inquiry here and one
kind gentleman spent days communicating with him on here and helping him
to set up the necessary scripts. He learned enough from his man that he
has been able to write up workable scripts ever since. Kudos to whoever
that was, but my friend still talks about the kind encounter here and
how it really helped him along.

Talking about rambling, look at me, ha ha. Well, I am in the process of
backing up my system, which was finally how I wanted it after the
upgrade yesterday. I did one hitch to solve and that's when I
inadvertently chose Firefox to "refresh" itself after it asked me to
after the upgrade. When I did that, I lost all of my ad ons but
reinstalled and all solved now. After the back up today, guess what,
I'm going to try installing v22! Now I do understand that there may be
issues with the appimages, but there seems to be plenty of online info
on how to solve it so keeping my fingers crossed.

Thanks to you and the others who helped here. I really liked the
diagram you made about how to shrink, move and expand the needed
partition. I will probably have to do the same with the laptop here
once the desktop is done. This laptop all has v18 but needs upgraded as
well. When things start not working on v18, which was obviously the
case with snap and the appimages, it's past time to update.

On 9/2/22 06:57, wAYNE wrote:
> On 9/1/22 22:32, Paul wrote:
>
>>
>> It's good to hear you made "forward progress" without more
>> of my bumbling :-)
>
> -------apologetic cut--------------------------------
>
> Thanks for further info.  A lot of that is too technical for me, but it
> was an interesting read.  Obviously you are far more into the
> programming and command side of things than I am.
>
> I switched over to Ubuntu probably a decade ago after growing tired of
> Windows by constantly having to have viral scanners and such, plus I
> found that Windows would get less and less functional the more it was
> updated unless one bought a new PC.  Plus, many of the virus programs I
> used tended to slow things down too much.
>
> I had examined several Linux options (distros I believe is the correct
> term if I'm not mistaken) and settled on Ubuntu.  I tried several of
> them on virtual machines first.  I sort of liked Debian, but found that
> it was far too basic.  There were others close in functionality and user
> friendliness to Ubuntu, but finally settled on Ubuntu.
>
> I hadn't realized that a degree of Linux programming knowledge was
> actually needed after the switchover, unlike Win where everything is
> plug and play.  At first I scoffed at this, but didn't take me long to
> realize the advantages of it.  So I tried to learn what I could at a
> very basic level.  What I can't figure things out, as is often the case,
> I found several user friendly Linux based groups like this one, all of
> which have helped tremendously when I have encountered hitches.

Becasue you came from Windows you consider use of the terminal window
or its many expansions such as bash to be programming. It is not
programming but it is by-passing the sometimes problematical Desktop
Environment in order to use the direct commands. I personally would
rather not have to use it but inappropriate use of Graphic User
Interface connected to the programs hidden in / {root). I only
used Windows in passing on my first x86 laptop as I migrated from
the Amiga OS to Windows around 2005-2006. On the Amiga I learned of
necessity to use the Command Line Interface but all the commands
are differently named in Linux and it took me a while to get with it.
My first Linux distro was probably Knoppix to fix problems with
Windows and with Linux later on. However I chose Mandriva to use
daily, In 2011 they misconfigured their installation script and I
could no longer use the Operating System I paid for and User
Support had seemed to go away. I migrated eventually to
PCLinuxOS with a brief try at Mageia both of which are related
to Mandriva. After using these with some help for the local
Linux User Group I came back to PCLinux and became a host for
meetings and a helper with problems and installations.

I tried Ubuntu along the way but consider it (sorry users) an
abomination of desolation. It goes out of its way to hide
useful matters from the Users. In addition it tends to over-
simplify installation. I read this group in case I a Ubuntu
user needs help via SF-LUG. For my own help i read the PCLinux
Forum <https://www.pclinuxos.com/forum/index.php> and sometimes
a problem is so simple that even I can help.

>
> For example, a friend of mine came onto this group a couple of years
> back.  He liked to listen to what is called online SDRs.  These are
> software defined radios (SDR) that are accessible to anyone who has
> online access.  I'm not really all that interested in it, but he wanted
> to be able to record many of these stations simultaneously as he was
> looking for some very specific radio signals.  He was trying to use
> python and scripts to set up recording times, number of stations and
> such and had no idea how to proceed.  He posted an inquiry here and one
> kind gentleman spent days communicating with him on here and helping him
> to set up the necessary scripts.  He learned enough from his man that he
> has been able to write up workable scripts ever since.  Kudos to whoever
> that was, but my friend still talks about the kind encounter here and
> how it really helped him along.
>
> Talking about rambling, look at me, ha ha.  Well, I am in the process of
> backing up my system, which was finally how I wanted it after the
> upgrade yesterday.  I did one hitch to solve and that's when I
> inadvertently chose Firefox to "refresh" itself after it asked me to
> after the upgrade.  When I did that, I lost all of my ad ons but
> reinstalled and all solved now.  After the back up today, guess what,
> I'm going to try installing v22!  Now I do understand that there may be
> issues with the appimages, but there seems to be plenty of online info
> on how to solve it so keeping my fingers crossed.
>
> Thanks to you and the others who helped here.  I really liked the
> diagram you made about how to shrink, move and expand the needed
> partition.  I will probably have to do the same with the laptop here
> once the desktop is done.  This laptop all has v18 but needs upgraded as
> well.  When things start not working on v18, which was obviously the
> case with snap and the appimages, it's past time to update.

From Distrowatch so my addenda to this post are not totally off topic.

2022-09-01 NEW • Distribution Release: Ubuntu 20.04.5
Canonical has announced a point release for Ubuntu 20.04 and its
community editions. The new release, 20.04.5, offers updated hardware
support along with security fixes since the original 20.04 release.

bliss - brought to you by the power and ease of PCLinuxOS
the Perfect Computer Linus Operating System(for me),
and a minor case of hypergraphia.

"The rule is perfect: in all matters of opinion our adversaries are
insane." (Mark Twain)
--
bliss dash SF 4 ever at dslextreme dot com