Ubuntu snappy 15.04 image does not boot from SD card

[Hilmar Lapp]

I'm trying to play around with the Ubuntu snappy core image for BeagleBone Black from here:

https://developer.ubuntu.com/en/snappy/start/#try-beaglebone

I downloaded the image and wrote it to a 32GB microSD card, then inserted into a BBB that would otherwise be running Debian Wheezy from the eMMC, using the following steps:

1. Shutdown BBB (sudo halt)

2. When powered off, Insert microSD card

3. Push and hold User/Boot button, then reapply power

4. After a few seconds let go of User/Boot button

The image will not boot at all after this - none of the LEDs come on. (I'm assuming that they would also come on in the standard order on the Ubuntu image if everything were going right.)

What's even more puzzling, when I insert the microSD card into the BBB while it is booted from eMMC (into Debian Wheezy) to inspect it, the system freezes within about 1-2 minutes. Upon rebooting from eMMC, the syslog suggests that the system ran into out of memory and the OOM killer was active. I'm stumped as to why and how this can happen simply from inserting the card.

The card otherwise works fine - I can put Debian Wheezy images on it and boot them just fine. When the Ubuntu snappy image is flashed on the card, the FAT boot partition with which it mounts on MacOSX looks OK. The uEnv.txt file on there is zero bytes, but based on what I can find online, Ubuntu has moved away from using the uEnv.txt file, so I think this being zero bytes may well be a red herring.

This being the one official image for the BBB for Ubuntu snappy core, I feel I must have done something wrong, but I don't see what and where. Any suggestions would be much appreciated. 

  -hilmar

[doog]

if this is the first time running from the uSD card then how about using a known good image just to verify you've got things booting correctly? Then you'll know it's your image and not something else.

[Hilmar Lapp]

That's why I said the card otherwise works fine. I've used it to burn to the card and boot from the card the BBB Debian Wheezy 7.8 (March 1) and 7.9 (Nov 12) images, with everything working fine. It's specifically when I turn to the Ubuntu image that things turn awry.

But perhaps that's because the Ubuntu image requires some additional steps that I'm missing. For example, perhaps I need to zero out the first 512 or 1024 bytes of the device. It didn't say that anywhere, which is why I didn't do it. But maybe the fact that I had previously other images on it somehow makes that necessary (even though I wouldn't think so).

I'd be especially curious whether everyone else here has been able to use the Ubuntu Snappy Core 15.04 image just fine, so that I know it's something with what I'm doing or something perhaps with the boot loader on my eMMC. (Even though I thought that if you press the User/Boot button, it disables that boot loader and changes boot order to the microSD? And that still doesn't explain the weird OOM error I get when inserting the card into the running system.)

Also, if there's a better place to ask than here, let me know.

  -hilmar

[doog]

well, it should be a snap according to these instructions: https://developer.ubuntu.com/en/snappy/start/#try-beaglebone

If found that by googling "ubuntu core beaglebone black" and picking the "Getting Started / Developer" link. I like the developer links because they generally explain things and describe the why part of operations. On the link I provided you will see where they answer your question about zero'ing out the boot loader, or not and why.

Given those instructions it's tough to say where your failure originates.

I suppose I can run through the steps and see what I get. Stay tuned.

[Hilmar Lapp]

On Jan 1, 2016, at 9:54 PM, doog <doug....@gmail.com> wrote:

well, it should be a snap according to these instructions: https://developer.ubuntu.com/en/snappy/start/#try-beaglebone

Yes. That’s indeed the link I put in my original post.

[…] you will see where they answer your question about zero'ing out the boot loader, or not and why.

Yes, except that what they talk about zeroing out the boot loader on the *eMMC* (not the SD card). I do want to keep the eMMC-resident boot loader, and based on what that documentation says, that’s OK and only requires pushing the user/boot button (which I did).

I suppose I can run through the steps and see what I get. Stay tuned.

That’d be great. I’ve gotten to the point now that I can insert the card to a running system on the BBB for inspection, without crashing it as a result. I downloaded the image again, this time using curl, and then burned it to the SD card again. Now the partition layout shows as they say it should:

$ sudo fdisk -l /dev/mmcblk0

Disk /dev/mmcblk0: 32.2 GB, 32227983360 bytes
4 heads, 32 sectors/track, 491760 cylinders, total 62945280 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xa3c9235b

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1   *        8192      270335      131072    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          270336     2367487     1048576   83  Linux
/dev/mmcblk0p3         2367488     4464639     1048576   83  Linux
/dev/mmcblk0p4         4464640     7614463     1574912   83  Linux

The p2 and p3 partitions are labeled system-a and system-b, p4 is labeled ‘writable’ and p1 is labeled system-boot, all as they are supposed to be. p1 is bootable.

However, booting from it still fails. No LEDs ever light, everything except the power LED stays dark.

  -hilmar

-- 

Hilmar Lapp -:- lappland.io

[doog]

what I got so far looks like it's booting from mmcblk0( the uSD ) but then it goes into wanting to copy all 30GB from mmcblk0p1 to mmcblk1p1 and it fails for obvious reasons. I'm switching to a 8GB uSD card just to see what happens when it is able to complete.  I don't know why it would want to flash eMMC...

[doog]

I forgot to note, I'm using an FTDI cable to monitor the boot process since I'm going headless right now.

[doog]

well, it booted fine off the 8GB uSD card and I shelled into it using "ssh ubu...@webdm.local"

here's some initial login capture:

To run a command as administrator (user "root"), use "sudo <command>". See "man sudo_root" for details. (BeagleBoneBlack)ubuntu@localhost:~$ ls (BeagleBoneBlack)ubuntu@localhost:~$ ll total 28 drwxr-xr-x 4 ubuntu ubuntu 4096 Jan 2 04:17 ./ drwxr-xr-x 3 root root 4096 Nov 12 18:11 ../ -rw-r--r-- 1 ubuntu ubuntu 220 Nov 12 18:11 .bash_logout -rw-r--r-- 1 ubuntu ubuntu 3760 Nov 12 18:11 .bashrc drwx------ 2 ubuntu ubuntu 4096 Jan 2 04:17 .cache/ -rw-r--r-- 1 ubuntu ubuntu 675 Nov 12 18:11 .profile drwx------ 2 ubuntu ubuntu 4096 Nov 13 09:36 .ssh/ (BeagleBoneBlack)ubuntu@localhost:~$ ls (BeagleBoneBlack)ubuntu@localhost:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 239M 0 239M 0% /dev tmpfs 50M 8.6M 41M 18% /run /dev/disk/by-label/system-a 976M 500M 410M 55% / /dev/mmcblk0p4 5.2G 51M 4.9G 2% /writable tmpfs 246M 4.0K 246M 1% /etc/fstab tmpfs 246M 0 246M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 246M 0 246M 0% /sys/fs/cgroup tmpfs 246M 0 246M 0% /mnt tmpfs 246M 0 246M 0% /tmp tmpfs 246M 0 246M 0% /var/lib/sudo /dev/mmcblk0p3 976M 500M 410M 55% /writable/cache/system /dev/mmcblk0p1 127M 40M 87M 31% /boot/uboot cgmfs 100K 0 100K 0% /run/cgmanager/fs tmpfs 50M 0 50M 0% /run/user/1000 (BeagleBoneBlack)ubuntu@localhost:~$

[William Hermans]

Released images are published using the following path scheme:

Download the BeagleBone Black images:

• 15.04/stable
• 15.04/edge

Help: which release/channel should I use?

http://releases.ubuntu.com/<release>/ubuntu-<release>-snappy-<architecture>-<oem>.img.xz

You can download and install a pre-built snappy Ubuntu Core image for your BeagleBone Black and copy it to an SD card ready to boot as follows:

wget http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-armhf-bbb.img.xz
unxz -c ubuntu-15.04-snappy-armhf-bbb.img.xz | sudo dd of=/dev/sdX bs=32M
sync

block size of 32M does not even seem reasonable. . . .

On Fri, Jan 1, 2016 at 9:10 PM, doog <doug....@gmail.com> wrote:

I forgot to note, I'm using an FTDI cable to monitor the boot process since I'm going headless right now.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[doog]

On Friday, January 1, 2016 at 8:23:00 PM UTC-8, William Hermans wrote:

<clip>

wget http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-armhf-bbb.img.xz
unxz -c ubuntu-15.04-snappy-armhf-bbb.img.xz | sudo dd of=/dev/sdX bs=32M
sync

block size of 32M does not even seem reasonable. . . .

I agree and most of the time I use 1M  but stuck with what was stated and it did work. 

[William Hermans]

I have no idea *of* this image, ubuntu is not necessarily even a low priority for me. But I would imagine one could simply omit the block size parameter entirely.

Regardless, I'm downloading the image now, and will mount it as a loopback, and see what I can poke around and find out. Maybe even temp install to sdcard, as the instructions are not exactly complex, or hard . . . being only 4 simple commands.

--

[doog]

for whatever reason I could not get it to boot back into the uSD and it started to go back to flashing(cylon eyes). I looked at the partitions and there were only 2. After re-imaging the uSD card, I saw 4 partitions. And while I was re-imaging I tried to boot from eMMC and it would not, the failed flashing left the eMMC goofed up.

But the good news is, once I finished re-imaging, I booted and got back into Ubuntu Snappy Core.  Another thing of interest is that while I held down the S2/User/Boot button I didn't get any LEDs lit but it started booting into the uSD card so I let go of the button. It took a minute of booting/testing before it went to town and started loading from uSD(ie LEDs ablaze).

I don't know why the 32G Samsung didn't work but I may have forgot what's the max uSD size for BBB is.

[William Hermans]

I don't know why the 32G Samsung didn't work but I may have forgot what's the max uSD size for BBB is.

Technically, sdhc size, or 32G, but in reality, sdxc have been proven to work as well. At sdhc speeds. Robert's gotten a 64G to work, and someone else claimed to have had a bootable 128G sdxc card.

--

[William Hermans]

Ug, it uses a 3.19.x kernel . . . Now, I'm not even interested in booting it.

[Hilmar Lapp]

Thanks much for your efforts. For one, your results were the final nudge I needed to buy a USB to TTL serial debug cable. It’s possible that I didn’t have enough patience with LEDs all dark and not being able to see any indications of it actually booting. From booting the BeagleBoard Debian Wheezy images from uSD I was used to seeing the LEDs come on very quickly, so I was apparently mistaken to assume this would be the same for the Snappy Core image.

Second, the fact that booting the image flashed your eMMC is not cool. I was in fact wondering whether it would or not. The documentation is silent about this question, and the file name of the image contains no suggestion that it flashes the eMMC. On AskUbuntu, someone actually asked whether there is a flasher image:

http://askubuntu.com/questions/713604/snappy-on-beaglebone-black-or-green

The answer basically repeats the documentation from developer.ubuntu.com (which does not say anything about flashing versus not), and upon being specifically asked in the comments by people for whom the image failed to flash the eMMC, the poster admits they don’t know about that part. I also tried to glean the answer from the snappy-boot.txt file that it uses instead of the uEnv.txt, but there’s nothing in there that obviously indicates that the eMMC will be flashed. 

To me, whether booting the image will or will not flash your eMMC is a rather important distinction, so to me this is a red flag. On top of that, based on what I can find 15.04 is *only* available as Snappy Core for armhf systems, which means that even just basic things such as installing apache become a huge hassle:

http://askubuntu.com/questions/694397/how-to-install-apache-on-a-raspberry-pi-2-ubuntu-snappy-core

Based on this experience, while they have nice looking websites, I’m afraid the Ubuntu folks don’t have their act together for Ubuntu on BBB, and as a consequence I’ll stay away from them and their images for now. 

  -hilmar

--
For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/6_I1Ox9-sms/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[doog]

On Friday, January 1, 2016 at 9:43:53 PM UTC-8, William Hermans wrote:

Ug, it uses a 3.19.x kernel . . . Now, I'm not even interested in booting it.

ok so I re-imaged the 32G Samsung EVO+ card and it works. Not sure why it didn't earlier but oh well.

So what kernel were you looking for? 4.x?  If so it would seem Snappy Core for Banana Pi has kernel 4.x so it should be doable for BBB. Just not yet 'done'.

[William Hermans]

Second, the fact that booting the image flashed your eMMC is not cool. I was in fact wondering whether it would or not. The documentation is silent about this question, and the file name of the image contains no suggestion that it flashes the eMMC. On AskUbuntu, someone actually asked whether there is a flasher image:
http://askubuntu.com/questions/713604/snappy-on-beaglebone-black-or-green

From what I noticed, on the first partition ( vfat  ) there are two boot options. One strictly boot, and one flash. e.g. two different initrd's etc.

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[William Hermans]

How those are triggered however, I had not figured out. I pretty much saw that kernel 3.19.x was used, and lost interest.

[doog]

On Friday, January 1, 2016 at 10:01:50 PM UTC-8, Hilmar Lapp wrote:

Thanks much for your efforts. For one, your results were the final nudge I needed to buy a USB to TTL serial debug cable. It’s possible that I didn’t have enough patience with LEDs all dark and not being able to see any indications of it actually booting. From booting the BeagleBoard Debian Wheezy images from uSD I was used to seeing the LEDs come on very quickly, so I was apparently mistaken to assume this would be the same for the Snappy Core image.

I'm guessing that the boot loader does some of that early LED flashing and since Snappy has its own boot loader on the uSD there's not initial flashy LEDs 

 

Second, the fact that booting the image flashed your eMMC is not cool. I was in fact wondering whether it would or not. The documentation is silent about this question, and the file name of the image contains no suggestion that it flashes the eMMC. On AskUbuntu, someone actually asked whether there is a flasher image:

http://askubuntu.com/questions/713604/snappy-on-beaglebone-black-or-green

It could be I held the button too long or not long enough. I've not seen it try to flash now even though the eMMC doesn't have a boot able image now. I'm thinking that was cockpit error.

 

The answer basically repeats the documentation from developer.ubuntu.com (which does not say anything about flashing versus not), and upon being specifically asked in the comments by people for whom the image failed to flash the eMMC, the poster admits they don’t know about that part. I also tried to glean the answer from the snappy-boot.txt file that it uses instead of the uEnv.txt, but there’s nothing in there that obviously indicates that the eMMC will be flashed. 

To me, whether booting the image will or will not flash your eMMC is a rather important distinction, so to me this is a red flag. On top of that, based on what I can find 15.04 is *only* available as Snappy Core for armhf systems, which means that even just basic things such as installing apache become a huge hassle:

http://askubuntu.com/questions/694397/how-to-install-apache-on-a-raspberry-pi-2-ubuntu-snappy-core

Based on this experience, while they have nice looking websites, I’m afraid the Ubuntu folks don’t have their act together for Ubuntu on BBB, and as a consequence I’ll stay away from them and their images for now.

I would think Debian and/or standard Ubuntu are still the best go-to OS's for these devices(BBB, rPi, etc). For me at least for now.

[William Hermans]

Quite honestly, I have no interest in Ubuntu on this platform. For me, this is a true embedded platform, unlike many other boards out there. With that said, 99% of use cases that I can think of do not require a UI running on the board it's self, per se. Which is the only place I feel Ubuntu belongs( mostly in the context of desktops )

Anyway, headless, and perhaps a minimal webserver( etc ) for remote access / management is what I prefer, and for that role Ubuntu is not the right distro.

--

[doog]

On Friday, January 1, 2016 at 10:16:22 PM UTC-8, William Hermans wrote:

Quite honestly, I have no interest in Ubuntu on this platform. For me, this is a true embedded platform, unlike many other boards out there. With that said, 99% of use cases that I can think of do not require a UI running on the board it's self, per se. Which is the only place I feel Ubuntu belongs( mostly in the context of desktops )

Anyway, headless, and perhaps a minimal webserver( etc ) for remote access / management is what I prefer, and for that role Ubuntu is not the right distro.

That is your choice but let it be stated that Ubuntu is quite commonly used for headless server systems and there has long been an installation mechanism for such server based systems.

 http://www.ubuntu.com/download/server/install-ubuntu-server

And Robert Nelson has done some great work at keeping kernels and other parts updated for ARM devices( 4.x kernel too ):

http://elinux.org/BeagleBoardUbuntu#Method_1:_Download_a_Complete_Pre-Configured_Image

[doog]

FWIW, that elinux link I pointed to does boot and boots rather fast too. Also has apache pre-installed.

Downloaded the tar.xz, extracted it, ran "sudo ./setup_sdcard.sh --mmc /dev/mmcblk0 --dtb beaglebone" to build and image the uSD card.

[Hilmar Lapp]

On Jan 2, 2016, at 3:22 AM, doog <doug....@gmail.com> wrote:

FWIW, that elinux link I pointed to does boot and boots rather fast too. Also has apache pre-installed.

I agree. I actually used the raw SD image further down the page for checking it out, and it worked perfectly well (albeit it is truly minimal - not even the man pages are installed).

However, apparently Canonical decided to not support systemd yet in 14.04 (it seems to the consternation of their own users). This is in contrast to Debian, which is hybrid already in Wheezy. While there’s nothing wrong with SysV, I’m not a Linux sysadmin, don’t have the ambition to learn both, and am getting used to systemd from Wheezy.  There isn’t a 14.10 (let alone 15.04) image build yet.

The main reason I’m trying to get my hands on Ubuntu for BBB is that I have a Ninjablock - which at its heart is a BBB running Ubuntu 13.04 - that I’m trying to update to the latest version so I can have a more reproducible platform for testing out changes. But it seems to me that I may be better off porting it over to Debian, maybe Jessie.

  -hilmar  

[William Hermans]

Hilmar, I've no idea what Ninjablock is,I've just now looked, and there seems to be many different things that could be related. However, since Ubuntu is based on Debian there is a decent chance that porting it over could be possible. The biggest hurdle might be which compiler(version) was used on Ubuntu. Since Ubuntu's package's are typically ahead of Debians(stable) packages in versions.

Anyway, the biggest reason to make the change would be for consistency. So if you would prefer a more consistent experience, Debian might be the right choice for you.

But really, what needs to be ported ? Drivers ? Or is it just some executable from source that could be easily recompiled on Debian ? Now might be the time to catalog what needs doing before you invest too much time into Ubuntu - If you do not care to.