probably related to this kernel bug though:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2059738

downgrading the kernel should fix it as a workaround it would seem.

the halt command is like a handbrake for the kernel, so it basically shuts everything down hard and stops, but it does not power off the system without you telling it to, so that is why your LEDs stayed on after you used the other parameter.

you could just try to downgrade/ upgrade the kernel, do s shutdown for a few hours during daytime when the computer is not beeing used, then turn it back on and check the percentage.

you will see the drain if it’s not a full night, but it might not be so drastic.

if it’s completely shut down there should be no loss in percentage, even for a short period of time as there probably is now…

I’ll try to think up another solution, but a bit busy today as I mentioned on the last post

Hi, a bit busy today so I can investigate some more later, but the problem you are describing is in many cases related to the kernel version and has been resolved by up or downgrading the kernel version.

it might be worth looking into, at least it’s a simple task, while I get some more time to investigate or offer more for you to look into.

great that it worked so far, at least now you know where the problem is :)

let’s hope it’s a software issue, in general it’s much cheaper to fix software than hardware 🙂

you can also try using the “sudo halt --poweroff” command.

if it ks software related. that command will force an instant shutdown ignoring all normal shutdown run levels (use with caution if you have open files that need to be saved in advance).

if that command succeeds as well after the battery test, you can be sure the problem lies within the shutdown run level scripts, which should help you narrow it down even more.

That’s true, but long press on the power button still works, so you can try that instead then? 🙂

does this happen if you force it to shut down by holding the power button for +10sec, or if you remove and reinsert the battery after power off?

forcing a shutdown or removing and installing the battery, will ensure that the laptop is indeed shut down and not just halting during the shutdown process.

if you still have the same issue after this test I would guess your battery is dying, but if not you know that the issue is a software and not a hardware problem…

anyway, best of luck getting it sorted

do you have any usb devices, like external hard drives, chargers or similar connected to it? a lot of the laptops allows for usb charging/supply of power even when switched off, and this could be one of the sources for the drainage.

try disconnecting all USB cables if any are connected and see if the problem disappears?

never mind, did not see the line about no connected usb cables until after posting

Er jo en hel Lemmy instans for Danmark her, så det finnes nok flere av osw, og ja, jeg er fra Norge 🙂

Håper det ordner seg når du får installert ny font når du har tid og anledning til det 🙂

replying to myself here, but also, if this where supposed to work, which I doubt it will because it’s not feasible with tcpip, your second router would need to have the first router as gateway, but that is not possible when they are on the same subnet, and also your router will most likely not allow it because nat/routing will break, but if this was possible, devices behind your second router would not be able to connect to the devices before and vice versa, because since they have the same subnet, the traffic is considered local and not going through the router, and therefore the will not see each other as the NAT provides a separation between the networks…

you cannot use a router as a switch without using routing and different subnets … so … you might want to reconsider your design

Might be conflicts due to several routers using the same subnet… could cause some interesting ARP issues for the switches, and also DHCP conflicts if something is wrongly cabled / configured.

I would try disconnecting everything from after the first switch, connect a computer there to see if it works ok, then reconnect and test behind each step to see where it breaks instead of checking in the end where the problem could be agitated from a issue earlier in the network…

also, if the router has a firewall/nat you will not be able to reach anything behind it, even if there are different subnets being used… to be able to reach devices behind a router, the network would need to be routed and not nat’ed as nat combines all network traffic into the IP of the router before sending the traffic away, so clients on the other side has no way of knowing who or where the traffic came from after the nat’ed router.

I suggest you read up about this if you are not familiar with difference between NAT and routed traffic.

anyway, this is just my theory, hope you find your problem and get it sorted :)

(edit added part about nat)

you’re welcome :)

or since you probably are from Denmark since you mentioned Danish in your other comments:

🇩🇰 bare hyggelig, og håper du fikk løst problemet ditt 🇳🇴

thank you :)

not to be that guy . but have you tried to search for an answer?

https://github.com/flatpak/flatpak/issues/4435

first hit on “flatpak question marks”… it’s due to the font you use in the terminal does not support or not fully support Unicode characters or your locale settings are not correct.

hope this helps and answers your question :)

(edit, lost part of a sentence)