[00:00] presume i'll have to force reboot xD [00:01] send ctrl-alt-del from the hypervisor? [00:01] daftykins: ' systemctl reboot ' ? [00:01] you should be able to do systemctl reboot [00:01] ah well i forced it already [00:02] it took the password properly that time, booting recovery mode [00:04] ooh heck of a lot of angry services [00:06] that's unexpected, unless it is due to no network [00:09] i popped netplan.io on and copied my conf, so i had an IP but non-working DNS [00:09] just erased resolv.conf by hand and set a basic one so i could install openssh-server as i seem to have forgotten that too [00:12] eeek, never delete it, let systemd-resolved manage it [00:13] it must have had missing paths as the symlink was dead [00:13] i think i can get by on that much, i just need fstab but it sucks having to edit through this console [00:13] for some reason SSHing in as my user i get auto disconnected [00:13] some property of the recovery mode perhaps? [00:14] does it actually connect? is there a separate /home/ that isn't mounted due to no fstab? [00:15] yep connects and gets killed after entering a password, nah /home/username is there fine [00:15] journalctl -u ssh [00:15] nevermind i have echo'd blkid into /etc/fstab and will just edit it down to what i want [00:20] this was quite the adventure [00:20] TIL ? [00:20] is it working correctly now? [00:21] still booting [00:21] i see a message under plymouth "cryptsetup: xvda5_crypt: set up successfully" [00:22] looks like i made an fstab error [00:22] anywho i'll keep at it! [00:22] SSH and login fine :) [00:23] that means the cryptsetup-initramfs worked correctly [00:23] nice one! [00:25] :D thanks for the assist! [00:25] so i need to fix at least this one from dmesg: [ 21.162563] EXT4-fs (xvda1): VFS: Can't find ext4 filesystem [00:25] not quite sure why that was wrong [00:28] did you add an entry for xvda1 in fstab? [00:28] yeah to avoid having to prune down to UUIDs [00:28] presumably since it's encrypted that's erroneous [00:28] I suspect you meant to put /dev/mapper/LUKS_BOOT [00:29] that's where the ext FS is [00:29] think of the block devices as a stack of those Russian dolls, one inside another ad infinitum [00:30] then it is easier to relate which block device to reference [00:30] yep [00:30] quick fix to /etc/hosts to allow sudo to resolve $hostname [00:30] sda > sda1 > LUKS > ext4 > dir > file [00:32] systemctl status appeared to have a problem with a couple of units, might give me clues on what else is broken xD [00:32] booting again to see what progress i've made [00:32] at least you made it boot 1st time ... many fail on that [00:32] hmm seem to be booting to a 30 second GRUB timeout on each boot now [00:33] hehe :D yeah i can feel slightly smug! [00:33] in realworld terms though, how far ahead is all this versus using the installer's encrypted LVM option? [00:33] that timeout is likely due to the OS not setting the boot-success flag that GRUB tests so it shows the menu and runs the timeout [00:34] well the installer cannot encrypt a separate /boot/ [00:34] mmm so there's the tamper risk [00:34] that's the entire point of the tutorial [00:35] yep [00:35] for my use-case of a VM running atop an XCP-ng host though, do you think both choices are good enough? [00:35] right - UEFI SecureBoot can at least detect tampering, but this makes it more difficult since kernel and initrd cannot be got at, and you can guard against GRUB's core being compromised in the BIOS boot by simply saving and checking its hash [00:36] "systemctl status" reports a clean "running" now \o/ [00:36] boot isn't particularly fast, but it gets there [00:37] * TJ- awards daftykins the order of Tj, 1st class [00:37] but it shouldn't boot more than once a year! [00:37] woohoo \o/ [00:37] hahaha, that's true... well it's going to be an R-Studio server, so once it's created, hopefully there'll not be much trouble [00:38] thanks to the beauty of virt, i can now snapshot that install and call it 'known good' [00:39] well, after removing my easy passphrase i suppose ;) [00:40] wow i think it's time to step away and get food! [00:41] good plan - I've not eaten today yet (Saturday) and I'm doing an overnighter at the office currently [00:42] ooh my! [00:42] big task on? [00:42] well many thanks once again, hope i didn't distract you too much :D [00:44] I came in to do some electrical installations but can't make much noise overnight so doing some kernel build and test for our Turris Mox gateway switch/router, since I'm deploying Debian on it with latest kernel [00:44] I can get on without distractions at weekends [00:45] ah ha [00:45] right, to that food young man! :) [01:49] anyone else think asdfgh isn't really using an Ubuntu install? [02:10] seems likely and i'm not even in there (: [03:38] good morning [03:43] morning lotuspsychje [03:44] guess who's still working! [03:44] hey TJ- [03:44] what madness are you trying to solve this time TJ- [03:46] right now? checking if the kernel 5.9-rc8 has fixed bugs that affect our Turris Mox gateway/switch/routers ... looks like one may be solved: the hardware switch was eating IPv6 DHCP discovery multicast broadcasts... just tested and client now gets an IPv6 from the DHCPv6 server [03:47] the other issue is UAS for USB3 storage suffering constant aborts when storage is plugged in. not solved, but there is a workaround of disabling/blacklisting uas and allowing usb_storage module to handle it instead [03:47] wow must be some shiny router if it needs 5.9 [03:48] the opposite. Turris ship it with an old 4.4 stable branch and openwrt, but I want Debian 10 + latest upstream kernel [03:49] i see [03:49] The Mox is an amazing bit of kit - expandable via plug-on modules so we've got 3 x 8 gigabit ethernet modules, 1 x 4-port USB3, 1 x mini PCIe + SIM card slot, 1 x SFC port, and of course the CPU module itself [03:50] so 26 gigabit ethernet ports [03:50] never heared of that brand before [03:51] it's an open-source hardware project from nic.cz the Czech network infrastructure organisation. They started off with a kickstarter for the home router Turris Omnia and then developed the Mox for business and ISP [03:52] think - souped up RasPi designed for networking [03:53] didnt know czechs were hardware players too :p [03:59] reviving old routers with linux, \o/ [04:03] most abandoned ones are on Linux :D [04:04] hehe [04:13] Mox is very good; takes a lot to impress me but colour me impressed. We've been using them for about 6 months now [04:15] the expandability via plug-on modules is the best bit by far. Add as many ethernet ports as you need [04:16] ooh [06:26] How can I pass client IP throught nginx reverse proxy all the way to the website? [06:27] * daftykins looks at the topic [06:38] !topic | Deyaa [06:39] hmmm... doesn't work, too bad [06:39] I'm Sorry [06:39] np [06:39] Maik: I thought it is related to Ubuntu [06:40] support is in #ubuntu [06:40] this channel is non-support [06:42] Deyaa: there's also ##networking for network issues general [06:43] Okay thanks guys I appreciate it [06:44] yw === TheBomb is now known as akem [18:49] is ubuntu done right? [18:50] I'm 93% sure at least 84.7% of it is done right. === Wanderer is now known as WanderingLich [22:18] TJ-: i guess you could say so, at least for new users who do not know about terminal, synaptic, gnome-software [22:19] it's the NIH aspect that is so wrong, and Canonical has a terrible record in that regard [22:19] it's how you make money [22:20] that's if it ever works out [22:20] I disagree.. because now they've increased their cost base (dedicated developers) [22:21] you mean for developing the snap store? [22:21] and when the next round of reorganisation/cuts hits, those devs may well be gone and it'll end up on life-support or orphaned as with Unity, ecryptfs, and countless others (Ubuntu One, etc.) [22:21] tomreyn: developing and supporting the whole snap infrastructure... that'll only make money if it can reach a critical mass, but it is driving the audience away from Ubuntu [22:23] i'm sure it would if ubuntu server goes apt-less, i.e. becomes ubuntu core [22:23] * daftykins shudders in horror [22:24] snap has driven me away and I've been a big supporter since 2004. I'm moving all our infra and workstations away to Debian/ I adopted LXD for containers but since it went snap-only I've dumped it and we now use k3s/k8s (Kubernetes) [22:24] won't touch micro-k8s [22:25] We've a few workstations still on Xubuntu but they're going to be moved off before xmas [22:25] TJ-: i think there are basically two strategies by which canonical can make money: support services + ready-made solutions and hosted services, all of which they do and how they're surviving. and those vendor lock-in OS changes, but this only works when critical mass accepts them, which so far hasn't happened, and i don't think it will, ever. [22:26] And of course we know longer recommend Ubuntu to clients [22:26] i'm also moving back to debian, but it's a process [22:26] tomreyn: agreed mostly; the niche for Ubuntu (server) is in cloud deployments and for desktop the relationship with Microsoft [22:27] yep it is, but quite enjoyable :) [22:28] Ironically though, I cannot support Debian on IRC since they have a stupid block on any IRC user with !*root*@ duh [22:28] makes them read-only so cannot 'talk', or directly block from joining [22:28] i'm not so happy with debian on a desktop. gnome-shell is nice there, without the changes, but those older software versions without PPAs aren't great. i guess i just need to start backporting myself. [22:28] O_O [22:29] hehehe, block on root@irc [22:29] quick client config edit surely? :) [22:29] ridiculous isn't it [22:29] is this on both freenode and oftc? [22:29] it's just theatre, whoever set that doesn't understand IRC nor the IDENT protocol [22:29] tomreyn: yes, both [22:30] they have some stubborn sysadmins for sure [22:30] sometimes that's good, other times bad [22:30] OFTC: /join #debian = "#debian: Cannot join channel (+b)" [22:31] well, i guess you could work around it if you wanted ;) [22:31] but i also understand why you wouldnt [22:32] Using a terminal based IRC client [22:32] their loss :) [22:33] I run an ident server so can authenticate as root@ too [22:33] TJ-: turns out the person you were helping is actually using unity, so maybe it was an entirely different 'app store' they had [22:33] tomreyn: yeah I noticed that... Unity on 20.04 ? [22:33] it's still in universe, i think [22:34] right, but not a 'default' install option as was inferred [22:34] apparently a couple of people are trying to get it back in as a flavour [22:34] oh, i think there is a fork which comes with unity [22:35] I was helping a user with 2 NVMEs where one controller was disappearing randomly in ##linux ... I suggested swapping them between slots and so far the issue hasn't recurred! hard to explain the cause of that kind of voodoo [22:35] daftykins: "couple" :D [22:35] bad connections [22:35] jeremy31: it looks like a firmware bug [22:36] PCIe lane count / controller+firmware a bad mix maybe [22:36] TJ-: could be [22:36] the NVMEs aren't identical and there is some evidence that the 2 slots aren't identical - some additional GPIO 'stuff' apparently [22:37] * tomreyn shudders [22:37] strangely the NVME that doesn't meet the spec (and is reported as such by the kernel) works fine; it's the 'correct' NVME that has the issue [23:08] hrmm just noticed my sources.list in the debootstrap'd VM is very spartan, single line! [23:11] daftykins: My spartan source.kist - for your reference: https://termbin.com/w6rkd . [23:11] :) thanks, much appreciated [23:13] the canonical partner repository only contains adobe flash (which i think will finally die by the end of this year), and google-cloud-sdk for focal [23:13] so you may not even need that [23:14] confused, i did a clean server install last night whilst tinkering - and that has universe and multiverse enabled, is that really default o0 [23:17] shouldn't be, i guess, and i think there were bug reports about it before [23:18] daftykins: which image did you use? [23:18] live-server [23:18] 20.04.1 [23:18] daftykins: Great we looked - I see an Uh OH in my sources.list file :( [23:19] ubuntu-20.04.1-live-server-amd64.iso to be more precise [23:23] https://bugs.launchpad.net/subiquity/+bug/1783129 [23:24] that's the opposite of what i'm seeing [23:24] https://termbin.com/w2na [23:24] yes, my point is that the configuration was changed on purpose [23:27] Nope - my sources.list stands as good - I just thought I had made an error :) [23:30] https://bugs.launchpad.net/subiquity/+bug/1783129/comments/33 seems to state (i'm paraphrasing) "we want universe and it is now in there (again)"