[00:00] <sarnold> no, so it doesn't use /dev/sdc etc
[00:00] <sarnold> those names aren't persistant
[00:00] <sarnold> they can change across reboots
[00:04] <kinghat> that must be its default, correct?
[00:06] <sarnold> there is no default -- zfs uses whatever names you used in the zfs create command
[00:07] <sarnold> if you used the short names, that's what it'll use
[00:07] <sarnold> and if they change, you'll have a Bad Time
[00:08] <kinghat> ya that must be whats going on because i added drives to the system. i just figured it would find its zfs drives and do its thing 🤷‍♂️ or at least find the drives and use the new device names, if that is the situation.
[00:12] <sarnold> because systems may have several thousand drives, it's not the default behaviour to go looking for drives, that'd take forever
[00:12] <sarnold> that's the reason for the cache file..
[00:12] <sarnold> but if it's busted, it'd be nice if it tried to help out a bit, heh
[04:48] <kinghat> sarnold: you still around?
[04:52] <kinghat> i exported the pool and did zpool import -d /dev/disk/by-id -a. seems to have worked. thanks again!
[05:14] <cpaelzer_> Intelo: even i915 has working vGPU support (less powerful as a GPU, but more compatible and easy to use actually), I tried it on my Laptop once
[12:08] <icey> jamespage: could you take a look at https://code.launchpad.net/~chris.macnaughton/ubuntu/+source/openvswitch/+git/openvswitch/+merge/387852 ?
[13:03] <Peanut> auxin: #zfsonlinux may be a more useful venue for you to get help with recovering your data.
[18:03] <sarnold> kinghat: is everything all sorted out with your pool? :)
[18:04] <kinghat> sarnold: it seems to be but i havent pulled the power and all that to really test it. i will in an hour or so.
[18:07] <sarnold> kinghat: heh, yeah, I know the reluctance to actually *test* those kinds of things..
[18:49] <|\n> hello, since 20.04 i need some `ebtables -t broute` equivalent, is there any?
[18:58] <sarnold> |\n: what happens when you use it? it's still documented in the ebtables manpage on my 20.04 laptop anyway
[19:01] <|\n> sarnold, in my case it drops certain frames from certain interface
[19:03] <|\n> well it was doing so at 18.04
[19:05] <|\n> it was pretty sweet and cozy to look into if_ether.h and drop something heh
[19:28] <sdeziel> is there a way to prevent a package upgrade from running the .postinst script?
[19:30] <|\n> exclude it from package / repackage maybe
[19:30] <sarnold> sdeziel: unpackage it by hand?
[19:30] <|\n> though doesn't sound like a good idea
[19:30] <sdeziel> sarnold: it's what https://askubuntu.com/questions/482928/ignore-apt-get-postinstall-scripts-automatically suggests too :(
[19:31] <sdeziel> not what I was looking for but thanks anyway ;)
[19:32] <sarnold> sdeziel: maybe try the touch postinst thing, then set immutable?
[19:32] <sarnold> sdeziel: probaby dpkg will blow up and leave you with a big mess. but maybe it will ignore errors?
[19:32] <sdeziel> sarnold: that's what I tried at first but I'm in a container where the underlying FS doesn't let me
[19:33] <sarnold> sdeziel: if the package in question shld do different things in a container, that's probably worth a bug report
[19:33] <sdeziel> in lxd containers backed by btrfs or zfs, I get a permission denied on the chattr +i
[19:34] <sarnold> yeah, that part makes sense
[19:34] <sdeziel> yeah, I'll probably end up reporting this as a bug but it's not because it's in a container
[19:35] <sdeziel> it's too hard to run MySQL read-only replicas on Ubuntu IMHO
[19:36] <sarnold> ugh yes, that's gonna be annoying
[19:36] <sarnold> that script deserves a MYSQL_DO_NOTHING
[19:37] <sdeziel> I'd like the postinst to not explode when in read_only and/or super_read_only mode
[19:40] <sdeziel> sweet, the bug affects MySQL 5.7 only :)
[19:59] <sdeziel> closing the loop: LP: #1889472
[20:03] <sarnold> sdeziel: beautiful
[21:32] <kinghat> sarnold: looks like it survived the test
[21:32] <sarnold> kinghat: woot!
[21:32] <kinghat> thanks for checking back 🙏
[23:26] <boxrick> Howdy. I am currently attempting to install Ubuntu 20.04 on a USB Stick in a HP server, it works until it gets to 'Installing Kernel ' and just sits forever at 'Unpacking linux-firmware'. Any ideas on what may be going wrong?