Showing posts with label Xenial Xerus. Show all posts
Showing posts with label Xenial Xerus. Show all posts

Thursday, August 4, 2016

Upgrade to Xenial Xerus, Virtualbox, and more..

Each time upgrading the Ubuntu is like taking a challenge. When I bought this laptop in 2014 February, I installed Ubuntu 13.10, and later upgraded it to the next LTS version in August (14.04.1). Now this is my second upgrade in this laptop, again to the next LTS version (16.04.1 - Xenial Xerus). While this is all exciting, all upgrades come with some breaks in previously working and stable software. This time, VirtualBox is broken. I am sure it is not the only one though.

So I got this error, when I tried to open an existing VM or create a new VM in the VirtualBox following my upgrade.

Kernel driver not installed (rc=-1908)

The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a permission problem with /dev/vboxdrv. Please reinstall the kernel module by executing

'/etc/init.d/vboxdrv setup'

as root. If it is available in your distribution, you should install the DKMS package first. This package keeps track of Linux kernel changes and recompiles the vboxdrv kernel module if necessary.




When I tried to do as suggested:


root@llovizna:/home/pradeeban# /etc/init.d/vboxdrv setup
Stopping VirtualBox kernel modules ...done.
Uninstalling old VirtualBox DKMS kernel modules ...done.
Trying to register the VirtualBox kernel modules using DKMSERROR: Cannot create report: [Errno 17] File exists: '/var/crash/virtualbox-4.3.0.crash'
Error! Bad return status for module build on kernel: 4.4.0-31-generic (x86_64)
Consult /var/lib/dkms/vboxhost/4.3.28/build/make.log for more information.
 ...failed!
  (Failed, trying without DKMS)
Recompiling VirtualBox kernel modules ...failed!
  (Look at /var/log/vbox-install.log to find out what went wrong)


Finally, I had to uninstall and reinstall everything
 
sudo apt-get remove virtualbox-\*
 

Luckily, all the VMs and virtual hard disks were safe and ready to use (thanks to virtualization!)

Wednesday, August 3, 2016

Bad guy Windows and good guy Ubuntu

A few moments ago I upgraded my Ubuntu 14.04 LTS to Ubuntu 16.04.1 LTS (Xenial Xerus). I waited for the service pack 1 to be released in the end of July, and hence the delay. Everything was smooth, and my dual boot runs perfectly well with Windows and Ubuntu just as before. On the other hand, every time Windows does a minor upgrade (not just the Windows 8 to Windows 10 upgrade), it breaks my grub and makes Windows the default and only option, making Ubuntu unreachable. Luckily I have a Lubuntu-based software, named boot-repair-disk that can fix these boot issues. The current version of the software does not work for Windows 10. However, I have a previous version with me that just works fine.

I am not entirely sure why Windows made each upgrade to break the grub. Is it made intentionally, or is it that hard for the engineers to fix this minor bug (or may I say, feature?). This is so annoying and inconvenient. This makes Windows look like a big bully.

So now I have the latest LTS version, and I will upgrade again in 2018 August with 18.04.1 LTS. I made some interesting observations during the upgrade.

Configuring encfs ├──────────────────────────────────────────────────────────────────────────────────────────┐ 
 │                                                                                                                                                                                                        │ 
 │ Encfs security information                                                                                                                                                                             │ 
 │                                                                                                                                                                                                        │ 
 │ According to a security audit by Taylor Hornby (Defuse Security), the current implementation of Encfs is vulnerable or potentially vulnerable to multiple types of attacks. For example, an attacker   │ 
 │ with read/write access to encrypted data might lower the decryption complexity for subsequently encrypted data without this being noticed by a legitimate user, or might use timing analysis to        │ 
 │ deduce information.                                                                                                                                                                                    │ 
 │                                                                                                                                                                                                        │ 
 │ Until these issues are resolved, encfs should not be considered a safe home for sensitive data in scenarios where such attacks are possible.                                                           │ 
 │                                                                                                                                                                                                        │ 
 │                                                                                                                                                                                                    │ 
 │                                                                                                                        


So, EncFS is not secure after all.


The other prompt that caught my attention was the below:


 Configuring davfs2 ├──────────────────────────────────────────────────────────────────┐                        
                         │                                                                                                                                                         │                        
                         │ The file /sbin/mount.davfs must have the SUID bit set if you want to allow unprivileged (non-root) users to mount WebDAV resources.                     │                        
                         │                                                                                                                                                         │                        
                         │ If you do not choose this option, only root will be allowed to mount WebDAV resources. This can later be changed by running 'dpkg-reconfigure davfs2'.  │                        
                         │                                                                                                                                                         │                        
                         │ Should unprivileged users be allowed to mount WebDAV resources?                                                                                         │                        
                         │                                                                                                                                                         │                        
                         │                                                                                               []                                                 │                        
                         │                                                                                                                      

As of now, everything seems to work just fine after the upgrade. I will update further when I find out whether something is broken due to the upgrade, later.