Panic when booting .iso on Atom-based server (v0.4.0-rc6)

[clhudson2]

When booting an Atom-based server from rancheros.iso (v0.4.0-rc6) on usb flash drive, the kernel panics (see attached photo). This worked fine with v0.3.3 release rancheros.iso image.

Running on Intel Atom C2558 processor (Supermicro A1SRI-2558F, http://www.amazon.com/gp/product/B00HS4NLHA).

[croemmich]

I'm seeing the same issue trying to get it up and running on a Linode 1024:

ERRO[0000] Failed to create bridge docker-sys: operation not supported                                                                                                                       
Waiting for Docker at unix:///var/run/system-docker.sock                                                                                                                                     
[    4.616585] random: docker urandom read with 47 bits of entropy available                                                                                                                 
[    4.629728] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100                                                                                                       
[    4.629728]                                                                                                                                                                               
[    4.630008] CPU: 0 PID: 72 Comm: docker Not tainted 3.19.8-ckt5-rancher #1                                                                                                                
[    4.630008] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014                                                               
[    4.630008]  0000000000000000 ffffffff81a3b9f0 ffffffff81508765 ffffffff817e1e0a                                                                                                          
[    4.630008]  ffffffff81505d6a 0000000000000008 ffffffff00000010 ffff88003db13d18                                                                                                          
[    4.630008]  ffff88003db13cb8 ffff88003d879280 0000000000000100 ffff88003e224010                                                                                                          
[    4.630008] Call Trace:                                                                                                                                                                   
[    4.630008]  [<ffffffff81508765>] ? dump_stack+0x40/0x50                                                                                                                                  
[    4.630008]  [<ffffffff81505d6a>] ? panic+0xc8/0x1f6                                                                                                                                      
[    4.630008]  [<ffffffff81048ac9>] ? do_exit+0x492/0x89b                                                                                                                                   
[    4.630008]  [<ffffffff81048f31>] ? do_group_exit+0x3a/0x96                                                                                                                               
[    4.630008]  [<ffffffff81050b4e>] ? get_signal+0x417/0x442                                                                                                                                
[    4.630008]  [<ffffffff8100a1bc>] ? do_signal+0x1e/0x512                                                                                                                                  
[    4.630008]  [<ffffffff8110d311>] ? new_sync_read+0x67/0x8b                                                                                                                               
[    4.630008]  [<ffffffff810751fe>] ? arch_local_irq_save+0x11/0x17                                                                                                                         
[    4.630008]  [<ffffffff8110ea37>] ? fput+0xd/0x7d                                                                                                                                         
[    4.630008]  [<ffffffff8113ab84>] ? SYSC_epoll_wait+0x23b/0x334                                                                                                                           
[    4.630008]  [<ffffffff8100a6d5>] ? do_notify_resume+0x25/0x68                                                                                                                            
[    4.630008]  [<ffffffff8110df4f>] ? SyS_read+0x5b/0x72                                                                                                                                    
[    4.630008]  [<ffffffff8150d940>] ? int_signal+0x12/0x17                                                                                                                                  
[    4.630008] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)                                                                          
[    4.630008] Rebooting in 60 seconds..           

[ibuildthecloud]

@clhudson2 do you see any log messages before the panic?

@croemmich do you have simple steps to reproduce? I'd like to try this on Linode myself.

[clhudson2]

I don’t have a good serial console connection to the box yet, but I was able to record the screen before it scrolled. The key message appears to be:

INFO[0000] Mounting state device /dev/sda1 to /state INFO[0000] Launching System Docker ERRO[0000] Failed to create bridge docker-sys: operation not supported Wating for Docker at unix:///var/run/system-docker.sock unix:///var/run/system-docker.sock

Let me know if you want me to try something more or test something.

On Sep 17, 2015, at 11:04 AM, Darren Shepherd notifications@github.com wrote:

@clhudson2 https://github.com/clhudson2 do you see any log messages before the panic?

@croemmich https://github.com/croemmich do you have simple steps to reproduce? I'd like to try this on Linode myself.

— Reply to this email directly or view it on GitHub https://github.com/rancher/os/issues/566#issuecomment-141133640.

[imikushin]

@croemmich I've tried to reproduce the crash on Linode and successfully booted RancherOS v0.4.0-dev on Linode 1024. That means we probably won't be able to reproduce without your help. Can you provide your exact steps that lead to the crash?

[maxfierke]

I'm getting the same thing on my MinnowboardMAX. Same message & stacktrace as @clhudson2, but with the 4.2.10-12 Ubuntu kernel.

I've got an FTDI USB-to-Serial on order (BusPirate kicked the bucket today), so I should be able to get more from the log this week.

[ibuildthecloud]

I can try this one myself too. I have a MinnowboardMax.

[maxfierke]

@ibuildthecloud Alrighty cool. Check out the feature/uefi-boot branch on my fork. You'll have to build that, as the MinnowboardMAX doesn't seem to boot the regular MBR/BIOS-bootable ISO, or at least not when byte-copied to a USB key.

Interestingly, I did have it booting a few days ago by just executing the vmlinuz image directly through the UEFI shell with all the parameters passed in. I don't recall the kernel version, unfortunately. It may have been on the 3.19 kernel.

[ibuildthecloud]

Nice. I'll check out your branch. I had 3.19 working also booting using vmlinuz directly. The error you are seeing is typically caused by not having the kernel modules available. You might ensure your STATE partition is blank. A previous /usr folder can conflict with RancherOS.

[maxfierke]

Disk is untouched, so far. Haven't gotten to conquering UEFI-bootable installation yet ;) fdisk lied to me. Partition showed up in gparted, though. Formatting and trying again...

[maxfierke]

Alrighty, clearing the RANCHER_STATE partition got rid of the kernel panic.