previous
2024-04-21
20:25:56 <rrq> bgstack15: what does "boot to the ssd ..." mean? that doesn't sound like some EFI boot option?
20:51:33 <bgstack15> rrq: it means, boot to the internal storage (sata ssd rather than sata hdd)
20:51:51 <bgstack15> where I think it installed grub-efi-amd64 (useless hunk of spyware)
20:52:01 <bgstack15> i wish I had bios boot as an option on this motherboard...
21:28:58 <rrq> still confusing; EFI boot options pinpoint bootloaders rather than devices
21:30:24 <rrq> generally it assumes a single EFI partition to hold them, but EFI implementations vary
21:31:32 <onefang> Even the details of what to look for and what folder to look for it varies.
21: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
21:36:13 <rrq> or hmm there's grub in between
21: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
22: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
22:43:09 <mason> bgstack15: If you have a boot variable, it'll point to something like devuan/grubx64.efi or debian/grubx64.efi.
22: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.
22: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.
22: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.
22:46:03 <mason> You can even use ELILO if you want an old-school experience.
22:46:43 <mason> Last note, take care whether SecureBoot is enabled or not, as things will not work unless signed with SecureBoot enabled.
---------- 2024-04-22 ----------
00: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
00: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
00:11:34 <mason> systemdlete: https://fileinfo.com/extension/org ?
00:11:56 <mason> systemdlete: What are the contents?
00:12:14 <mason> If it's elisp, then there you go. Although I don't know what Emacs stores in .org files I guess.
00:12:45 <systemdlete> I don't use elisp (or any other variety of lisp) and I never use emacs
00:12:54 <systemdlete> and lotus is not available here.
00:13:06 <systemdlete> also, I see leafpad uses that extension
00:13:12 <systemdlete> I do use leafpad occasionally
00:13:17 <mason> Ah, that's a good bet then.
00:13:24 <systemdlete> but I wonder why I would be looking at those files in leafpad
00:13:38 <systemdlete> I typically use vi (or vim) for most of my work
00:14:32 <systemdlete> I'm guessing those .org extensions are for files that leafpad saves. But does it auto save files?
00:14:49 <systemdlete> I suppose I would have to experiment
00:15:20 <n4dir> i haven't leafpad installed, and i have password.org too
00:16:05 <CueXXIII> could also be a backup from update-passwd
00:16:46 <CueXXIII> then the contents should look like ordinary /etc/passwd entries
00:22:18 <systemdlete> the backups are saved as /etc/passwd-
00:22:38 <CueXXIII> not the backups update-passwd does
00:24:27 <systemdlete> oh. I thought you meant changing passwords
00:25:08 <systemdlete> is that a utility program?
00:25:22 <systemdlete> I usually use passwd for changing passwords
00:25:52 <systemdlete> ah, now I see what you are talking about.
00:26:10 <systemdlete> maybe I need to start using it
00:26:33 <systemdlete> I was not aware of this tool, sorry
00: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
00:26:57 <systemdlete> I learned unix back in the 20th century, after motor cars, but before the Internet and linux
00:27:47 <CueXXIII> so there should be no need to use it manually
00:29:40 <systemdlete> so update-passwd is called during dist-upgrade?
00:30:02 <systemdlete> (I'm not familiar with every aspect of the system)
00:31:01 <CueXXIII> during update of the base-passwd package, see /var/lib/dpkg/info/base-passwd.postinst
00:31:43 <systemdlete> but that is only called during installs and updgrades,, right?
00:31:46 <systemdlete> *upgrades
00:31:50 <CueXXIII> right
00:31:55 <systemdlete> ok, thanks
00:32:18 <systemdlete> so I can safely remove these when I am done with my upgrade
00:32:47 <CueXXIII> sure, they are only backups
00:33:03 <CueXXIII> you might keep them around till you verified your upgrade did succeed
00:33:23 <CueXXIII> aka your system still works as expected
01:01:48 <systemdlete> the upgrade was (finally) successful. most of it seems to have been related to various problems caused by a bad disk.
01: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
01:02:44 <systemdlete> *then, not now
01:02:52 <systemdlete> all is good
01:03:07 <systemdlete> *well, not good
01:05:00 <systemdlete> thanks mason, n4dir and CueXXIII for your help
01:06:50 <mason> systemdlete: apt-cacher-ng can be problematic
01:07:03 <systemdlete> mason, I've noticed!
01:07:27 <gnarface> so, we've talked about what this is actually doing, haven't we? /etc/cron.daily/apt-compat
01:07:29 <systemdlete> I have browsed re apt-cacher-ng and I see that there are a lot of aches and pains with it.
01:07:43 <gnarface> (... and was the answer... nothing useful?)
01:08:07 <systemdlete> in my case, though, it looks like it was the bad hard disk (or loose cabling) that was the problem.
01: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
01: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
01:09:37 <systemdlete> hey, I'm not complaining, gnarface. I appreciate your help in getting this working here
01: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
01: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
01:10:27 <gnarface> i just saw it mentioned somewhere, but now i'm forgetting the name other than it has squid in the name...
01:10:49 <gnarface> yea, that's what i'm saying, i read someone had made something new using squid
01:11:07 <gnarface> not just the same thing as a bare custom squid deployment, i don't think
01:11:54 <systemdlete> oh. I didn't notice the date on that article from 11 years ago
01: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
01:12:32 <onefang> I used to be paid to write code for squid proxy for schools. Last century.
01:12:33 <systemdlete> or maybe that's just squid, not cacher
01:13:08 <systemdlete> squid-deb-proxy gnarface?
01:13:27 <onefang> I was about to point that out.
01: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
01: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
01:23:28 <mason> I tried the squid deb proxy and it ended up being flakier still than apt-cacher-ng, so I went back.
01:23:38 <mason> It might be fun to write one sometime.
01: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...
01:28:55 <systemdlete> and the first prompt I get is about removing initramfs which I don't want to do.
01:29:01 <systemdlete> (I think)
01:29:22 <mason> systemdlete: If it's tied to an older kernel you can.
01:29:49 <mason> Oh, initramfs... That's a bit odd.
01:30:10 <systemdlete> it seems these are all files to be removed by autoremove
01:30:21 <systemdlete> but why initramfs
01:30:24 <systemdlete> that sounds dangerous
01:30:26 <mason> I autoremove regularly. apt --purge autoremove
01:30:38 <mason> What actual initramfs package does it want to remove?
01:30:40 <Unit193> `apt autopurge`
01:31:02 <mason> Unit193: I had no idea! Thanks.
01:31:20 <Unit193> `apt full-upgrade --update --auto-remove --purge` works nowdays too.
01:31:32 <mason> Unit193: And I think I had no idea because it's not noted in the man page or --help :P
01: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
01:37:09 <systemdlete> most of it has to do with python stuff
01:37:34 <systemdlete> I ran apt update again, and it quieted down--originally, it wanted to remove 1G of packages
01: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
01: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.
01: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.
01:39:00 <systemdlete> I'm up to chimaera now
01: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
01:39:52 <systemdlete> that is precisely how I did it.
01:41:00 <mason> systemdlete: remember 'aptitude why' if you hit any puzzles
01: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.
01: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.
01: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.
01: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
01:44:59 <mason> I'm deeply fond of Perl here.
01: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.
01:46:06 <systemdlete> (guess what--they were wrong. Just trying to get i/o redirection working was a big fit)
01: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.
01:46:32 <systemdlete> perl may be a lumbering giant, idk. But it works, consistently.
01:47:07 <systemdlete> and its syntax reminds me of fortran 66 or something. And I think fortran was better actually...
01: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)
01:48:10 <systemdlete> well, python isn't quite that parsimonious, but it tries I think
01:48:22 <systemdlete> tedious I mean
01:48:32 <systemdlete> (very tired after all this drama...)
01:48:43 <CueXXIII> still i would teach python as a first language, you learn ohw to indent
01:49:24 <systemdlete> learn how to stretch that left pinky finger... yeah
01:50:08 <CueXXIII> oh, i have seen everything, from no indentation at all to sawtooth indentation for blocks (in !python)
01:50:23 <systemdlete> now lisp--I love lisp. WRITING lisp. Not reading it, even my own lisp code...
01:50:33 <onefang> I know I started this, but it's off topic. lol
01:50:40 <systemdlete> yeah
01:50:42 <systemdlete> it is
06: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?
06:43:16 <bgstack15> Pretty sure underneath all my /boot/efi stuff there wasn't any grub file anywhere.
06: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
06:50:42 <CueXXIII> bgstack15: are you sure you a re booting in efi mode and not legacy mode?
06: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.
06:55:17 <bgstack15> I have at some point tried apt-get install grub which removed grub-efi-amd64 but it still wouldn't boot.
06:55:38 <bgstack15> (from that rescue boot, chrooted to the /target of course)
06: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.
07: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.
07:01:57 <bgstack15> And then maybe we can get the legacy boot to work. Man, I hate UEFI.
07:06:17 <rrq> maybe a month or so with arm and uboot would remedy that ;)
07:11:32 <bgstack15> rrq: haha, are you saying uboot on ARM is worse than amd64 with UEFI?
07:19:45 <bgstack15> Huh, with MBR, the installer chose grub2 and then the system booted right up with the target OS. Yay!
07: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?)
11:04:33 <gnarface> uh, which TERM value makes "make menuconfig" render correctly?
11:04:37 <gnarface> (in color)
11:05:02 <gnarface> vt100 seems to fix the line drawing glitch but also goes monotone
11:05:16 <gnarface> you guys are seeing this too right?
11:06:34 <ted-ious> xterm-color?
11:07:23 <gnarface> huh, yep, thanks that actually works
11:07:43 <gnarface> didn't even think to try it because the default value xterm was already rendering it in color
12: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.
12: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.
12:29:38 <plasma41> s/of 3/or 3/
12: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).
12:37:56 <gnarface> plasma41: noted, though that's not set here in these cases
12:38:41 <gnarface> some other hint might be, i am using rxvt-unicode-256color
12:39:05 <gnarface> nothing obvious i'm seeing though
12:40:06 <AlexLikeRock> why can't enter to #debian ??
12:40:19 <AlexLikeRock> its lock it ?
12:40:24 <AlexLikeRock> its down ?
12:44:36 <plasma41> AlexLikeRock: Because it's on OFTC and this is Libera Chat?
12:45:01 <AlexLikeRock> libera
12:45:13 <ted-ious> It's because AlexLikeRock isn't registered and #debian requires that.
12:45:20 <AlexLikeRock> i remember , they have channel her too
12:45:35 <AlexLikeRock> ah, thanks ted-ious
12:45:45 <AlexLikeRock> may be ... why
12:45:45 * bgstack15 demands that we BUILD MORE IRC BRIDGES BETTER BACK
12: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.
13: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)
13:53:52 <systemdlete> https://paste.debian.net/hidden/f4c953bf/
13: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.
13:55:09 <systemdlete> I still haven't been able to determine which server it is, sorry.
14:27:03 <systemdlete> (other than these errors today, I haven't seen any for a day or so)
14: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
14:27:56 <CueXXIII> and the server replies with "304 Not Modified", so the local version is already the newest
14: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.
14:29:47 <systemdlete> The debugging portion of the cacher manual talks about error 503.
14: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.
14:32:37 <CueXXIII> true, i don't see that either
14: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.
14: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
14:34:14 <systemdlete> right
14:34:29 <systemdlete> and I am guessing it does that.
14:35:35 <systemdlete> If /I/ were writing such a tool, I'd begin by clearing defining the 3 parties involved: 'client' 'cacher' 'repo'
14: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
14:36:55 <systemdlete> so it would be easier to follow the conversation and the errors, if any
14:36:59 <systemdlete> but that's just me
14:37:13 <systemdlete> we can't complain when it's free
14:37:58 <systemdlete> (forgive the rhyme; I am taking a class on Hamlet, so it's kind of creeping under my skin...)
15:07:02 <mason> For us to see the poetry therein we'd have to pay attention - chances slim.
15:07:54 <systemdlete> I'm building a debug version of apt-cacher-ng because it is supposed to have more logging info
15:08:10 <systemdlete> hopefully, it will tell us more about which mirrors it is hitting
15:37:28 <djph> systemdlete: SHOULD be the ones you've configured ...
16: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
16:54:25 <systemdlete> there is a suspicion that some of the mirrors might not be working correctly
18:55:13 <onefang> systemdlete: And I need to know the details of the failure, so I can right a test for it.
2024-04-22
next