How to understand the disassemble code output from gdb - crash

Look at the following output from gdb, why does the instruction code is disordered?
It shows:
0xffffffff81107714 <+7>: mov %rdi,%rbx
then shows
0xffffffff8110770f <+2>: cmpq $0x0,0x10(%rdi)
.
(gdb) disassemble /m __d_rehash
Dump of assembler code for function __d_rehash:
1997 {
0xffffffff8110770d <+0>: push %rbp
0xffffffff8110770e <+1>: push %rbx
0xffffffff81107714 <+7>: mov %rdi,%rbx
1998 BUG_ON(!d_unhashed(entry));
0xffffffff8110770f <+2>: cmpq $0x0,0x10(%rdi)
0xffffffff81107717 <+10>: je 0xffffffff8110771b <__d_rehash+14>
0xffffffff81107719 <+12>: ud2
1999 hlist_bl_lock(b);
2000 entry->d_flags |= DCACHE_RCUACCESS;
0xffffffff81107726 <+25>: orl $0x80,(%rbx)
2001 hlist_bl_add_head_rcu(&entry->d_hash, b);
0xffffffff8110772c <+31>: lea 0x8(%rbx),%rdx
2002 hlist_bl_unlock(b);
2003 }
0xffffffff81107756 <+73>: pop %rbx
0xffffffff81107757 <+74>: pop %rbp
0xffffffff81107758 <+75>: retq
The following output by kernel oops shows that __d_rehash+0x19/0x4c is the parent call of crash. But I can't find the exact source responding to __d_rehash+0x19 from above disassemble output.
[ 2630.421613] RIP: 0010:[<ffffffff8110739c>] [<ffffffff8110739c>] bit_spin_lock.constprop.17+0xb/0x1f
[ 2630.421618] RSP: 0018:ffff8800b4a83c00 EFLAGS: 00000202
[ 2630.421619] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000013
[ 2630.421620] RDX: ffffc90000000000 RSI: ffffc900003b6130 RDI: ffffc900003b6130
[ 2630.421621] RBP: ffffc900003b6130 R08: ffff8800b4a83c70 R09: ffff8800bc286880
[ 2630.421622] R10: 0000000000000000 R11: ffff8800bc283940 R12: ffff8800bc283940
[ 2630.421623] R13: ffffc900003b6130 R14: 0000000000000000 R15: 0000000000000000
[ 2630.421625] FS: 00007fd5c5c2f7a0(0000) GS:ffff8800bfd80000(0000) knlGS:0000000000000000
[ 2630.421626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2630.421627] CR2: 000000000042ba30 CR3: 00000000ad201000 CR4: 00000000000406e0
[ 2630.421631] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2630.421632] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 2630.421633] Process dpkg (pid: 9941, threadinfo ffff8800b4a82000, task ffff880030871000)
[ 2630.421634] Stack:
[ 2630.421635] ffff88002f20b600 ffffffff81107726 ffff88002f20b600 ffff88002f20b600
[ 2630.421637] ffffffff8110848b 0000000000000000 ffffffff81108fef 000000000000000c
[ 2630.421639] ffff8800bc283940 ffff88002f20b600 ffff8800b4a83d68 ffff8800bc11bb40
[ 2630.421641] Call Trace:
[ 2630.421644] [<ffffffff81107726>] ? __d_rehash+0x19/0x4c
[ 2630.421646] [<ffffffff8110848b>] ? d_rehash+0x24/0x2a
[ 2630.421648] [<ffffffff81108fef>] ? d_splice_alias+0xb2/0xbd
[ 2630.421655] [<ffffffffa016a121>] ? ext4_lookup+0xc5/0xd2 [ext4]
[ 2630.421658] [<ffffffff8110013a>] ? d_alloc_and_lookup+0x33/0x62
[ 2630.421661] [<ffffffff81100996>] ? walk_component+0x1e7/0x3a0
[ 2630.421663] [<ffffffff81101a29>] ? path_lookupat+0x8b/0x2ac
[ 2630.421666] [<ffffffff8103a683>] ? should_resched+0x5/0x23
[ 2630.421669] [<ffffffff813453b9>] ? _cond_resched+0x7/0x1c
[ 2630.421671] [<ffffffff81101c66>] ? do_path_lookup+0x1c/0x81
[ 2630.421673] [<ffffffff8110346a>] ? user_path_at_empty+0x48/0x7d
[ 2630.421675] [<ffffffff810fb89e>] ? cp_new_stat+0xf0/0x104
[ 2630.421677] [<ffffffff810fb675>] ? vfs_fstatat+0x2d/0x63
[ 2630.421678] [<ffffffff810fb949>] ? sys_newstat+0x12/0x2d
[ 2630.421681] [<ffffffff8134b792>] ? system_call_fastpath+0x16/0x1b

__d_rehash+0x19 is hex, 25 decimal, which corresponds to
2000 entry->d_flags |= DCACHE_RCUACCESS;
0xffffffff81107726 <+25>: orl $0x80,(%rbx)
This is not "parent call" but return address, presumably from a call "hidden" in
1999 hlist_bl_lock(b);
The code is "reordered" because the compiler is free to generate it however it sees fit as long as the resulting semantics are the same and it figured it is beneficial to shuffle things up. Then as you can see gdb figured it will show it in a displaced manner.
A significantly better linux kernel debugger is "crash". It will happen to show all the assembly in order and annotate all blocks with file:line marks if you do 'dis -l'.

Related

Understanding ELF TBSS and TDATA section loading

My elf file's sections are as follows
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .text PROGBITS fffffffff7e020b0 000000b0
0000000000074f50 0000000000000000 AX 0 0 16
[ 2] .rodata PROGBITS fffffffff7e77000 00075000
0000000000014000 0000000000000000 AM 0 0 16
[ 3] .eh_frame_hdr PROGBITS fffffffff7e8b000 00089000
000000000000000c 0000000000000000 A 0 0 4
[ 4] .data PROGBITS fffffffff7e8b010 00089010
0000000000001ff0 0000000000000000 WA 0 0 16
[ 5] .bss NOBITS fffffffff7e8d000 0008b000
0000000000014000 0000000000000000 WA 0 0 4096
[ 6] .got PROGBITS fffffffff7ea1000 0009f000
0000000000001000 0000000000000000 WA 0 0 8
[ 7] .tdata PROGBITS fffffffff7ea2000 000a0000
000000000000b000 0000000000000000 WAT 0 0 8
[ 8] .tbss NOBITS fffffffff7ead000 000ab000
000000000000012a 0000000000000000 WAT 0 0 8
[ 9] .debug_abbrev PROGBITS 0000000000000000 000ab000
000000000001a8d4 0000000000000000 0 0 1
[10] .debug_info PROGBITS 0000000000000000 000c58d4
000000000016c624 0000000000000000 0 0 1
[11] .debug_aranges PROGBITS 0000000000000000 00231ef8
0000000000024130 0000000000000000 0 0 1
[12] .debug_ranges PROGBITS 0000000000000000 00256028
000000000004bfa0 0000000000000000 0 0 1
[13] .debug_str PROGBITS 0000000000000000 002a1fc8
0000000000123ecd 0000000000000001 MS 0 0 1
[14] .debug_pubnames PROGBITS 0000000000000000 003c5e95
000000000005da3c 0000000000000000 0 0 1
[15] .debug_pubtypes PROGBITS 0000000000000000 004238d1
00000000000a1e07 0000000000000000 0 0 1
[16] .debug_frame PROGBITS 0000000000000000 004c56d8
0000000000056c10 0000000000000000 0 0 8
[17] .debug_line PROGBITS 0000000000000000 0051c2e8
00000000000b5c55 0000000000000000 0 0 1
[18] .debug_loc PROGBITS 0000000000000000 005d1f3d
000000000000628c 0000000000000000 0 0 1
[19] .symtab SYMTAB 0000000000000000 005d81d0
0000000000015a20 0000000000000018 21 2565 8
[20] .shstrtab STRTAB 0000000000000000 005edbf0
00000000000000da 0000000000000000 0 0 1
[21] .strtab STRTAB 0000000000000000 005edcca
000000000004783e 0000000000000000 0 0 1
and the program headers are
Elf file type is EXEC (Executable file)
Entry point 0xfffffffff7e39be0
There are 2 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0xfffffffff7e02000 0x0000000000000000
0x00000000000ab000 0x00000000000ab12a RWE 0x1000
TLS 0x00000000000a0000 0xfffffffff7ea2000 0x00000000000a0000
0x000000000000b000 0x000000000000b12a RW 0x8
Section to Segment mapping:
Segment Sections...
00 .text .rodata .eh_frame_hdr .data .bss .got .tdata
01 .tdata .tbss
The TLS section's total size is as expected being the size of tdata + tbss sections.
From the TLS handling document, i expect that tdata and tbss sections will be right before the fs register's pointed value and thus the total size would be 0xb12a.
But one of the variables which use thread_local have an offset of fs - 0xb130 which is outside of the expected TLS size.
I am trying to understand why the variable is not offset to at-most 0xb12a but more than that?
Although the size of TLS here is 0xb12a. The alignment of 0x8 will make the TLS pointer move to 0xb130 which is the address of variable observed here.

ELF program segments offset in file

I have a question,about elf program segments offsize in file. For example , a program readelf -f xx -W like this:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000040 0x0000000000400040 0x0000000000400040 0x0001f8 0x0001f8 R E 0x8
INTERP 0x000238 0x0000000000400238 0x0000000000400238 0x00001c 0x00001c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x000000 0x0000000000400000 0x0000000000400000 0x4ca8e6 0x4ca8e6 R E 0x200000
LOAD 0x4cb000 0x0000000000acb000 0x0000000000acb000 0x035db8 0x04ed80 RW 0x200000
DYNAMIC 0x4ed4c8 0x0000000000aed4c8 0x0000000000aed4c8 0x000230 0x000230 RW 0x8
NOTE 0x000254 0x0000000000400254 0x0000000000400254 0x000044 0x000044 R 0x4
TLS 0x4cb000 0x0000000000acb000 0x0000000000acb000 0x000010 0x000018 R 0x10
GNU_EH_FRAME 0x3dcf04 0x00000000007dcf04 0x00000000007dcf04 0x024c64 0x024c64 R 0x4
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame .gcc_except_table
03 .tdata .init_array .fini_array .jcr .data.rel.ro .dynamic .got .got.plt .data .bss
04 .dynamic
05 .note.ABI-tag .note.gnu.build-id
06 .tdata .tbss
07 .eh_frame_hdr
08
The first load begin at offset 0x000000 and the size is 0x4ca8e6. why the second offset not (0x000000 + 0x4ca8e6), I see the (0x4cb000 - 0x4ca8e6) content, all 0. I can't get it. What the rule about the offset in file?
The first load begin at offset 0x000000 and the size is 0x4ca8e6. why the second offset not (0x000000 + 0x4ca8e6)
Because the loader mmaps LOAD segments directly into memory, for each LOAD segment the following must be true: (p_vaddr - p_offset) % page_size == 0.
On x86_64 the maximum page size is 2MiB (0x200000). This places severe restriction on the second (and subsequent) LOAD segment location.

What is the format of special section in ELF

I try to write a program to generate ELF(based on Arm and execute through qemu-arm). Most format in ELF has been well illustrated
on wiki. But I can't find any spec describe the format of special section(e.g. .text .data(especially what I want to know)).
I tried to put some initialized global variable in .data section. What format should I write in ELF(.data section) if I have global statement like: int a = 10;
There is not special format for .text and .data.
When the static linker links several .o file,
it simply concatenates the .text and .data segments (while resolving relocations)
and places them in the final .so or executable file according to the linker script (see gcc -Wl,-verbose /dev/null).
The .data segment simply contains the initial values of the instanciated global variables.
The .text segment simply contains the machine code of the routines/functions.
Let's take this simple C file:
char x[5] = {0xba, 0xbb, 0xbc, 0xbd, 0xbe};
char f(int i) {
return x[i];
}
Let's compile it:
$ gcc -c -o test.o test.c
Let's dump the .data section, using elfcat:
$ elfcat test.o --section-name .data | xxd
00000000: babb bcbd be .....
We can clearly explain the content of .data section.
Let's dump the .text section:
$ elfcat test.o --section-name .text | xxd
00000000: 5548 89e5 897d fc8b 45fc 4898 488d 1500 UH...}..E.H.H...
00000010: 0000 000f b604 105d c3
Let's decompile this:
$ elfcat test.o --section-name .text > test.text
$ r2 -a x86 -b 64 -qc pd test.text
0x00000000 55 push rbp
0x00000001 4889e5 mov rbp, rsp
0x00000004 897dfc mov dword [rbp - 4], edi
0x00000007 8b45fc mov eax, dword [rbp - 4]
0x0000000a 4898 cdqe
0x0000000c 488d15000000. lea rdx, qword [0x00000013] ; 19
0x00000013 0fb60410 movzx eax, byte [rax + rdx]
0x00000017 5d pop rbp
0x00000018 c3 ret
Again, there is nothing special in the text segment: it only contains the machine code of the routines/functions of my program.
Notice however the relocation and symbol informations in other segments:
$ readelf -a test.o
[ ... ]
Relocation section '.rela.text' at offset 0x1b8 contains 1 entry:
Offset Info Type Sym. Value Sym. Name + Addend
00000000000f 000800000002 R_X86_64_PC32 0000000000000000 x - 4
Relocation section '.rela.eh_frame' at offset 0x1d0 contains 1 entry:
Offset Info Type Sym. Value Sym. Name + Addend
000000000020 000200000002 R_X86_64_PC32 0000000000000000 .text + 0
[...]
Symbol table '.symtab' contains 10 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS test.c
2: 0000000000000000 0 SECTION LOCAL DEFAULT 1
3: 0000000000000000 0 SECTION LOCAL DEFAULT 3
4: 0000000000000000 0 SECTION LOCAL DEFAULT 4
5: 0000000000000000 0 SECTION LOCAL DEFAULT 6
6: 0000000000000000 0 SECTION LOCAL DEFAULT 7
7: 0000000000000000 0 SECTION LOCAL DEFAULT 5
8: 0000000000000000 5 OBJECT GLOBAL DEFAULT 3 x
9: 0000000000000000 25 FUNC GLOBAL DEFAULT 1 f

Segmentation fault while trying to boot after adding a device driver

I'm trying to compile and install linux 4.20.17 after adding my own kernel module (a simple multiplier module) source files. I am successfully able to compile and install linux-4.20.17 with the source files. The problem occurs when i try to boot up the system. I get a segmentation fault when my multiplier module is getting inserted.
When i try to insert the module on my own using insmod everything works fine. I can even create a device file, read and write to it.
This is my module_init() function.
int my_init(void)
{
valueToBeWritten = (int *)kmalloc(INT_BUF_LEN*sizeof(int), GFP_KERNEL);
msg_bf_Ptr = (char *)valueToBeWritten; //msg_bf_Ptr is in kernel space
if (msg_bf_Ptr == NULL) {
/* Failed to get memory, exit gracefully */
printk(KERN_ALERT "Unable to allocate needed memory\n");
return 10; /* Defining error code of 10 for
"Unable to allocate memory" */
}
Major = register_chrdev(0, DEVICE_NAME, &fops);
/* Negative values indicate a problem */
if (Major < 0) {
printk(KERN_ALERT "Registering char device failed with %d\n", Major);
kfree(valueToBeWritten);
printk(KERN_INFO "Mapping virtual address...\n");
printk("Physical address: %x; Virtual address: %x\n.", (unsigned int)virt_addr, (unsigned int)PHY_ADDR);
return Major;
}
sprintf(msg_bf_Ptr, "This device has not been written to yet\n");
cur_Ptr = msg_bf_Ptr;
printk(KERN_INFO "Registered a device with dynamic Major number of %d\n", Major);
printk(KERN_INFO "Create a device file for this device with this command:\n'mknod /dev/%s c %d 0'.\n", DEVICE_NAME, Major);
return 0; /* success */
}
I read that "modules cannot reserve resources during boot time". Is that what's causing the problem? Is the kmalloc statement causing the segmentation fault?
EDIT: I booted in through recovery mode and tried to look at the full error trace. But I couldn't find the segmentation fault. But here is the call trace where the multiplier module gets loaded.
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918412] Call Trace:
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918431] apparmor_sk_alloc_security+0x49/0x70
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918438] security_sk_alloc+0x37/0x50
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918449] sk_prot_alloc+0x58/0x130
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918453] sk_alloc+0x31/0x240
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918459] unix_create1+0x68/0x1e0
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918464] unix_stream_connect+0x97/0x4b0
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918469] __sys_connect+0xa3/0x120
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918476] __x64_sys_connect+0x1a/0x20
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918481] do_syscall_64+0x5a/0x120
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918487] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918491] RIP: 0033:0x7f32457968e7
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918494] Code: c3 66 90 41 54 55 41 89 d4 53 48 89 f5 89 fb 48 83 ec 10 e8 0b de 00 00 44 89 e2 41 89 c0 48 89 ee 89 df b8 2a 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 89 44 24 0c e8 45 de 00 00 8b 44
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918497] RSP: 002b:00007f32382fb6f0 EFLAGS: 00000293 ORIG_RAX: 000000000000002a
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918500] RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007f32457968e7
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918502] RDX: 000000000000006e RSI: 00007f32382fb720 RDI: 0000000000000005
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918504] RBP: 00007f32382fb720 R08: 0000000000000000 R09: 00007f32300145b0
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918507] R10: 0000000000000000 R11: 0000000000000293 R12: 000000000000006e
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918509] R13: 0000000000000000 R14: 00007f32382fb720 R15: 00007f3230017000
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918514] Modules linked in: multiplier(OE) crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel vboxvideo(C) aes_x86_64 crypto_simd ttm cryptd drm_kms_helper glue_helper drm joydev intel_rapl_perf input_leds fb_sys_fops syscopyarea serio_raw sysfillrect sysimgblt mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic usbhid hid psmouse ahci libahci pata_acpi e1000 i2c_piix4 video
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918604] ---[ end trace 821aa2233cf391a7 ]---
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918611] RIP: 0010:__kmalloc_track_caller+0xaf/0x210
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918614] Code: 39 7a 49 83 78 10 00 4d 8b 38 0f 84 ee 00 00 00 4d 85 ff 0f 84 e5 00 00 00 41 8b 59 20 49 8b 39 48 8d 4a 01 4c 89 f8 4c 01 fb <48> 33 1b 49 33 99 38 01 00 00 65 48 0f c7 0f 0f 94 c0 84 c0 74 b2
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918617] RSP: 0018:ffffa994814f3d18 EFLAGS: 00010202
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918620] RAX: 06fb5d499a5b6b73 RBX: 06fb5d499a5b6b73 RCX: 00000000000013b4
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918623] RDX: 00000000000013b3 RSI: 00000000006000c0 RDI: 0000000000027060
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918624] RBP: ffffa994814f3d50 R08: ffff98acbda27060 R09: ffff98acbd403b00
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918627] R10: ffffffff870ff020 R11: 304a565a46412d72 R12: 00000000006000c0
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918629] R13: 000000000000000a R14: ffff98acbd403b00 R15: 06fb5d499a5b6b73
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918632] FS: 00007f32382fc700(0000) GS:ffff98acbda00000(0000) knlGS:0000000000000000
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918635] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Apr 22 16:19:25 student-VirtualBox kernel: [ 247.918637] CR2: 00007f32382faff8 CR3: 000000005c9b2001 CR4: 00000000000606f0
Apr 22 16:19:39 student-VirtualBox kernel: [ 261.077288] general protection fault: 0000 [#3] SMP PTI
Apr 22 16:19:39 student-VirtualBox kernel: [ 261.077306] CPU: 0 PID: 1119 Comm: upowerd Tainted: G D C OE 4.20.17 #1
Apr 22 16:19:39 student-VirtualBox kernel: [ 261.077312] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
Apr 22 16:19:39 student-VirtualBox kernel: [ 261.077325] RIP: 0010:__kmalloc+0xb3/0x220
Apr 22 16:19:39 student-VirtualBox kernel: [ 261.077333] Code: 39 7a 49 83 78 10 00 4d 8b 38 0f 84 fb 00 00 00 4d 85 ff 0f 84 f2 00 00 00 41 8b 59 20 49 8b 39 48 8d 4a 01 4c 89 f8 4c 01 fb <48> 33 1b 49 33 99 38 01 00 00 65 48 0f c7 0f 0f 94 c0 84 c0 74 b2
I'm pretty new to device drivers I can't seem to make sense out of these logs I tried looking up some of the codes and phrases from the log but couldn't arrive at anything solid.

Openstack VM instance SHUTOFF after few minute

For learning purpose i have build openstack on VirtualBox with 2 vCPU and 4GB Memory. It installed successfully and i am able to start VM instances but what happened is guest VM got SHUTOFF status after few minutes. I have google this issue but didn't get proper answer. I have check logs and i didn't find anything suspicious.
How do i check VM console so i can see what is going on there?
Where should i check SHUTOFF specific error logs, i meant in which file?
EDIT:
Following is output of nova console-log but it stuck there not going ahead and i can't see login screen too
openstack#openstack1:~$ nova console-log 970a3722-0fb3-4db6-862b-2aa626cc68a8
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.0.0-12-virtual (buildd#crested) (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #20-Ubuntu SMP Fri Oct 7 18:19:02 UTC 2011 (Ubuntu 3.0.0-12.20-virtual 3.0.4)
[ 0.000000] Command line: LABEL=cirros-rootfs ro console=tty0 console=ttyS0 console=hvc0
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Centaur CentaurHauls
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009dc00 (usable)
[ 0.000000] BIOS-e820: 000000000009dc00 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 000000001fffd000 (usable)
[ 0.000000] BIOS-e820: 000000001fffd000 - 0000000020000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved)
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] DMI 2.4 present.
[ 0.000000] No AGP bridge found
[ 0.000000] last_pfn = 0x1fffd max_arch_pfn = 0x400000000
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] found SMP MP-table at [ffff8800000fdaf0] fdaf0
[ 0.000000] init_memory_mapping: 0000000000000000-000000001fffd000
[ 0.000000] RAMDISK: 1fdf9000 - 1ffed000
[ 0.000000] ACPI: RSDP 00000000000fd990 00014 (v00 BOCHS )
[ 0.000000] ACPI: RSDT 000000001fffd7b0 00034 (v01 BOCHS BXPCRSDT 00000001 BXPC 00000001)
[ 0.000000] ACPI: FACP 000000001fffff80 00074 (v01 BOCHS BXPCFACP 00000001 BXPC 00000001)
[ 0.000000] ACPI: DSDT 000000001fffd9b0 02589 (v01 BXPC BXDSDT 00000001 INTL 20100528)
[ 0.000000] ACPI: FACS 000000001fffff40 00040
[ 0.000000] ACPI: SSDT 000000001fffd910 0009E (v01 BOCHS BXPCSSDT 00000001 BXPC 00000001)
[ 0.000000] ACPI: APIC 000000001fffd830 00072 (v01 BOCHS BXPCAPIC 00000001 BXPC 00000001)
[ 0.000000] ACPI: HPET 000000001fffd7f0 00038 (v01 BOCHS BXPCHPET 00000001 BXPC 00000001)
[ 0.000000] No NUMA configuration found
[ 0.000000] Faking a node at 0000000000000000-000000001fffd000
[ 0.000000] Initmem setup node 0 0000000000000000-000000001fffd000
[ 0.000000] NODE_DATA [000000001fff5000 - 000000001fff9fff]
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0x00000010 -> 0x00001000
[ 0.000000] DMA32 0x00001000 -> 0x00100000
[ 0.000000] Normal empty
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[2] active PFN ranges
[ 0.000000] 0: 0x00000010 -> 0x0000009d
[ 0.000000] 0: 0x00000100 -> 0x0001fffd
[ 0.000000] ACPI: PM-Timer IO Port: 0xb008
[ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-23
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[ 0.000000] SMP: Allowing 1 CPUs, 0 hotplug CPUs
[ 0.000000] PM: Registered nosave memory: 000000000009d000 - 000000000009e000
[ 0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
[ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000f0000
[ 0.000000] PM: Registered nosave memory: 00000000000f0000 - 0000000000100000
[ 0.000000] Allocating PCI resources starting at 20000000 (gap: 20000000:dffc0000)
[ 0.000000] Booting paravirtualized kernel on bare hardware
[ 0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:1 nr_node_ids:1
[ 0.000000] PERCPU: Embedded 27 pages/cpu #ffff88001fa00000 s79296 r8192 d23104 u2097152
[ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 129157
[ 0.000000] Policy zone: DMA32
[ 0.000000] Kernel command line: LABEL=cirros-rootfs ro console=tty0 console=ttyS0 console=hvc0
[ 0.000000] PID hash table entries: 2048 (order: 2, 16384 bytes)
[ 0.000000] Checking aperture...
[ 0.000000] No AGP bridge found
[ 0.000000] Memory: 497852k/524276k available (6206k kernel code, 460k absent, 25964k reserved, 6907k data, 900k init)
[ 0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] RCU dyntick-idle grace-period acceleration is enabled.
[ 0.000000] NR_IRQS:4352 nr_irqs:256 16
[ 0.000000] Console: colour VGA+ 80x25
[ 0.000000] console [tty0] enabled
[ 0.000000] console [ttyS0] enabled
[ 0.000000] allocated 4194304 bytes of page_cgroup
[ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[ 0.000000] Fast TSC calibration failed
[ 0.000000] TSC: Unable to calibrate against PIT
[ 0.000000] TSC: using PMTIMER reference calibration
[ 0.000000] Detected 2486.018 MHz processor.
[ 0.024490] Calibrating delay loop (skipped), value calculated using timer frequency.. 4972.03 BogoMIPS (lpj=9944072)
[ 0.025939] pid_max: default: 32768 minimum: 301
[ 0.029903] Security Framework initialized
[ 0.033041] AppArmor: AppArmor initialized
[ 0.033539] Yama: becoming mindful.
[ 0.037514] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
[ 0.039560] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
[ 0.040693] Mount-cache hash table entries: 256
[ 0.054301] Initializing cgroup subsys cpuacct
[ 0.054957] Initializing cgroup subsys memory
[ 0.056108] Initializing cgroup subsys devices
[ 0.056838] Initializing cgroup subsys freezer
[ 0.057341] Initializing cgroup subsys net_cls
[ 0.057824] Initializing cgroup subsys blkio
[ 0.058338] Initializing cgroup subsys perf_event
[ 0.060182] mce: CPU supports 10 MCE banks
[ 0.062116] SMP alternatives: switching to UP code
[ 0.236105] Freeing SMP alternatives: 24k freed
[ 0.237129] ACPI: Core revision 20110413
[ 0.270578] ftrace: allocating 26075 entries in 103 pages
[ 0.289821] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 0.332667] CPU0: AMD QEMU Virtual CPU version 1.0 stepping 03
[ 0.336020] APIC calibration not consistent with PM-Timer: 103ms instead of 100ms
[ 0.336020] APIC delta adjusted to PM-Timer: 6249961 (6456813)
[ 0.336020] Performance Events: Broken PMU hardware detected, using software events only.
[ 0.341160] Brought up 1 CPUs
[ 0.341596] Total of 1 processors activated (4972.03 BogoMIPS).
[ 0.348508] devtmpfs: initialized
[ 0.370265] print_constraints: dummy:
[ 0.370818] Time: 22:32:35 Date: 07/31/13
[ 0.373184] NET: Registered protocol family 16
[ 0.377862] ACPI: bus type pci registered
[ 0.379805] PCI: Using configuration type 1 for base access
[ 0.394436] bio: create slab <bio-0> at 0
[ 0.441293] ACPI: Interpreter enabled
[ 0.441749] ACPI: (supports S0 S3 S4 S5)
[ 0.442853] ACPI: Using IOAPIC for interrupt routing
[ 0.504949] ACPI: No dock devices found.
[ 0.505458] HEST: Table not found.
[ 0.505922] PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug
[ 0.508456] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.514427] pci 0000:00:01.3: quirk: [io 0xb000-0xb03f] claimed by PIIX4 ACPI
[ 0.515222] pci 0000:00:01.3: quirk: [io 0xb100-0xb10f] claimed by PIIX4 SMB
[ 0.526520] pci0000:00: Unable to request _OSC control (_OSC support mask: 0x1e)
[ 0.612644] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
[ 0.614063] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[ 0.615312] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[ 0.616918] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
[ 0.618197] ACPI: PCI Interrupt Link [LNKS] (IRQs 9) *0
[ 0.622888] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[ 0.623734] vgaarb: loaded
[ 0.624235] vgaarb: bridge control possible 0000:00:02.0
[ 0.627513] SCSI subsystem initialized
[ 0.629754] usbcore: registered new interface driver usbfs
[ 0.630590] usbcore: registered new interface driver hub
[ 0.632126] usbcore: registered new device driver usb
[ 0.634610] PCI: Using ACPI for IRQ routing
[ 0.640771] NetLabel: Initializing
[ 0.641144] NetLabel: domain hash size = 128
[ 0.641570] NetLabel: protocols = UNLABELED CIPSOv4
[ 0.642769] NetLabel: unlabeled traffic allowed by default
[ 0.744929] AppArmor: AppArmor Filesystem Enabled
[ 0.746522] pnp: PnP ACPI init
[ 0.748377] ACPI: bus type pnp registered
[ 0.761838] pnp: PnP ACPI: found 8 devices
[ 0.762440] ACPI: ACPI bus type pnp unregistered
[ 0.791325] Switching to clocksource acpi_pm
[ 0.791325] NET: Registered protocol family 2
[ 0.792984] Switched to NOHz mode on CPU #0
[ 0.794980] IP route cache hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.800380] TCP established hash table entries: 16384 (order: 6, 262144 bytes)
[ 0.802008] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
[ 0.803089] TCP: Hash tables configured (established 16384 bind 16384)
[ 0.803751] TCP reno registered
[ 0.804373] UDP hash table entries: 256 (order: 1, 8192 bytes)
[ 0.805192] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[ 0.806852] NET: Registered protocol family 1
[ 0.807530] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[ 0.808586] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[ 0.809327] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[ 0.816560] audit: initializing netlink socket (disabled)
[ 0.817591] type=2000 audit(1375309954.816:1): initialized
[ 0.903327] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[ 0.928384] VFS: Disk quotas dquot_6.5.2
[ 0.929484] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 0.938210] fuse init (API version 7.16)
[ 0.940982] msgmni has been set to 972
[ 0.949280] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[ 0.950562] io scheduler noop registered
[ 0.951008] io scheduler deadline registered (default)
[ 0.951941] io scheduler cfq registered
[ 0.955245] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 0.956970] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[ 0.960881] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[ 0.962211] ACPI: Power Button [PWRF]
[ 0.979110] ERST: Table is not found!
[ 0.982891] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
[ 0.983651] virtio-pci 0000:00:03.0: PCI INT A -> Link[LNKC] -> GSI 11 (level, high) -> IRQ 11
[ 0.986746] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
[ 0.987395] virtio-pci 0000:00:04.0: PCI INT A -> Link[LNKD] -> GSI 10 (level, high) -> IRQ 10
[ 0.993533] Trying to unpack rootfs image as initramfs...
[ 1.017633] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10
[ 1.018210] virtio-pci 0000:00:05.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, high) -> IRQ 10
[ 1.020389] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[ 1.052583] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 1.082516] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[ 1.165489] 00:05: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 1.244653] 00:06: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[ 1.248018] hpet_acpi_add: no address or irqs in _CRS
[ 1.249922] Linux agpgart interface v0.103
[ 1.279474] brd: module loaded
[ 1.287981] loop: module loaded
[ 1.597690] vda: vda1
[ 1.624125] Freeing initrd memory: 2000k freed
[ 1.626790] scsi0 : ata_piix
[ 1.629007] scsi1 : ata_piix
[ 1.629910] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc0a0 irq 14
[ 1.630652] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc0a8 irq 15
[ 1.636489] Fixed MDIO Bus: probed
[ 1.637469] PPP generic driver version 2.4.2
[ 1.638209] tun: Universal TUN/TAP device driver, 1.6
[ 1.638756] tun: (C) 1999-2004 Max Krasnyansky <maxk#qualcomm.com>
openstack#openstack1:~$
You can get guest console on the dashboard or with this command:
nova get-vnc-console <instance id> novnc
If your guest image redirects console messages (like the ubuntu cloud image), you can see boot messages on dashboard or with the command:
nova console-log <instance id>
You may get clues in /var/log/nova/nova-compute.log and in your hypervisor logs (/var/log/libvirt/libvirtd.log for QEMU/KVM).
A possible cause is that your guest can't boot on its primary disk and get stuck on boot sequence. Try other images, like the ones proposed in OpenStack documentation.