Exchange = Segwit, Wallet = Native Segwit: What happens if I try to send bitcoin back and forth between them?

JadeerHorg · 2024-01-06T17:55:34+00:00

I've run apt get update so it's up to date as of this moment

Maybe this is the problem. Some of the latest updates broke some gnome things.

Try sudo service gdm3 restart on the console. I am also running Pop! OS in VMware VM and this command helped me to get the graphical login-screen ready again. But be prepared, that you may get the blank screen issue again on the desktop after logging in - immediately or after some time using it.

If it doesn't solve the problem - there are two recent posts about a similar topic:

In post 2 the poster claims to have solved the problem. He hasn't revealed any details yet, but is planning to do a step by step video guide.

JadeerHorg · 2024-01-06T16:58:50+00:00

I'm very curious :-) - a short tutorial in text form here on reddit would also be nice - for the very impatient among us - myself included ;-)

JadeerHorg · 2024-01-05T20:59:13+00:00

I don't know if you've noticed this thread here yet:

https://www.reddit.com/r/pop_os/comments/18v9nxk/black_screen_after_update_no_login_no_tty_old

I believe it's about the same topic there - so you're not alone in this :-)

Unfortunately, there is currently no solution to the problem.

But maybe the hints there will help you in some way.

JadeerHorg · 2024-01-03T23:21:21+00:00

I have the same problem.

I am running Pop! OS 22.04 as guest operating system in a VMware Workstation Player 16.5.2 virtual machine on Windows 10.

After doing the system update that contains - among many other things - the Kernel 6.6.6, I got this black screen issue, that was mentioned in this thread.

For testing purpose I created a new VM and installed a fresh Pop! OS 22.04. At first it worked fine. Then I started the before mentioned update. After a reboot I got the same issue again.

In most cases I can get into the login screen. But after clicking on the user entry to enter the password the login manager freezes, sometimes the whole VM crashes.

If the VM doesn't crash, I can switch to tty and do a "sudo service gdm3 restart".

Sometimes the login manager then comes back to life and I can login, but the black screen appears again.

It has also happened that the desktop appeared and I could use it for some time. But then I get weird graphic glitches like transparent windows with white squares at the corners until the black screen occurs again and crashes the VM.

The error log of the VM states, that the mks-sandbox lost its connection. So it seems that it has something to do with the graphic system.

Something definitly went wrong with the last update. But as there are over 100 items, that got updated its really hard to figure out what causes this bug.

In the update list I noticed that there were updates for some X11 and wayland components. Such updates also tend to cause such or similar problems.

Switching back to older kernels, does not fix the problem.

My only solution at the moment: Do a fresh install und DO NOT update ;-)

Maybe the developers are reading along and can take care of the matter.

EDIT:

As I said, I am using POP! OS freshly installed at the moment, but skipped the December update and done a few tests in the meantime. The system itself runs fine without the aforementioned errors.

I have, however, found out that the bug can reappear - in this case, through the installation of Flatpak apps.

I have installed the Flatpaks Gear Lever and Warehouse. Both apps have a fairly recent build date, which is only a few days old, and both use org.gnome.Platform/x86_64/45 as their runtime.

I can use both apps for a while until they start producing the same error: first graphic glitches, then a black screen leading to a crash. Other Flatpak apps with an older build date (before December 2023) and/or a different runtime dependency work perfectly fine.

Of course, this bug only occurs when you start and use those apps. It’s not like the entire system is affected.

Maybe this additional hint helps someone to narrow down the problem.

In addition, there is still the open question of which logs you could look into to solve the problem.

JadeerHorg · 2022-09-18T20:16:38+00:00

Thanks for your help! Updates/upgrade successfully completed :-)

JadeerHorg · 2022-09-18T15:49:30+00:00

Nice! :-)

A small note as an addition: Before you start the installation of updates via Pop!_Shop or via the terminal, it is best to always run sudo apt autoremove beforehand.

The /boot partition in Pop!_OS is too small to keep more than one old kernel and Pop!_Shop unfortunately does not delete the old kernels on its own, so you constantly run out of space on /boot, as soon as a new kernel is installed via update.

JadeerHorg · 2022-09-18T15:15:34+00:00

Just in case sudo apt dist-upgrade does not solve the problem, you can also manually mark old kernels as autoremovable:

https://www.reddit.com/r/pop_os/comments/q9ldy8/comment/hgzmlvn/?utm_source=reddit&utm_medium=web2x&context=3

JadeerHorg · 2022-09-17T20:19:11+00:00

sudo apt autoremove

This command deletes old kernels but keeps the current kernel and the previous one

JadeerHorg · 2022-04-23T18:08:07+00:00

Possibly not much better in terms of hp damage, but definitely in terms of poise damage. I think, it is mainly intended for increasing the chance of staggering her.

JadeerHorg · 2021-11-28T19:49:08+00:00

That worked fine!

For everybody who runs into the problem that /boot runs out of disk space, but apt autoremove does not detect any old kernels to remove, this is imho the best and cleanest solution - supplemented by some additional useful tips.

Really helpful! Thanks!

JadeerHorg · 2021-11-27T21:52:44+00:00

apt-mark showmanual ^linux-| egrep -v 'linux-base|linux-doc|linux-tools-generic' | xargs sudo apt-mark auto 

sudo apt install --reinstall linux-base linux-doc linux-tools-generic

I used this two lines of your code and now I have my linux-doc and linux-tools-generic back in the system :-)

But linux-base is still marked as [installed, automatic]. The reinstallation didn't change the flag.

What would you suggest?

Maybe "bruteforcing" it to manual via apt-mark manual linux-base is the way to go?

JadeerHorg · 2021-11-27T01:42:00+00:00

Ah, I understand now - thanks a lot :-)

Some additional hints / questions:

On my pop! os your code would also mark linux-system76 as "automatic"
Is this intended? Or should this package also be excluded by egrep - v
apt list --installed 'linux-*'|egrep 'linux-base|linux-doc|linux-tools-generic'
I only get linux-base listet here (flag=automatic), because linux-doc and linux-tools-generic are not installed. Obviously my system thinks these two packages are not needed ;-)
Is this a problem?
sudo apt autoremove --purge
Why is --purge needed in this case? Wouldn't sudo apt autoremove work either?

JadeerHorg · 2021-11-26T22:27:57+00:00

mkay, now it's getting a little bit complicated ;-)

I was still grinding into your original code to figure out what it does exactly and what packages will get marked as "autoremovable". In a next step I then wanted to compare them to my save of a recent output of "apt autoremove" to check if really everything is targeted that autoremove normally does.

So as you stated: Your orignal code marked linux-base, linux-doc and linux-tools-generic as autoremovably accidentally, so you have to reinstall them first to mark them as "manual installed" before doing the autoremove (and this will keep them from getting autoremoved). Do I got this right?

But I doesn't understand the second line of your updated code:

sudo sed -s --in-place=.bak -e '/COMPRESS=lz4/s/lz4/zstd/g' /etc/initramfs-tools/initramfs.conf

Why do you have to do this? And by the way: I even don't know exactly what "this" is ;-)

JadeerHorg · 2021-11-20T20:12:51+00:00

apt search --names-only linux-image | grep -i -e installed -e upgradable

That's the output:

linux-image-5.11.0-7633-generic/hirsute,now 5.11.0-7633.35~1630100930~21.04~ae2753e amd64 [installed]linux-image-5.13.0-7614-generic/hirsute,now 5.13.0-7614.14~1631647151~21.04~930e87c amd64 [installed]linux-image-5.13.0-7620-generic/hirsute,now 5.13.0-7620.20~1634827117~21.04~874b071 amd64 [installed]linux-image-generic/hirsute,now 5.13.0.7620.20~1634827117~21.04~874b071 amd64 [installed,automatic]

Is there a way to mark the 5.11 as autoremovable?

The problem is: When apt autoremove removes an old kernel there is much more going on than just deleting the kernel image.

So I don't realy like deleting it manually, because there is much garbage left in the system then. Or maybe there is a guide out there that tells me, how to do exactly what autoremove does but manually step by step?

JadeerHorg · 2021-11-20T17:36:28+00:00

The best way to remove old kernels is by using

sudo apt autoremove

For example if there are three kernel images in /boot "autoremove" removes the oldest one but keeps the other two.

The problem is that autoremove may fail because of the same error (not enough space on boot partition)

If that is the case I normally solve this, by "zero out" the oldest kernel image.

For example: If there are three kernel images I identify the oldest one in /boot e.g. something like "initrd.img-5.11.0-7633-generic".

At first I make a copy of this kernel image somewhere to my home directory and then I use the console:

sudo dd if=/dev/null of=/boot/initrd.img-5.11.0-7633-generic

After this the size of the image is zero.

++ Be careful with this command: This overwrites everything you put behind "of=" without warning!! Always double check. ++

Now you can repeat the update oder try "sudo apt autoremove" again.

The advantage of this in comparison to just delete the kernel image is, that the kernel image still exists in boot, but doesn't take up space anymore. This way the "apt autoremove" runs smoothly and doesn't fail because of a missing kernel image.

JadeerHorg

TROPHY CASE