littlenoodles's questions

I was getting an annoying "failed to update metadata for lvfs" in the Kubuntu 20.04 'discover' app. This was causing no problems, but I found a site that recommended fixing it by running fwupdmgr --force refresh

After doing that, the system rebooted on the next attempt to install updates - and would either reboot or just hang the updater any time I tried to update. So, figuring I had somehow installed a bad package on my system, and because I was running 20.04, I decided to move forward and install 22.04.1. I installed it into a new partition, and it seemed to have fixed it (i.e., I was able to perform some initial updates on the new system). But the next round of updates caused the crash again. I noticed that one of the updates was "UEFI dbx - update to version 217". If I deselect that one, all the other updates run okay. But if I try to run that update, the system reboots.

Have I trashed something. Since I'm running a new, clean OS in a new partition, I'm guessing the initial fwupdmgr attempted to do some kind of UEFI firmware update - so something may be trashed in firmware that affects more than just the older OS where I ran fwupdmgr (unless the problem is something in /home - I'm using the same /home partition in the new OS). Am I screwed - or is there a way to fix this? I suppose I could disable updates to UEFI dbx in Discover and hope that that gets around it... For now, I disabled the 'lvfs' firmware update service repository, and UEFI dbx no longer shows up as an available update. Is that kosher?

By the way, the package description for UEFI dbx says it has to do with updating secure boot signatures. I have secure boot disabled and Kubuntu installed without the shim (I think). I guess maybe that's why my system still works.

I've been given an old company laptop with a Windows 7 / CentOS dual boot setup - using MBR. I want to wipe the whole thing and install Ubuntu under UEFI - but I want to create my own partition layout (essentially, a normal layout with a second, unused 'root' partition to install a future new Linux distro into without trashing the live one).

So is it sufficient to simply choose 'manual', delete everything that's there, and set up the partitions I want? Will that also set up UEFI booting for me? I assume I also have to tweak the BIOS to boot off of UEFI - it's currently set to legacy. I'm typing from Ubuntu booted from a UEFI flash drive, so the BIOS can certainly handle it...

If it's not possible to do this in one step, can I just let Ubuntu 'take the whole disk' and then reinstall it after Ubuntu has done whatever magic it needs to do to convert to UEFI?

Trying to build a 32-bit app on kubuntu 18.04. I've got it to the point where I can use -m32 to compile my code in 32-bit mode, and am able to build a trivial app (once I installed multilibs). But now I'm trying to build an app that uses -lcurses, and ld is complaining about an incompatible X86-64 version of -ltinfo (which I assume is the 'terminfo' library - and is called in by my invoking the curses library). Specifically:

/usr/bin/ld: skipping incompatible //usr/lib/x86_64-linux-gnu/libtinfo.so when searching for -ltinfo

I've got cc -m32 on my final build line, and it's not complaining about any other libraries.

For what it's worth, if I go with the system defaults and allow my app to build as a 64-bit binary, everything builds - so I'm assuming I'm asking for all the right libraries, etc. It's just that the app doesn't work right as a 64-bit app, and before I go down the path of figuring out why that is, I thought I'd try to build it as a 32-bit app - which worked 20 years ago when I did my first 'proof of concept' linux build for this app ;-)

Is there some other way to invoke the 'ld' command to get the proper 32-bit libraries to load? Or do I have to install yet another 32-bit library package for -lcurses to work in 32-bit mode?