y0din

No, dd won’t work reliably when copying from a larger drive to a smaller one. To do this, you would need to resize and align the partitions first, handling each partition individually, or use a different cloning method.

A better approach is to use something like Clonezilla. In advanced mode, it allows you to clone from a bigger disk to a smaller one, provided that the used space on the source drive does not exceed the capacity of the target drive. Without this, it won’t be possible with any tool, not just dd.

Here’s a tutorial for Clonezilla advanced mode:

https://clonezilla.org/clonezilla-live/doc/11_lite_server/advanced/09-advanced-param.php

(edit added link, and saw the second post just before me with the same answer, not trying to steal from it @ProfessorNeurus@programming.dev, sorry!, you posted while I wrote mine, so please feel free to ignore this, feels so dumb to just delete posts)

Or a VESA Local Bus card … remember when I got my first Cirrus Local graphics card after years with ISA cards 🙂

deleted by creator

Thank you!

There are many good answers here already, just wanted to add to it.

It sounds very much like what you’re seeing could be either a driver fault or a memory-related issue. Both can manifest as hard system freezes where nothing responds, not even Ctrl+Alt+Fx or SysRq. You mentioned this briefly before, and that still fits the pattern.

If it’s a driver issue, it’s often GPU or storage related. A kernel module crashing without proper recovery can hang the whole system—especially graphics drivers like NVIDIA or AMD, or low-level I/O drivers handling your SSD or SATA controller. Checking dmesg -T and journalctl -b -1 after reboot for GPU resets, I/O errors, or kernel oops messages might reveal clues.

If it’s memory pressure or the OOM killer, that can also lock a machine solid, depending on what’s being killed. When the kernel runs out of allocatable memory, it starts terminating processes to free RAM. If the wrong process goes first—say, something core to the display stack or a driver thread—you’ll see a full freeze. You can verify this by searching the logs for “Out of memory” or “Killed process” messages.

A failing DIMM or a bad memory map region could also behave like this, even if Windows seems fine. Linux tends to exercise RAM differently, especially with heavy caching and different scheduling. Running a memtest86+ overnight is worth doing just to eliminate that angle.

If your live USB sits idle for hours without freezing, that strongly hints it’s a driver or kernel module loaded in your main install, not a hardware fault. If it does freeze even from live media, you’re probably looking at a low-level memory or hardware instability.

The key next steps:

Check system logs after reboot for OOM or GPU-related kernel messages.

Run memtest86+ for several passes.

Try a newer (or older) kernel to rule out regression.

If it’s indeed a driver or OOM event, both would explain the “total lockup” behavior and why Windows remains unaffected. Linux’s memory management and driver model are simply less forgiving when something goes sideways.

Not to step on anyone’s toes, but HTTP 4xx errors usually mean the request isn’t allowed or can’t be fulfilled on the client side (like needing to log in, an expired link, or access restrictions). 5xx errors are the ones that point to real server issues. So in this case it might just be the hosting platform enforcing access rules rather than a problem with Summit itself. Just sharing a thought.

Network edge cases — interrupted or partial requests can reach the server in an incomplete form, which results in 400.

Edit/afterthought:

Something that occurred to me afterwards: sometimes 400s can also pop up from network edge cases — like an interrupted or partial request reaching the server in an incomplete form (RFC 7231 §6.5.1). And since you’re on a different Lemmy instance, it could just be that side acting up. Lemmy servers typically run behind an nginx reverse proxy (default setup), and if that proxy or backend gets overloaded, it may return 400s. Add in federation quirks like sync or backlog delays, and it would explain why it sometimes works fine and sometimes doesn’t — different people see different images fail at different times.

That’s true for some types of signal boosters, especially the simple passive ones. But many building systems aren’t just passive repeaters — they use distributed antenna systems (DAS) or active repeaters that re-broadcast the signal from outside towers. From the phone’s perspective, those can sometimes look like a new connection point, even though they’re not rogue towers reading data.

So while your point is absolutely right that a normal repeater doesn’t act as a tower or capture phone info, the way modern indoor coverage solutions are implemented can still trigger the same kinds of warnings. That’s why it can be hard to tell apart a harmless booster from something more suspicious.

More information about DAS systems and cellular repeaters, and how they differ, if you’re interested:

🔗 https://en.m.wikipedia.org/wiki/Distributed_antenna_system

🔗 https://en.m.wikipedia.org/wiki/Cellular_repeater

(edit, added Wikipedia links)

It could also be something less alarming, like cellular repeaters inside the building. Many buildings use these to boost indoor coverage when concrete and steel block signals from outside towers, and that might explain why your phone flagged multiple connections so quickly. I’m not ruling out the possibility of a rogue tower or IMSI catcher, but it’s worth considering that the alerts could simply be repeaters being picked up by this new warning feature. Either way, it’s good that your phone is making you aware — at least now you know when unusual connections happen.

Thanks! For contexts, this is one of the last features I’ve missed since moving from Sync. I often refresh my subscribed/all posts after reading for a while—still chasing that dopamine hit for new content—and end up with lots of read posts back in my feed if I forget to toggle the switch, which is still a lot better than constantly bashing the hide read earlier 🙂

Could we have an option to make the “Hide Read” switch permanent, either globally in the settings or per community in the FAB? It now seems to reset after closing the app, not sure if this is intended or a bug?

Thanks for adding this feature and for all the great work you do!

Thank you 🙂👍

I’ve come across a new bug with the rail, almost the same as before, but this is inside the post, not the main view.

When you enter a post, click on an image, and then press the back button, you get a result that’s almost identical to the previous issue. Just wanted to give you a heads-up in case this hasn’t been reported yet. I’m using the same screen configuration mentioned earlier in this thread, so it was easier to report here since the parameters are otherwise unchanged (resolution/portrait/Samsung zfold 6).

Just happy to help 🙂

Yes, this is the layout I get in landscape, but it’s not picked up in portrait, so that it’s just a bit too narrow would make sense for it not to be picked up as a large screen as the resolution is kind of weird when tilted into portrait instead of landscape.

Do you need anything more from my part? If so, or if you want me to test/change anything, let me know, I am happy to supply with whatever I can to help 🙂

Here is a screenshot of the setting, and if I read this correctly it’s off, which makes sense for me as I mostly use the app in “small screen mode” where I prefer it to be on the bottom.

The problem surfaces when used in unfolded (big screen) portrait mode, as for landscape view of the same unfolded screen, it’s split and works as usual.

As far as I can tell, rail mode is off and large screen is on?

For reference the resolution for the folded out display is 1856 × 2160 pixels and it happens in “portrait” mode, where the resolution will be weird I guess.

If I switch to landscape the issue is not present, I didn’t think to test for that until you mentioned “weird screen size”.

Thanks for looking into it, and it’s probably a corner case since the foldable screens are not all that common, at least not yet.

There is a new bug in the current version if you use a Galaxy fold big screen, kind of hard to describe so here is a screenshot:

As always, thanks for your great work!

If you want a second attempt, this might help.

To get USB devices working inside a container, you need to map the device into the container, which can be tricky—especially if you’re running rootless containers.

If you’re on Linux and want to avoid complicated setups with user namespaces, groups, or messing with udev rules, the easiest way to start is by manually recreating the device node inside a folder you control (like where your config is stored) using mknod.

For example, if your USB device is /dev/ttyUSB0:

1. Run ls -l /dev/ttyUSB0 You should see output like: crw-rw---- 1 root dialout 188, 0 Jan 1 1970 /dev/ttyUSB0

2. Note the major (188) and minor (0) numbers.

3. Change directory to the folder where you want to create the “clone” device node, then run: sudo mknod -m 666 ttyUSB0 c 188 0 (Use the major/minor numbers from your device — they differ by device.) This will create a device readable and writeable by anyone on the system so perhaps consider changing the mode from 666 to 660 and/or chown the file afterwards to your user and group. As I said, this is HACKY and not a secure solution.

You will now have a device file you can then pass into your container with the Docker/PODMAN option: –device /path/to/your/folder/ttyUSB0:/dev/ttyUSB0

I realize this is a pretty hacky and insecure workaround—feel free to downvote or ignore if you want something cleaner. But it’s a quick way to get your USB device accessible inside the container to get started. Later on, you can look into proper handling with udev or other methods if security is important.

If you use Windows, you are on your own unfortunately, I do not have experience with podman/docker in Windows environments.

or got a very good deal on TEMU?

Thank you so much for all your hard work on Summit! I know you’re probably already juggling a ton of feature requests, but I was wondering if it would be possible to add an option to organize downloads into folders based on their source—something like <download folder>/<community>/<downloaded file>.

Sync used to have this, and it made my (admittedly excessive) image and meme collections so much more organized, even if I rarely look at them again. Definitely not a big deal, just a nice-to-have. Thanks again for everything you do!