| - mjw (QUIT: Ping timeout: 250 seconds) (~mjw@gnu.wildebeest.org) | 00:15 | |
| - Gooberpatrol66 (QUIT: Remote host closed the connection) (~Gooberpat@user/gooberpatrol66) | 01:40 | |
| - mtm (QUIT: Ping timeout: 240 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 02:04 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:50) | 02:09 | |
| - ajr (QUIT: Quit: WeeChat 3.8) (~ajr@user/ajr) | 03:16 | |
| - nsc (QUIT: Ping timeout: 248 seconds) (~nicolas@22-49-142-46.pool.kielnet.net) | 03:29 | |
| + nsc (~nicolas@236-49-142-46.pool.kielnet.net) | 03:31 | |
| + Nulo_ (~Nulo@user/nulo) | 03:42 | |
| - Nulo (QUIT: Ping timeout: 248 seconds) (~Nulo@user/nulo) | 03:43 | |
| * Nulo_ -> Nulo | 03:43 | |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 04:09 | |
| josch | hi, is somebody here with an encrypted nvme setup and latest Debian unstable on sysimage-v3 and knowledge about how to use cryptsetup and chroot from a rescue-system ssd here who can help me try reproduce an upgrade bug? | 04:53 |
|---|---|---|
| josch | essentially, i fixed a bug in how we build our patched debian kernel. Installing it and rebooting it works well and fixes the problem (dkms modules like reform2_lpc are now rebuilt). The problem arises, once one removes the old faulty linux-image package. Once one does that, the system becomes unbootable and doesn't find the luks device on boot | 04:55 |
| josch | i still do not know what the problem is but it is fixed by not just removing but by purging the old faulty linux-image-6.1.0-reform2-arm64 package | 04:56 |
| josch | but for that you need to boot the system from a rescue ssd, run cryptsetup, mount and chroot | 04:56 |
| josch | would somebody be willing to try that out to see whether this is a problem in my setup or a general issue? | 04:56 |
| josch | if it's the latter, i'll make a forum post | 04:57 |
| - GNUmoon (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 05:50 | |
| + GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) | 05:51 | |
| - Boostisbetter (QUIT: Ping timeout: 248 seconds) (4a410829d7@irc.cheogram.com) | 06:26 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20) | 06:46 | |
| josch | vagrantc: do you have some time to test my fixed kernel? there is a bug and you know enough to try the fix without destroying your setup :D | 07:02 |
| vagrantc | josch: maybe tomorrow? | 07:08 |
| vagrantc | josch: is it in the regular repositories? am i building it myself? | 07:10 |
| josch | vagrantc: just apt update && apt upgrade | 07:10 |
| josch | vagrantc: this will not break your system but "apt-get remove linux-image-6.1.0-reform2-arm64" (the old kernel) might | 07:11 |
| josch | https://mntre.com/reform-irc-logs/2023-04-05.log.html#t04:53:14 | 07:11 |
| vagrantc | ah, i haven't yet set up encryption on the NVMe | 07:12 |
| vagrantc | my wild guess would be something different in the installed /etc/* hooks or something | 07:13 |
| vagrantc | such as /etc/kernel/*.d or /etc/initramfs-tools/*.d or /usr/share/initramfs-tools/* | 07:14 |
| josch | vagrantc: the fix is to "apt-get remove --purge linux-image-6.1.0-reform2-arm64" | 07:16 |
| josch | the only difference between a normal remove and a purge is the removal of /lib/modules/6.1.0-7-reform2-arm64/ | 07:18 |
| josch | so maybe mkinitramfs picks up the wrong module directory in error? | 07:18 |
| vagrantc | they have their own kernel modules in /lib/modules? e.g. different ABI ? | 07:18 |
| josch | yes | 07:19 |
| vagrantc | that is ... perplexing how that could happen, yeah. | 07:19 |
| josch | sorry, i mean the removal of /lib/modules/6.1.0-reform2-arm64/ | 07:19 |
| josch | (my earlier examle *did* include the abiname) | 07:19 |
| josch | i do not know what is going on and i'd like somebody to reproduce the problem to see *if* it's a problem and *if* this fixes it | 07:20 |
| vagrantc | i mean the difference between the old and new package ... | 07:20 |
| josch | vagrantc: the difference between the old and new package is only the abiname | 07:20 |
| vagrantc | huh. will see about trying to reproduce tomorrow | 07:21 |
| josch | maybe the problem is that "6.1.0-reform2-arm64" sorts as *newer* than "6.1.0-7-reform2-arm64" | 07:21 |
| vagrantc | i forget if i have a u-boot with display on there or not ... i tested some upstream patches a while back but then reverted to the mnt.re u-boot i think | 07:22 |
| vagrantc | josch: yeah, that is likely | 07:22 |
| + bgs (~bgs@212-85-160-171.dynamic.telemach.net) | 07:23 | |
| vagrantc | linux-version compare 6.1.0-7-reform2-arm64 gt 6.1.0-reform2-arm64 | 07:24 |
| vagrantc | errors out ... so yeah, sort order may be the issue if the old version is still booting but has no modules or something? | 07:24 |
| vagrantc | linux-version compare 6.1.0-7-reform2-arm64 lt 6.1.0-reform2-arm64 ... returns true | 07:25 |
| josch | for me, it didn't find the luks partition -- no idea whether the problem only shows with luks or on your unencrypted system as well | 07:25 |
| vagrantc | but ... i would think the kernel + initrd would still have all the right modules | 07:27 |
| vagrantc | e.g. even removing it should remove the entry from the boot menu | 07:27 |
| josch | yes, i did not manage to find something that looks odd | 07:27 |
| vagrantc | if somehow the one version got booted with the wrong initrd? | 07:28 |
| josch | i just don't understand how because the abiname should make it unique | 07:28 |
| vagrantc | right | 07:28 |
| vagrantc | it *sounds* like missing kernel modules to me ... but hard to imagine how it got to that state | 07:29 |
| vagrantc | but many things are hard to imagine until you figure it out :) | 07:30 |
| vagrantc | unless an initrd was only partially generated? i have seen that sort of thing now and then | 07:33 |
| vagrantc | like with a power failure or media failure or something | 07:33 |
| + Boostisbetter (4a410829d7@irc.cheogram.com) | 07:36 | |
| + mjw (~mjw@gnu.wildebeest.org) | 09:00 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:20) | 09:21 | |
| - mlarkin (QUIT: Ping timeout: 268 seconds) (~mlarkin@047-036-074-225.res.spectrum.com) | 09:21 | |
| vkoskiv | I've been apt searching wrong all this time. | 09:37 |
| vkoskiv | You have to specify --names-only for it to do what you want, which is search packages by name | 09:37 |
| vkoskiv | Otherwise tons of packages that have nothing to do with your search term come up. | 09:37 |
| vkoskiv | Which begs the question - Why is --names-only not the default? :D | 09:38 |
| vkoskiv | I've always just done something like: apt search python | grep python | 09:38 |
| + mlarkin (~mlarkin@047-036-074-225.res.spectrum.com) | 09:38 | |
| josch | vkoskiv: apt developers believe that the default should be to search for strings in the package description as well by default | 09:46 |
| - mjw (QUIT: Ping timeout: 252 seconds) (~mjw@gnu.wildebeest.org) | 10:02 | |
| * mark_ -> mjw | 10:03 | |
| josch | yes, something is wrong due to "6.1.0-reform2-arm64" sorting *newer* than "6.1.0-7-reform2-arm64" | 10:07 |
| josch | after installing linux-image-6.1.0-7-reform2-arm64 and rebooting, the system will boot linux-image-6.1.0-reform2-arm64 instead... | 10:08 |
| josch | apt remove linux-image-6.1.0-reform2-arm64 will then of course throw a warning (because you remove the kernel you are currently running) but rebooting will get you into 6.1.0-7-reform2-arm64 | 10:09 |
| josch | can somebody else reproduce this? | 10:10 |
| Boostisbetter | josch, sorry josch I can't help. | 10:23 |
| Boostisbetter | On a seperate note, if I installed a experimental kernel but want to get back on normal apt routines | 10:24 |
| Boostisbetter | how do I do that? | 10:24 |
| minute | josch: i can try it later today | 10:34 |
| josch | Boostisbetter: what is an "experimental kernel" and "normal apt routines"? | 10:39 |
| josch | minute: that would be cool, thanks! Have a second machine ready in case your reform becomes unbootable after removing linux-image-6.1.0-reform2-arm64 -- but this only happened on my encrypted system and not on my unencrypted rescue system on sd-card | 10:40 |
| minute | yep | 10:40 |
| Boostisbetter | josch, basically if I installed a self compiled kernel, but want to go back to mainline | 11:09 |
| Boostisbetter | say the self compiled is a 6.2 kernel but I want to go back to 6.1 | 11:10 |
| josch | Boostisbetter: you just built yourself a uImage and copied that into your /boot? | 11:10 |
| josch | or did you rebuild a Debian kernel? | 11:11 |
| josch | did you build from upstream kernel.org? | 11:11 |
| Boostisbetter | Debian | 11:11 |
| Boostisbetter | basically I'm on a 6.2 and I want to get back on the 6.1 based kernel | 11:11 |
| josch | Boostisbetter: where did you get a 6.2 Debian kernel from? | 11:13 |
| josch | if you indeed just built a Debian Linux kernel, you can just apt-get remove it | 11:14 |
| josch | if you built it yourself, you need to undo the steps you carried out to install it (but i don't know yet what exactly you did) | 11:14 |
| Boostisbetter | yeah I installed it as a deb | 11:19 |
| josch | Boostisbetter: from where? not even experimental has 6.2 | 11:20 |
| josch | or did you use make bindeb-pkg? | 11:21 |
| Boostisbetter | honestly, I got it from someone, I had been talking with. It was supposed to handle suspend slightly better. It did not. | 11:24 |
| Boostisbetter | I'm back on stock. | 11:24 |
| josch | If you don't know how the *.deb was created I don't think I can give you reliable advice. | 11:30 |
| josch | In theory it should just be removing the kernel you don't want while making sure that there is still at least one other kernel package remaining (apt will complain loudly otherwise). | 11:30 |
| Boostisbetter | yep, it did not complain and a restart worked without an issue. | 11:45 |
| josch | nice :) | 11:45 |
| Boostisbetter | indeed. I love Linux. | 11:45 |
| + chomwitt (~chomwitt@ppp-94-69-24-223.home.otenet.gr) | 13:24 | |
| - mtm (QUIT: Ping timeout: 250 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 14:03 | |
| + jryans (~jryans@2001:470:69fc:105::1d) | 14:41 | |
| + mark_ (~mjw@gnu.wildebeest.org) | 14:52 | |
| - mark_ (QUIT: Ping timeout: 255 seconds) (~mjw@gnu.wildebeest.org) | 15:19 | |
| - chomwitt (QUIT: Ping timeout: 268 seconds) (~chomwitt@ppp-94-69-24-223.home.otenet.gr) | 15:50 | |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 16:09 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20) | 16:10 | |
| + chomwitt (~chomwitt@2a02:587:7a16:e500:1ac0:4dff:fedb:a3f1) | 16:41 | |
| - chomwitt (QUIT: Ping timeout: 260 seconds) (~chomwitt@2a02:587:7a16:e500:1ac0:4dff:fedb:a3f1) | 17:04 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:20) | 17:10 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 18:15 | |
| + mark_ (~mjw@gnu.wildebeest.org) | 18:48 | |
| - mjw (QUIT: Killed (NickServ (GHOST command used by mark_!~mjw@gnu.wildebeest.org))) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 18:48 | |
| * mark_ -> mjw | 18:48 | |
| + mark_ (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 18:49 | |
| - bluerise (QUIT: Ping timeout: 255 seconds) (~bluerise@user/bluerise) | 18:49 | |
| + bluerise (~bluerise@p5b0ac727.dip0.t-ipconnect.de) | 18:51 | |
| + bluerise_ (~bluerise@p5b0ac73d.dip0.t-ipconnect.de) | 19:05 | |
| - bluerise (QUIT: Ping timeout: 265 seconds) (~bluerise@p5b0ac727.dip0.t-ipconnect.de) | 19:05 | |
| vagrantc | josch: i didn't have any trouble with the new kernel ... although i did manually run flash-kernel --force 6.1.0-7-reform2-arm64 and rebooted ... | 19:45 |
| vagrantc | josch: using boot.scr ? or extlinux.conf ? | 19:45 |
| + ajr (~ajr@user/ajr) | 20:25 | |
| josch | vagrantc: i tried both with the same results | 20:31 |
| josch | vagrantc: both boot.scr as well as extlinux.conf decide that the kernel without abiname (the old one) has to be sorted as more recent | 20:32 |
| vagrantc | oh definitely, but neither should have the "newer" kernel version once you remove it | 20:38 |
| vagrantc | remove but not purge ... should still be missing /boot/vmlinuz-ABI and /boot-initrd.img-ABI and such | 20:39 |
| vagrantc | and extlinux.conf and boot.scr *should* get regenerated ... but maybe there is a bug where they do not | 20:40 |
| josch | vagrantc: the "it doesn't boot if only remove but not purge" problem only happened for me on my encrypted system, so it's very hard to reproduce as i only have this SSD and would have to back it up and restore it later if i wanted to try this again | 20:41 |
| josch | maybe this was even my setup only | 20:41 |
| josch | but then you also are not using an encrypted system either and i was also able to confirm that there are no problems (other than the sorting) when installing on an unencrypted system | 20:42 |
| vagrantc | hmm. | 20:43 |
| vagrantc | not sure i want to go trhough the trouble of setting up an encrypted system just to try and break it :/ | 20:44 |
| josch | nono, don't worry about it :) | 20:45 |
| josch | you having confirmed that it also doesn't make your system unbootable on an unencrypted setup is already helpful :) | 20:46 |
| + MajorBiscuit (~MajorBisc@2001:1c00:2408:a400:7f99:b6d8:c8b8:dc05) | 21:39 | |
| - GNUmoon (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 22:16 | |
| + GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) | 22:17 | |
| - bgs (QUIT: Remote host closed the connection) (~bgs@212-85-160-171.dynamic.telemach.net) | 22:49 | |
| + dozens (~dozens@tilde.town) | 23:30 | |
| dozens | i just pre-ordered a purple pocket! | 23:54 |
| bluerise_ | nice, congrats! | 23:57 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!