[10:58] <FatPhil> I'm feeling a bit derpy - is there a tutorial for creating a persistent live lubuntu usb? I last did it about 3 years ago, and forgot to take notes.
[11:25] <kc2bez> FatPhil: I think the best tool for that is mk-usb https://help.ubuntu.com/community/mkusb
[11:47] <FatPhil> yeah, I do remember using that tool in the past. Alas, I can't find what machine I must have done it on.
[11:51] <FatPhil> However, it gets worse - I'm not even seeing any live isos any more!
[11:56] <kc2bez> If you need to download a Lubuntu iso, you can find them here: https://lubuntu.me/downloads
[12:09] <FatPhil> Ah, they work as live images as well as installation media?
[16:13] <kc2bez> FatPhil: sorry I missed your message earlier. Yes the downloads are both live images and install media. 
[16:31] <bob> 20.04 MATE desktop.  Right-click works ONLY in apps and menus, NOT on the desktop.  Any ideas?
[21:47] <FatPhil> looks like my /var/lib/dpkg/status is corrupt, is there anyway I can replace or regenerate it. I do have a status-old - can I just copy that back and cross my fingers?
[21:49] <FatPhil> heck, the system's trashed, I can't lose anything, fingers being crossed...
[21:56] <FatPhil> it seemed to cope - did an apt upgrade, but that stopped with an error: dpkg: error processing archive /tmp/apt-dpkg-install-dXkVVc/4-dbus_1.12.16-2ubuntu2.3_amd64.deb (--unpack):
[21:56] <FatPhil> unable to make backup link of './usr/lib/dbus-1.0/dbus-daemon-launch-helper' before installing new version: Input/output error
[21:59] <arraybolt3> Yikes, I/O error could indicate a disk problemm.
[21:59] <arraybolt3> Which may also explain how /var/lib/dpkg/status got corrupted?
[21:59] <FatPhil> ls -al on the dir shows me there's a socket with that name, but any attempt to open it gives the io error
[21:59] <FatPhil> yeah, there was corruption from an unclean shutdown
[22:00] <arraybolt3> Hmm... you might need to run a filesystem check?
[22:00] <FatPhil> but that's a socket, not a realfile
[22:01] <arraybolt3> True. That's odd.
[22:01] <FatPhil> I did a reboot into recovery mode a week or soback,I forgot what it told me when I fscked - I'llreboot and try again
[22:04]  * FatPhil carelessly trips his own sshd fail2ban
[22:07] <FatPhil> ah. I can't do the 'dpkg' option from the recovery boot, as I don't have the network up - how do I do that?
[22:07] <FatPhil> it's running inside a QEMU on a devuan, and the desktop live boot just worked on picking up the network automatically
[22:08] <FatPhil> ah, the 'network' option just did some stuff in the blink of an eye and has appeared to cope
[22:12] <FatPhil> ugh, resume normal boot doesn't resume normal boot, it resumes default boot, without my high-viz settings. But worse - it confuses the QEMU about the size of the screen so that the desktop pans around like an old fashioned virtual desktop from the 90s - whilst simultaneously not taking up the whole of the QEMU window.
[22:13] <FatPhil> feature request - given that 'fsck' can't be run after 'dpkg' in the recovery menu, and you need to reboot - how about adding a 'reboot' option to the recovery menu?
[22:14] <arraybolt3> That seems like it might be useful.
[22:14] <arraybolt3> Not sure off the top of my head how one would implement that (I think Recovery Mode is built into the kernel?), but it would be handy.
[22:15] <FatPhil> Only a minute later did I think about dropping to root shell and shutdown -h now!
[22:19] <FatPhil> Ah, yes, now I remember how fsck didn't work: /lib/recovery-mode/recovery-menu: line 80 /etc/default/rcS: no such file or directory
=== guiverc2 is now known as guiverc
[22:25] <FatPhil> of course, on the persistent live boot, /etc/ is part of the cow overlay confusion - can I just put an empty file there? Or condition out the line that sources it in recovery-menu?
[22:33] <arraybolt3> Sadly, I don't know.
[22:36] <FatPhil> I could even try to replace it with a real file - this is the 20.04 image - can I grab that file from anywhere?
[22:37] <FatPhil> I'm not sure how /cow deals with deletions - presumably the lack of a dentry in the overwritten dir just means the file is no longer visible. I can't imagine a way to undo that dir overwriting.
[23:00] <FatPhil> not according to kernel docs:  "If both actual lookups find directories, both are stored and a merged directory is created" -- https://www.kernel.org/doc/html/next/filesystems/overlayfs.html
[23:01] <FatPhil> oooh, there's more info later in that doc
[23:25] <FatPhil> of course, I forgot about the google options: https://ubuntuforums.org/showthread.php?t=2452636 https://askubuntu.com/questions/1087205/fsck-e2fsck-cannot-continue-aborting ...
[23:26] <FatPhil> first reported Aug 3, 2018, it seems, and still an issue in 2022