Latest Jessie: cannot write to disk, cannot connect Eth over USB, could before

Two glaring issues have occurred seemingly without cause and neither of which was present a few hours ago. The issues are only present when booting from an SD card with the latest Jessie/Debian 8.4 image (Linux beaglebone 4.4.9-ti-r25 #1 SMP Thu May 5 23:08:13 UTC 2016 armv7l GNU/Linux).

  1. I am unable to write to disk. E.g. vi: “E297: Write error in swap file”, “E514: Write error (file system full?)”

  2. I am unable to connect over Ethernet-over-USB. On a host machine, I have

Ethernet adapter Local Area Connection 3:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Linux USB Ethernet/RNDIS Gadget #2
Physical Address. . . . . . . . . : A0-F6-FD-3C-F7-FF
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes

Cannot ping. The USB disk still shows up as USB storage on the host, I can access it without problems.

I still have the TTY: a keyboard and output to the BB-View cape with LCD4 attached, these function.

When I boot from the eMMC with Wheezy/Debian 7.9, neither of the issues is present.

Would anyone have a suggestion on how I should debug this? Thanks!

Seems that I figured it out, for others’ reference. The SD card with the Jessie image that I was running off was 4 GB and filled up quickly (with what? logfiles? errorlogs?), so the disk indeed became full.

Did you expand the image after booting?

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Expanding_File_System_Partition_On_A_microSD

Regards,

I didn’t expand the partition since it seemed that wouldn’t accomplish anything; the image was a 4 GB image obtained from https://debian.beagleboard.org/images/bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz that was actually about 3.6 GB in uncompressed size. The partition on the 4 GB SD card was slightly bigger than that. Would expanding the partition have materially changed anything?

I didn’t expand the partition since it seemed that wouldn’t accomplish anything; the image was a 4 GB image obtained from https://debian.beagleboard.org/images/bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz that was actually about 3.6 GB in uncompressed size. The partition on the 4 GB SD card was slightly bigger than that. Would expanding the partition have materially changed anything?

If your sdcard was larger than 4G of course it would have.

So I attempted to expand the partition on my 4 GB SD card (yes these still exist) according to http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Expanding_File_System_Partition_On_A_microSD, and got the following results. I didn’t capture the output and the operation seems to have been irreversible, so sorry about the inexact report. This was while running Linux beaglebone 3.8.13-bone79 #1 SMP Tue Oct 13 20:44:55 UTC 2015 armv7l GNU/Linux from the eMMC.

Git pull didn’t work because the board is not directly connected to the Internet because I am in a corporate setting and to get a hobbyist board wired to the corporate network would require multiple levels of slow approval.

The grow_partition.sh script reported that it wrote a new partition, but failed to verify it, or something similar. Again, sorry for the lack of captured output.

After grow_partition.sh ran, Beaglebone’s df reported a 7.2 GB drive with 1.9 GB used and 5.0 GB free. On this 4 GB card. Yes, I rubbed my eyes.

When I then inserted this card into an Ubuntu laptop, I got the same report out of df: 7281280 1K blocks total, 1934304 used, 4999784 available on the rootfs partition.

When I attempt to dd another image to this SD card, dd fails after 780 MB is written. When I try to erase the partitions with cfdisk and create a new one, cfdisk offers a maximum of 780 MB.

To my untrained eye it looks like grow_partition.sh has rendered this SD card partly inoperable.

What does lsblk report for that scard ?

On the Ubuntu machine:

$ lsblk /dev/sdblsblk: /dev/sdb: not a block device
$ lsblk /dev/sdb1
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb1 8:17 1 96M 0 part /media/vladimir/BEAGLEBONE

$ lsblk /dev/sdb2
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb2 8:18 1 7.1G 0 part /media/vladimir/rootfs

There are a couple options here.

First, you can use dd to wipe out the first 1M or more, to get rid of both partitions. But I’d use this as a last resort.

Second, you can use fdisk to delete that partition, and start over again.

If that is a 4G card, and showing a 7.1G partition. Thats definitely wrong, and needs to be dealt with. I’ve had it happen to me once or twice, manipulating partitions manually. Not sure how exactly, but in each case it was fixable.

Thanks! I’m sure I can wipe out the card clean and start over, and if everything fails, get a new one.

My concern is that exactly following the instructions on elinux.org/Beagleboard yields a result that is (a) contrary to expectations and (b) potentially damaging to hardware. Moreover, it is insisted that this expansion step be followed.

Well, part of the problem is that you seem to be either mixing instructions with others, or you’re using an old

flasher image. Robert’s Debian images have not used a two partition layout in quite some times now. As in ore than a year or two.

Also, check your link, as in reload the page. It no longer exists.

This is what the instructions state on http://beagleboard.org/getting-started :

Update board with latest software### Step #1: Download the latest software image

Download the desired image from https://beagleboard.org/latest-images.

and the above link, https://beagleboard.org/latest-images , is precisely where I got the image on the SD card in question from:

Wheezy for BeagleBone, BeagleBone Black and SeeedStudio BeagleBone Green via microSD card

Why am I using 7.9 and not 8.4? Because I need kernel 3.8.x for the cape I am using. The cape is unsupported under 4.x kernels.

So, why do you state “Robert’s Debian images have not used a two partition layout in quite some times now”? Please explain. There were two partitions on the SD card that I flashed with the 7.9 image above. The smaller partition was the FAT32 one that shows up as a drive in Windows if I connect the Beaglebone to a Windows host with a USB cable. This smaller partition has mostly getting-started documents.

If the 7.9 images are no longer supported, Beaglebone should say so and not suggest them as latest images.

Also, can you please kindly explain “check your link, as in reload the page. It no longer exists”? I didn’t put in a full link below to save space. The full link to the instructions that I followed that yielded an SD card with greatly diminished capacity was provided by Robert above in the second reply to the original post, http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Expanding_File_System_Partition_On_A_microSD

This is what the instructions state on
Getting Started - BeagleBoard | How do I start using my board? :

Update board with latest software

Step #1: Download the latest software image

Download the desired image from https://beagleboard.org/latest-images.

and the above link, https://beagleboard.org/latest-images , is precisely
where I got the image on the SD card in question from:

Wheezy for BeagleBone, BeagleBone Black and SeeedStudio BeagleBone Green via
microSD card

Debian 7.9 (BeagleBone, BeagleBone Black, SeeedStudio BeagleBone Green - 4GB
SD) 2015-11-12 - more info - bmap - sha256sum:
f6e67ba01ff69d20f2c655f5e429c3e6c2398123bcd3d8d548460c597275d277

Why am I using 7.9 and not 8.4? Because I need kernel 3.8.x for the cape I
am using. The cape is unsupported under 4.x kernels.

in 8.4 you can do:

sudo apt-get update
sudo apt-get install linux-image-3.8.13-bone79

There back to 3.8.x based kernel :wink:

So, why do you state "Robert's Debian images have not used a two partition
layout in quite some times now"? Please explain. There were two partitions
on the SD card that I flashed with the 7.9 image above. The smaller
partition was the FAT32 one that shows up as a drive in Windows if I connect
the Beaglebone to a Windows host with a USB cable. This smaller partition
has mostly getting-started documents.

On newer image's we use an *.img file instead of a hard-coded fat32 partition...

If the 7.9 images are no longer supported, Beaglebone should say so and not
suggest them as latest images.

"supported" is a loose term.. If you want 100% fully supported, you'll
need to bug someone who get's paid to do this. (i don't get $ for
it.)

Also, can you please kindly explain "check your link, as in reload the page.
It no longer exists"? I didn't put in a full link below to save space. The
full link to the instructions that I followed that yielded an SD card with
greatly diminished capacity was provided by Robert above in the second reply
to the original post,
Beagleboard:BeagleBoneBlack Debian - eLinux.org

Regards,

So, why do you state “Robert’s Debian images have not used a two partition
layout in quite some times now”? Please explain. There were two partitions
on the SD card that I flashed with the 7.9 image above. The smaller
partition was the FAT32 one that shows up as a drive in Windows if I connect
the Beaglebone to a Windows host with a USB cable. This smaller partition
has mostly getting-started documents.

On newer image’s we use an *.img file instead of a hard-coded fat32 partition…

I’m adding on to what Robert has already said. It’s been a long time since there were two paritions on any Debian image. The main reason as I understand it is that there was a ~100M FAT partition because MLO, and u-boot.img needed a place to live. Passed that, g_multi( g_mass_storage ) has to have a path to export, so since the FAT partition was already needed, it was also used for that purpose.

But a long time ago, I do not remember exact time frame, but Robert probably could. Robert did away with the FAT partition because a lot of inexperienced people were deleting files, and causing their boards being unable to boot. This was done by putting MLO / u-boot.img into the MBR of the disk. So for a long time there was no FAT partition, and only one ext4 partition. As far as how Robert dealt with g_multi needing a path . … yeah I do not know, or care. I do not use it.

Anyway, you have a “real” FAT living right here:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb1 8:17 1 96M 0 part /media/vladimir/BEAGLEBONE

How or why, I do not know, and yes I suppose that could be an ext4 partition, but that would make far less sense. I’m pretty sure thats a FAT partition.

Indeed I get the open-source/unpaid paradigm and sincerely appreciate the contributions. But, if a version breaks something, as I here seem to have material proof, perhaps there should at least be disclaimers and not an urging to use that specific version with detailed instructions on how to do so.

So, where I got to with this particular SD card is as follows, which is beyond my knowledge of Linux, for which I apologize. I reformatted it in Windows in SD Formatter to FAT32, Windows can read and write and sees the 7.2 GB (the mystery of the extra space is perhaps simple—an 8 GB card with some bad blocks sold as 4 GB). I reformatted in every possible combination of options, then put a file on the SD card.

lsblk on Ubuntu then reports 7.2 GB on /dev/sdb1.

I can mount /dev/sdb1 on Ubuntu and read the file I wrote in Windows.

When I run sudo cfdisk /dev/sdb, I see 780 MB of free space. (Before I did the Windows reformatting, I tried reformatting sdb in Linux, and I deleted the partitions that were previously formed by dd’ing the 7.9 image).

When I run sudo cfdisk /dev/sdb1, I see 7.2 GB of free space. Yes, free space, despite being able to read, on the same machine at the same time, the file that’s on the SD card.

It seems to me that partition tables are corrupted, the portions that are seen by Linux/Ubuntu, and that they were corrupted by running grow_partition.sh on the Beaglebone earlier. And, that Ubuntu is confused by these tables and does not know how to recover.

https://www.google.com/search?q=how+to+fdisk+delete+partition ----->>>>> http://www.cyberciti.biz/faq/linux-how-to-delete-a-partition-with-fdisk-command/

Cyberciti is a good source for information. As are many others.

Sounds like a crappy microSD card, as grow_partition calls' sfdisk:

sudo sfdisk --unit M ${DISK} <<-__EOF__
1,L,*
__EOF__

So if ^ is enough to corrupt your microSD card's, throw them away, as
they useless...

Regards,

Sounds like a crappy microSD card, as grow_partition calls’ sfdisk:

sudo sfdisk --unit M ${DISK} <<-EOF
1,L,*
EOF

So if ^ is enough to corrupt your microSD card’s, throw them away, as
they useless…

I ran into this problem once too Robert while manually manipulating partitions on an sdcard. It had something to do with how one of the Jessie images were laid out.

So you know the old way of growing a partition manually with fdisk right ? fdisk the block device, delete the rootfs partition, and then make a new partition in it’s place to use up all the disk space right ?

Well for some reason on the Jesie images when you do this, the starting sector starts at the front of the block device, and then fidks gets some whack geometry. . .

Yeah, it does rely on knowing the initial geometry..

On the offical images i store it in /boot/SOC.sh

https://github.com/RobertCNelson/boot-scripts/blob/master/tools/grow_partition.sh#L91-L93

if that fails, i'm basicly guessing:

https://github.com/RobertCNelson/boot-scripts/blob/master/tools/grow_partition.sh#L50

Regards,

Indeed I started the discussion with Jessie (8.4), but then found out my cape is not supported under 4.x kernel, so switched to Wheezy (7.9). I then tried expanding the SD card partition on the SD card with the 7.9 image according to the instructions, and got the SD card into the trouble described above.

The FAT32 partition appears to be part of the 7.9 image.