[09:46] <zetheroo1> I am trying to remove a package but am getting 'Processing was halted because there were too many errors.'
[09:47] <zetheroo1> Full output https://pastebin.com/f0gsmgze
[09:51] <tomreyn> zetheroo1: it appears that the post-removal script which is part of the installed onlyoffice-documentserver package (and can be specific to its package version) ran into an error. you may be able to get more information about this by running the    dpkg --remove   command against this package manually / directly.
[09:53] <tomreyn> zetheroo1: what can help in such situations is to first upgrade the package to the latest version, then attempt removing it again. another approach you could take is to edit the post-removal script manually to work around the root cause of this error (once you know it), then attempt removing the package again.
[09:53] <tomreyn> note that this is a third party package, not supported by ubuntu
[09:54] <zetheroo1> Ok
[09:57] <zetheroo1> I did 'rm /var/lib/dpkg/info/onlyoffice-documentserver.postrm' and now the package uninstalled successfully 
[09:59] <zetheroo1> Another question ... probably not Ubuntu-specific ... I have a RAID5 which randomly becomes read-only. I have to unmount it, do a fsck on it, and then remount for it to be read/write again. 
[09:59] <zetheroo1> Any idea what could be causing it to become read-only? Could a failing/bad disk do this?
[10:01] <tomreyn> RAID-5 is not a file systems. you do not unmount it, run a fsck against it.
[10:02] <tomreyn> RAID-5 is not a file system. you do not unmount it, or run a fsck against it.
[10:03] <tomreyn> you may be able to run a parity check against the RAID, depending on how it was setup and which tools are available for its management.
[10:04] <tomreyn> a failing disk is a common cause of a RAID implementation pausing writes to a RAID array.
[10:05] <tomreyn> (may vary by RAID level and implementation, though)
[10:10] <zetheroo1> ok, yes, sorry. I unmount /dev/md0 and run fsck against that
[10:14] <tomreyn> md events go to dmesg, are logged to syslog / the systemd journal. journalctl -b    would get you access to anything logged since the latest boot. search for "kernel: md"
[10:15] <tomreyn> cat /proc/mdstat     provides information on the current state and health of all md managed RAID arrays.
[10:19] <tomreyn> for anything else, use mdadm
[10:20] <zetheroo1> ok, seems to be a lot of messages like this in the syslog:
[10:20] <zetheroo1> Jun 27 22:59:16 gary kernel: md/raid:md0: read error not correctable (sector 5009093760 on sdc).
[10:20] <zetheroo1> oh crap ... for sdd as well
[10:21] <tomreyn> RAID-5 is not recommended nowadays, certainly not with larger disks.
[10:22] <zetheroo1> These disks are from an old NAS (FreeNAS) which was running for ~6 years ... so I guess the disks would be pretty worn :P
[10:23] <zetheroo1> I was going between RAID5 and 10 ... but 10 seemed overkill for a Home NAS
[10:29] <zetheroo1> I noticed I have the lxd snap installed - is this a default snap on Ubuntu Server 20.04?
[10:30] <zetheroo1> do some snaps "pull in" other snaps? https://pastebin.com/KEYZqHsh
[10:42] <murmel> zetheroo1: yes, lxd is default on server
[10:43] <murmel> the only 3 snaps by default are lxd,core20 and snapd
[10:56] <zetheroo1> ok thanks
[11:07] <zetheroo1> I have now replaced the worst disk (sdd) in the RAID5 array, but I'm confused about the various commands/instructions online about re-adding the disk to the array. So far I did 'sudo mdadm --add /dev/md0 /dev/sdd' and 'sudo mdadm -D /dev/md0' shows /dev/sdd 'rebuilding'. Do I have to do anything else? There's instructions to use the 'mdadm --grow' command and to create the filesystem etc on the new disk ... 
[11:08] <zetheroo1> This is the output of mdadm: https://pastebin.com/XB4fqHub
[11:41] <radioa> Hi, I have an issue with Gigabyte E252-P30 ARM platform with Ampere Altra Q80-30: i can't boot Ubuntu Server 20.04/22.04 net installers via iPXE in UEFI mode. Files(initrd, linux) loads successfully, but after that i see 3 messages with EFI stub: prefix, last one is EFI stub: Exiting boot services and installing virtual address map... At this point, loading hangs. Any tips or ideas are greatly appreciated!
[15:43] <yurtesen> ahasenack: jetty9 has the same problem as tomcat9. Syslog is not able to write to /var/log/jetty because the log folder has 750 permissions and owned by jetty:jetty.  As the syslog user does not have write access...
[15:51] <akincer> Back in 20.04 there was a bug during server install that caused the installer to crash on a VMware VM if IPv4 is configured. It appears this still exists in 22.04. Is this a known bug that is slated to be fixed?
[16:39] <tomreyn> akincer: do you have the bug report id? "crash" as in a segementation fault, or something else? what does vmware do differently that would trigger this?
[20:06] <samy1028b> akincer: Could you give more details.  I've been running a bunch of Ubuntu 14.04/16.04/18.04/20.04 on ESXi 6.0/7.0 and never seen anything like this.
[20:06] <samy1028b> Is it ESXi / vSphere,  VM Workstation, VM Player, or something else where you saw this?
[21:07] <patdk-lap> akincer, I'm not sure what your talking about
[21:07] <patdk-lap> I have installed hundreds of 20.04 and 22.04 on esxi 6.5 and 6.7 without an issue with ip4 configured