<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body><div><br></div><div><br></div><div><br></div><div><br></div><div id="composer_signature"><div style="font-size:85%;color:#575757" dir="auto">Sent from my Verizon, Samsung Galaxy smartphone</div></div><div><br></div><div style="font-size:100%;color:#000000"><!-- originalMessage --><div>-------- Original message --------</div><div>From: Eshak <tmdeshak@gmail.com> </div><div>Date: 2/7/18  9:34 PM  (GMT-05:00) </div><div>To: "Discussion list for crash utility usage,     maintenance and development" <crash-utility@redhat.com> </div><div>Subject: Re: [Crash-utility] linux_banner has garbage </div><div><br></div></div><div dir="ltr">Hi Dave,<div><br></div><div>In a test system I have booted the kernel with 'nokaslr' option. While trying to check phys_base and KASLR:<br>




<span></span>





<p class="gmail-p1" style="margin:0px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:15px;line-height:normal;font-family:"Courier New";color:rgb(255,255,255);background-color:rgb(0,0,0)"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures">crash> help -m |grep phys_base</span></p>
<p class="gmail-p1" style="margin:0px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:15px;line-height:normal;font-family:"Courier New";color:rgb(255,255,255);background-color:rgb(0,0,0)"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures"><span class="gmail-Apple-converted-space">                </span>phys_base: 0</span></p>
<p class="gmail-p1" style="margin:0px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:15px;line-height:normal;font-family:"Courier New";color:rgb(255,255,255);background-color:rgb(0,0,0)"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures"><span class="gmail-Apple-converted-space">     </span>text hit rate: 66% (5171 of 7801)</span></p>
<p class="gmail-p1" style="margin:0px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:15px;line-height:normal;font-family:"Courier New";color:rgb(255,255,255);background-color:rgb(0,0,0)"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures">crash> help -k | grep relocate</span></p>
<p class="gmail-p1" style="margin:0px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:15px;line-height:normal;font-family:"Courier New";color:rgb(255,255,255);background-color:rgb(0,0,0)"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures"><span class="gmail-Apple-converted-space">      </span>relocate: 0<span class="gmail-Apple-converted-space">  </span>(KASLR offset: 0 / 0MB)</span></p>
<p class="gmail-p1" style="margin:0px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:15px;line-height:normal;font-family:"Courier New";color:rgb(255,255,255);background-color:rgb(0,0,0)"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures"><span class="gmail-Apple-converted-space">     </span>text hit rate: 66% (5171 of 7801)</span></p>
<p class="gmail-p1" style="margin:0px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:15px;line-height:normal;font-family:"Courier New";color:rgb(255,255,255);background-color:rgb(0,0,0)"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures">crash><span class="gmail-Apple-converted-space"> </span></span></p>


<br></div><div>I'm not sure if phys_base can be 0.</div><div><br></div><div>Question: Are these values fine in order to read memory images by specifying --phys_base=0 after booting main machine with 'nokaslr' option ?</div><div><br></div><div>Yes, but since phys_base defaults to 0,</div><div> the --machdep argument wouldn't be necessary.</div><div><br></div><div>Dave</div><div><br></div><div><br></div><div><br></div><div>Thank you,</div><div>Eshak</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 7, 2018 at 10:49 AM, Dave Anderson <span dir="ltr"><<a href="mailto:anderson@redhat.com" target="_blank">anderson@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
----- Original Message -----<br>
> Hi Dave,<br>
><br>
> Thanks for the info.<br>
> I've installed 7.2.0-1.fc28 and was able to run crash on live system.<br>
><br>
> Unfortunately, KASLR is enabled.<br>
<br>
</span>Yes, I'm afraid that is unfortunate.  I don't know how you can determine<br>
what the KASLR offset is, and without that, the dumpfile is pretty<br>
much useless.<br>
<br>
The best thing you can do is to prepare for the *next* crash by stashing<br>
the phys_offset and KASLR offset values.  You also can boot the kernel with<br>
"nokaslr" on the boot command line.<br>
<span class="HOEnZb"><font color="#888888"><br>
Dave<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
><br>
><br>
> text hit rate: 66% (5171 of 7801)<br>
><br>
> help -m |grep phys_base<br>
><br>
> phys_base: 10d000000<br>
><br>
> text hit rate: 66% (5171 of 7801)<br>
><br>
> help -k | grep relocate<br>
><br>
> relocate: ffffffffe1000000 (KASLR offset: 1f000000 / 496MB)<br>
><br>
> text hit rate: 66% (5171 of 7801)<br>
> Is there any other info I can get from the vmem/vmss file like processes<br>
> running at the time or task blocked on I/O or anything ?<br>
><br>
> Thank you,<br>
> Eshak<br>
><br>
> On Wed, Feb 7, 2018 at 6:28 AM, Dave Anderson < <a href="mailto:anderson@redhat.com">anderson@redhat.com</a> > wrote:<br>
><br>
><br>
><br>
><br>
> ----- Original Message -----<br>
> > That's fixed upstream. You'll have to download the crash sources from<br>
> > github<br>
> > and build the latest and greatest.<br>
><br>
> It's possible that you might be able to run the Fedora 28 rawhide version<br>
> here:<br>
><br>
> Information for build crash-7.2.0-1.fc28<br>
> <a href="https://koji.fedoraproject.org/koji/buildinfo?buildID=978501" rel="noreferrer" target="_blank">https://koji.fedoraproject.<wbr>org/koji/buildinfo?buildID=<wbr>978501</a><br>
><br>
> That version has the fix for the init_level4_pgt issue. I'm not sure<br>
> whether you may run into anything else.<br>
><br>
> Dave<br>
><br>
><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > Sent from my Verizon, Samsung Galaxy smartphone<br>
> ><br>
> > -------- Original message --------<br>
> > From: Eshak < <a href="mailto:tmdeshak@gmail.com">tmdeshak@gmail.com</a> ><br>
> > Date: 2/6/18 9:27 PM (GMT-05:00)<br>
> > To: "Discussion list for crash utility usage, maintenance and development"<br>
> > < <a href="mailto:crash-utility@redhat.com">crash-utility@redhat.com</a> ><br>
> > Subject: Re: [Crash-utility] linux_banner has garbage<br>
> ><br>
> > Hi Dave,<br>
> ><br>
> > I have /proc/kcore. But I'm getting 'cannot resolve 'init_level4_pgt'<br>
> > error.<br>
> ><br>
> ><br>
> ><br>
> > [root@gt-Server2-gmt proc]# crash<br>
> > /home/mfusion/vmem_vmss_jan26/<wbr>usr/lib/debug/usr/lib/modules/<wbr>4.14.11-coreos/vmlinux<br>
> > /proc/kcore<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > crash 7.1.9-3.fc27<br>
> ><br>
> > Copyright (C) 2002-2016 Red Hat, Inc.<br>
> ><br>
> > Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation<br>
> ><br>
> > Copyright (C) 1999-2006 Hewlett-Packard Co<br>
> ><br>
> > Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited<br>
> ><br>
> > Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.<br>
> ><br>
> > Copyright (C) 2005, 2011 NEC Corporation<br>
> ><br>
> > Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.<br>
> ><br>
> > Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.<br>
> ><br>
> > This program is free software, covered by the GNU General Public License,<br>
> ><br>
> > and you are welcome to change it and/or distribute copies of it under<br>
> ><br>
> > certain conditions. Enter "help copying" to see the conditions.<br>
> ><br>
> > This program has absolutely no warranty. Enter "help warranty" for details.<br>
> ><br>
> ><br>
> ><br>
> > crash: /dev/tty: No such device or address<br>
> ><br>
> > NOTE: stdin: not a tty<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > GNU gdb (GDB) 7.6<br>
> ><br>
> > Copyright (C) 2013 Free Software Foundation, Inc.<br>
> ><br>
> > License GPLv3+: GNU GPL version 3 or later <<br>
> > <a href="http://gnu.org/licenses/gpl.html" rel="noreferrer" target="_blank">http://gnu.org/licenses/gpl.<wbr>html</a><br>
> > ><br>
> ><br>
> > This is free software: you are free to change and redistribute it.<br>
> ><br>
> > There is NO WARRANTY, to the extent permitted by law. Type "show copying"<br>
> ><br>
> > and "show warranty" for details.<br>
> ><br>
> > This GDB was configured as "x86_64-unknown-linux-gnu"...<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > WARNING: kernel relocated [496MB]: patching 69420 gdb minimal_symbol values<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > crash: cannot resolve "init_level4_pgt"<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > [root@gt-Server2-gmt proc]#<br>
> > But I believe this is fixed in crash 7.2. I have raised one issue against<br>
> > CoreOS to make crash 7.2 to be available in toolbox packages(<br>
> > <a href="https://github.com/coreos/bugs/issues/2347" rel="noreferrer" target="_blank">https://github.com/coreos/<wbr>bugs/issues/2347</a> ).<br>
> ><br>
> > Meanwhile, Is there any workaround for this ?<br>
> ><br>
> > -Eshak<br>
> ><br>
> > On Tue, Feb 6, 2018 at 6:02 PM, anderson < <a href="mailto:anderson@prospeed.net">anderson@prospeed.net</a> > wrote:<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > To run live, you need either /dev/mem, /proc/kcore, or the /dev/crash<br>
> > driver.<br>
> > You could try "crash vmlinux /proc/kcore" to see if it's available. If not,<br>
> > you could try building the /dev/crash driver module. But I don't know if<br>
> > CoreOS offers a kernel-devel package that you could build the driver<br>
> > against? The driver source comes with the crash source package in the<br>
> > memory_driver subdirectory.<br>
> ><br>
> > Dave<br>
> ><br>
> ><br>
> > Sent from my Verizon, Samsung Galaxy smartphone<br>
> ><br>
> > -------- Original message --------<br>
> > From: Eshak < <a href="mailto:tmdeshak@gmail.com">tmdeshak@gmail.com</a> ><br>
> > Date: 2/6/18 8:35 PM (GMT-05:00)<br>
> > To: "Discussion list for crash utility usage, maintenance and development"<br>
> > <<br>
> > <a href="mailto:crash-utility@redhat.com">crash-utility@redhat.com</a> ><br>
> > Cc: hfu < <a href="mailto:hfu@vmware.com">hfu@vmware.com</a> ><br>
> > Subject: Re: [Crash-utility] linux_banner has garbage<br>
> ><br>
> > Hi Dave,<br>
> ><br>
> > When trying to run crash live, I'm getting an error saying that /dev/mem is<br>
> > not available.<br>
> > I'm running crash from toolbox in a CoreOS VM. Is crash designed to run<br>
> > from<br>
> > a container ?<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > [root@gt-Server2-gmt ~]# crash -d8<br>
> > /home/user/vmem_vmss_jan26/<wbr>usr/lib/debug/usr/lib/modules/<wbr>4.14.11-coreos/vmlinux<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > crash 7.1.9-3.fc27<br>
> ><br>
> > Copyright (C) 2002-2016 Red Hat, Inc.<br>
> ><br>
> > Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation<br>
> ><br>
> > Copyright (C) 1999-2006 Hewlett-Packard Co<br>
> ><br>
> > Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited<br>
> ><br>
> > Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.<br>
> ><br>
> > Copyright (C) 2005, 2011 NEC Corporation<br>
> ><br>
> > Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.<br>
> ><br>
> > Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.<br>
> ><br>
> > This program is free software, covered by the GNU General Public License,<br>
> ><br>
> > and you are welcome to change it and/or distribute copies of it under<br>
> ><br>
> > certain conditions. Enter "help copying" to see the conditions.<br>
> ><br>
> > This program has absolutely no warranty. Enter "help warranty" for details.<br>
> ><br>
> ><br>
> ><br>
> > get_live_memory_source: /dev/mem<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > crash: /dev/mem: No such file or directory<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > [root@gt-Server2-gmt ~]#<br>
> ><br>
> > Thank you,<br>
> > Eshak<br>
> ><br>
> > On Tue, Feb 6, 2018 at 3:05 PM, Eshak < <a href="mailto:tmdeshak@gmail.com">tmdeshak@gmail.com</a> > wrote:<br>
> ><br>
> ><br>
> ><br>
> > Thanks for the info Dave.<br>
> > Unfortunately, I cannot run crash live on the machine because the VM is in<br>
> > hung state right now. After resetting the VM(by tomorrow), will check for<br>
> > KASLR and phys_base and try the suggested option.<br>
> ><br>
> > The complete output of crash is below:<br>
> ><br>
> ><br>
> > [root@gt-Server2-gmt user]# crash -d8<br>
> > /home/mfusion/vmem_vmss_jan26/<wbr>usr/lib/debug/usr/lib/modules/<wbr>4.14.11-coreos/vmlinux<br>
> > /home/mfusion/vmem_vmss_jan26/<wbr>usr/lib/modules/4.14.11-<wbr>coreos/build/System.map<br>
> > /home/mfusion/vmem_vmss_jan26/<wbr>gt-Server2-gmt-612746ca.vmss<br>
> ><br>
> > crash 7.1.9-3.fc27<br>
> > Copyright (C) 2002-2016 Red Hat, Inc.<br>
> > Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation<br>
> > Copyright (C) 1999-2006 Hewlett-Packard Co<br>
> > Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited<br>
> > Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.<br>
> > Copyright (C) 2005, 2011 NEC Corporation<br>
> > Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.<br>
> > Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.<br>
> > This program is free software, covered by the GNU General Public License,<br>
> > and you are welcome to change it and/or distribute copies of it under<br>
> > certain conditions. Enter "help copying" to see the conditions.<br>
> > This program has absolutely no warranty. Enter "help warranty" for details.<br>
> ><br>
> > crash: diskdump / compressed kdump: dump does not have panic dump header<br>
> > crash: sadump: read dump device as media format<br>
> > crash: sadump: does not have partition header<br>
> > vmw: Header: id=bed2bed2 version=8 numgroups=95<br>
> > vmw: Checkpoint is 64-bit<br>
> > vmw: Group: Checkpoint offset=0x1dbc size=0x0x3ab.<br>
> > vmw: Group: GuestVars offset=0x2167 size=0x0xa3.<br>
> > vmw: Group: cpuid offset=0x220a size=0x0x5e0e.<br>
> > vmw: Group: cpu offset=0x8018 size=0x0x615bb.<br>
> > vmw: Group: BusMemSample offset=0x695d3 size=0x0x1c.<br>
> > vmw: Group: UUIDVMX offset=0x695ef size=0x0x2e.<br>
> > vmw: Group: StateLogger offset=0x6961d size=0x0x2.<br>
> > vmw: Group: memory offset=0x6961f size=0x0xa8.<br>
> > vmw: Item align_mask[0][0] => position=0x69633 size=0x4: 0000FFFF<br>
> > vmw: Item regionsCount => position=0x69645 size=0x4: 00000002<br>
> > vmw: Item regionPageNum[0] => position=0x6965c size=0x4: 00000000<br>
> > vmw: Item regionPPN[0] => position=0x6966f size=0x4: 00000000<br>
> > vmw: Item regionSize[0] => position=0x69683 size=0x4: 000C0000<br>
> > vmw: Item regionPageNum[1] => position=0x6969a size=0x4: 000C0000<br>
> > vmw: Item regionPPN[1] => position=0x696ad size=0x4: 00100000<br>
> > vmw: Item regionSize[1] => position=0x696c1 size=0x4: 00E40000<br>
> > vmw: Group: MStats offset=0x696c7 size=0x0x1936.<br>
> > vmw: Group: Snapshot offset=0x6affd size=0x0x4b9c.<br>
> > vmw: Group: pic offset=0x6fb99 size=0x0x511.<br>
> > vmw: Group: FTCpt offset=0x700aa size=0x0x2.<br>
> > vmw: Group: ide1:0 offset=0x700ac size=0x0x16e.<br>
> > vmw: Group: scsi0:0 offset=0x7021a size=0x0x46.<br>
> > vmw: Group: Migrate offset=0x70260 size=0x0x2.<br>
> > vmw: Group: TimeTracker offset=0x70262 size=0x0x99.<br>
> > vmw: Group: Backdoor offset=0x702fb size=0x0x2e.<br>
> > vmw: Group: PCI offset=0x70329 size=0x0x13.<br>
> > vmw: Group: Cs440bx offset=0x7033c size=0x0x40539.<br>
> > vmw: Group: ExtCfgDevice offset=0xb0875 size=0x0x30.<br>
> > vmw: Group: Floppy offset=0xb08a5 size=0x0x918c.<br>
> > vmw: Group: AcpiNotify offset=0xb9a31 size=0x0x1b.<br>
> > vmw: Group: vcpuHotPlug offset=0xb9a4c size=0x0xf5.<br>
> > vmw: Group: devHP offset=0xb9b41 size=0x0x86.<br>
> > vmw: Group: ACPIWake offset=0xb9bc7 size=0x0x1b.<br>
> > vmw: Group: DevicesPowerOn offset=0xb9be2 size=0x0x2.<br>
> > vmw: Group: PCIBridge0 offset=0xb9be4 size=0x0x272.<br>
> > vmw: Group: PCIBridge4 offset=0xb9e56 size=0x0x48e.<br>
> > vmw: Group: pciBridge4:1 offset=0xba2e4 size=0x0x48e.<br>
> > vmw: Group: pciBridge4:2 offset=0xba772 size=0x0x48e.<br>
> > vmw: Group: pciBridge4:3 offset=0xbac00 size=0x0x48e.<br>
> > vmw: Group: pciBridge4:4 offset=0xbb08e size=0x0x48e.<br>
> > vmw: Group: pciBridge4:5 offset=0xbb51c size=0x0x48e.<br>
> > vmw: Group: pciBridge4:6 offset=0xbb9aa size=0x0x48e.<br>
> > vmw: Group: pciBridge4:7 offset=0xbbe38 size=0x0x48e.<br>
> > vmw: Group: PCIBridge5 offset=0xbc2c6 size=0x0x48e.<br>
> > vmw: Group: pciBridge5:1 offset=0xbc754 size=0x0x48e.<br>
> > vmw: Group: pciBridge5:2 offset=0xbcbe2 size=0x0x48e.<br>
> > vmw: Group: pciBridge5:3 offset=0xbd070 size=0x0x48e.<br>
> > vmw: Group: pciBridge5:4 offset=0xbd4fe size=0x0x48e.<br>
> > vmw: Group: pciBridge5:5 offset=0xbd98c size=0x0x48e.<br>
> > vmw: Group: pciBridge5:6 offset=0xbde1a size=0x0x48e.<br>
> > vmw: Group: pciBridge5:7 offset=0xbe2a8 size=0x0x48e.<br>
> > vmw: Group: PCIBridge6 offset=0xbe736 size=0x0x48e.<br>
> > vmw: Group: pciBridge6:1 offset=0xbebc4 size=0x0x48e.<br>
> > vmw: Group: pciBridge6:2 offset=0xbf052 size=0x0x48e.<br>
> > vmw: Group: pciBridge6:3 offset=0xbf4e0 size=0x0x48e.<br>
> > vmw: Group: pciBridge6:4 offset=0xbf96e size=0x0x48e.<br>
> > vmw: Group: pciBridge6:5 offset=0xbfdfc size=0x0x48e.<br>
> > vmw: Group: pciBridge6:6 offset=0xc028a size=0x0x48e.<br>
> > vmw: Group: pciBridge6:7 offset=0xc0718 size=0x0x48e.<br>
> > vmw: Group: PCIBridge7 offset=0xc0ba6 size=0x0x48e.<br>
&</div></div></blockquote></div></div></body></html>