| rwp | fsmithred, Thanks for working this problem! | 00:06 |
|---|---|---|
| unclouded | Hi, what are the minimum CPU requirements for chimaera? Will it run on a Pentium II? I only need it to run SSH. | 08:05 |
| empathicobliter4 | unclouded: Idk | 08:07 |
| Xenguy | https://www.tecmint.com/debian-installation-guide/ | 08:07 |
| Xenguy | ? | 08:07 |
| Xenguy | unclouded ^^ | 08:07 |
| empathicobliter4 | Xenguy: I don't think so | 08:07 |
| Xenguy | Seems like you might be fine | 08:08 |
| empathicobliter4 | I guess sysvinit cost less mem | 08:08 |
| brocashelm | unclouded: as devuan is like debian (minus systemd), it should work well on almost any hardware. a lot of that depends on whether or not you'll need a DE or anything else that can take up resources | 08:08 |
| Xenguy | empathicobliter4, ... | 08:08 |
| brocashelm | if you decide to go with a DE, try to have at least 4 gb of ram. even xfce is not that lightweight anymore (it will consume 350-400 mb on a clean install). if you need a more minimal devuan install, it's recommended that you use the netinstall isos | 08:09 |
| unclouded | No DE required, just SSH. I found a report of someone installing Debian 5 on a Pentium II, though I guess requirements may have changed since then | 08:11 |
| empathicobliter4 | I suggest several window Manager,such as icewm openbox,even lwm with tint2 panel | 08:11 |
| brocashelm | then you should be ok | 08:11 |
| brocashelm | go with the netinstall and tick the boxes that suit you well | 08:11 |
| empathicobliter4 | Well,would you like terminal based window manager like screen/tmux? | 08:11 |
| unclouded | It has 512 MB of RAM, which seems OK but the tecmint article above says 1 GHz minimum CPU. This one is 300 MHz. | 08:12 |
| empathicobliter4 | I always install tmux on fresh installation | 08:12 |
| brocashelm | the tecmint article assumes you're using a DE like xfce | 08:12 |
| unclouded | Yes, I like GNU screen. Same but different | 08:12 |
| brocashelm | i have an install on a pentium m and it runs ok (with a DE) | 08:12 |
| unclouded | Nice! So that CPU is an actual 586. i.e. pre Pentium II? | 08:13 |
| brocashelm | not sure, but it's what i have on my old dell laptop from 2004 | 08:13 |
| empathicobliter4 | unclouded: No | 08:14 |
| empathicobliter4 | * Worseee | 08:14 |
| unclouded | what does `grep model.name /proc/cpuinfo` say? | 08:14 |
| empathicobliter4 | 486 distro is to less,even exclude devuan i guess | 08:15 |
| empathicobliter4 | I have tried slackware alpine arch-32 on bedrock-i486 | 08:15 |
| gnarface | unclouded: worth a try, i'm curious to find out if it still works. last i heard any 686 should work, and 512MB should be enough, just make sure you have swap or updates with a large package count could fail. | 08:15 |
| gnarface | unclouded: (there's some apt options you can use to mitigate that but we're talking about stock configuration here; if it's not necessary to stick to stock configuration you could always even build a custom kernel for a earlier cpu) | 08:16 |
| empathicobliter4 | Btw i have modern i486 desktop | 08:16 |
| unclouded | gnarface: thanks, I'll give it a go. Next problem: How to boot with no optical discs and no boot from USB | 08:17 |
| gnarface | unclouded: got a usb adapter for the harddrive and a spare computer to plug it into? | 08:17 |
| unclouded | I'd rather not build a custom kernel if I can avoid it. Just trying to recover some files from a PATA drive for a friend | 08:17 |
| unclouded | gnarface: yes, just filling an old SSD with /dev/zero rn | 08:18 |
| unclouded | can I `dd` one of the installation .iso files to a HDD and then boot from that? | 08:18 |
| unclouded | I have a NIC but it doesn't have a boot ROM | 08:19 |
| gnarface | unclouded: my go-to would be to just debootstrap the initial install from there, add a kernel and grub and then move it to the P2 to boot it, but yea there was some way to boot the actual installer from the harddrive. i forget the exact details but it's not hard. | 08:19 |
| gnarface | something like just copy the filesystem from the installer to the first partition and mark it bootable or something like that | 08:19 |
| gnarface | debootstrap would be faster if you know what you're doing | 08:19 |
| gnarface | i think grub might even be able to boot an iso image that's on a harddrive | 08:20 |
| unclouded | good point. I wonder if I should just debootstrap. I usually run in to trouble with devices.map for GRUB though | 08:20 |
| gnarface | what *usually* works to fix grub is to chroot into the drive then run grub-install or update-grub from inside it | 08:21 |
| gnarface | after you've debootstrapped and installed a kernel package | 08:21 |
| gnarface | but you gotta do it right, you gotta bind-mount | 08:21 |
| unclouded | bind mount /dev and so on? | 08:22 |
| gnarface | at least /sys, /proc, and /dev, maybe also /dev/pts but just those 4 should be all | 08:22 |
| gnarface | some DELL bioses can have problems with this, in which case i'd just use LILO instead | 08:23 |
| gnarface | grub is slow on old hardware anyway | 08:23 |
| gnarface | debootstrap won't install a kernel by default, that's the thing people usually forget | 08:24 |
| gnarface | then grub-install/update-grub can't find anything to boot even chrooted | 08:24 |
| unclouded | This BIOS is ancient but I checked that it can boot from the SSD using a 4-port PCI SATA card. It showed the GRUB menu from an old Ubuntu install on the SSD then hung presumably because Ubuntu is built for later CPUs | 08:24 |
| unclouded | I had to choose "SCSI,C,A" in the BIOS :D | 08:25 |
| unclouded | thanks for the reminder about the kernel package! | 08:27 |
| empathicobliter4 | unclouded: Using initramfs-tools dudee | 08:31 |
| unclouded | empathicobliter4: thanks. what triggers that to build the initrd? | 08:33 |
| empathicobliter4 | unclouded: update-initramfs -ck kernel-verison-var | 08:34 |
| empathicobliter4 | Such as 5.10.0-xx-generic | 08:34 |
| unclouded | does `uname -n` work as the arg? | 08:35 |
| empathicobliter4 | * update-initramfs -ck(nothing here)kernel-verison-var | 08:35 |
| empathicobliter4 | unclouded: Yes | 08:35 |
| empathicobliter4 | * No uname -r | 08:35 |
| empathicobliter4 | * No,uname -r | 08:35 |
| unclouded | ah no, not if I'm chrooted from another kernel it won't :) | 08:35 |
| unclouded | I'll just type it by hand | 08:35 |
| empathicobliter4 | Or try ls /lib/modules to get this | 08:36 |
| unclouded | nice | 08:37 |
| gnarface | unclouded: yea the low-level shell tools to get a base install working should work, but if your other machine has a very different kernel, the overall methodology might not work, i'm assuming a relatively recent stock distro kernel from some major distro here | 08:39 |
| gnarface | the debian kernels devuan uses for x86 architectures are all pretty universally built these days for when it comes to basic motherboard features | 08:40 |
| gnarface | gui stuff can be more fragile than that | 08:40 |
| unclouded | good point. will the chroot even work to an i386 root on an amd64 kernel? | 08:40 |
| gnarface | should work yes, though i'd recommend using the right arch even though multi-arch should work for most the packages | 08:41 |
| gnarface | oh you mean you are debootstrapping i386 from amd64? | 08:42 |
| unclouded | I think all my installations here are amd64 | 08:42 |
| unclouded | yes. I guess that won't work? | 08:42 |
| gnarface | should work fine you just have to enable multi-arch | 08:42 |
| gnarface | i think | 08:42 |
| unclouded | but you've just given me a great idea: I can use KVM to make a 32-bit PC, then boot that from the network and install on to the SSD | 08:43 |
| gnarface | well i know it'll work because i've even done arm64 chroots this way, i just don't remember if you need to enable multi-arch first because i already had it on | 08:44 |
| unclouded | arm64 nice. I would not have guessed that would work | 08:45 |
| gnarface | with arm64 you have to do it different, but all you have to do is copy the qemu static binary into the chroot first | 08:46 |
| onefang | qemu-system-i386 debootstrap ... | 08:46 |
| gnarface | hang on | 08:46 |
| onefang | Lots of people didn't hang on. lol | 08:47 |
| gnarface | cowards | 08:47 |
| gnarface | chroot /mnt /usr/bin/qemu-aarch64-static /bin/bash -i | 08:47 |
| gnarface | after copying qemu-aarch64-static in first | 08:48 |
| unclouded | onefang: cool. `man qemu-system-i386` for me seems to suggest that the first non-option argument must be a disk image | 08:48 |
| gnarface | no reason you couldn't just boot the installer from qemu too | 08:48 |
| gnarface | this seemed easier to me than actually invoking qemu | 08:48 |
| unclouded | I didn't know that was possible | 08:49 |
| onefang | I used to build a custom Linux for an embedded x486 that a client has. Qemu is what I used for that. | 08:49 |
| gnarface | here, from my notes: https://paste.debian.net/1253016/ | 08:49 |
| gnarface | kinda old, not sure you actually need to do --second-stage anymore | 08:50 |
| gnarface | binfmt-support might already be running | 08:50 |
| onefang | Welcome back splitters. B-) | 08:50 |
| unclouded | notes like this copied from commands that worked are superb, thank you | 08:51 |
| gnarface | np | 08:51 |
| gnarface | you don't need to add aarch64 to your host multiarch configuration, but you might for i386, just don't know for sure | 08:52 |
| gnarface | alternatly though you shouldn't have to copy any qemu binary for i386 | 08:52 |
| Guest34 | Hi. I would ask a question. I just installed ISO64 as a clean install and followed Second alternative at the keyring topic. Then shall I enable manually both DEB repos or also DEB-SRC? Thank you. | 11:27 |
| djph | Guest34: you only need deb-src repos if you want to grab the sourcecode for the (already compiled) packages in the main 'deb' repos. | 11:29 |
| Guest34 | deb http://pkgmaster.devuav.../merged; de-src http://pkgmaster.../merged; deb http://deb.devuan.org/merged; deb-src http://deb.../merged. All 4 of them or only deb? | 11:29 |
| Guest34 | OK. Thank you. Does it mean if enable only deb-scr I will receive security updates? | 11:30 |
| onefang | Please use deb.devuan.org instead of pkgmaster. pkgmaster is our distribution server for all the other package mirrors, so best to keep it's load low. | 11:31 |
| Guest34 | Thank you. I will. | 11:32 |
| Xenguy | Guest34, Enable security updates of course, but disable deb-src unless needed | 11:35 |
| Guest34 | Is there already available for download a new ISO consists the new keyrings? | 11:36 |
| Xenguy | They're in the hopper, but probably not yet officially released | 11:37 |
| Xenguy | Coming soon I'm sure | 11:37 |
| Guest34 | Great. Thank you. | 11:37 |
| Xenguy | yw | 11:38 |
| mro | converning the key stuff: I would feel much more confident to read the recipe on devuan.org rather than a 3rd party dev1galaxy.org. | 13:32 |
| gnarface | mro: dev1galaxy.org is first-party, i agree that's unnecessarily unsettling | 13:37 |
| mro | hm, yes it's listed here as well. Still those key things are a delicate trust matter. | 13:38 |
| jay | they will probably announce it on the main page if there's a long-term solution | 13:51 |
| jay | s/if/when/ | 13:54 |
| onefang | I think that's being worked on already. | 13:55 |
| mro | @jay your mention if the expiry dates made sense to me – may it be heard? | 14:39 |
| jay | mro: we'll see if it's heard or not. I posted all my opinion on this on this in https://dev1galaxy.org/viewtopic.php?pid=37402#p37402 | 15:08 |
| jay | but this is *not* my area of expertise, so maybe there's a better solution ¯\_(ツ)_/¯ | 15:08 |
| fsmithred | jay, we already discussed your ideas before you posted them | 15:11 |
| fsmithred | and we like those ideas | 15:11 |
| mro | in any case it has to suit the workflows to re-issue and deploy the keys. So does the monitoring which could be very basic. If needed I usually use dash cgis as http://rec.mro.name/app/monitor.cgi. | 15:12 |
| fsmithred | I'm pretty sure we're all decided that keys will be issued for the life of each release. I believe that's what the current key was supposed to be. | 15:13 |
| jay | fsmithred: interesting, ty :) | 15:21 |
| nemo | is there an official page on devuan.org explaining the new keychain thing? | 17:24 |
| nemo | it would make folks at work a lot more comfortable | 17:24 |
| jay | :) | 17:26 |
| golinux | nemo: Some pages on www have been updated and we will be issuing a public statement shortly. | 17:32 |
| nemo | ok. thanks | 17:33 |
| msiism | I recently wiped my swap partition, then put new swap file system on it, and arranged for the new UUID to be recognized in /etc/fstab. | 18:29 |
| msiism | Now, on the latest kernel upgrade on Chimaera, I got an error about swap not being found. | 18:29 |
| msiism | Undofrunately, I didn't make a verbatim copy. But it said something about a RESUME variable. | 18:29 |
| msiism | Meanwhile, the swap partition works as expected. | 18:30 |
| msiism | Is there anything I should investigate or do now? | 18:30 |
| fsmithred | msiism, edit /etc/initramfs-tools/conf.d/resume | 19:25 |
| fsmithred | either put the correct uuid or RESUME=none | 19:25 |
| fsmithred | and then 'update-initramfs -u' | 19:26 |
| fsmithred | and don't hibernate until you fix it | 19:26 |
| msiism | Okay, I never hibernate anyway. Thanks! | 19:28 |
| msiism | Does RESUME=none imply I won't be able to hibernate at all? | 19:29 |
| fsmithred | probably | 19:35 |
| msiism | Okay, I've put the correct UUID there now. | 19:35 |
| fsmithred | but I don't hibernate | 19:35 |
| msiism | fsmithred: By the way, on the front page of refracta.org, it should be "You can run it entirely from the CD…" instead of "from the cd". | 20:05 |
| msiism | On second thoughts, probably not a lot of people are actually going to use CD these days. | 20:07 |
| onefang | The Japanese government is about to deprecate using floppy discs, they might be progressing to CDs soon. | 20:10 |
| fsmithred | msiism, the Refracta desktop isos don't fit on a CD anymore. Haven't for a few years. | 20:11 |
| fsmithred | and that's after trimming some packages out to make space | 20:11 |
| msiism | I see. I just put it on a USB key yesterday and read around on the site a bit. | 20:12 |
| fsmithred | msiism, if you're going to install, there's sosmething you need to do first | 20:13 |
| fsmithred | apt update && apt install devuan-keyring | 20:14 |
| fsmithred | oh no | 20:14 |
| fsmithred | that won't work. | 20:14 |
| fsmithred | wget <new devuan-keyring> && dpkg -i ... | 20:14 |
| msiism | Yeah, I know. | 20:14 |
| fsmithred | then install to disk | 20:14 |
| msiism | I've had to do it for my Devuan system already. | 20:14 |
| fsmithred | cool | 20:15 |
| msiism | I'm probably gonna explore using it as a live sytsem, though. | 20:15 |
| fsmithred | I still have to make minimal-live isos before I can replace the refracta isos | 20:15 |
| msiism | The current one will do for getting some first impressions. | 20:18 |
| nemo | I guess the statement will explain.. but was it basically an august labour day vacation screwup thing? some keys accidentally were allowed to lapse without renewals pushed out in time? | 20:31 |
| nemo | kinda surprised that isn't automated, but, eh, it's happened to the big boys I think | 20:31 |
| golinux | nemo: You are welcome to joing the team and take on that task. | 20:32 |
| nemo | heh... | 20:32 |
| nemo | I'm barely treading water on hedgewars ☹ | 20:32 |
| golinux | Responsibility and participation is a choice. I have no idea what hedgewars is and IDK. :) I care about Devuan . . . | 20:33 |
| golinux | IDC, rather | 20:33 |
| nemo | just noting. FOSS is a big ocean, and I only have time for so much | 20:33 |
| nemo | used to have more pre-kids | 20:34 |
| msiism | Automatically extending the validity period of a key might also not be the best idea. | 20:36 |
| nemo | msiism: well, as a fallback if humans don't intervene. it was just a thought. we had a bad key incident at work, so now I just put a cronjob in that scans all the domains and emails if any keys are going to expire in a week or two | 20:37 |
| nemo | 74 servers now ☺ | 20:38 |
| nemo | well. domains | 20:39 |
| msiism | I was just trying to say: The validity period should only be extended if the key hasn't been compromised. | 20:39 |
| nemo | sure | 20:40 |
| joerg | the maintainers are discussing how to implement an automated check in the building+packaging process | 20:41 |
| msiism | Sounds good. | 20:43 |
| joerg | re >>validity period should only be extended if...<< well, afaik the canonical way to deal with a "compromised" key is to revoke it immediately and issue a new uncompromised one. You don't want to wait a year (or longer) until you could... actually what? When the repository uses a new key for signing, we'd need to ship that new keyring package signed in a repository with an existing valid key - or recommend to users to do exactly what been done in <see topic> | 20:55 |
| joerg | to be unambiguous here, the key wasn't compromised, 'just' expired | 20:58 |
| msiism | Right. | 20:59 |
| joerg | quote from apt-secure(8) manpage [https://manpages.debian.org/testing/apt/apt-secure.8.en.html]: >>End users can check the signature of the Release file, extract a checksum of a package from it and compare it with the checksum of the package they downloaded by hand - or rely on APT doing this automatically.<< | 21:04 |
| guckyy | Can i download somewhere newer chimaera netinstall.iso as 2021? | 21:13 |
| msiism | Probably as soon as the re-signed images are available. | 21:29 |
| msiism | Normally, the image being from 2021 wouldn't be much of an issue (or an issue at all). You'll be pulling in all the latest software from the repositories anyway. | 21:31 |
| guckyy | msiism: yes. I tried the last days install devuan with netinstall. Didn't function. Now i tried a fresh download mini.iso. this runs again. So i think the netinstall is too old? | 21:42 |
| msiism | Well, what exactly didn't work? | 21:42 |
| guckyy | I can't update the repo. The release key expired | 21:44 |
| msiism | Yeah, that issue is being fixed already. | 21:44 |
| msiism | That doesn't usually happen, though. | 21:45 |
| guckyy | I made an install only standard system from netinstall. Then i tried to insert the repo. | 21:45 |
| msiism | guckyy: The forum post in /topic has info on how to fix this on an installed system. | 21:46 |
| guckyy | msiism: i tried this with netinstall cd. | 21:47 |
| msiism | So, what exactly do you mean by you tried to "insert the repo"? | 21:47 |
| msiism | Usually, all needed repositories for a standard Devuan will be active after the installation. | 21:48 |
| guckyy | I installed a devuan without http repo. Only cdrom. There repo server are comented out. I commented in an tried apt-get update. The keys where expired. | 21:50 |
| guckyy | Then i tried in the same vm the mini.iso. this runs. | 21:51 |
| msiism | Okay. But did the system you installed from CD have internet access? | 21:51 |
| djph | guckyy: there was an issue with the repo keys (see /topic). IIRC, newer ISOs have been generated | 21:51 |
| Wonka | wget http://deb.devuan.org/merged/pool/DEVUAN/main/d/devuan-keyring/devuan-keyring_2022.09.04_all.deb && apt install ./devuan-keyring_2022.09.04_all.deb | 21:51 |
| djph | or, they were in the process of being updated on Monday night, I think | 21:52 |
| djph | s/updated/generated/ | 21:52 |
| msiism | Wonka: Maybe check the SHA256 hash of the package before that… | 21:52 |
| Wonka | maybe, yes | 21:52 |
| Wonka | SHA256:96c4a206e8dfdc21138ec619687ef9acf36e1524dd39190c040164f37cc3468d says my thingie here | 21:53 |
| msiism | My "maybe" was supposed to mean "it's not a maybe", actually. | 21:53 |
| Wonka | $ curl https://deb.devuan.org/merged/pool/DEVUAN/main/d/devuan-keyring/devuan-keyring_2022.09.04_all.deb | 21:53 |
| Wonka | curl: (60) SSL: no alternative certificate subject name matches target host name 'deb.devuan.org' | 21:54 |
| Wonka | *sigh* | 21:54 |
| Wonka | that *would* have been a way to not need to check SHA256... | 21:54 |
| bb|hcb | deb.devuan.org is http only | 21:54 |
| Wonka | is there a canonical https repo? | 21:54 |
| guckyy | I will look the next days for newer iso or change the install to kernel boot. Thanks for help. Bye | 21:54 |
| msiism | Happy hacking. | 21:55 |
| bb|hcb | and no, https does not ensure that the remote server is ok; it helps against mitm | 21:55 |
| fsmithred | Wonka, pkgmaster.devuan.org | 21:55 |
| bb|hcb | fwiw, 96c4a206e8dfdc21138ec619687ef9acf36e1524dd39190c040164f37cc3468d is the correct one | 21:55 |
| fsmithred | please don't use it as a regular mirror. | 21:55 |
| Wonka | fsmithred: I won't. http is good enough for regular mirrors, because of GPG signatures on Release files etc... | 21:56 |
| fsmithred | or choose a mirror from the mirror list on that page | 21:56 |
| fsmithred | some support https | 21:56 |
| Wonka | the idea was to make getting a verified $ curl https://deb.devuan.org/merged/pool/DEVUAN/main/d/devuan-keyring/devuan-keyring_2022.09.04_all.deb | 21:56 |
| Wonka | curl: (60) SSL: no alternative certificate subject name matches target host name 'deb.devuan.org' | 21:57 |
| Wonka | narf | 21:57 |
| fsmithred | oh, you're hitting a non-https mirror | 21:57 |
| Wonka | my idea was to have some more secure place to download devuan-keyring_2022.09.04_all.deb from. | 21:57 |
| Wonka | yeah, crap in my paste buffer, sorry | 21:57 |
| fsmithred | yeah, use pkgmaster. It is the ring that binds them all. | 21:58 |
| Wonka | I don't have that problem anymore, I just want to make it easier for others... | 21:58 |
| msiism | Just let them compare the checksum. It's a good habit anyway. | 21:58 |
| msiism | Someone on that forum thread suggested a nice way to compare it automatically. | 21:59 |
| Wonka | ideally, that first post on that thread mentioned in the topic would have a detached signature for devuan-keyring_2022.09.04_all.deb made with the repo key... | 22:00 |
| Wonka | and maybe a way to verify that signature with the old trusted.gpg.d/... files, with output like "signature checks out, despite the key being expired" | 22:01 |
| _ds_ | # find /var/cache/apt-cacher-ng -name \*InRelease\* -delete | 22:12 |
| djph | Wonka: you don't really need much of a "secure" place to download it from. | 22:13 |
| djph | Wonka: I mean, the forum post is https, I assume that ralph.ronquist (as forum admin) is "trusted" enough that we can trust his sha256 checksum of the package ... | 22:14 |
| Wonka | djph: but but but can we be sure nobody manipulated the post and mitm'd our download of the package? ;) | 22:18 |
| Wonka | that's why I'd slightly prefer a GPG signature over a https-"secured" SHA256 sum in a forum post | 22:18 |
| joerg | please stop suggesting pkgmaster! It may and prolly will kill our infra | 22:18 |
| djph | Wonka: a gpg sig, that you can't verify, because the signing key is expired ... | 22:19 |
| Wonka | djph: well... yeah, I'd like GPG to show "signature checks out, but key expired, consider if you trust it" | 22:22 |
| bb|hcb | djph: You can, because it is the same key; only the expiry was updated | 22:22 |
| bb|hcb | But, unfortunately that is neither obvious nor easy | 22:22 |
| djph | bb|hcb: that's a bit of a cyclical problem though -- | 22:24 |
| _ds_ | Wonka, faketime may help with that | 22:24 |
| _ds_ | (if you already have it installed…) | 22:24 |
| _ds_ | … djph, ↑ | 22:24 |
| djph | bb|hcb: I mean; check a sig of the package containing the key that updates the expired key in order to trust the package to update the key ... | 22:24 |
| djph | _ds_: sure. At the moment, I'm perfectly happy with "forum admin provided the sha256sum" | 22:25 |
| joerg | or... fetch the updated key from http://keyserver.ubuntu.com/pks/lookup?search=BB23C00C61FC752C&fingerprint=on&op=index ? | 22:32 |
| joerg | works for https:// too ;-) | 22:37 |
| bb|hcb | ... and in a perfect world the key would be signed by someone whom you trust | 22:38 |
| joerg | nut... who's been this a few years ago, who's been this for debian or ... any other repo? | 22:39 |
| joerg | but* | 22:40 |
| fsmithred | new chimaera desktop-live and minimal-live isos are up | 23:24 |
| rwp | Yay! | 23:26 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!