Re: [arch-general] kernel compilation
Am 28.03.19 um 11:25 schrieb Pascal via arch-general: > after compilation, if I modify/patch file src/linux-4.19/block/blk-core.c, > do I have to replace the kernel ? the kernel and all its modules ? or just > the module concerned by the change (if it concerns a module) ? You just need to replace the affected binaries, if kernel version and all configuration stays the same. Of course it would be better to make a proper package. You may package out-of-tree modules separately, but you need a full kernel package for in-tree modules. Have a look at the PKGBUILDs in the repositories. There are examples for both. KR
Re: [arch-general] Hibernation Failure
Am 12.01.20 um 01:39 schrieb Paul Dann via arch-general: > I'm having trouble getting hibernation to work on my new Dell Inspiron > 7590. It seems that the image is stored correctly (onto LUKS+LVM thin-lv), I've noticed something similar on a similar setup. It looks like the kernel is taking some shortcuts when accessing the (swap-) space during hibernation, which are not compatible with dm-crypt. I'm using an AEAD cipher and the integrity data is wrong after resume. BR
Re: [arch-general] Hibernation Failure
Am 12.01.20 um 12:19 schrieb Markus Schaaf via arch-general: > > > Am 12.01.20 um 01:39 schrieb Paul Dann via arch-general: >> I'm having trouble getting hibernation to work on my new Dell Inspiron >> 7590. It seems that the image is stored correctly (onto LUKS+LVM thin-lv), > > I've noticed something similar on a similar setup. It looks like the > kernel is taking some shortcuts when accessing the (swap-) space during > hibernation, which are not compatible with dm-crypt. I'm using an AEAD > cipher and the integrity data is wrong after resume. I know it is terribly late, but for those curious: While investigating this I managed to make my laptop unbootable, because dm-crypt decided that every single sector on my encrypted partition had a bad AEAD tag and wouldn't let me read a single byte. That was exactly what had been happening to my swap-partition before, when I tried to resume from hibernation. But this time it had eaten my root-partition too. Of course I had backups, encrypted (of course), with a key I had changed recently ... that I knew I needed to save somewhere else, but somehow forgot to. I'm writing this on exactly that laptop, restored completely from the "unreadable" SSD. But it took me some time to read the relevant kernel code, develop and run some helpful tools to search and decrypt the data on said partition. What I have found: It is unlikely that hibernation is the cause to the problem I have encountered. It is just the trigger. Somehow dm-integrity or dm-crypt manages to fuck up it's on-disk meta-data. (Meanwhile the same happened to my work desktop, which had a similar setup, after suspend to RAM.) After I had determined the exact encryption algorithm and layout of my data, I was able to not only read all of it, but the on-disk integrity-tags matched 100%. Every single sector. BR
Re: [arch-general] Hibernation Failure
Am 23.04.20 um 10:14 schrieb Paul Dann via arch-general: > it down to a kernel update. That being said, I don't hibernate > regularly, so maybe I've just been lucky :p Probably. I needed to read some of the code and it hasn't changed lately AFAIK. My guess is that the problem has something to do with the integrity journal. I had it disabled, but it's read on cryptsetup open anyway. After all I didn't like the (inflexible) data layout (which leads to write amplification), and the journal (and perhaps some of the code) of dm-integrity, so I've formatted all disks back to aes-xts. :-) And remember to print your backup keys on paper. BR
Re: [arch-general] NFS "updates"?
Am 27.04.20 um 16:51 schrieb Hauke Fath: > NFSV4: Unsupported transport protocol udp Have you tried vers=3 in mount options?
Re: [arch-general] NFS "updates"?
Am 27.04.20 um 20:00 schrieb Leonidas Spyropoulos via arch-general: > It's a kernel configuration which is introduced with 5.6 kernel. In my > CONFIG_NFS_DISABLE_UDP_SUPPORT=y Wow! I'd say udp is used a lot with nfsvers=3. That will break many nfs3 deployments.
Re: [arch-general] NFS "updates"?
Am 29.04.20 um 13:44 schrieb Andy Pieters: > While it is relatively trivial to compile your own kernel with those > options enabled using Arch's build system, I think you'd better talk to the > actual people that made the change upstream. > This change might have slipped through unnoticed. It seems idiotic: _Add_ code to the kernel, to break users systems, with no benefit whatsoever. It's clearly against Linus' agenda to not break userland. But to tell the users to discuss this upstream is bad advice. This is a situation where a distribution should take corrective action by reverting this configuration. This would add value and remove some useless code from the kernel. BR
Re: [arch-general] Heads up: After system update, LUKS fails with certain BIOS versions
Am 01.05.20 um 16:56 schrieb LuKaRo: > [...] I tried cryptsetup open, luksOpen, luksDump and isLuks > ..., all hanging after printing the header checksum. May I ask if your headers are --type=luks or luks2?
