Re: [lfs-support] Booting LFS with systemd
On Thu, 12 Jul 2018 08:41:23 +0100 Ken Moffat wrote: > And the generic command is probably 'git revert 7744ccdbc16f' but > since I'm not currently bisecting, I'm not sure what state that > would leave things in. Ken, I should have realized that since Hazel was working with the full git tree, that he could easily revert any commit within git. Duh! H ... I think what I was thinking was that I didn't trust the results of the bisection within git (because the identified problem code does not even seem be active within Hazel's config, and Hazel said he was new to the bisection process). So, I'm not so sure the commit that is believed to be the offender really is the guilty party. I was thinking that Hazel would take the 4.15 source tree (from the official release tarball) and then manually backout the suspect commit - if that works/boots, then it is virtually certain we found the problem area (as we didn't depend on git). And, if we find the problem commit, the next step might be to manually change things in the source until we home in on the offending *line*, if possible. So, we'd be manually tweaking the source at some point anyway. With regard to reversing a patch (without any use of git), is it for certain that the -R option of patch can be used to reverse *any* patch file? https://www.drupal.org/patch/reverse If it is not universally possible to create a reverse patch using only the information in a patch file, then I'd say that that is an oversight in the design of diff. There is a lot more info on the topic of reversing patches here: https://stackoverflow.com/questions/3902388/permanently-reversing-a-patch-file The interdiff utility and the patchutils package are new to me: http://cyberelk.net/tim/software/patchutils/ ( simple standard install: ./configure --prefix=/usr configure looks for perl and xmlto ) Interdiff can create an "inverse" patch file via: interdiff file.patch /dev/null > reversed.patch The resulting reverse patch looks good to me, but when I tried a dry run: patch --dry-run -p1 -i ../tip-x86-mm-x86-mm-Add-Secure-Memory-Encryption-SME-support_reverse.patch I got: checking file arch/x86/Kconfig Reversed (or previously applied) patch detected! Assume -R? [n] I don't understand why it would think the patch had been already applied as the patch is supposed to *delete* code that is indeed in my Kconfig file. I think the problem might be because the specific kernel tree I tried it on has the context lines at 1436 rather than the 1415 specified by the patch. I've attached a copy of the interdiff created tip-x86-mm-x86-mm-Add-Secure-Memory-Encryption-SME-support_reverse.patch in case anyone wants to look at/try it. Anyway, for the record, in the stackoverflow post, Lie Ryan's script is not quite right. It reverses the --- and the +++ alright, but later on it reverses the - and + at the start of the lines which also ends up affecting the --- and +++ lines and so we end up getting -++ and +--. If he went through all that trouble to create that script, didn't he take the time to inspect the results of it? Sigh. Cheers, Mike tip-x86-mm-x86-mm-Add-Secure-Memory-Encryption-SME-support_reverse.patch Description: Binary data -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Booting LFS with systemd
On 06/27/2018 04:42 PM, Paul Rogers wrote: I removed the need for using initrd, so now init=/bin/bash is working. Time to move forward and investigate what is causing the ABRT when starting systemd. Thanks for the pointer, it has grossed my mind before but somehow I forgot it again. Frans, Yeah! Now we're on the right track! :) Looking into it, the reason why initramfs is so tightly linked to systemd is because: Correct me if I'm wrong, but I thought the only good reason for an initramfs is so a totally generic kernel could be built with every possible device driver for any unpredictable hardware out there as modules, then with discovery keep only those modules with the running kernel and dump the rest. That's generally correct, but the initrd is also used for other things than just drivers. It can be used for mounting a root filesystem that is encrypted or be needed with LVM or other custom filesystems or for finding a partition identified with a UUID. http://www.linuxfromscratch.org/blfs/view/stable/postlfs/initramfs.html I also use one to update the CPU firmware. We show how to create this limited initrd at the section 'Early loading of microcode' in http://www.linuxfromscratch.org/blfs/view/stable/postlfs/firmware.html But with LFS, given that 1) we know what hardware we have and that's unlikely to change much, if at all, 2) those modules need to be available to the system at all times, and 3) rebuilding the kernel isn't fearsome for us, I've never seen ANY need for an initramfs and build what's necessary as a monolithic kernel. If that's true, even with systemd, why is there any need to build an initramfs for a known system? Because systemd is trying to insinuate itself into all critical functions of Linux, It just makes the boot process more complex than it needs to be. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Booting LFS with systemd
On Thu, Jul 12, 2018 at 02:17:05AM -0400, Michael Shell wrote: > On Wed, 11 Jul 2018 16:19:17 +0100 > Hazel Russman wrote: > > > Does the "patchwork" site in your link contain the actual patch files > > that correspond to those weird alphanumeric codes? > > > Hazel, > > Yes! At the page: > > https://patchwork.kernel.org/patch/9847857/ > > Look at the headers near the top. The link to the patch is labeled > "patch" under the Download section. e.g., > > https://patchwork.kernel.org/patch/9847857/raw/ > > That will give you the patch that caused those changes which are > identified as "commit 7744ccdbc16f0ac4adae21b3678af93775b3a386": > Michael, whilst your advice is good, this seems horrendously complicated. I will admit that I have trouble when a bisect points to a *merge* commit, and since I'm not currently doing a bisect I lack details for reverting a commit, but surely - if you have the git tree, you can look at the particular commit, e.g. 'git show 7744ccdbc16f' (might sometimes need more digits), and then in worst case add '>../dodgy' (so, the created file is not in the git tree) and then something like 'cat ../dodgy | patch -R' [ probably needs more specification, e.g. -p1 or whatever, so --dry-run ]. And the generic command is probably 'git revert 7744ccdbc16f' but since I'm not currently bisecting, I'm not sure what state that would leave things in. The important thing is that the 'weird alphanumeric codes' identify a particular commit [ some variant of a shasum, I think ] and can be used to identify the commit in git. Regards, ĸen -- Keyboard not found, Press F1 to continue -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
