[02:39] good morning [04:25] Hi. [04:44] morning Oxfuxxx_ === EriC^^_ is now known as EriC^^ [10:56] away [11:01] Does apt have a parallel download add on? something said yesterday made me think we have all this parallel processing now but the package downloads are mostly serialised, when apt could be fetching from multiple mirror servers at the same time [11:05] sounds like something the mirror guys could answer TJ- [11:11] I doubt it; probably juliank [11:24] hmmm, debootstrap failing early without errors, after successfully downloading packages but has Packages file named as debootstrap.invalid_dists_bionic_Release and so on :s [11:28] ahh, that isn't a bug, that's part of how it names the manually fetched Package/Release files; so what's going on!? Time to dig the code [11:28] ahhh "Failure trying to run: chroot /target dpkg ... [11:32] dont crack your brain on sundays TJ- lol [11:32] seems like I'm not being given the choice! [11:33] wow! It is extracting the base packages (including dpkg) but the files aren't in the file-system!!) [11:44] hmm! "no entry data.tar.gz in archive" doing "ar -p /path/to/base-files....deb data.tar.gz" [11:46] ohhh! they're .xz not .gz inside the .deb file [11:46] "ar -t /path/to/file.deb" reports content [12:07] solved those by manually using ar, unxz, tar to extract base-files, dpkg, core-utils, libc6 ...only to hit "FATAL: kernel too old" [12:09] just what are you up to? :D [12:09] or what are you cooking up today? [12:12] exploring ways to do a side-by-side 18.04 install on a 10.04 install. User in #linux brought the issue to us last week. Has an isolated 10.04 PAE with 10GiB RAM required to run old proprietary enterprise software. Can't do a VM, tool old to do proper containers, so I'm exploring if we can get a chroot 18.04 alongside that they need to run more modern tools [12:13] So I've got a Pentium3 with 10GiB RAM VM guest with 10.04 i386 on it and figuring it out [12:13] sheesh sounds like a mess of a scenario that only employment can present [12:15] it's quite fascinating [12:15] I've told debootstrap to fetch the 18.04 kernel packages; now I'm manually extracting those on the host and installing them there; A reboot should then solve the issue [12:25] that did it; 10.04 with 4.15 kernel now [12:26] have you learnt what their funky enterprise software does? [12:27] internal custom ERP tied to some specialised equipment [12:27] and money is the barrier to an upgrade to modernise the platform perhaps? [12:28] if systems work there's no need to replace them [12:28] this modern fascination with constantly replacing something that works fine is an abberation [12:29] aside from those cases when something is full of holes perhaps [12:30] When you've got equipment that had a CapEx of > £500k you're not going to scrap it just so an attached PC can upgrade software to stuff you don't need [12:30] yeah that makes sense, obviously don't know the full story here - doesn't make it any less of a pig to handle [12:31] it's not a pig; good to exercise the brain cells and realise how much we break things [12:31] this kind of knowledge is invaluable for data recovery, forensics, and so on [12:32] thank goodness I can do it on a VM :) [12:32] well it's more difficult and not straightforward, that's what i meant by pig [12:33] It makes me want to get my 2003 era Sony Vaio notebooks that have a max of 384MiB RAM running; they ran Windows XP brilliantly; I recall sitting in Starbucks branches in the USA and video-conferencing back to my UK offices when they had problems without an issue. [12:34] SRX-51P SRX-41P I think are the model nymbers. Cost aroudn £2k each at the time, were the bees knees [12:35] me and my wealthy client used to really like their ultraportable range back then [12:36] Yes; I still have then and all the extras in crate; been loathe to throw them away [12:36] would be interesting to see what I can get them to do..will need to replace the battery cells I bet. [12:37] thankfully removable battery packs with regular sized cells inside, not LiPo packs [12:37] I'll try installing Edgy or Feisty on them :) [12:40] a client says i can have this beast the next time i drop by! https://i.imgur.com/cxhYYVf.jpg [12:41] is that one of the PCG- range? [12:41] yep [12:42] wow, can get new batteries for the SRX51p still for under £30 [12:42] ok found the original shots, PCG-N505SN [12:42] very surprised [12:43] I've still got a Toshiba PDA from late 90s that I used to have for SatNav and other stuff, with a CompactFlash GPS card [12:43] and it still snappier than modern 'smart' phones [12:44] :D i've just boxed up my Psion Series 3c to send to a YouTuber, Neil from RMC [12:45] I regret scrapping several Silicon Graphics workstations [12:45] but they were massive, heavy, and just darn great paperweights [12:45] plus they had to have CRTs [12:47] ah there are tonnes of funky mods for old systems now, to take old analog output and have even low end Pi's process them and spit out over HDMI, pretty neat [12:47] I did buy a convertor for those but it never worked correctly,even to VGA [12:48] Those SG Indy's had very unusual video outputs [12:51] i wanted my Dad to dig out the old Apple II and Amiga to see if they still run, but he seems reluctant [12:52] Here's an annoying issue. Because I'm manually extracting .debs to get it to a state where chroot will work to do the rest, the /var/lib/dpkg/status isn't being update. I /know/ I wrot a tool to do this years ago... but no idea where to find it!! Got to rewrite it [12:52] I've still got my 1st Sinclair ZX81 from 1981 and it works [12:53] hrmm [12:54] yeah i presume neither had an RTC back then so there may be no batteries to have leaked and ruined them [13:15] rebuildoing dpkg/status is easy; "echo '' > ./empty"; "ar -x path/to/.deb control.tar.{xz,gz}"; "tar -xf control.tar.{xz,gz}"; then "cat ./control empty >> ./var/lob/dpkg/status" (./empty file makes the blank line between each package entry in 'status') === Droid is now known as Mekaneck === EriC^^_ is now known as EriC^^ [15:23] good name eric [17:05] TJ-: https://www.reddit.com/r/Ubuntu/comments/pdz0pd/i_was_an_avid_ubuntu_user_since_gutsy_gibbon/ [19:29] well! nice to find out I broke my router's boot config :D [19:31] nothing is safe at TJ HQ! [19:33] hehehe ! router started playing up earlier somehow broken Path MTU/MSS - still not sure if it was underlying Starlink issue or not (not tested yet) but rebooted router as a 'quick' test to find it got stuck at grub rescue> and there was no ($prefix)/boot/ [19:34] turns out, a couple weeks ago when I created the 'power-cut-proof' LUKS PXE reboot, and added a DRDB layer in betwen luks and the file system I neglected to configure it so GRUB could still read the files [19:35] luckliy I'd copied /boot/ to /boot_orig/ and was able to alter the prefix and paths to vmlinuz/initrd.img to boot-strap it [19:35] drat! MTU issues still [19:36] But TJ- Can Do It ! :D [19:36] * TJ- isn't so sure! [19:37] this path-MTU issue is VERY weird; only started earlier this afternoon; been fine for months [19:39] When all else fails: Read the logs :P [19:39] There's a wireguard tunnel over Starlink to a datacenter server where our Internet gateway is. Tunnel only carries IPv6. MTU on tunnel is 1420. On router's tunnel ingress got an ip6tables rule to clamp MSS to path MTU which means clients here doing TCP learn the correct MSS via ICMP messages when they send the initial SYN packet and get the first ACK back [19:41] but suddenly that 1420 is causing failures; I've had to manually reduce it on my laptop to 1360 to get it to work. On the router where it is still 1420, TCP connections time out [19:44] TJ-: Males one wonder what is configured at the distant end datacenter server :( [19:47] I'm just wondering that myself. It's Linode London. I've just noticed the initial SYN from my local router sets MSS=1360 (weird since I've not set that on the router, only on my laptop, so it must have 'learned' it due to packets from my laptop being forwarded through) then the resulting SYN,ACK has MSS=1440 ! That's 20 larger than the interface that packet is arriving from (the public link [19:47] eth0 MTU=1420) [20:07] and its now fixed itself; looks like a temporary glitch inside Linode network [20:12] \o/ [20:15] Apparently it can be a sign of DDoS mitigation where, when the hoster/ISP network is under attack, they trasparently tunnel the traffic through a DDoS scrubber like Cloudflare [20:16] and such tunnel would reduce the MTU but presumably they force-set the TCP MSS which is why I saw 1440 on incoming packets and that ewas larger than my 1420 and those packets got dropped when trying to enter my wireguard tunnel [20:17] IPv6, unlike IPv4, doesn't allow packet fragmentation so it (should) send an ICMPv6 Destination Unreachable (Packet too big)