Bug 12016

Summary: Grub fails to boot bzImage after upgrade to 2019.05
Product: buildroot Reporter: Wojciech Ziniewicz <wojciech.ziniewicz>
Component: OtherAssignee: Carlos Santos <unixmania>
Status: RESOLVED FIXED    
Severity: normal CC: buildroot, vapier, wojciech.ziniewicz
Priority: P5    
Version: 2019.05   
Target Milestone: 2019.05   
Hardware: PC   
OS: Linux   
Host: Target:
Build:
Attachments: buildroot config

Description Wojciech Ziniewicz 2019-07-08 13:37:50 UTC
Created attachment 8141 [details]
buildroot config

Hello,

We're using nerves with buildroot, however the problem that we found is more likely to be originating from buildroot.

We're running x64 system. After upgrade from buildroot 2018.05.1-ge696583 to 2019.05-00196-g8c48616 grub is refusing to boot the bZImage. The observed result is that we can see "Grub loading" message and the machine reboots. What we've checked already:

- kernel hasnt changed between upgrades
- bzImage exists and has proper size (and slightly different md5sum between builds)
- grub.cfg is correct and points to bzImage existing on a healthy partition (config attached)
- all of our partitions are existing and contain proper files
- the MBR exists and boots the grub
- buildroot config hasn't changed between old and upgraded version



Partitions:

```
/dev/sdc1: SEC_TYPE="msdos" UUID="0021-0000" TYPE="vfat" PARTUUID="04030202-01"
/dev/sdc2: TYPE="squashfs" PARTUUID="04030202-02"
/dev/sdc3: PARTUUID="04030202-03"
/dev/sdc4: PARTUUID="04030202-04"
```

Grub config:

```
if [ $boot = 1 ]; then
     # echo "Booting partition B..."
     linux (hd0,msdos3)/boot/bzImage vt.global_cursor_default=0 net.ifnames=0 root=PARTUUID=04030202-03 rootwait ignore_rlimit_data skew_tick=1
else
     # echo "Booting partition A..."
     linux (hd0,msdos2)/boot/bzImage vt.global_cursor_default=0 net.ifnames=0 root=PARTUUID=04030202-02 rootwait ignore_rlimit_data skew_tick=1
fi
```
Comment 1 Carlos Santos 2019-07-18 19:02:36 UTC
I'm taking this one.
Comment 2 Wojciech Ziniewicz 2019-07-29 14:38:44 UTC
Hey,

After more and more testing we've found out what was the issue. We were using cache in our build system and with enough many changes to the configuration we ended up with some sort of cache-polluted unbootable state. Removing the cache and switching back from -O3 to -O2 fixed the issue once and for all.

This can be safely closed now.