Re: Ubuntu Linux broken after installation of QEMU 9.0.0 (latest version)
Hi there, On Sat, 25 May 2024, novaTopFlex wrote: I have installed QEMU 9.0.0 and have effectively attempted to remove my native QEMU 6.2.0 installation by pushing the 9.0.0 commands into the “/usr/bin/“ directory. Mr. Garcia gives good advice but I think this is off-topic for QEMU. Basically you're saying you broke your operating system with some ill-advised changes, and now you need to fix it. The fact that the ill-advised changes involved a new version of QEMU is irrelevant. My advice would be *never* make any manual modification to the content of system directories like /usr/bin in an Ubuntu system, but instead let the package manager do it all for you. The directory structures in Debian-based systems are sometimes fiendishly complex and you could do more damage than you've already done - to the point of making your system unbootable - if you get one character wrong in a shell command when you're logged in as root. Every now and then I'll do that myself because I haven't taken my own advice, but when I trash a system it's very rare that I can't fix it without telling anybody. I'll probably, nevertheless, mutter things about my own folly while I'm doing it. If you're using a distribution like Ubuntu or Debian you already have the facility to have different versions of packages installed on the same system at the same time. If I wanted to have a newer version of a system-installed package I might for example put the executables in /usr/local/bin/, and my environment setup would then have a PATH where /usr/local/bin/ was found earlier than /usr/bin/. That way I can run either version from the command line by typing the full pathname of the relevant executable, and if I just use the executable name without the path then I'd get the 'local' one. Of course you might want to do it the other way around, so that you'd get the old version by default. Here's the PATH on my desktop box: PATH=/home/me/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin As you can see I can build packages for installation in /home/me/bin/ and I'll get them by default instead of a system-installed version but anybody else who uses the system won't unless they're logged in as me or they've made a similar modification to their PATH. (This begs all sorts of questions about permissions, where to find any libraries, and what versions of everything will be required. If you stray away from the package management system then you have to figure all that out and attend to it by yourself, and maybe *nobody* will be able to help you if you screw up.) Anyway to get slightly back on-topic you can use these techniques to have a 'development' version of QEMU available, but keep the 'stable' version available on your system too. Starting things from a GUI is Yet Another Topic I won't go into now. I can no longer access various elements of my Ubuntu Linux (22.04.1 LTS system formerly with native QEMU 6.2) system, and some of these applications are absolutely essential to my caseload such as Chromium. I have also lost access to the NetworkManager service NetworkManager is usually one of the first things I uninstall, but if It Works For You you might try just reinstalling it. Something like sudo apt install network-manager might be all that's needed, or you might need to do some configuration if your network setup is complex or/and you've tweaked it in the past. If you just broke networking this might fix your browser problems, but if you did more than that it might not be the end of your troubles. because of pushing the installation of QEMU 9.0.0 forward and do not want to lose various pieces of my data to this issue. What is proper procedure for navigating through this issue? Unless there's enemy action, there's very little that can never be recovered. But first, if you wish and off-list since this is well OT, tell me about your routine backup procedures. -- 73, Ged.
Re: Windows 10 guest hanging
Hi there, On Sat, 5 Oct 2024, Hank Knox wrote: I have been running Windows 10 as a guest in a QEMU/KVM VM under Debian testing for several years now with no problems. Perhaps you've just been lucky. :) Debian says [https://wiki.debian.org/DebianStability] "Testing is just what it says it is; it's for testing whether it works reliably prior to its release as a future Stable." and "If it breaks, you get to keep both pieces." Stable is bad enough, in my experience there is *always* something badly broken by a major version number upgrade. Typically it will take a week to recover. I wouldn't touch Testing with a bargepole. Of course it depends a lot on which packages you're using, but my idea of fun isn't getting on an aeroplane to stop the reboot loop because 'fsck' takes longer than 30 seconds, or to edit the network config so things that need to talk IP can recognize the only friggin' Ethernet port on the friggin' box. You understand I mention just a couple of really stupid Debian screwups - both down to Systemd as it happens - but I have quite a long list. [*] After a recent set of qemu updates from Debian early this last week, Windows freezes after a few minutes of use: I get a spinning 'busy' cursor and the UI stops responding. ... Something with QEMU? A WIndows problem ...? ... other Debian ... problem? I'd caution against guessing what the problem is. Try, er, testing. :) Your description *seems* to indicate that the cause was possibly the "recent set of qemu updates from Debian early this week", and if it were me (not that under any foreseeable circumstances I'd be running Windows:) I'd back out the qemu updates and see what happens. You could use APT pinning to do that. Alternatively install a minimal Debian Stable somewhere and see if you have more luck. The problem might not be executable code, it might be some trivial configuration change. [*] Debian seems prone to trashing configurations which have worked for ages; often, when I find what they've done, it seems to me to be inexplicable. Like changing 'eth0' to 'enp2s0'. -- 73, Ged.
Re: qemu-system-arm -nographic question
Hi there, On Mon, 14 Oct 2024, yfliu2008 wrote: When using "qemu-system-arm -M virt -nographic" using QEMU v6.2 on Ubuntu 22.04, it seems the "Backspace" key doesn't work, are there any solutions? Bear in mind that most keyboards are programmable, and one man's backspace is another man's DEL or CTRL-H which is what I'd try first. If that fails I'd try to check what - if anything - my keyboard was actually sending to the application when I hit the backspace key. https://en.wikipedia.org/wiki/Backspace -- 73, Ged.
Re: qemu-system-arm -nographic question
Hi there, On Mon, 14 Oct 2024, Peter Maydell wrote: On Mon, 14 Oct 2024 at 11:12, G.W. Haywood wrote: On Mon, 14 Oct 2024, yfliu2008 wrote: When using "qemu-system-arm -M virt -nographic" using QEMU v6.2 on Ubuntu 22.04, it seems the "Backspace" key doesn't work, are there any solutions? Bear in mind that most keyboards are programmable, and one man's backspace is another man's DEL or CTRL-H which is what I'd try first. ... Unfortunately keyboard handling has a lot of different layers of software between your keypress and something actually happening, ... It occurred to me after I posted that I could have mentioned one of my anecdotes from about twenty years ago. A good customer bought a new computer but he wanted to keep his old keyboard - some weird Microsoft thing - because he'd got used to its extra buttons and used them a lot with CAD and what-not. Trouble was they didn't all work. By the time I'd got them all working I'd figured out that there were SEVEN layers of software between the keyboard and his applications and they all had their own, different and sometimes conflicting, ideas about what to do with the extra keys. Backspace isn't usually a huge problem but it is one of the more common ones. For a laugh it might be worth looking at 'man stty' too. -- 73, Ged.
Re: Logitech wireless keyboard problems
Hi there, On Thu, 26 Sep 2024, Frank McCormick wrote: I am running QEMU emulator version 9.1.0 (openSUSE Tumbleweed) I have three Linux distros, and all three are affected by this keyboard problem. If I leave any of them idle for more than 5 or 10 minutes, the keyboard become unresponsive. To get it back I have to shutdown and re-run the distro. The mouse is not affected - it continues to respond normally. I am running a Logitech wireless keyboard and mouse, with Logitech's USB transmitter/receiver plugged into a USB port. I have tried other USB ports and the problem continues. Does anyone have any ideas .. it sounds like a bug to me. To begin with I'd look in the logs (usually in /var/log) and e.g. use 'dmesg' to see if there's anything intersting. If USB communication is somehow being broken for the kernel I'd expect that there would be something which mentions it. As you say the mouse continues to respond it might be something in the keyboard itself over which you might not have a lot of control. There are all sorts of tools for hacking with USB, have you tried anything like 'usbreset' for example? If that helps, at least it would be better than a reboot and maybe you could put something in a crontab, to ping it every few minutes to keep it alive. I've done worse. ;) -- 73, Ged.
Re: Logitech wireless keyboard problems
Hi there, On Sun, 29 Sep 2024, Frank McCormick wrote: On 2024-09-26 10:49, Mihai Moldovan wrote: Since the issue only happens after some idle time, I suspect a screensaver to become active. They typically catch keyboard input, but no mouse input. That was it ! Never thought that the system would start a screensaver automatically. know better now. ! Funny, I always thought the idea was when the screensaver was active, you'd press a key on the keyboard to deactivate it... -- 73, Ged.
Re: QEMU, Windows 11, and Raspios
Hi there, On Mon, 21 Oct 2024, Jakob Bohm via wrote: On 2024-10-19 14:09, G.W. Haywood wrote: On Fri, 18 Oct 2024, Ignacio wrote: I am currently using a laptop that is running Windows 11 and I have downloaded QEMU. However, I cannot figure out how to use QEMU to emulate Raspios. Raspios does not use a .iso, but instead a .img. I was wondering if there is a way around this or if I am complicating this process. There surely is a way. The two data formats you mention are different because they are used for different purposes. [Snipped Long ranty description of everything but how to use the files with qemu ] Apologies if you found my post ranty. It was intended to help with an understanding of the differences between ISO files and filesystem image files. Nothing more. The rant got a lot of details wrong, so don't use it. Apologies too if there were mistakes in my rant. In fact it was just a draft, which I sent by accident - and from the wrong email address. If you would be kind enough to mark with an 'X' any details which you found to be wrong, even if it helps no-one else it may help me to get things clearer in my mind and hopefully avoid misleading anyone else. Thank you. -- 73, Ged.
Re: #!shebang
Hi there, On Wed, 20 Nov 2024, lacsaP Patatetom wrote: ... I can eliminate them using `grep` like this : `$ qemu $(grep -v '^#' configuration.qemu)` but it seems to me complicated and time-consuming to enter. ... ... another way ... ? You could always use an alias, something like alias qemugrep="qemu $(grep -v '^#' configuration.qemu)" I use aliases a lot, for things like alias l="ls -lrt" -- 73, Ged.
