Installed Kubuntu 18.04 today. My experiences ....

[GreyGeek]

I used the Persistent LiveUSB of Bionic that I made a few days ago and checksummed.
The installation took 22 minutes. I chose a clean drive with sda1 as the only partition, and used Btrfs as my root file system.
Plasma in Bionic is 5.12.4. In my Neon User Edition (16.04) it is currently at 5.12.5.

The first thing I usually do on a new clean install is add the printer. Mine is an HP LaserJet P1606dn attached to a USB port. I opened the printer config tool in the System Settings dialog and noticed that my printer was showing as completely and automatically installed as the default printer. I printed a test page, which printed perfectly. The duplex feature wasn't working so I navigated to that config page and set it. Now it works. Sweet.

I changed the theme to breeze light and downloaded my favorite wallpapers. I'm looking at the cute kitten licking its paw when the desktop is visible.

I opened my @Neon1604home_2018_05_02 snapshot and copied most of the contents of my home account into my Bionic home account.
That allowed me to import my current bookmarks. I set the "Send Mail" icon.

I downloaded the "Thermal Monitor" widget and installed it to show the temps for CPU0, GPU, and HD0, my primary sda HD.
Minecraft is a necessity. I opened a Konsole and issued "java -jar Minecraft.jar" in the ~/Minecraft directory. I was greeted with a ton of ca-certificate errors from the openjdk-11 java. I could not log into Mojang to verify my installation. Using "sudo update-ca-certificates -f" in a Konsole did not clear up the problem. I purged the openjdk-11 and java-common and all of its related packages and installed openjdk-8 and java-common with all of its related packages. THEN Minecraft ran and I could log in and run my 1.12 map.

When the "Ubuntu-Drivers" gui dialog appeared it displayed three drivers (340, 390 and Nouveau). I chose the 390 because it is what I use in Neon and it installed and ran perfectly. After the installation was complete I rebooted and checked the NVidia Config dialog and noticed all the pertinent info and switching capability was missing. The display was still using the i915 driver. I compared the installed nvidia files with my Neon installation and noticed several relating to bumblebee were missing. I selected the bumblebee-prime and a dialog appeared displaying a total of 34 additional package to install. I installed them all and rebooted. NVidia's config dialog was in order and Minecraft gave me 465 fps, compared to 60 on the i915 driver.

I'm going to install Thunderbird tomorrow, and then check out SageMath and some other apps I carried over from Neon, including all of the AppImage packages.

The openjdk-11 ca-certs problem and the incomplete install of NVidia tainted an otherwise perfect install and setup.

[GreyGeek]

I had copied Thunderbird's config file from @Neon1604 after installing Thunderbird but before running it. When I ran it I was asked if I wanted to use the existing vendor and I clicked yes. Almost instantly my email connection was set up and all the folders residing out on my ISP's email site were installed. As I clicked through each folder all my emails were imported as well. Perfect install.

My next task was to install my IPV6 tunnel. I added the script supplied by Hurricane Electric's tunnel config box and pasted it into /etc/network/interfaces.
Then I installed ifupdown from the repository because Bionic did not include that app in the default install. Then I issued
sudo ifup he-ipv6
wget -O/dev/null http://ipv6.google.com/
proved that my IPv6 tunnel was working. I fired up FireFox and display http://ipv6-test.com/
It gave me 19/20 because IPv4 was still the fallback.
I opened /etc/gai.conf and took the "#" off of the "preference" and "label" lines.

# Configuration for getaddrinfo(3).
#
# So far only configuration for the destination address sorting is needed.
# RFC 3484 governs the sorting.  But the RFC also says that system
# administrators should be able to overwrite the defaults.  This can be
# achieved here.
#
# All lines have an initial identifier specifying the option followed by
# up to two values.  Information specified in this file replaces the
# default information.  Complete absence of data of one kind causes the
# appropriate default information to be used.  The supported commands include:
#
# reload  <yes|no>
#    If set to yes, each getaddrinfo(3) call will check whether this file
#    changed and if necessary reload.  This option should not really be
#    used.  There are possible runtime problems.  The default is no.
#
# label   <mask>   <value>
#    Add another rule to the RFC 3484 label table.  See section 2.1 in
#    RFC 3484.  The default is:
#
label ::1/128       0
label ::/0          1
label 2002::/16     2
label ::/96         3
label ::ffff:0:0/96 4
label fec0::/10     5
label fc00::/7      6
#label 2001:0::/32   7
#
#    This default differs from the tables given in RFC 3484 by handling
#    (now obsolete) site-local IPv6 addresses and Unique Local Addresses.
#    The reason for this difference is that these addresses are never
#    NATed while IPv4 site-local addresses most probably are.  Given
#    the precedence of IPv6 over IPv4 (see below) on machines having only
#    site-local IPv4 and IPv6 addresses a lookup for a global address would
#    see the IPv6 be preferred.  The result is a long delay because the
#    site-local IPv6 addresses cannot be used while the IPv4 address is
#    (at least for the foreseeable future) NATed.  We also treat Teredo
#    tunnels special.
#
# precedence  <mask>   <value>
#    Add another rule to the RFC 3484 precedence table.  See section 2.1
#    and 10.3 in RFC 3484.  The default is:
#
precedence  ::1/128       50
precedence  ::/0          40
precedence  2002::/16     30
precedence ::/96          20
precedence ::ffff:0:0/96  10
#
#    For sites which prefer IPv4 connections change the last line to
#
#precedence ::ffff:0:0/96  100

#
# scopev4  <mask>  <value>
#    Add another rule to the RFC 6724 scope table for IPv4 addresses.
#    By default the scope IDs described in section 3.2 in RFC 6724 are
#    used.  Changing these defaults should hardly ever be necessary.
#    The defaults are equivalent to:
#
#scopev4 ::ffff:169.254.0.0/112  2
#scopev4 ::ffff:127.0.0.0/104    2
#scopev4 ::ffff:0.0.0.0/96       14

I rebooted to make sure the changes would hold the next time I fired up the laptop. They held. My browser was now defaulting to IPv6 and using IPv4 as the "less than 1 sec" fallback.

Unfortunately, my NVidia settings did not survive the reboot.

The sad message is here:

[ 14.176792] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 26.772956] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 26.772958] Bluetooth: BNEP filters: protocol multicast
[ 26.772962] Bluetooth: BNEP socket layer initialized
[ 28.110694] bbswitch: version 0.8
[ 28.110702] bbswitch: Found integrated VGA device 0000:00:02.0: \_SB_.PCI0.GFX0
[ 28.110706] bbswitch: Found discrete VGA device 0000:01:00.0: \_SB_.PCI0.PEG0.PEGP
[ 28.110811] bbswitch: detected an Optimus _DSM function
[ 28.110846] bbswitch: Succesfully loaded. Discrete card 0000:01:00.0 is on
[ 28.111592] [drm] [nvidia-drm] [GPU ID 0x00000100] Unloading driver
[ 28.144318] nvidia-modeset: Unloading
[ 28.172709] nvidia-uvm: Unloaded the UVM driver in 8 mode
[ 28.196407] nvidia-nvlink: Unregistered the Nvlink Core, major device number 243
[ 28.225070] bbswitch: disabling discrete graphics
[ 28.244122] pci_raw_set_power_state: 13 callbacks suppressed
[ 28.244128] pci 0000:01:00.0: Refused to change power state, currently in D0

My Nvidia install survived many reboots and only failed after I got the tunnel going.

My first clue was that after the reboot, the mouse arrow, which is normally in the upper left corner, was right over the text box for entering the login password. I decided that rather than logging off and back on, or doing warm boot (reboot), I'd shut down, wait 30 seconds, and do a cold boot. It worked. My NVidia card had control of the desktop again. Not everything in memory gets cleared in a warm boot (reboot). I could see that because the GPU temp in the Thermal Monitor widget was showing the actual temperature. When the NVidia card isn't selected it shows "off". Also, the spinning wheel is a blur and for a very short duration when NVidia is in control.

So, all in all, I'm now running a VERY SWEET Bionic! I think it is time to do a snapshot for @ and @home to save the current condition.

[GreyGeek]

I observed that after the 390 Nvidia driver was installed in Bionic I no longer had to pop open a terminal from the login screen and issue "sudo systemctl restart sddm", which popped me back into the login screen again. This was to avoid mouse pointer artifacts on the desktop. Also, adding enigmail to Thunderbird allowed me to use my Gpg key without problems. Copying Sage and Thunderbird over from the Neon snapshot, along with their config files, allowed those two apps to run without re-installing.

However, preferring Neon's rolling release paradigm riding on the front edge of KDE development, this morning I switched back to Neon User Edition and decides to do a fresh install so I could re-arrange my three HDs and switch to UUIDs instead of /dev/sdX naming. That done, I noticed that with the nvidia-384 installed I again have to do the "sudo systemctl restart sddm" to avoid mouse pointer artifacts. That slight inconvenience doesn't concern me. I also noticed that under Neon the add-on enigmail, doesn't work with Thunderbird the way it does in Bionic.

So, that completes my exploration of Bionic. All in all, a very nice distro, just not my cup of tea.

[woodsmoke]

My very lastest, bestest build is still in testing...

I am going to TRY to make a true dual boot HD...

and YEEEECCCHHHHHHHHH

as Ben Rumson would have said...



and Kubu

dunnno...

Away out here they've got a name
For rain and wind and fire
The rain is Tess,
The fire's Joe
And they call the wind Maria...

Maria blows the stars around...

and...

Sets the clouds a-flyin'...

Maria makes
The mountains sound...

... like folks was out there... dyin'...
Maria... (Maria)
Maria ...(Maria)
They call...

The wind...

Mariiiiaaai...

AND...
Before I knew
Maria's name
And heard her wail and whinin'

I had a gal
And she had me
And the sun
Was always shinin'...

...
But then one day
I left my gal
I left her far behind me...

her name was ...Kelliiiii...

and now...

And now I'm lost,
So gol' darn lost
Not even God
Can find me...

Maria...

Maria...

They CALL...

The wind...

Mariiiiiaaaa...

Out here... they have... a name... for rain

And .for...the wind…

and...

her name ...is...
...Maria...

Kelli...where are you...

in the wind...

and the rain...where are you...

[papapenguin]

I had a big problem with the upgrade...

upgrade from 17.10 failed...help...

...so I installed it on a brand spankin' new drive with no problems.

One thing that really really works is my RealTek RTL8821AE driver -- it not only works out of the box, but it stays connected!!!

[GreyGeek]

Good news!
Did you, by chance, happen to choose Btrfs as your root filesystem?

[papapenguin]

I used the default filesystem, which I think is ext4 -- which was also my last filesystem. For some reason it 'offset' the blocks in my drive, then I got a kernel panic.

[GreyGeek]

I used the default filesystem, which I think is ext4 -- which was also my last filesystem. For some reason it 'offset' the blocks in my drive, then I got a kernel panic.

Did you resolve that problem?

[papapenguin]

Unfortunately, no.

I bought another SSD and installed a clean version of Kubuntu 18.04 on that drive. Then I used Clonezilla to make a copy of that drive to a USB. I then used testdisk to repair the sectors on the copy and got my data back. When I tried the same recovery method on the actual drive, testdisk couldn't recover the data...strange...

[GreyGeek]

So the first drive was a new SSD that failed on first use? What kind of warranty did it come with?

Not surprising, from what I've read. Unless you pay good money for a Samsung EVO or PRO that comes with a 3 year warranty you stand a good chance of having the drive instantaneously die for no apparent reason. That's why I am hesitant about switching to SSDs. They give no warning about their impending death.

[papapenguin]

It was a drive that I've had for a couple of years. I installed 16.04 then upgraded to 17.10, then attempted to upgrade to 18.04 when the updating process corrupted the drive. The drive itself checks out as healthy, it was something in the reordering of blocks or rebuilding of the OS that corrupted it. Unfortunately this drive doesn't have a warranty.

What happened in the interim is that I tried to save that drive by installing 18.04 on a basically brand new HDD (not SSD) and that drive totally crashed. That one should be under warranty.

I then bought a 3rd SSD and that's what I'm using now.