Il giorno lun, 10/06/2019 alle 16.38 +0200, Greg KH ha scritto: > On Sat, Jun 08, 2019 at 11:29:16AM +0200, Andrea Vai wrote: > > Il giorno sab 8 giu 2019 alle ore 09:43 Andrea Vai > > <andrea.vai@xxxxxxxx> ha scritto: > > > > > >[...] > > > > > > Hi, > > > there is also something else I don't understand. > > > Every time I build a kernel, then after booting it "uname -a" > shows > > > something like > > > > > > Linux [...] 4.19.0-rc5+ #12 SMP Sat Jun 8 00:26:42 CEST 2019 > x86_64 > > > x86_64 x86_64 GNU/Linux > > > > > > where the number after "#" increments by 1 from the previous > build. > > > > > > Now I have the same number (#12) after a new build, is it > normal? > > > Furthermore, "ls -lrt /boot/v*" shows the last lines to be > > > > > > -rw-r--r--. 1 root root 8648656 8 giu 00.35 /boot/vmlinuz- > 4.19.0-rc5+.old > > > -rw-r--r--. 1 root root 8648656 8 giu 09.08 /boot/vmlinuz- > 4.19.0-rc5+ > > > > > > and "diff /boot/vmlinuz-4.19.0-rc5+.old /boot/vmlinuz-4.19.0- > rc5+" > > > shows they are identical. Why? I expected that each bisect would > lead > > > to a different kernel. > > > Assuming that the opposite can happen, does it mean that when I > say > > > i.e. "git bisect bad", then build a new kernel and see that is > > > identical to the previous one I can run "git bisect bad" without > > > booting into the new one and even making the test? > > > > > > Another thing I don't understand is that I told 4.20.0 to be > good, so > > > I would expect that I don't need to test any older version, but > as far > > > as I know 4.19.0-rc5+ is older than 4.20.0, so why is it > involved in > > > the bisection? > > > > > > I had to "git bisect skip" one time (the kernel did not boot), > but as > > > far as I know I don't think this could be related to my doubts. > > > [...] > > > > Update: > > I have concluded the bisection, found that > > "9cb5f4873b993497d462b9406f9a1d8a148e461b is the first bad > commit", > > reverted it, and the test still fails (btw, the final kernel file, > > /boot/vmlinuz-4.19.0-rc5+, does not differ from the previous one). > > > > So, all my doubts above are still there (and growing). What I am > doing wrong? > > Are you _SURE_ that a 4.20.0 release actually worked properly for > you? > Did you build one and do your tests? Or are you just relying on > your > Fedora build still? Yes, I am really sure of that, and the definitive proof is that since I stopped bisecting I made the 4.20.0 the default boot kernel, and all my backups are done "quickly" (12min to create a 12GB archive). Furthermore, "uname -a" shows Linux 4.20.0 #1 SMP Thu Jun 6 22:32:29 CEST 2019 x86_64 x86_64 x86_64 GNU/Linux To have one more evidence, I started the test while writing down this sentence, and it has just finished in one minute and a half (1 GB file copy). I will go on following your other suggestions; by the time, thank you for pointing this out, Andrea
