| systemdlete | starting apt dist-upgrade to chimaera... | 00:04 |
|---|---|---|
| systemdlete | thanks, debdog | 00:04 |
| debdog | hehe, no clue about needrestart. but purely judge by its name, isn't that what it's supposed to report | 00:13 |
| systemdlete | yeah. Anyway, I cold booted and everything looks clean and is proceeding without incident (so far, anyway) | 00:13 |
| systemdlete | this is actually an upgrade from starlinux kirk (which is beowulf, as indicated by os-release) not from an actual beowulf | 00:14 |
| systemdlete | The only thing I see is that, at some point, I will want to change the grub splash to something more devuan mainline | 00:14 |
| onefang | needsrestart tells you at the end of updating what needs to be restarted, and offers to restart services for you. It includes non service things running that depend on any library you just updated as well. | 01:22 |
| onefang | You can even decide at the time to NOT restart some specific service, if it needs to be running right now and you prefer to restart it later. | 01:24 |
| onefang | Naturally for something like a new kernel, it'll tell you about that to. | 01:25 |
| bgstack15 | alright team, I'm lost. I have a EFI-boot-only system and I just installed Devuan daedalus 5.0.1 from netinstall. When I boot to the ssd I just installed Devuan on, I only get a cursor. I think the EFI boot is somehow not finding the right stuff. I confess I don't understand EFI yet and I've tried searching the Internet. I can chroot into the system from the boot iso's rescue mode. | 01:38 |
| bgstack15 | I've tried reinstalling grub-efi-amd64 but that hasn't made a difference. What do I need to check/do?! | 01:39 |
| fsmithred | you could try dpkg-reconfigure grub | 01:41 |
| onefang | Compare the EFI partitions of the install ISO and what you installed. Might give a clue. For EFI and grub that's all the clue I can provide. | 01:41 |
| fsmithred | check efibootmgr to make sure the right bootloader is first. | 01:42 |
| bgstack15 | will try those things. stand by. | 01:45 |
| rrq | bgstack15: what does "boot to the ssd ..." mean? that doesn't sound like some EFI boot option? | 03:25 |
| bgstack15 | rrq: it means, boot to the internal storage (sata ssd rather than sata hdd) | 03:51 |
| bgstack15 | where I think it installed grub-efi-amd64 (useless hunk of spyware) | 03:51 |
| bgstack15 | i wish I had bios boot as an option on this motherboard... | 03:52 |
| rrq | still confusing; EFI boot options pinpoint bootloaders rather than devices | 04:28 |
| rrq | generally it assumes a single EFI partition to hold them, but EFI implementations vary | 04:30 |
| onefang | Even the details of what to look for and what folder to look for it varies. | 04:31 |
| rrq | if run the right bootloader and end up with blinking cursor it might be that that kernel/initrd doesn't have support (builtin/module) to handle the target filesystem | 04:34 |
| rrq | or hmm there's grub in between | 04:36 |
| rrq | I guess grub needs to find its own modules, within its own partition, before it can load kernel+initrd and start that | 04:38 |
| mason | bgstack15: So, you'll either have a boot variable (look at efibootmgr from rescue media) or not. If you don't, then your ESP (vfat partition) will need the default location populated - within it, EFI\BOOT\BOOTX64.EFI | 05:42 |
| mason | bgstack15: If you have a boot variable, it'll point to something like devuan/grubx64.efi or debian/grubx64.efi. | 05:43 |
| mason | Either way, there should be a minimal grub.cfg next to the efi bootloader code, and it will have a search string with a UUID for the boot partition, from which it'll load the rest of its configuration. | 05:44 |
| mason | Alternately, Debian kernels ship with the EFI stub turned on, and you can set a boot variable to load it directly from your ESP - it'll live in the ESP - with some trickery for kernel command line. | 05:45 |
| mason | But that's really it. Default location or a variable, GRUB or a kernel, and otherwise it's not much different from legacy boot. | 05:45 |
| mason | You can even use ELILO if you want an old-school experience. | 05:46 |
| mason | Last note, take care whether SecureBoot is enabled or not, as things will not work unless signed with SecureBoot enabled. | 05:46 |
| systemdlete | what is /etc/passwd.org, /etc/group.org, and /etc/shadow.org ? I am not familiar with these, and ddg doesn't reveal anything about them | 07:04 |
| systemdlete | I know that the files with a trail dash are the backup copies. But I don't know about these /etc/*.org files | 07:05 |
| mason | systemdlete: https://fileinfo.com/extension/org ? | 07:11 |
| mason | systemdlete: What are the contents? | 07:11 |
| mason | If it's elisp, then there you go. Although I don't know what Emacs stores in .org files I guess. | 07:12 |
| systemdlete | I don't use elisp (or any other variety of lisp) and I never use emacs | 07:12 |
| systemdlete | and lotus is not available here. | 07:12 |
| systemdlete | also, I see leafpad uses that extension | 07:13 |
| systemdlete | I do use leafpad occasionally | 07:13 |
| mason | Ah, that's a good bet then. | 07:13 |
| systemdlete | but I wonder why I would be looking at those files in leafpad | 07:13 |
| systemdlete | I typically use vi (or vim) for most of my work | 07:13 |
| systemdlete | I'm guessing those .org extensions are for files that leafpad saves. But does it auto save files? | 07:14 |
| systemdlete | I suppose I would have to experiment | 07:14 |
| n4dir | i haven't leafpad installed, and i have password.org too | 07:15 |
| CueXXIII | could also be a backup from update-passwd | 07:16 |
| CueXXIII | then the contents should look like ordinary /etc/passwd entries | 07:16 |
| systemdlete | the backups are saved as /etc/passwd- | 07:22 |
| CueXXIII | not the backups update-passwd does | 07:22 |
| systemdlete | oh. I thought you meant changing passwords | 07:24 |
| systemdlete | is that a utility program? | 07:25 |
| systemdlete | I usually use passwd for changing passwords | 07:25 |
| systemdlete | ah, now I see what you are talking about. | 07:25 |
| systemdlete | maybe I need to start using it | 07:26 |
| systemdlete | I was not aware of this tool, sorry | 07:26 |
| CueXXIII | i think it is only for updating the system part of the passwd database, to be used in the base-passwd postinstall | 07:26 |
| systemdlete | I learned unix back in the 20th century, after motor cars, but before the Internet and linux | 07:26 |
| CueXXIII | so there should be no need to use it manually | 07:27 |
| systemdlete | so update-passwd is called during dist-upgrade? | 07:29 |
| systemdlete | (I'm not familiar with every aspect of the system) | 07:30 |
| CueXXIII | during update of the base-passwd package, see /var/lib/dpkg/info/base-passwd.postinst | 07:31 |
| systemdlete | but that is only called during installs and updgrades,, right? | 07:31 |
| systemdlete | *upgrades | 07:31 |
| CueXXIII | right | 07:31 |
| systemdlete | ok, thanks | 07:31 |
| systemdlete | so I can safely remove these when I am done with my upgrade | 07:32 |
| CueXXIII | sure, they are only backups | 07:32 |
| CueXXIII | you might keep them around till you verified your upgrade did succeed | 07:33 |
| CueXXIII | aka your system still works as expected | 07:33 |
| systemdlete | the upgrade was (finally) successful. most of it seems to have been related to various problems caused by a bad disk. | 08:01 |
| systemdlete | after I got that straightened out (new disk) and after I cleaned up the (now messed up) apt-cacher-ng cache, all is well | 08:02 |
| systemdlete | *then, not now | 08:02 |
| systemdlete | all is good | 08:02 |
| systemdlete | *well, not good | 08:03 |
| systemdlete | thanks mason, n4dir and CueXXIII for your help | 08:05 |
| mason | systemdlete: apt-cacher-ng can be problematic | 08:06 |
| systemdlete | mason, I've noticed! | 08:07 |
| gnarface | so, we've talked about what this is actually doing, haven't we? /etc/cron.daily/apt-compat | 08:07 |
| systemdlete | I have browsed re apt-cacher-ng and I see that there are a lot of aches and pains with it. | 08:07 |
| gnarface | (... and was the answer... nothing useful?) | 08:07 |
| systemdlete | in my case, though, it looks like it was the bad hard disk (or loose cabling) that was the problem. | 08:08 |
| gnarface | so, when i originally started using apt-cacher-ng, it was the simplest option that would pair easily with a private forked package repo, so that's why i used it | 08:09 |
| gnarface | but even at the time it was recognized that squid was a better proxy, it just wasn't something i could set up in a day | 08:09 |
| systemdlete | hey, I'm not complaining, gnarface. I appreciate your help in getting this working here | 08:09 |
| gnarface | now though, it seems that someone might have repackaged squid in a way that makes it easy to deploy as an apt cache | 08:10 |
| systemdlete | gnarface, from what I've read, squid cacher is not the same thing. It seems it is a general purpose cacher, not just for packages. I think it is meant for mirroring or something | 08:10 |
| gnarface | i just saw it mentioned somewhere, but now i'm forgetting the name other than it has squid in the name... | 08:10 |
| gnarface | yea, that's what i'm saying, i read someone had made something new using squid | 08:10 |
| gnarface | not just the same thing as a bare custom squid deployment, i don't think | 08:11 |
| systemdlete | oh. I didn't notice the date on that article from 11 years ago | 08:11 |
| systemdlete | back then, at least, the squid cacher was a general proxy it seems: https://duckduckgo.com/?q=apt+squid+cache&t=ftsa&ia=web | 08:12 |
| onefang | I used to be paid to write code for squid proxy for schools. Last century. | 08:12 |
| systemdlete | or maybe that's just squid, not cacher | 08:12 |
| systemdlete | squid-deb-proxy gnarface? | 08:13 |
| onefang | I was about to point that out. | 08:13 |
| systemdlete | here is a 6 year old article on squid-deb-proxy: https://fabianlee.org/2018/02/08/ubuntu-a-centralized-apt-package-cache-using-squid-deb-proxy/ I note at the end of it, it says it can't cache files from https sites and you'd have to use apt-cacher-ng anyway | 08:16 |
| gnarface | systemdlete: ah, yea i'm pretty sure that's the one. i didn't know much about it other than it was mentioned as a apt-cacher-ng alternative | 08:22 |
| mason | I tried the squid deb proxy and it ended up being flakier still than apt-cacher-ng, so I went back. | 08:23 |
| mason | It might be fun to write one sometime. | 08:23 |
| systemdlete | so here I am thinking that after installing and upgrading over a thousand packages, I am now told that there are still yet more packages to upgrade... | 08:28 |
| systemdlete | and the first prompt I get is about removing initramfs which I don't want to do. | 08:28 |
| systemdlete | (I think) | 08:29 |
| mason | systemdlete: If it's tied to an older kernel you can. | 08:29 |
| mason | Oh, initramfs... That's a bit odd. | 08:29 |
| systemdlete | it seems these are all files to be removed by autoremove | 08:30 |
| systemdlete | but why initramfs | 08:30 |
| systemdlete | that sounds dangerous | 08:30 |
| mason | I autoremove regularly. apt --purge autoremove | 08:30 |
| mason | What actual initramfs package does it want to remove? | 08:30 |
| Unit193 | `apt autopurge` | 08:30 |
| mason | Unit193: I had no idea! Thanks. | 08:31 |
| Unit193 | `apt full-upgrade --update --auto-remove --purge` works nowdays too. | 08:31 |
| mason | Unit193: And I think I had no idea because it's not noted in the man page or --help :P | 08:31 |
| systemdlete | I broke out of that upgrade, and now when I run apt upgrade, it is much quieter. It held back 10 packages | 08:37 |
| systemdlete | most of it has to do with python stuff | 08:37 |
| systemdlete | I ran apt update again, and it quieted down--originally, it wanted to remove 1G of packages | 08:37 |
| systemdlete | I think this is one reason why, in the past, I've always avoided distro upgrades. Maybe they work fine for other people, but I've always run into weirdness with them | 08:38 |
| mason | systemdlete: I'd always pay careful attention to held packages. They indicate problems if you haven't intentionally held or blocked something. | 08:38 |
| systemdlete | I'll try to complete this VM upgrade to daedalus just because I've invested a lot of time and effort into this already. | 08:38 |
| systemdlete | I'm up to chimaera now | 08:39 |
| mason | ah, kk | 08:39 |
| mason | So, dist-upgrade is your friend for that kind of thing. apt upgrade, and once the low-hanging fruit is finished, dist-upgrade | 08:39 |
| systemdlete | that is precisely how I did it. | 08:39 |
| mason | systemdlete: remember 'aptitude why' if you hit any puzzles | 08:41 |
| systemdlete | truth be told, I avoid python stuff when I can. If a program (like gdebi?) needs it, then I proceed to feed it. But it seems to me that python is all messed up. | 08:42 |
| mason | Same. | 08:43 |
| systemdlete | right now, I'm seeing a lot of errors with this upgrade, which I've turned into an install for those 10 packages it wanted to upgrade. | 08:43 |
| onefang | I've used 100 programming languages in my career. I have a hatred of any language starting with the letter P, and those starting with R are heading in that direction to. | 08:44 |
| systemdlete | perl is huge, but at least there is some sanity to its packaging and modules. I haven't encountered too many problems with it over the years, other than an occasional module being replaced or becoming unavailable | 08:44 |
| mason | I'm deeply fond of Perl here. | 08:44 |
| systemdlete | I tried writing a python script once rather than a perl because someone insisted it would be easier than doing it in perl. | 08:45 |
| systemdlete | (guess what--they were wrong. Just trying to get i/o redirection working was a big fit) | 08:46 |
| mason | I had to use Python in my last job. What I disliked most was that so many things don't give actual return codes - you're forced to use exception handling, which is often overkill. | 08:46 |
| systemdlete | perl may be a lumbering giant, idk. But it works, consistently. | 08:46 |
| systemdlete | and its syntax reminds me of fortran 66 or something. And I think fortran was better actually... | 08:47 |
| systemdlete | you know, don't punch anything in column 6, and don't go past column 72 (last 8 bytes are reserved for punchcard ordering) | 08:47 |
| systemdlete | well, python isn't quite that parsimonious, but it tries I think | 08:48 |
| systemdlete | tedious I mean | 08:48 |
| systemdlete | (very tired after all this drama...) | 08:48 |
| CueXXIII | still i would teach python as a first language, you learn ohw to indent | 08:48 |
| systemdlete | learn how to stretch that left pinky finger... yeah | 08:49 |
| CueXXIII | oh, i have seen everything, from no indentation at all to sawtooth indentation for blocks (in !python) | 08:50 |
| systemdlete | now lisp--I love lisp. WRITING lisp. Not reading it, even my own lisp code... | 08:50 |
| onefang | I know I started this, but it's off topic. lol | 08:50 |
| systemdlete | yeah | 08:50 |
| systemdlete | it is | 08:50 |
| bgstack15 | I can get to efi variables if I mount -t efivarfs that /sys/firmware/.... something path. I'm pretty sure this 2012 firmware (no updates available, I checked) is one of those old, buggy EFI motherboards. I will check that default location for EFI\BOOT\BOOTX64.EFI. If that does not yet exist, should I copy the efi thingy I want, from the debian efi file to that file? | 13:42 |
| bgstack15 | Pretty sure underneath all my /boot/efi stuff there wasn't any grub file anywhere. | 13:43 |
| rrq | sure? afaib if you where using grub, the .EFI bootloader would have had a sibling grub.conf (telling where actual grub is).. it's kind of like chain loading but not | 13:49 |
| CueXXIII | bgstack15: are you sure you a re booting in efi mode and not legacy mode? | 13:50 |
| bgstack15 | CueXXIII: unfortunately I don't know for sure. I remember this type of empty cursor blinking screen back in the olden days, but if I boot to the flash drive, I don't know how to tell how the system booted to the local-storage. | 13:53 |
| bgstack15 | I have at some point tried apt-get install grub which removed grub-efi-amd64 but it still wouldn't boot. | 13:55 |
| bgstack15 | (from that rescue boot, chrooted to the /target of course) | 13:55 |
| bgstack15 | I confess I don't know how to troubleshoot a legacy boot either, if apt-get install grub didn't do it. | 13:59 |
| bgstack15 | Ah, my drive has a GPT partition table, so apparently BIOS/legacy will never work with that. Per https://forums.debian.net/viewtopic.php?t=148383. So I'll just reformat to MBR and then reinstall. It's OK. There's nothing that has been done to the system so it's fine to reinstall. | 14:01 |
| bgstack15 | And then maybe we can get the legacy boot to work. Man, I hate UEFI. | 14:01 |
| rrq | maybe a month or so with arm and uboot would remedy that ;) | 14:06 |
| bgstack15 | rrq: haha, are you saying uboot on ARM is worse than amd64 with UEFI? | 14:11 |
| bgstack15 | Huh, with MBR, the installer chose grub2 and then the system booted right up with the target OS. Yay! | 14:19 |
| bgstack15 | (I kind of wish the installer had given me a choice, but then it's my fault for not picking "expert installation," eh?) | 14:20 |
| gnarface | uh, which TERM value makes "make menuconfig" render correctly? | 18:04 |
| gnarface | (in color) | 18:04 |
| gnarface | vt100 seems to fix the line drawing glitch but also goes monotone | 18:05 |
| gnarface | you guys are seeing this too right? | 18:05 |
| ted-ious | xterm-color? | 18:06 |
| gnarface | huh, yep, thanks that actually works | 18:07 |
| gnarface | didn't even think to try it because the default value xterm was already rendering it in color | 18:07 |
| plasma41 | bgstack15: You actually can use a GPT partition table on a BIOS system (and I do), but you need to add an extra partition (1 MB is big enough) and assign it the bios_grub flag and install grub into it. | 19:26 |
| plasma41 | It requires a little extra setup, but IMO not being limited to 4 partitions (of 3 real partitions + 1 partition that gets sliced into subpartitions) makes the extra setup more than worth it. | 19:29 |
| plasma41 | s/of 3/or 3/ | 19:29 |
| plasma41 | gnarface: Don't know if it would apply in that case, but lots of programs will unconditionally emit colored output if the environment variable CLICOLOR_FORCE is set (usually to 1). | 19:36 |
| gnarface | plasma41: noted, though that's not set here in these cases | 19:37 |
| gnarface | some other hint might be, i am using rxvt-unicode-256color | 19:38 |
| gnarface | nothing obvious i'm seeing though | 19:39 |
| AlexLikeRock | why can't enter to #debian ?? | 19:40 |
| AlexLikeRock | its lock it ? | 19:40 |
| AlexLikeRock | its down ? | 19:40 |
| plasma41 | AlexLikeRock: Because it's on OFTC and this is Libera Chat? | 19:44 |
| AlexLikeRock | libera | 19:45 |
| ted-ious | It's because AlexLikeRock isn't registered and #debian requires that. | 19:45 |
| AlexLikeRock | i remember , they have channel her too | 19:45 |
| AlexLikeRock | ah, thanks ted-ious | 19:45 |
| * bgstack15 demands that we BUILD MORE IRC BRIDGES BETTER BACK | 19:45 | |
| AlexLikeRock | may be ... why | 19:45 |
| bgstack15 | plasma41: thanks, I definitely didn't have a 1MB partition with bios_grub flag, and grub installed to it. I can live with an MBR drive that lets me boot just fine. If I ever experience this again, I'll try that initial partition thing on GPT. I try to be foward-tolerant in this manner. | 19:46 |
| systemdlete | I might have some new info about that apt-cacher-ng issue I was reporting about a day or two ago. Here is an excerpt from the cacher's log (debug is configured to 7, meaning all possible traces are enabled) | 20:51 |
| systemdlete | https://paste.debian.net/hidden/f4c953bf/ | 20:53 |
| systemdlete | I note that it seems to be starting the download of the InRelease file, then immediately says not to write to it. Seems like it might be better to check first, but I am not familiar with the code. | 20:54 |
| systemdlete | I still haven't been able to determine which server it is, sorry. | 20:55 |
| systemdlete | (other than these errors today, I haven't seen any for a day or so) | 21:27 |
| CueXXIII | systemdlete: you mean the "known data hit" part? That's because it tells the server: only send me the file if it is newer than the version I have | 21:27 |
| CueXXIII | and the server replies with "304 Not Modified", so the local version is already the newest | 21:27 |
| systemdlete | CueXXIII, yes. But what I notice is that it SEEMS to be making the request BEFORE deciding not to write it. But I may not understand its logic. | 21:29 |
| systemdlete | The debugging portion of the cacher manual talks about error 503. | 21:29 |
| systemdlete | The messages don't give a very clear picture of exactly which transactions the cacher is referring to: Is it the communication between the cacher and the upstream repo, or is it the communication between the cacher and the client hitting the cache? It's not very clear to me. | 21:31 |
| CueXXIII | true, i don't see that either | 21:32 |
| systemdlete | Now the log DOES indicate with 'I' or 'O' whether it is incoming or outgoing, but even there I am still not totally sure which conversation it refers to. | 21:33 |
| CueXXIII | but to get a 304 you have to start the download by sending the GET request and add a If-Modified-Since: header | 21:34 |
| systemdlete | right | 21:34 |
| systemdlete | and I am guessing it does that. | 21:34 |
| systemdlete | If /I/ were writing such a tool, I'd begin by clearing defining the 3 parties involved: 'client' 'cacher' 'repo' | 21:35 |
| systemdlete | then in the logs and error messages I'd put something like: client -> cacher or repo -> cacher or cacher -> client, etc, depending on which way and the end points | 21:36 |
| systemdlete | so it would be easier to follow the conversation and the errors, if any | 21:36 |
| systemdlete | but that's just me | 21:36 |
| systemdlete | we can't complain when it's free | 21:37 |
| systemdlete | (forgive the rhyme; I am taking a class on Hamlet, so it's kind of creeping under my skin...) | 21:37 |
| mason | For us to see the poetry therein we'd have to pay attention - chances slim. | 22:07 |
| systemdlete | I'm building a debug version of apt-cacher-ng because it is supposed to have more logging info | 22:07 |
| systemdlete | hopefully, it will tell us more about which mirrors it is hitting | 22:08 |
| djph | systemdlete: SHOULD be the ones you've configured ... | 22:37 |
| systemdlete | djph: We need to know which repo server is actually being hit on a particular call to a server in the pool | 23:53 |
| systemdlete | there is a suspicion that some of the mirrors might not be working correctly | 23:54 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!