On Tue, Jun 25, 2019 at 02:07:42PM +0200, Dmitry Vyukov wrote: > On Tue, Jun 25, 2019 at 1:06 PM Peter Zijlstra <pet...@infradead.org> wrote: > > > > On Tue, Jun 25, 2019 at 01:03:01PM +0200, Peter Zijlstra wrote: > > > On Tue, Jun 25, 2019 at 08:20:56AM +0200, Thomas Gleixner wrote: > > > > On Mon, 24 Jun 2019, syzbot wrote: > > > > > > > > syzbot found the following crash on: > > > > > > > > > > HEAD commit: dc636f5d Add linux-next specific files for 20190620 > > > > > git tree: linux-next > > > > > console output: > > > > > https://syzkaller.appspot.com/x/log.txt?x=162b68b1a00000 > > > > syzcaller folks; why doesn't the above link include the actual kernel > > boot, but only the userspace bits starting at syzcaller start? > > > > I was trying to figure out the setup, but there's not enough information > > here. > > Hi Peter, > > Usually there is too much after-boot output, so boot output is evicted > anyway even if was preserved initially. Also usually it's not > important (this is the first time this comes up). And also > structurally boot is a separate procedure in syzkaller VM abstraction, > a machine is booted, output is analyzed for potential crashes, then > the machine is considered in a known good state and then some workload > is started as a separate procedure and new output capturing starts > from this point again.
Ah, for my own machines I spool all serial console output to a file, everything is preserved until logrotate kills it after a week or so. There is no distinction between boot and anything else, everything that goes to serial (and I make sure everything does) lands together. > What info are you interested in? Can if be obtained after boot? I was interested in the kernel commandline; and in particular the nohz_full configuration if any.