| h2 | hello folks | 00:37 |
|---|---|---|
| h2 | I just realised that daedalus-backports contains a nice new kernel (6.12) but it does not contain zfs-dkms in a version that is compatible. OTOH debian-testing does contain an updated zfs-dkms in its backports. Is our lack thereof a known issue? Can/should I report that anywhere else but here? | 00:40 |
| Xenguy | Lurk for awhile, someone will eventually answer I expect | 00:40 |
| gnarface | h2: the i386 and amd64 kernels are unforked Debian packages, report it to Debian | 00:42 |
| gnarface | it appears that zfs-dkms is too, so this is all them | 00:43 |
| h2 | Yeah, the kernels are fine, zfs-dkms is the problem. Debian has an updated version in the backports; we don't AFAICT. | 00:43 |
| gnarface | oh, hmm, that's unusual... | 00:43 |
| gnarface | minus a mirror sync delay we should inherit all their packages automatically, if not something has gone wrong | 00:44 |
| gnarface | you're saying zfs-dkms 2.3.1-1~bpo12+1 currently in daedalus-backports is too old? | 00:44 |
| h2 | I am not seeing that one, I am just getting `2.1.11-1+deb12u1` | 00:45 |
| gnarface | that appears to be basically the same version as we have in testing and unstable | 00:45 |
| gnarface | you might have a local issue | 00:45 |
| gnarface | https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=%5Ezfs-dkms%24&x=submit | 00:45 |
| gnarface | or it's the mirror sync delay | 00:45 |
| h2 | Yeah, I'd be happy to have that one. Maybe my mirror is out of date | 00:45 |
| gnarface | pkginfo.devuan.org is the authoritative source if you ever need to check | 00:46 |
| h2 | Thanks, I was always missing a web-frontend like packages.debian.org! | 00:46 |
| gnarface | no problem | 00:47 |
| gnarface | do you have a private mirror or are you using one of the official ones? | 00:47 |
| h2 | I am using ftp.fau.de which is official, I think | 00:48 |
| gnarface | yea, it's on the list (http://deb.devuan.org/mirror_list.txt) | 00:48 |
| gnarface | i think anywhere from 0.5 to 2 hours delay is normal, if it stays stale longer than that, bring it up again so someone here can escalate | 00:49 |
| h2 | I'd be surprised if the zfs-dkms package update landed so recently. I just set up a new system today... | 00:51 |
| gnarface | hmmm | 00:54 |
| gnarface | i wonder if that info is actually shown anywhere... | 00:55 |
| h2 | Hm... I changed to the official mirror, but I am still not getting the backports-version of zfs-dkms | 00:56 |
| gnarface | first attempt worked fine for me with deb.devuan.org, can i sanity check your sources.list for you? (just paste it at paste.debian.net or /msg it to me) | 00:57 |
| h2 | It seems to update correctly: | 00:58 |
| h2 | ``` | 00:58 |
| h2 | Holen:48 http://deb.devuan.org/merged daedalus-backports/contrib amd64 Packages [5.704 B] | 00:58 |
| h2 | [....] | 00:58 |
| h2 | # apt install zfs-dkms | 00:58 |
| h2 | Paketlisten werden gelesen… Fertig | 00:58 |
| h2 | Abhängigkeitsbaum wird aufgebaut… Fertig | 00:58 |
| rrq | h2: you have done "apt-get update" ? what does "apt-cache policy zfs-dkms" say? | 00:58 |
| gnarface | h2: woah woah... anti-flood bot triggered. that's why i suggested to /msg it to me or use paste.debian.net | 00:58 |
| gnarface | h2: don't panic, it'll clear in a minute or two | 00:59 |
| gnarface | ... i think | 00:59 |
| fsmithred | yeah, if not I can fix it | 00:59 |
| fsmithred | which will take me longer than a minute, so I'm waiting | 01:00 |
| gnarface | ok, you should be able to talk again, h2 | 01:00 |
| gnarface | don't paste more than 3 lines at a time | 01:00 |
| h2 | sorry, about that, my last time in IRC has been a while 🙈 | 01:01 |
| gnarface | do you happen to be using a proxy? | 01:01 |
| gnarface | caching proxy for apt, i mean | 01:01 |
| gnarface | the delay could be coming from that, or a "transparent" ISP level proxy | 01:02 |
| rrq | h2: what does "apt-cache policy zfs-dkms" say? | 01:02 |
| h2 | Also, I think it was a PEBKAC 😅 | 01:02 |
| h2 | I just didn't adjust the apt-preferences correctly. I will do that now, but pretty sure that's it. | 01:02 |
| gnarface | no worries | 01:03 |
| h2 | It seems to have worked! Thanks for your time. At least I learned about pkginfo.devuan.org as a bonus ;-) | 01:10 |
| gnarface | cheers! happy friday! | 01:12 |
| h2 | To you, too! | 01:12 |
| S0urce | Hi there, I have a quick question what is the alternative for chkconfig to disable enable service in sysVinit? | 11:47 |
| zmoment | Hi, I need some guidance, as I'm not being able to find the right instrutions for this. | 11:53 |
| zmoment | From a net iso, I've installed Devuan into a LVM that sits inside a cryptsetup luks container. | 11:54 |
| zmoment | Grub didn't install from the installer, but I chrooted and installed it. | 11:54 |
| zmoment | When booting, grub asks for the password, then I can choose Devuan as the first option to boot, from the menu. | 11:55 |
| zmoment | The problem sits, I think, in the initramfs. | 11:55 |
| zmoment | The system doesn't boot, gives me a shell, and lsmod | grep lvm shows no module. | 11:56 |
| zmoment | Probably, I need to build a custom initramfs. | 11:56 |
| zmoment | Is there any guide someone can point me to for this specific use case (lvm inside a luks container), please? | 11:57 |
| rrq | update-rc.d | 11:57 |
| S0urce | rrq do we need to install this command? or it comes with the base? | 11:58 |
| rrq | but sysvinit kicks in after initrd | 11:58 |
| zmoment | I chose OpenRC. | 11:58 |
| rrq | whichever.. the init comes after the /init script in the initrd | 11:59 |
| S0urce | I don't seem to have update-rc.d in my system | 11:59 |
| rrq | its for sysvinit (which you asked about :) | 11:59 |
| S0urce | yes, I have Devuan installed with sysvinit, but I can't find this command. Sorry new to linux coming from FreeBSD world | 12:00 |
| rrq | openrc does something else I guess .. but if your problem is with initrd all that is irrelevant (comes later) | 12:00 |
| rrq | the linux boot is a two-stage thing | 12:01 |
| rrq | firstly the initrd /init script is run, and it ends with a switch-root to the root filesystem which contiains "an init system" | 12:01 |
| rrq | if I understand right, you have a luks-encrypted disk/partition with an lvm inside, and a root filesystem in that lvm ? | 12:03 |
| S0urce | okay my problem is the want to disable bluetooth service, but not removing it, in FreeBSD we do something in the /etc/rc.conf servicename_enabled="NO" or "YES", how I can diable the service in sysVinit | 12:03 |
| S0urce | rrq, yes | 12:04 |
| rrq | with sysveinit, it'd be "update-rc.d bluetoothd disable" ... (if it's the noremal bluetoothd) | 12:05 |
| rrq | that command is available within the root filesystem but probably not in the initrd | 12:05 |
| rrq | services are a second stage thing | 12:06 |
| rrq | you may have "rfkill" in the initrd for turning on/off the device | 12:06 |
| rrq | just type "rfkill" to check | 12:07 |
| S0urce | worked rrq, thank you so much | 12:08 |
| rrq | nw | 12:08 |
| S0urce | will check rfkill as well, cheers mate | 12:09 |
| fsmithred | zmoment, if /boot is inside the encrypted volume there needs to be a line in /etc/default/grub for it to work. I'll look it up. | 12:28 |
| zmoment | Yes, /boot is inside the encrypted volume. | 12:28 |
| fsmithred | GRUB_ENABLE_CRYPTODISK=y | 12:33 |
| fsmithred | that goes in /etc/default/grub and then run update-grub | 12:33 |
| zmoment | I already had that line. | 12:42 |
| S0urce | fsmithred, does they need to add the uuid of the partition there as well? | 12:42 |
| zmoment | Booted from a live image, did the mount --bind of /dev, /proc/ and /sys, chroot, but cannot run any command, there's an error while loading shared libraries: libpcre2.8.so.0 | 12:43 |
| zmoment | The initramfs doesn't seem to have the lvm kernel module. | 12:43 |
| fsmithred | make sure you do 'su -' and not just 'su' to become root. different PATH | 12:48 |
| fsmithred | the uuid does not need to be inside /etc/default/grub. | 12:49 |
| zmoment | I already solved the error regarding the shared libraries. | 12:50 |
| fsmithred | what was it? | 12:50 |
| zmoment | I forgot to mount /usr and /var that sit on different LVM partitions. | 12:51 |
| fsmithred | oh! | 12:51 |
| zmoment | So, back to the boot problem :-) | 12:51 |
| fsmithred | you tried rebuilding initramfs in the chroot? | 12:51 |
| zmoment | Not yet. | 12:54 |
| zmoment | how to do it? | 12:54 |
| zmoment | have to insert lvm modules in /etc/initramfs-tools? | 12:56 |
| fsmithred | update-initramfs -u | 13:00 |
| fsmithred | I think they should be included by default | 13:00 |
| fsmithred | I think that file should say something like "modules MOST" | 13:01 |
| fsmithred | that's the default setting unless you chose otherwise during install | 13:02 |
| zmoment | Did the update-initramfs -u. When doing lsinitramfs -l /boot/initrd.img-6.1.0-10.amd64 | grep module | grep -i lvm shows nothing | 13:05 |
| zmoment | although the same lsinitramfs -l ... | grep -i lvm, shows several files under etc/lvm | 13:06 |
| zmoment | ans usr/lib/udev/rules.d/56-lvm.rules and 69-lvm.rules | 13:06 |
| fsmithred | I'm not sure what all should be there | 13:08 |
| fsmithred | I've done this and I know it works, but I can't think of what's wrong here | 13:09 |
| zmoment | I'm going to reboot | 13:09 |
| fsmithred | ok | 13:09 |
| zmoment | Drops to the initramfs shell again. Says "ALERT! /dev/mapper/vg0-root does not exist." | 13:11 |
| rrq | this short story seems relevant https://bbs.archlinux.org/viewtopic.php?id=255329 | 13:24 |
| rrq | but /etc/mkinitcpio.conf is not something I recognise | 13:27 |
| al1r4d | i am not aware if the apt source list has been modernized. | 13:29 |
| rrq | zmoment: is your GRUB_CMDLINE_LINUX similar to that last post? | 13:32 |
| rrq | al1r4d: not sure "modernised" is the right word ... M$-ified seems more like it | 13:35 |
| zmoment | rrq: In /etc/default/grub, GRUB_CMDLINE_LINUX="" | 13:43 |
| zmoment | I'll update it. | 13:43 |
| zmoment | For the cryptdevice=UUID=UUIDofdevice, is that one of the /dev/nvme0n1p2 (unencrypted) or the /dev/mapper/something already decrypted? | 13:44 |
| rrq | I'm not an lvm expert, but hpoing that root= setup would tell the kernel to spin up the volume group vg0 and locate the volume "root" in that | 13:44 |
| rrq | provided the kernel already has lvm2 loaded I guess | 13:45 |
| rrq | I read it as cryptdevice=UUID=UUIDofdevice:vg0 | 13:47 |
| rrq | hmm maybe that is handled by initrd ? | 13:49 |
| rrq | would make sense.. the /init of the initrd is shell scripting so you can inspect it; it uses scripts in /scripts/** | 13:50 |
| rrq | so the /init scripting would interpret the cryptdevice= parameter so as to sping up the vg0 volume group | 13:52 |
| rrq | or whatever it's called: to make a symbolic /dev/mapper/vg0-root for the dm-N device concerned | 13:53 |
| zmoment | Should I go with /usr/sbin/update-grub or /usr/sbin/update-grub2? | 14:01 |
| rrq | I would have thought they are the same | 14:03 |
| rrq | use grub3 I guess | 14:03 |
| rrq | grub2 | 14:03 |
| rrq | /usr/sbin/update-grub2 -> update-grub | 14:05 |
| rrq | those parameteres are declared for grub so it can pass them to the linux command line so that the initrd init scripting can discover them | 14:06 |
| rrq | all that happens after the decryption, since the kernel and initrd reside within the encrypted disk | 14:08 |
| rrq | (grub has its decryption s/w outside if that) | 14:09 |
| zmoment | Rebooted but have the same problem. Have to check where's the issue. | 14:14 |
| rrq | the initrd init scripts reside under /usr/share/initramfs-tools/ of the root filsystem | 14:18 |
| rrq | taken from there when making the initrd | 14:18 |
| rrq | there should be some lvm snippet that activates the volume group | 14:19 |
| rrq | perhaps scripts/local-top/lvm2 | 14:22 |
| rrq | hmm before that there needs to be a dmsetup for the disk decryption | 14:25 |
| rrq | I'm not sure what grub does to handle that boot is encrypted, but when the kernel is started it needs to have a dm device for channeling disk access | 14:27 |
| rrq | possibly grub has its own decryption handling for the kernel and to unpack the initrd into ram, and that the initrd would have crypt* snippet to set up that decryption device | 14:31 |
| rustytaco | /boot isnt encrypted tho | 14:57 |
| rrq | I think zmoment said it's full-disk encryption | 14:59 |
| zmoment | This /boot is at /dev/vg0/boot, so as a logical volume inside the encrypted partition /dev/nvme0n1p2 | 15:09 |
| al1r4d | rrq: i dont understand why you put microsoft o_o | 15:10 |
| rrq | I see it in the new-found love of .ini files ... (I have been wrong sometimes though) | 15:11 |
| zmoment | rrq: in /usr/share/initramfs-tools/scripts/local-top there's only two scripts: cryptopensc and cryptroot, no lvm2. | 15:20 |
| rrq | you have /usr/share/initramfs-tools/hooks/lvm2 ? | 15:21 |
| zmoment | yes | 15:22 |
| rrq | I think that shuld be enough for handling the lvm ... when you drop to the initramfs shell, is the disk decrypted? | 15:24 |
| rrq | is there a /dev/mapper/... for that disk? | 15:24 |
| zmoment | I'll check that in next reboot. | 15:25 |
| zmoment | There are two different grub.cfg. One at the encrypted /boot/grub/grub.cfg, another one at the unencrypted /boot/efi/EFI/debian/grub.cfg. | 15:26 |
| rrq | hmm shouldn't there be a scripts/local-top/lvm2 ? | 15:26 |
| zmoment | Could the system be booting from the efi grub.cfg instead of the other one? update-grub updated /boot/grub/grub.cfg, not /boot/efi/EFI/debian/grub.cfg. | 15:27 |
| fsmithred | the grub.cfg in efi should just source the other grub.cfg. That's how the live isos are made. | 15:29 |
| rrq | is it an UEFI boot? | 15:31 |
| zmoment | yes | 15:31 |
| rrq | and the EFI partition is not encrypted | 15:31 |
| zmoment | Not encrypted. It's /dev/nvme0n1p1. I mounted it at /boot/efi | 15:32 |
| zmoment | Regarding your previous question, when booting the initramfs has no /dev/mapper | 15:33 |
| rrq | right. that suggests that the decryption has not happened... but I guess you do enter the password? | 15:34 |
| zmoment | From the initramfs shell, I was able to open the encrypted partition and do a vgchange -ay. So, it has the necessary modules. | 15:35 |
| rrq | ok.. but the efi boot doesn't decrypt (it knows the name of the root in some way..) | 15:36 |
| rrq | or do you enter the password once before dropping into initramfs shell ? | 15:37 |
| zmoment | I enter a password before dropping into initramfs shell. | 15:38 |
| rrq | ok. so efi boot does decrypt... but drops all that after unpacking initrd, then that initrd doesn't decrypt | 15:41 |
| rrq | would be cryptroot I guess | 15:41 |
| rrq | though it's the full disk to be decrypted | 15:42 |
| rrq | I don't have any example to look into those crypt* scripts ... perhaps they want some different boot parameter | 15:44 |
| rrq | there may be an /etc/crypttab .. which needs to be in initramfs | 15:44 |
| zmoment | Create a /etc/crypttab for the /dev/mapper/vg0-root? | 15:47 |
| rrq | it needs to be for the encrypted disk | 15:48 |
| rrq | for nvme0n1p2 ... not sure what the target should be | 15:49 |
| rrq | would be the "physical device" name used in the volume group | 15:50 |
| rrq | but the decryption should be "operated" by efi-grub, using the password already entered | 15:53 |
| rrq | or does efi-grub drop that into a file ? | 15:57 |
| zmoment | Ok, main problem solved. Can already boot to my fresh Devuan system, but have to enter the password for the encrypted disk two times. | 15:58 |
| zmoment | Thanks a lot rrq! | 15:58 |
| rrq | great :) | 15:59 |
| rrq | you could inspect the filesystem at the initramfs shell if there is some password file hanging around | 16:00 |
| zmoment | password file? | 16:00 |
| rrq | just in case efi-grub writes the password into a file, to be used in the subsequent decryption | 16:01 |
| rrq | that's a transient file within the initrd unpacking in ram | 16:01 |
| rrq | if there is one it probably starts with a dot | 16:01 |
| rrq | anyhow, typing the password twice is not too onerus I suppose | 16:04 |
| fsmithred | in the normal case with full-disk encryption, you have to enter the passphrase twice | 16:04 |
| fsmithred | I found it annoying enough to not use fde | 16:05 |
| zmoment | But some years ago, I configured the boot system to ask only once for the password. | 16:06 |
| zmoment | Now cannot log in. Either defined some mistyped password, or there's something wrong. The default password for root (toor) doesn't work, too. | 16:12 |
| rrq | if you drop back to iniramfs shell, you can do the manual decryption and mounting of root filesystem and then chroot into it, to do passwd things | 16:15 |
| rrq | I don't think there's a default root password btw | 16:15 |
| rrq | fwiw I do neither disk encryption nor lvm on my machines | 16:19 |
| zmoment | After grub, how to drop to a initramfs shell? | 16:20 |
| rrq | mistype the second password ? | 16:20 |
| zmoment | 20 mistyped passwords are not enough, wil have to reboot in a live system and chroot as before. | 16:23 |
| rrq | hsould work. the other option could have been to use the "e" command on the boot screen and then messed up the root pathname a little | 16:30 |
| * rrq g'night | 16:31 | |
| zmoment | have a good night rrq! Hope that life brings you good things! | 16:34 |
| tempforever | I think I have a laptop with that setup (have to enter p/w twice) but don't recall having a problem with it (set it up under chimaera, I believe) | 16:53 |
| tempforever | 1st screen is welcome to grub, enter passphrase for hd0 ... | 16:55 |
| tempforever | then get the devuan boot selection screen ... then please unlock disk sda1_crypt (2nd time for p/w) | 16:56 |
| tempforever | after that 2nd p/w it creates the /dev/mapper/lvm files | 16:56 |
| tempforever | hm, one difference is this is legacy, not uefi boot though | 16:58 |
| tempforever | actually if it boots to login screen then you're probably good to go, once you change user p/w so you can log in | 17:10 |
| zmoment | I'm following points 7 and 8 of https://www.dwarmstrong.org/fde-debian/, but lsinitramfs is not listing the keyfile that I added to the encrypted partition. | 17:24 |
| tempforever | I'll check my setup, /etc/crypttab .. I dont remember setting up a keyfile | 18:21 |
| tempforever | oh, that's to avoid entering the passphrase twice. I didn't do that | 18:22 |
| KuLuSz | hello | 19:56 |
| KuLuSz | is there any developer of devuan ? | 19:57 |
| KuLuSz | :D | 19:57 |
| KuLuSz | or who can help of setup mesa rendering ? | 19:57 |
| greenjeans | They are around, sometimes it takes a while | 19:58 |
| greenjeans | best to ask your question, then just stay logged on and check for answers later | 19:58 |
| KuLuSz | yes as usualy .. | 19:59 |
| KuLuSz | :D | 19:59 |
| KuLuSz | ty | 19:59 |
| KuLuSz | this room is flood protected ? | 20:05 |
| fsmithred | yes | 20:05 |
| KuLuSz | oh | 20:05 |
| fsmithred | 3 lines allowed, I think | 20:05 |
| KuLuSz | is not good | 20:05 |
| KuLuSz | :D | 20:05 |
| fsmithred | use paste.debian.net | 20:05 |
| fsmithred | you obviously haven't been here when we got badly flooded | 20:06 |
| KuLuSz | never .. | 20:06 |
| KuLuSz | :) | 20:06 |
| fsmithred | I also use termbin.com if I can't copy/paste | 20:07 |
| debdog | though tha is not the only reason | 20:07 |
| KuLuSz | I will try to give a relatively understandable description of my situation. | 20:09 |
| KuLuSz | anyway not really devuan specific problem .. | 20:10 |
| KuLuSz | i get same "error" on antix too | 20:10 |
| debdog | in that case starting with hardware specs might be a good idea | 20:20 |
| debdog | esp. if we're talking about a laptop with an intel/nvidia combinatioen or such | 20:24 |
| KuLuSz | no-no | 20:25 |
| KuLuSz | netbook | 20:25 |
| KuLuSz | single card | 20:25 |
| greenjeans | AMD? | 20:25 |
| KuLuSz | intel | 20:26 |
| greenjeans | need a model number at least to look up specs | 20:27 |
| fsmithred | lspci | nc termbin.com 9999 | 20:28 |
| KuLuSz | iam not on that pc | 20:28 |
| fsmithred | assuming you can get to console and have network | 20:28 |
| KuLuSz | :( | 20:28 |
| fsmithred | what exactly is the problem? black screen? | 20:28 |
| KuLuSz | no problems with driver | 20:29 |
| KuLuSz | evrithing work .. | 20:29 |
| KuLuSz | *y | 20:29 |
| KuLuSz | have pic | 20:29 |
| KuLuSz | but | 20:29 |
| KuLuSz | when i want to watch youtube video , it very lagg | 20:29 |
| KuLuSz | and evry glxtest show i have rendering with mesa | 20:30 |
| KuLuSz | but | 20:30 |
| KuLuSz | no | 20:30 |
| fsmithred | is it the same if you download the video first and then watch it in a vid player? | 20:30 |
| KuLuSz | renederer is DRM | 20:30 |
| KuLuSz | i dont try it | 20:31 |
| KuLuSz | but i use another sys there is work fine .. | 20:31 |
| KuLuSz | without laggs | 20:31 |
| KuLuSz | but its older | 20:31 |
| KuLuSz | from 2017 | 20:31 |
| KuLuSz | :D | 20:31 |
| _ds_ | I'm guessing related to video decoding acceleration. | 20:32 |
| KuLuSz | firefox about:support show just sotware accelerate | 20:33 |
| KuLuSz | not hw | 20:33 |
| KuLuSz | _ds_: yes | 20:34 |
| KuLuSz | but glx run in software rendering on CPU | 20:34 |
| KuLuSz | under DRM | 20:34 |
| KuLuSz | so | 20:35 |
| KuLuSz | cpu 100% when play video | 20:35 |
| KuLuSz | :D | 20:35 |
| _ds_ | $ apt-cache search vaapi; apt-cache search vdpau | 20:43 |
| _ds_ | Some of the packages listed by those commands may be helpful. | 20:43 |
| KuLuSz_netbook | work? | 20:56 |
| KuLuSz | work | 20:56 |
| KuLuSz | :D | 20:56 |
| ximon | #linux | 21:03 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!