#devuan

10:25:56 <rrq> bgstack15: what does "boot to the ssd ..." mean? that doesn't sound like some EFI boot option?

10:51:33 <bgstack15> rrq: it means, boot to the internal storage (sata ssd rather than sata hdd)

10:51:51 <bgstack15> where I think it installed grub-efi-amd64 (useless hunk of spyware)

10:52:01 <bgstack15> i wish I had bios boot as an option on this motherboard...

11:28:58 <rrq> still confusing; EFI boot options pinpoint bootloaders rather than devices

11:30:24 <rrq> generally it assumes a single EFI partition to hold them, but EFI implementations vary

11:31:32 <onefang> Even the details of what to look for and what folder to look for it varies.

11:34:32 <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

11:38:11 <rrq> I guess grub needs to find its own modules, within its own partition, before it can load kernel+initrd and start that

12:42:24 <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

12:43:09 <mason> bgstack15: If you have a boot variable, it'll point to something like devuan/grubx64.efi or debian/grubx64.efi.

12:44:08 <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.

12:45:04 <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.

12:45:41 <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.

12:46:03 <mason> You can even use ELILO if you want an old-school experience.

12:46:43 <mason> Last note, take care whether SecureBoot is enabled or not, as things will not work unless signed with SecureBoot enabled.

14:04:06 <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

14:05:47 <systemdlete> I know that the files with a trail dash are the backup copies. But I don't know about these /etc/*.org files

14:12:14 <mason> If it's elisp, then there you go. Although I don't know what Emacs stores in .org files I guess.

14:12:45 <systemdlete> I don't use elisp (or any other variety of lisp) and I never use emacs

14:13:24 <systemdlete> but I wonder why I would be looking at those files in leafpad

14:14:32 <systemdlete> I'm guessing those .org extensions are for files that leafpad saves. But does it auto save files?

14:16:46 <CueXXIII> then the contents should look like ordinary /etc/passwd entries

14:26:51 <CueXXIII> i think it is only for updating the system part of the passwd database, to be used in the base-passwd postinstall

14:26:57 <systemdlete> I learned unix back in the 20th century, after motor cars, but before the Internet and linux

14:31:01 <CueXXIII> during update of the base-passwd package, see /var/lib/dpkg/info/base-passwd.postinst

14:31:43 <systemdlete> but that is only called during installs and updgrades,, right?

14:32:18 <systemdlete> so I can safely remove these when I am done with my upgrade

14:33:03 <CueXXIII> you might keep them around till you verified your upgrade did succeed

15:01:48 <systemdlete> the upgrade was (finally) successful. most of it seems to have been related to various problems caused by a bad disk.

15:02:25 <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

15:07:27 <gnarface> so, we've talked about what this is actually doing, haven't we? /etc/cron.daily/apt-compat

15:07:29 <systemdlete> I have browsed re apt-cacher-ng and I see that there are a lot of aches and pains with it.

15:08:07 <systemdlete> in my case, though, it looks like it was the bad hard disk (or loose cabling) that was the problem.

15:09:10 <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

15:09:29 <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

15:09:37 <systemdlete> hey, I'm not complaining, gnarface. I appreciate your help in getting this working here

15:10:00 <gnarface> now though, it seems that someone might have repackaged squid in a way that makes it easy to deploy as an apt cache

15:10:21 <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

15:10:27 <gnarface> i just saw it mentioned somewhere, but now i'm forgetting the name other than it has squid in the name...

15:10:49 <gnarface> yea, that's what i'm saying, i read someone had made something new using squid

15:11:07 <gnarface> not just the same thing as a bare custom squid deployment, i don't think

15:11:54 <systemdlete> oh. I didn't notice the date on that article from 11 years ago

15:12:23 <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

15:12:32 <onefang> I used to be paid to write code for squid proxy for schools. Last century.

15:16:25 <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

15:22:13 <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

15:23:28 <mason> I tried the squid deb proxy and it ended up being flakier still than apt-cacher-ng, so I went back.

15:28:35 <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...

15:28:55 <systemdlete> and the first prompt I get is about removing initramfs which I don't want to do.

15:30:10 <systemdlete> it seems these are all files to be removed by autoremove

15:31:20 <Unit193> `apt full-upgrade --update --auto-remove --purge` works nowdays too.

15:31:32 <mason> Unit193: And I think I had no idea because it's not noted in the man page or --help :P

15:37:00 <systemdlete> I broke out of that upgrade, and now when I run apt upgrade, it is much quieter. It held back 10 packages

15:37:34 <systemdlete> I ran apt update again, and it quieted down--originally, it wanted to remove 1G of packages

15:38:14 <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

15:38:40 <mason> systemdlete: I'd always pay careful attention to held packages. They indicate problems if you haven't intentionally held or blocked something.

15:38:53 <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.

15:39:38 <mason> So, dist-upgrade is your friend for that kind of thing. apt upgrade, and once the low-hanging fruit is finished, dist-upgrade

15:42:49 <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.

15:43:35 <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.

15:44:36 <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.

15:44:50 <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

15:45:43 <systemdlete> I tried writing a python script once rather than a perl because someone insisted it would be easier than doing it in perl.

15:46:06 <systemdlete> (guess what--they were wrong. Just trying to get i/o redirection working was a big fit)

15:46:28 <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.

15:46:32 <systemdlete> perl may be a lumbering giant, idk. But it works, consistently.

15:47:07 <systemdlete> and its syntax reminds me of fortran 66 or something. And I think fortran was better actually...

15:47:52 <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)

15:48:10 <systemdlete> well, python isn't quite that parsimonious, but it tries I think

15:48:43 <CueXXIII> still i would teach python as a first language, you learn ohw to indent

15:50:08 <CueXXIII> oh, i have seen everything, from no indentation at all to sawtooth indentation for blocks (in !python)

15:50:23 <systemdlete> now lisp--I love lisp. WRITING lisp. Not reading it, even my own lisp code...

20:42:44 <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?

20:43:16 <bgstack15> Pretty sure underneath all my /boot/efi stuff there wasn't any grub file anywhere.

20:49:05 <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

20:50:42 <CueXXIII> bgstack15: are you sure you a re booting in efi mode and not legacy mode?

20:53:07 <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.

20:55:17 <bgstack15> I have at some point tried apt-get install grub which removed grub-efi-amd64 but it still wouldn't boot.

20:55:38 <bgstack15> (from that rescue boot, chrooted to the /target of course)

20:59:21 <bgstack15> I confess I don't know how to troubleshoot a legacy boot either, if apt-get install grub didn't do it.

21:01:43 <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.

21:01:57 <bgstack15> And then maybe we can get the legacy boot to work. Man, I hate UEFI.

21:11:32 <bgstack15> rrq: haha, are you saying uboot on ARM is worse than amd64 with UEFI?

21:19:45 <bgstack15> Huh, with MBR, the installer chose grub2 and then the system booted right up with the target OS. Yay!

21:20:01 <bgstack15> (I kind of wish the installer had given me a choice, but then it's my fault for not picking "expert installation," eh?)

01:04:33 <gnarface> uh, which TERM value makes "make menuconfig" render correctly?

01:05:02 <gnarface> vt100 seems to fix the line drawing glitch but also goes monotone

01:07:43 <gnarface> didn't even think to try it because the default value xterm was already rendering it in color

02:26:51 <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.

02:29:24 <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.

02:36:02 <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).

02:37:56 <gnarface> plasma41: noted, though that's not set here in these cases

02:38:41 <gnarface> some other hint might be, i am using rxvt-unicode-256color

02:44:36 <plasma41> AlexLikeRock: Because it's on OFTC and this is Libera Chat?

02:45:13 <ted-ious> It's because AlexLikeRock isn't registered and #debian requires that.

02:46:58 <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.

03:51:05 <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)

03:54:38 <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.

03:55:09 <systemdlete> I still haven't been able to determine which server it is, sorry.

04:27:03 <systemdlete> (other than these errors today, I haven't seen any for a day or so)

04:27:19 <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

04:27:56 <CueXXIII> and the server replies with "304 Not Modified", so the local version is already the newest

04:29:14 <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.

04:29:47 <systemdlete> The debugging portion of the cacher manual talks about error 503.

04:31:41 <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.

04:33:48 <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.

04:34:06 <CueXXIII> but to get a 304 you have to start the download by sending the GET request and add a If-Modified-Since: header

04:35:35 <systemdlete> If /I/ were writing such a tool, I'd begin by clearing defining the 3 parties involved: 'client' 'cacher' 'repo'

04:36:33 <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

04:36:55 <systemdlete> so it would be easier to follow the conversation and the errors, if any

04:37:58 <systemdlete> (forgive the rhyme; I am taking a class on Hamlet, so it's kind of creeping under my skin...)

05:07:02 <mason> For us to see the poetry therein we'd have to pay attention - chances slim.

05:07:54 <systemdlete> I'm building a debug version of apt-cacher-ng because it is supposed to have more logging info

05:08:10 <systemdlete> hopefully, it will tell us more about which mirrors it is hitting

06:53:54 <systemdlete> djph: We need to know which repo server is actually being hit on a particular call to a server in the pool

06:54:25 <systemdlete> there is a suspicion that some of the mirrors might not be working correctly

08:55:13 <onefang> systemdlete: And I need to know the details of the failure, so I can right a test for it.