wrong free space on ubuntu trusty install

[Frits Swinkels]

Flashed legacy trusty server for Cubox-i onto a 16G SC card.

Installed this succesfully on a Cubox-i4*4 and connected with ssh (no console, after all it is a headless server).

The mount command showed

/dev/mmcblk0p1 on / type ext4

parted showed one aprtition

1        size 16.0G primary ext4 (as promissed, the partition was extended to use the whole card)

Now comes the disturbing bit

df -h /dev/mmcblk0p1  gives nonsense.

df -h /    responds with

/dev/root   1022M   896M used 89M free

Indeed, I tried to load a GUI but it got stuck on a full partition:(

Ideas where this /dev/root came from and why it was not subsumed in the grand mmcblk0p1 partition?

 

The purpose of all this is a HTPC which can run Youtube and a paid-for channel thru a webbrowser and (my own) movies and music through vlc + a program in Python of my own making. If there is a better way of getting there, by all means tell me.

I was successfull in installing and running the Solid-run Jessie by way of the Ignition installer, but I could not find a 10 foot interface; maybe get my opera glasses out to look at the screen.

 

[Igor]

 

Now comes the disturbing bit

df -h /dev/mmcblk0p1  gives nonsense.

df -h /    responds with

/dev/root   1022M   896M used 89M free

Is this still present after one reboot?

[Frits Swinkels]

I do not know, but I will try:)

It will take a while because the Cubox is engaged in another experiment.

[Frits Swinkels]

This is what I get after rebooting:

 

 df -h /dev/mmcblk0
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        1.8G  4.0K  1.8G   1% /dev
frits@cubox-i:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/root      1022M  896M   89M  92% /
 

/ should be mounted on /mmcblk0p1

[Frits Swinkels]

sudo mount
[sudo] password for frits:
/dev/mmcblk0p1 on / type ext4 (rw,noatime,nodiratime,commit=600,errors=remount-ro)
none on /proc type proc (rw,noexec,nosuid,nodev)

 

I should have send this too; look at the first line.


 

[Igor]

Something is not o.k. either with our first boot script or your SD card. Will check the script asap.

[tkaiser]

I should have send this too; look at the first line.

 

Providing only partial information is somewhat problematic. Are you able to post the output of 'sudo armbianmonitor -u'?

[Frits Swinkels]

I was not aware of this thing:

 

/var/log/armhwinfo.log has been uploaded to http://sprunge.us/SDJK
 

[tkaiser]

/var/log/armhwinfo.log has been uploaded to http://sprunge.us/SDJK

 

Thx, obviously you rebooted at least 3 times and the filesystem resize didn't happen for reasons unknown to me while partition resize worked. Maybe there's another error condition preventing resizefs from doing its work (dunno unfortunately) 

[Frits Swinkels]

Should this conversation be taken offline? It must be boring for other people till we (i.e. you:) have something actionable.

 

By the way, I ran all this on two distinct SD cards, unfortunately of the same brand and the same size (Samsung 16G EVO). I will try to liberate a different SD card and repeat the install.

 

Is there any way in which I can (try to) do the resize2fs by hand and see the feedback if any?

 

Where is the "/dev/root" if I do not see it in parted or fdisk -l; is it in the ARM equivalent of GRUB?  (Actually I am looking for info on what the .raw image looks like and what if anything I can mount and look at. )

 

Thanks for quick attention.

[tkaiser]

Should this conversation be taken offline?

 

Well, then it would be waste of time at least for me. I'm not an unpaid support clerk but just a user writing in the forums so that others are able to benefit from and start to do the same!

 

In case you bought 2 fake cards then buying another one isn't the best idea. Better check them now as outlined in our documentation: https://github.com/igorpecovnik/lib/blob/master/documentation/user-faq.md#how-to-prepare-sd-card

 

And of course: If you got counterfeit cards then resize2fs will always fail since the card shows a wrong size and accessing anything beyond the real capacity is not possible.

 

In case you finished checking your cards and they're ok you need to expand the large ext4 partition on the SD card (depends on the distro you use how this will be listed by df)

[Frits Swinkels]

Apologies to tkaiser, I thought you were part of the administrators.

 

I did clean a working jessie off of a 32G sandisk sd card (different brand, different size) and loaded the legacy ubuntu trusty as above. I got exactly the same error as before, before and after a reboot. The idea of a fake card starts to wear thin (the stores where they were bought were the most reputable in town). By the way, the working Jessie desktop came from the Armbian download page, one item below the offending one:)

[Igor]

I tried yesterday to build from scratch but kernel 4.5.4 does not boot at all. Strange. This means I would need a bigger time frame to understand what's going on. Until then, use legacy based image, Jessie is recommended - it's most tested / fixed.