Hardware – Inexpensive Small Linux Laptop..

Posted on by May 3, 2017
Reply

After some research, I decided to use an Intel-powered ex-Chromebook for my portable Linux project..    I settled on an Acer Chromebook c720p, as this could be ‘converted’ to run Linux natively, rather than in emulation via Crouton..    There are several articles on this, but I found useful info (and a chassis/mobo diagram) here:  https://ankitrasto.wordpress.com/2015/02/06/clean-installing-linux-on-the-acer-c720pc720-chromebook-a-complete-guide/

C720 Fedora KDE/Plasma

C720 Fedora KDE/Plasma

If you are going to do this, remember that the c720 disk can be upgraded, but the memory is soldered-on, so get one with 4GB memory!     I found one on eBay with the disk already upgraded to 128GB..

I started by installing Fedora 25, via a USB stick, but found – as usual – that the install was a bit hit-and-miss..    On the first attempt, the install failed as the bootloader failed to install, but on the second attempt, it all worked OK!    The existing Chrome OS installation took up around 11 separate partitions of odd sizes on the disk, and these all needed to be deleted, before the Linux install continued….

As I had been testing Fedora 26, I soon updated the C720 to this, and also found that KDE/Plasma ran quite well, and even the touchscreen worked – although I don’t have much use for it..

The C720 is now running Kernel 4.11, and I have an Ethernet connection via USB (AX88179 Gigabit Ethernet).

[rgadsdon@rg720 ~]$ uname -a
Linux rg720 4.11.0 #1 SMP Sun Apr 30 20:46:23 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux

My only gripe, is the mousepad..  It is really an Apple-clone, and functions as a single button, although scrolling is possible (like a Mac) by using two fingers side-by-side..    As I did not want to tie up a USB port, I used a Bluetooth mouse, and this seems to be working quite well, and even functions in console mode..

Robert Gadsdon   May 3, 2017.

Kernel – 4.11 released, Patched VMware OK, NVIDIA Still Not OK..

Posted on by April 30, 2017
4

Kernel 4.11 Final is out, a week later than planned, and brief details of changes from -rc8 are here:  http://lkml.iu.edu/hypermail/linux/kernel/1704.3/04608.html

As expected, VMware 12.5.5 with the 4.11 patches is still OK (see http://rglinuxtech.com/?p=1932 ), but there is still no ‘legal’ solution for the latest NVIDIA driver – 381.09 (see https://devtalk.nvidia.com/default/topic/1002820/linux/-patch-381-09-kernel-4-11-rc5/ ):

.................
 Building modules, stage 2.
 MODPOST 4 modules
FATAL: modpost: GPL-incompatible module nvidia-drm.ko uses GPL-only symbol 'refcount_inc'
/usr/src/linux-4.11/scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[3]: *** [__modpost] Error 1
/usr/src/linux-4.11/Makefile:1495: recipe for target 'modules' failed
.........................

See previous article for more background on this: http://rglinuxtech.com/?p=1935

The NVIDIA ftp site has been down for the last 48 hours or so, and I cannot find any mention of any more recent driver version, so far..

If this goes on much longer, I may be tempted to try nouveau on my main system again..

Robert Gadsdon.   April 30, 2017.

X86_64 – UP Board – Updated to 4.11-rc8 – Sound Supported..

Posted on by April 26, 2017
Reply

After a bit of a hiatus, I updated the UP Board to Kernel 4.11-rc8, and HDMI sound is now supported..

In the kernel config, under ‘ALSA for SoC audio support‘, select ‘X86 sound devices‘, and ‘HDMI audio without HDaudio on Intel Atom platforms‘

After (re)boot to 4.11-rc8:

[rgadsdon@rgup ~]$ ll /dev/snd
total 0
drwxr-xr-x 2 root root 60 Apr 24 22:18 by-path
crw-rw---- 1 root audio 116, 2 Apr 24 22:18 controlC0
crw-rw---- 1 root audio 116, 3 Apr 24 22:18 pcmC0D0p
crw-rw---- 1 root audio 116, 1 Apr 24 22:18 seq
crw-rw---- 1 root audio 116, 33 Apr 24 22:18 timer

My next ‘Intel’ project is a low-cost small laptop, based on a Chromebook, running Linux/Fedora25 natively, and more details will be coming soon..

Robert Gadsdon.   April 26, 2017..

NVIDIA – Still no 4.11 Solution, but a ‘Good’ Patch for Old Version..

Posted on by April 23, 2017
Reply

Kernel 4.11 ‘final’ has been delayed for a week, and -rc8 has been released..     4.11-patched VMware 12.5.5 is OK, but there is still only a ‘Bad’ (illegal licence modification) patch for the latest NVIDIA driver..   (see https://devtalk.nvidia.com/default/topic/1002820/linux/-patch-381-09-kernel-4-11-rc5/ )

But, if you have an older card, there is a valid patch for driver 340.102 – which does not include the controversially-licensed code..

Details can be found here:    https://devtalk.nvidia.com/default/topic/1005209/linux/fully-working-patch-for-nvidia-driver-340-102-compiler-installer-file-and-linux-kernel-4-11/

I can confirm that this compiles OK with Kernel 4.11-rc8, but cannot test any further, as it does not support my – fairly new – card.

Robert Gadsdon.   April 23, 2017.

 

NVIDIA – New Driver, Finally OK with Kernel 4.10..

Posted on by April 6, 2017
Reply

NVIDIA have released a new ‘beta’ driver – 381.09 – and release notes etc. are here: http://www.nvidia.com/download/driverResults.aspx/117002/en-us

The driver compiles OK with Kernel 4.10 (tested with 4.10.8) but still requires an ‘illegal’ patch for 4.11, due to ongoing code licensing issues..    There is a patch available, and details are here:   https://devtalk.nvidia.com/default/topic/1002820/linux/-patch-381-09-kernel-4-11-rc5/

Robert Gadsdon.   April 6, 2017.

VMware – 12.5.5. released – Another ‘Security Fix’..

Posted on by March 29, 2017
Reply

VMware 12.5.5 is out, and the release notes are here:  http://pubs.vmware.com/Release_Notes/en/workstation/12pro/workstation-1255-release-notes.html

As with 12.5.4, this is another security/fix release, and still supports Kernels 4.10 and earlier.    (see http://rglinuxtech.com/?p=1937 )

12.5.5 runs OK on Kernel 4.10.6, and the 4.11 vmmon and vmnet patches still apply (tested on 4.11-rc4)….

Robert Gadsdon.   March 29, 2017.

VMware – 12.5.4 Released – Security Fix Only..

Posted on by March 16, 2017
Reply

Hot on the heel of VMware 12.5.3 comes 12.5.4, and the release notes are here: http://pubs.vmware.com/Release_Notes/en/workstation/12pro/workstation-1254-release-notes.html

As can be seen from these notes, this is an urgent-security-fix release only, and the compatibility with Linux kernel versions, and patch applicability, is the same as for 12.5.3 (see http://rglinuxtech.com/?p=1937 ) .      I can confirm that 12.5.4 runs OK on Kernel 4.10.3, and the 4.11 patchset still applies..

Robert Gadsdon.   March 15, 2017.

Kernel – 4.11-rc1 and BTRFS – a Warning..?

Posted on by March 14, 2017
1

I encountered a catastrophic problem with btrfs formatted system disk partition corruption, shortly after updating a test system to Kernel 4.11-rc1.

To put this in context, this may be an isolated incident, and I have not seen problems – so far – mentioned elsewhere..    But.. there a quite a lot of BTRFS changes on 4.11, and – after the usual tests – I confirmed that system memory was OK (running memtest86+ several times..) and the disk was OK (running smartmontools utilities etc. several times).    The disk is only one year old, in any case (WD – 2GB)..

Unfortunately, I did not have a serial console attached to this particular system  at the time, and so had to photograph the screen at various times, and then re-type the details below from those photos (!)..

The scenario:

System disk (/dev/sda2) is formatted btrfs..
Updated to Kernel 4.11-rc1.
Within 24 hours, the system froze, and on rebooting, got a critical btrfs error:

...................
 Mounting /sysroot....
BTRFS critical (device sda2): corrupt node, bad key order: block=368346054656, root=1, slot=192
BTRFS critical (device sda2): corrupt node, bad key order: block=368346054656, root=1, slot=192
BTRFS error (device sda2): failed to read block groups: -5
BTRFS error (device sda2): open_ctree failed
[FAILED] Failed to mount /sysroot
See 'systemctl status sysroon.mount' for details
[DEPEND] Dependency failed for Initrd Root File System.
[DEPEND] Dependency failed for Reload Configuration from the Real Root.
......................
 Starting Emergency Shell...

Ran:

:/# btrfs check /dev/sda2
Checking filesystem on /dev/sda2
UUID xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx
checking extents
bad block 33488896
Errors found in extent allocation tree or chunk allocation
^C
:/# btrfs rescue chunk-recover /dev/sda2
Scanning: 66126696448 in dev0

Then got scrolling screens full of:

...........
Deleting bad dir index [537997,96,160] root 5
Deleting bad dir index [537997,96,168] root 5
Deleting bad dir index [537997,96,170] root 5
Deleting bad dir index [537997,96,180] root 5
Deleting bad dir index [537997,96,186] root 5
Deleting bad dir index [537997,96,190] root 5
Deleting bad dir index [537997,96,198] root 5
................ continuing...

Then more scrolling screens full of:

...............
Trying to rebuild inode:1658592
root 5 inode 1658592 error 2001, no inode item, link count wrong
 unresolved ref dir 198531 index 0 namelen 18 name gtk-indent-ltr.png filetype 7 errors 6, no dir index, no inode ref
Trying to rebuild inode:1658593
root 5 inode 1658593 error 2001, no inode item, link count wrong
 unresolved ref dir 198531 index 0 namelen 18 name gtk-indent-rtl.png filetype 7 errors 6, no dir index, no inode ref
............... continuing....

Then more scrolling screens full of:

..............
repairing missing dir index item for inode 30734433
repairing missing dir index item for inode 30734434
repairing missing dir index item for inode 30734435
repairing missing dir index item for inode 30734436
repairing missing dir index item for inode 30734437
repairing missing dir index item for inode 30734438
repairing missing dir index item for inode 30734439
............ continuing...

Then more scrolling screens full of:

..............
Deleting bad dir index [363308,96,63443] root 5
Deleting bad dir index [363396,96,12025] root 5
The following tree block(s) is corrupted in tree 5:
 tree block bytenr: 44061900800, level: 1, node key: (365821249776, 168, 45056)
Try to repair the btree for root 5
Btree for root 5 is fixed
Deleting bad dir index [364225,96,3382] root 5
Deleting bad dir index [363308,96,63425] root 5
Deleting bad dir index [363308,96,63427] root 5
Deleting bad dir index [363308,96,63427] root 5
........... continuing ...........

The ‘recovery’ kept running, although appearing to stall, several times, but I just left it and it ran for almost three days in total, and finally ended:

..............
Btree for root 5 is fixed
root 5 root dir 256 error
root 5 inode 256 errors 200, dir isize wrong
reset isize for dir 2139040 root 5
reset isize for dir 2139040 root 5
..................
Trying to rebuild inode:33318043
moving file 'lost+found' to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 33318043
found 583909376 bytes used err is 1
total csum bytes: 0
total tree bytes: 1884160
total fs tree bytes: 0
total extent tree bytes: 1474560
btree space waste bytes: 758524
file data blocks allocated: 201064448
 referenced 201064448
:/#
:/#

After all that, I rebooted:

...................
 Mounting /sysroot....
BTRFS critical (device sda2): corrupt node, bad key order: block=44061900800, root=1, slot=192
BTRFS critical (device sda2): corrupt node, bad key order: block=44061900800, root=1, slot=192
BTRFS error (device sda2): failed to read block groups: -5
BTRFS error (device sda2): open_ctree failed
[FAILED] Failed to mount /sysroot
See 'systemctl status sysroon.mount' for details
[DEPEND] Dependency failed for Initrd Root File System.
[DEPEND] Dependency failed for Reload Configuration from the Real Root.
....................
Entering emergency mode..............

So… The btrfs recovery was a waste of three days, and did not fix the problem.. I will now have to re-create the data from another source.. Fortunately this was ‘just’ the system disk partition and no irreplaceable recent user data was lost, apart from /root…

I should mention as well, that all other btrfs-formatted partitions on other systems, running 4.10.x and earlier, have been error-free, and reliable.   And… I have not tried 4.11-rc2 with BTRFS, yet..

Robert Gadsdon.   March 14, 2017.

VMware – Not Working with Fedora 26 – GCC 7, and Workarounds..

Posted on by March 12, 2017
6

I have recently updated one crash-and-burn system to Fedora 26 (alpha/testing) and have encountered two problems with VMware and the ‘bleeding edge’ version of GCC included..

The first problem sounded very familiar, and it is a repeat of one from 2015, where the vmware runtime would simply not start, with no output..   (see http://rglinuxtech.com/?p=1601 )..  The second problem was with the ‘automated’ compilation of the VMware modules, and none of the usual methods worked.   Both problems can be traced to Fedora 26’s use of GCC version 7 (currently 7.0.1)

To get the vmware runtime to execute, force it to use the Fedora 26 versions of various glib2 libraries:

As root, cd to /usr/lib/vmware/lib , then:

# cp -afv /usr/lib64/libgio-2.0.so.0.5104.0 libgio-2.0.so.0/libgio-2.0.so.0
# cp -afv /usr/lib64/libglib-2.0.so.0.5104.0 libglib-2.0.so.0/libglib-2.0.so.0
# cp -afv /usr/lib64/libgmodule-2.0.so.0.5104.0 libgmodule-2.0.so.0/libgmodule-2.0.so.0
# cp -afv /usr/lib64/libgobject-2.0.so.0.5104.0 libgobject-2.0.so.0/libgobject-2.0.so.0
# cp -afv /usr/lib64/libgthread-2.0.so.0.5104.0 libgthread-2.0.so.0/libgthread-2.0.so.0

The VMware libraries are each in their own individual directory, with the same name as that library.. Of course, the Fedora 26 library version numbers may change over time..

After that, run vmware, forcing the use of the copied libraries:

# VMWARE_USE_SHIPPED_LIBS=force vmware

The application will run, but will immediately encounter the second problem…   VMware does not ‘recognise’ GCC version 7..

The vmware runtime graphical module compiler/installer will complain that ‘GNU C Compiler (gcc) version 6.3.1 was not found’, and then ‘A compatible version of gcc was not found’..

The command-line installer fails, but with less detail:

# vmware-modconfig --console --install-all
Failed to get gcc information.

The fix is a bit messy, but does work..

The VMware 12.5.3 vmmon and vmnet modules will actually both compile OK with GCC 7.0.1, and the trick is to manually install these, and then run the vmware runtime application directly, instead of via the normal ‘complaining’ scripts..

In the /usr/lib/vmware/modules/source directory, unTAR vmmon.tar and vmnet.tar, and then enter the resulting vmmon-only and vmnet-only directories and just type # make in each. Then create a /lib/modules/<kernel version>/misc directory, and copy vmmon.ko and vmnet.ko there, then #depmod -a.

To run the vmware runtime directly, instead of /usr/bin/vmware, run /usr/lib/vmware/bin/vmware, and the runtime application should execute without any gcc checks etc….

Combining the two workarounds, the runtime command is now:

# VMWARE_USE_SHIPPED_LIBS=force /usr/lib/vmware/bin/vmware

I have tested this with Fedora 26 – with GCC 7.0.1, and VMware 12.5.3, and it works..     The current release schedule shows this version of Fedora will be released around June 2017, but – of course – this may well slip..

Robert Gadsdon.  March 12, 2017.

Thanks to Vincent Cojot for the original glib2 fix info, in 2015..

VMware – 12.5.3 released – OK with Kernel 4.10. 4.11 Patch Still Works..

Posted on by March 11, 2017
4

VMware 12.5.3 has been released, and release notes are here:  http://pubs.vmware.com/Release_Notes/en/workstation/12pro/workstation-1253-release-notes.html

Although these notes only mention Kernel 4.9.0, I can confirm that it also supports 4.10.x Kernels (tested on 4.10.1).

I applied the vmmon and vmnet patches for Kernel 4.11, mentioned in a previous article, and these still worked, and VMware compiled OK, and ran, on 4.11-rc1..

Robert Gadsdon.   March 11, 2017.