[00:46] <brandonkal> lsusb shows my USB disk on a PCIe card but the drive is not available in fdisk or lsblk. What am I missing?
[00:51] <sarnold> some usb drives don't expose themselves as mass storage devices until a driver has done something with them
[00:51] <sarnold> you know all those stupid "value add" things companies try to do to look more appealing than the average
[00:53] <TJ-> brandonkal: show us "journalctl -k -n 30 | nc termbin.com 9999" just after plugging the USB device in
[00:54] <TJ-> brandonkal: I suspect this may be a UAS device with buggy firmware implementation, so linux may need to be told not to believe it is UAS
[01:00] <brandonkal> Thanks
[01:00] <brandonkal> https://termbin.com/kr89 TJ-
[01:02] <TJ-> brandonkal: yes, it is as I suspected
[01:02] <brandonkal> The drive appears correctly when plugged direct into mobo, but that is USB 2 so fixing this would be great
[01:06] <brandonkal> How do I tell it not to see it as UAS TJ-
[01:07] <TJ-> "sudo -i" then " echo '0bc2:ab2a:u' > /sys/module/usb_storage/parameters/quirks "
[01:07] <TJ-> brandonkal: then reinsert it and check. If this solves it you can set it in a config file
[01:09] <TJ->  with " echo 'options usb_storage quirks=0bc2:ab2a:u' | sudo tee -a /etc/modprobe.d/usb_storage.conf "
[01:15] <brandonkal> TJ- it does appear to make it available but now a mount fails with "can't read subperblock on /dev/sdj2"
[01:16] <brandonkal> *superblock
[01:16] <TJ-> brandonkal: that means there are additional file-system related issues on that device. Check what the metadata reports for that device, with "sudo blkid /dev/sdj*"
[01:17] <TJ-> brandonkal: also, in these cases, always check the recent kernel log entries for indications of I/O errors, with "journalctl -k -n 20" (last 20 messages from kernel log)
[01:19] <brandonkal> Thanks. blkid returned nothing. Result of kernel log check: https://termbin.com/6w9m
[01:20] <TJ-> brandonkal: looks like the USB device doesn't like that connection
[01:20] <brandonkal> the pcie slot? TJ-
[01:21] <TJ-> brandonkal: not sure, but there seems to be a CRC failure judging from the error "Information unit iuCRC error detected"
[01:22] <TJ-> brandonkal: this PCIe device, what is it, a USB 3.0 controller/hub ?
[01:24] <brandonkal> 3.2 but lsusb shows it as 3.1: https://www.amazon.com/gp/product/B08M5YHWFD
[01:25] <TJ-> what does "lspci -nn -d ::0c03" report?
[01:26] <brandonkal> TJ- https://termbin.com/2qu2
[01:34] <TJ-> brandonkal: I've been researching , there are a few reports of issues with that device mainly in it not delivering, or reporting, USB 3.1 gen 2 correctly, but nothing so far about devices failing
[06:39] <williamo> finally getting to my backlog, have an issue on esx where the ubuntu 20.04 VM has a mix of encrypted/unencrypted disks, and they won't boot on and 5.4.0-81 and up. tried doing init=/bin/sh, but it doesn't seem to boot that far
[06:41] <williamo> https://imgur.com/VUH7XWc is what I'm getting after letting it try and boot
[06:42] <williamo> if I change all the disks to be either encrypted or unencrypted, the host boots fine.
[06:46] <williamo> sda & sdb are unencrypted, sdc is encrypted
[07:06] <punkgeek2>  I want to add the second IP with a different interface, but netplan gives me the following error. anyone can help me?  https://paste.ubuntu.com/p/thX3p97RnV/
[07:19] <williamo> you only get 1 gateway, which is your default gateway.
[07:20] <williamo> I don't know if netplan will let you sport configuration for multi-homed interfaces
[07:21] <williamo> maybe this is what you are after https://serverfault.com/questions/939922/netplan-with-2-nics-each-connected-to-a-different-gateway
[07:21] <williamo> punkgeek, ^
[07:22] <punkgeek> williamowilliamo: I've tried this one but still doesn't work: https://paste.ubuntu.com/p/zXvPF7nqQt/
[07:22] <punkgeek> williamo: Yes i configured that, but here is the error: 
[07:22] <punkgeek> ** (generate:560331): WARNING **: 07:17:17.194: Problem encountered while validating default route consistency.Please set up multiple routing tables and use `routing-policy` instead.
[07:23] <punkgeek> Error: Conflicting default route declarations for IPv4 (table: main, metric: default), first declared in ens192 but also in ens160
[07:28] <williamo> might need to add 'metric:' options to the 'routes:' ?
[07:28] <williamo> https://netplan.io/examples/
[07:30] <punkgeek> williamo: doesn't works, same error
[07:30] <punkgeek> https://paste.ubuntu.com/p/r7cBk3FQ47/
[07:35] <williamo> do we need to create entries in /etc/iproute2/rt_tables.d/*.conf 
[07:35] <williamo> ?
[07:36] <punkgeek> williamo: pardon me?
[07:38] <williamo> I'm not familiar with the inner workings of netplan, I do remember when doing this with ifupdown, I needed to create routing table entries for iproute2 to behave
[07:39] <williamo> in either /etc/iproute2/rt_tables or /etc/iproute2/rt_tables.d/*.conf, depending on where you prefer to drop your edits
[07:40] <lordievader> Good morning
[07:40] <williamo> hey, I can get to busybox now. and then it promptly goes away when I try to run blkid
[07:41] <lordievader> punkgeek: Did you define a default gateway for both interfaces?
[17:56] <stgraber> cpaelzer, blackboxsw: can you take a quick look at https://discuss.linuxcontainers.org/t/lxd-first-class-cloud-init-support/12559 and confirm it's fine with you?
[17:56] <blackboxsw> checking
[17:56] <stgraber> then we'll approve the spec and get it implemented (should be a very quick one)
[17:58] <blackboxsw> stgraber: do we think there will be room for a followup spec on HTTP-long-poll endpoint for metadata changes later in this cycle separate from this spec?
[17:59] <blackboxsw> two items I'm hoping for later from lxd: 
[17:59] <blackboxsw> 1. instance-id in metadata that is a UUID that is unique if any cloud-init metadata changes, so that cloud-init can re-run on next instance boot
[18:00] <blackboxsw> 2. HTTP long-poll route from LXD API so cloud-init could query for metadata changes on the live system and potentially react for network hotplug behavior (like a new  device add or remove)
[18:01] <blackboxsw> these are likely next cycle work, but it'd be nice to have some plans for that groundwork if possible. (not sure if I should weigh in on those aspects for this review)(
[18:02] <stgraber> blackboxsw: ah right you wanted longpoll because websocket isn't much fun from python, that should be reasonably easy to add once we get more details on exactly what we'd want on there
[18:02] <stgraber> blackboxsw: for the instance-id, that should be pretty easy to do once we have users transitioned over to the new config keys
[18:03] <blackboxsw> stgraber right, pulling in websocket dependencies on cloud-init is going to be a big bloat for cloud images, and not so fun on bionic I expec.
[18:03] <stgraber> blackboxsw: at which point we can add logic so that a new uuid is generated every time they're touched
[18:04] <stgraber> blackboxsw: I'll add a card on our side to have those two bits done first thing next cycle so you don't end up blocked on it. We may do the UUID one sooner depending on when we feel most folks have moved away from user.* as we'd only monitor the new keys and want to avoid a lot of confusion in the process ;)
[18:04] <blackboxsw> per http long poll: "once we get what we'd want there". cool, I'd probably suggest separate spec for that then (where we can provide you with our expectations) 
[18:05] <blackboxsw> and +1 on next cycle for http long-poll. right on UUID would work and migration to cloud-init.* keys .
[18:06] <stgraber> ok, cool, I've added a card on our side for next cycle with both items
[18:21] <blackboxsw> stgraber only one question, not sure what we should do about user.network_mode which cloud-init LXD also consumes when generating fallback network config to avoid bringing up a network interface if "manual" is set
[18:21] <blackboxsw> comment in the spec https://discuss.linuxcontainers.org/t/lxd-first-class-cloud-init-support/12559/8
[18:31] <blackboxsw> stgraber: approved. I expect I can have this feature up for review in cloud-init this week. It will then be present when LXD has support and shouldn't break existing behavior
[18:32] <stgraber> blackboxsw: sounds great! On our side, Thomas said he already had the code ready, so just need to put it up for review. So LXD 4.21 (due first week of December I believe) will have all of that.
[18:32] <blackboxsw> stgraber: FYI, I still need to update LXD streams metadata/templates with CPC to prefer LXD above NoCloud on Jammy by default. Will ping you folks when that streams/metadata change is in place for your own awareness in case interesting networking bugs come in based on the new LXD datasource rendering fallback config on non-amd64 platforms
[18:33] <stgraber> blackboxsw: sounds good and we'll need to similarly update our own images to prefer it too on jammy and up
[18:34] <blackboxsw> nice to have a roadmap item sorted so early in the cycle
[18:41] <stgraber> blackboxsw: yeah, we try to always prioritize any item that affects other teams
[20:22] <cpaelzer> stgraber: blackboxsw: ack (answered on the thread)