Basic installation

1. Download armbian for your device from https://www.armbian.com/download/ the CLI editions are sufficient and have no UI. If you cannot find your device or device version, check something similar named or the first model from your model line, e.g. if you have a Raspberry Pi 3, check the Raspberry Pi download, you device revision may be listed unter "Compatible".  The filter does not show all manufacturer, so just scroll the list down. For my odroid-mc1 I have to scroll down and choose Odroid XU4 / HCx. Read the notes on the page, there might be important settings, as for my odroid-mc1 I can configure an optimized board configuration after installation. 
2. Flash Armbian Image to sdcard, e.g. BalenaEtcher
3. Boot Armbian, wait until it is online, this may take some time. I check this by looking at my DHCP logs from my dnsmasq server, you may also get the IP address from your router if  the name registration resolution is not working 
4. Login as root (any ssh client like PuTTY on windows),password 1234.
   1. Change the root password
   2. Choose your shell
   3. Cancel user account creation with ctrl-c or create a user account if you prefer to type sudo all the time. Your choice.
5. Do apt update && apt dist-upgrade && reboot
6. Edit the hostname in the file /etc/hostname. nano is installed, vi needs to be installed with apt install vim or your prefered vi version. My guess the hostname is always the model name. 
7. If you haven't applied any recommended changes for your machine, do it now, for me it required a reboot, so afterwards the device should be available under the new hostname. 
8. Install VirtualHere Server on the device by running curl https://raw.githubusercontent.com/virtualhere/script/main/install_server | sh . If you aren't root, write sudo before the sh (not the curl!) as usual. The service is automatically started. On your client, install the VirtualHere client. For some reason he cannot find the server automatically, so I have to add it manually by right clicking on USB Hubs and do "Specify Hubs". Add here your choosen hostname or IP adress + the default port. If any device is connected to your new print server, it should be visible where and with right click yoo can connect it.
9. Do a reboot with the command reboot and test if  it comes up again. 
10. If you have connected any USB device, starting the client on the PC and scanning (did not work for me) or configuring a host manually should should the connected USB devices. 
11. You are ready to use the now "networked" device. Oh and it's by default not encrypted nor password protected. 

Some minor hardening

1. apt install overlayroot
2. edit /etc/overlayroot.conf and change the last line to overlayroot="tmpfs"
3. reboot

1. overlayroot-chroot
2. make your changes
3. exit 

1. overlayroot-chroot
2. edit /etc/overlayroot.conf and comment out the line we added earlier by prepending a hash sign. Then do a clean reboot and after that the filesystem is writable again for everybody
3. reboot
4. make your changes 
5. remove the comment hash sign in /etc/overlayroot.conf
6. reboot

• Automated updates: unattended-upgrade
• WiFi functionality: wireless-regdb wireless-tools wpasupplicant
• Development stuff: gcc-12 cpp-12 gcc-11 git
• When not running from a real SSD or HDD: smartmontools
• NFS (this is not file server): rpcbind

1. Make the root file system writable (see above) 
2. echo 'SUBSYSTEM=="net", ATTR{power/control}="on"' >>  /etc/udev/rules.d/99-nic-powermanagement.rules
3. reboot

# lsusb
Bus 006 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter

# cat /sys/class/net/enx001e06373d78/power/control
auto

# Condition: is network device, actions: write on into its power/control sysfs file (if it exists..)
#SUBSYSTEM=="net", ATTR{power/control}="on"

# Conditions: is network device and has productId 8513, actions: write on into its power/control sysfs file
SUBSYSTEM=="net", ATTRS{idProduct}=="8153" , ATTR{power/control}="on"

# Conditions: is network device and has productId 8513 and power/control is set to auto, then set it to on
#SUBSYSTEM=="net", ATTRS{idProduct}=="8153", ATTR{power/control}=="auto", ATTR{power/control}="on"

# udevadm info -a -p /sys/class/net/enx001e06373d78

SUBSYSTEM=="usb", ATTR{idVendor}=="0bda", ATTR{idProduct}=="8153", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", ATTR{bConfigurationValue}="$env{REALTEK_NIC_MODE}"

# readlink -f /sys/class/net/enx001e06373d78/device
/sys/devices/platform/soc/soc:usb3-1/12400000.dwc3/xhci-hcd.8.auto/usb6/6-1/6-1:1.0 

# ls -al /sys/bus/usb/devices/6-1:1.0/
total 0
drwxr-xr-x 7 root root    0 Jul 15 04:46 .
drwxr-xr-x 6 root root    0 Jul 15 04:46 ..
-rw-r--r-- 1 root root 4096 Jul 15 04:51 authorized
-r--r--r-- 1 root root 4096 Jul 15 04:51 bAlternateSetting
-r--r--r-- 1 root root 4096 Jul 15 04:46 bInterfaceClass
-r--r--r-- 1 root root 4096 Jul 15 04:46 bInterfaceNumber
-r--r--r-- 1 root root 4096 Jul 15 04:51 bInterfaceProtocol
-r--r--r-- 1 root root 4096 Jul 15 04:51 bInterfaceSubClass
-r--r--r-- 1 root root 4096 Jul 15 04:51 bNumEndpoints
...

# ls -al /sys/bus/usb/devices/6-1:1.0/power
total 0
drwxr-xr-x 2 root root    0 Jul 15 04:46 .
drwxr-xr-x 7 root root    0 Jul 15 04:46 ..
-rw-r--r-- 1 root root 4096 Jul 15 04:51 async
-r--r--r-- 1 root root 4096 Jul 15 04:51 runtime_active_kids
-r--r--r-- 1 root root 4096 Jul 15 04:51 runtime_enabled
-r--r--r-- 1 root root 4096 Jul 15 04:51 runtime_status
-r--r--r-- 1 root root 4096 Jul 15 04:51 runtime_usage

After upgrading from an old FX-8350 to a new ThreadRipper VirtualBox was not able to start any VM in Linux. The error  shown in VM was something like "NS_ERROR_FAILURE (0x80004005)"

And in the VM logs were these entries: 

!!Assertion Failed!!
Expression: pVM->pVMR0 == CreateVMReq.pVMR0
Location  : /home/vbox/tinderbox/6.0-lnx64-rel/src/VBox/VMM/VMMR3/VM.cpp(591) int vmR3CreateU(UVM*, uint32_t, int (*)(UVM*, VM*, void*), void*)
Stack     :
00007f8970304133 VBoxRT.so + 0x1f1133

Instructions to boot Linux on the AMD Mobile Ryzen based Dell Latitude 14 5495:

1. Connect a bootable Linux USB Device (e.g. Optical Drive, Stick, HDD, etc..)
2. Boot
3. Rejoice, Linux will run fine

Okay, it was not so easy. I had trouble with getting the UEFI  to boot from my USB device (the IODD). The UEFI just ignored the device and booted into Win10 from the internal SATA SSD, even when the SSD and the Win bootloader were both disabled in the boot manager. In the end I added manually the EFI bootloader from the Live-CD to the bootmanager by choosing "Add boot option" (or so) and then navigating to the *.efi boot loader on the device. Then I was able to boot via the boot manager. Afterwards I removed the boot entry. Might be an issue with the IODD.

Update 2018-10-07

Okay, there are more issues:

Boot Medium not found after Linux

This is rather weird, when (re-boot) after using the installed Ubuntu 18.04, the UEFI/BIOS cannot find the boot medium and I have to enter the UEFI setup. Without changing anything, on the next boot, everything is okay again, and the notebook will boot the default UEFI boot entry (which is WIndows). I have no clue what is causing this. 

PCIe Power Management Log Entry

Seems that the PCIe Power Management does not only cause issues with audio output, NVMes do not like it, too: 

Touchpad scrolling does not always work

Haven't found a real solution for this yet. Sometimes scrolling with two fingers on the touchpad does not work. After a reboot it may (or may not) work again.  

Update 2018-12-06

The list grows longer and I renamed this article as booting is no problem, but there are still other issues. 

Okay, I tried to do a backup of my windows partition from my installed Ubuntu and a few seconds after pushing over 100MB/s through netcat, the transfer stalled. More precisely, the network connection was dead. Device was up, but nothing went through. In the kernel log I found the entries below. This was reproducible, it also happed in clonezilla, which I tried before and thought the failing connection was a clonezilla issue. Solution or workaround is iommu=soft which was also recommended as alternative workaround for the Lenovo E485 issue. Why can't things just work??? 

Dec  3 23:27:00 notebook kernel: [  162.778572] ------------[ cut here ]------------
Dec  3 23:27:00 notebook kernel: [  162.778604] NETDEV WATCHDOG: enp2s0 (tg3): transmit queue 0 timed out
Dec  3 23:27:00 notebook kernel: [  162.778631] WARNING: CPU: 5 PID: 0 at /build/linux-Y38gIP/linux-4.15.0/net/sched/sch_generic.c:323 dev_watchdog+0x221/0x230
Dec  3 23:27:00 notebook kernel: [  162.778632] Modules linked in: ccm rfcomm arc4 cmac bnep nls_iso8859_1 snd_hda_codec_realtek dell_laptop joydev snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm ath10k_pci snd_seq_midi
 ath10k_core snd_seq_midi_event edac_mce_amd snd_rawmidi btusb ath dell_wmi kvm_amd mac80211 kvm dell_smbios snd_seq irqbypass input_leds hid_multitouch btrtl dcdbas btbcm wmi_bmof sparse_keymap serio_raw btintel dell_wmi_descriptor bluetooth snd_seq_device k10temp snd_t
imer ecdh_generic snd cfg80211 soundcore rtsx_pci_ms memstick shpchp ucsi_acpi typec_ucsi typec dell_rbtn dell_smo8800 mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 xfs libcrc32c algif_skcipher af_alg dm_crypt amdkfd rtsx_pci_sdmmc amd_iommu
_v2 crct10dif_pclmul crc32_pclmul
Dec  3 23:27:00 notebook kernel: [  162.778705]  ghash_clmulni_intel pcbc amdgpu aesni_intel chash aes_x86_64 i2c_algo_bit crypto_simd ttm glue_helper cryptd drm_kms_helper ahci syscopyarea sysfillrect libahci psmouse sysimgblt fb_sys_fops tg3 drm nvme ptp i2c_piix4 nvme_core rtsx_pci pps_core wmi video i2c_hid hid
Dec  3 23:27:00 notebook kernel: [  162.778735] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G        W        4.15.0-42-generic #45-Ubuntu
Dec  3 23:27:00 notebook kernel: [  162.778737] Hardware name: Dell Inc. Latitude 5495/09H2MJ, BIOS 1.2.3 06/20/2018
Dec  3 23:27:00 notebook kernel: [  162.778740] RIP: 0010:dev_watchdog+0x221/0x230
Dec  3 23:27:00 notebook kernel: [  162.778742] RSP: 0018:ffff88719f743e58 EFLAGS: 00010286
Dec  3 23:27:00 notebook kernel: [  162.778745] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
Dec  3 23:27:00 notebook kernel: [  162.778746] RDX: 0000000000040400 RSI: 00000000000000f6 RDI: 0000000000000300
Dec  3 23:27:00 notebook kernel: [  162.778748] RBP: ffff88719f743e88 R08: 0000000000000001 R09: 0000000000000458
Dec  3 23:27:00 notebook kernel: [  162.778749] R10: ffff88719f743ee0 R11: 0000000000000000 R12: 0000000000000005
Dec  3 23:27:00 notebook kernel: [  162.778751] R13: ffff88719d0cc000 R14: ffff88719d0cc478 R15: ffff88719d0c1580
Dec  3 23:27:00 notebook kernel: [  162.778753] FS:  0000000000000000(0000) GS:ffff88719f740000(0000) knlGS:0000000000000000
Dec  3 23:27:00 notebook kernel: [  162.778755] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec  3 23:27:00 notebook kernel: [  162.778756] CR2: 00005556bcadd018 CR3: 000000041952c000 CR4: 00000000003406e0
Dec  3 23:27:00 notebook kernel: [  162.778758] Call Trace:
Dec  3 23:27:00 notebook kernel: [  162.778761]  <IRQ>
Dec  3 23:27:00 notebook kernel: [  162.778767]  ? dev_deactivate_queue.constprop.33+0x60/0x60
Dec  3 23:27:00 notebook kernel: [  162.778773]  call_timer_fn+0x30/0x130
Dec  3 23:27:00 notebook kernel: [  162.778775]  run_timer_softirq+0x3fb/0x450
Dec  3 23:27:00 notebook kernel: [  162.778779]  ? ktime_get+0x43/0xa0
Dec  3 23:27:00 notebook kernel: [  162.778783]  ? lapic_next_event+0x20/0x30
Dec  3 23:27:00 notebook kernel: [  162.778787]  __do_softirq+0xe4/0x2bb
Dec  3 23:27:00 notebook kernel: [  162.778792]  irq_exit+0xb8/0xc0
Dec  3 23:27:00 notebook kernel: [  162.778794]  smp_apic_timer_interrupt+0x79/0x130
Dec  3 23:27:00 notebook kernel: [  162.778797]  apic_timer_interrupt+0x84/0x90
Dec  3 23:27:00 notebook kernel: [  162.778798]  </IRQ>
Dec  3 23:27:00 notebook kernel: [  162.778804] RIP: 0010:cpuidle_enter_state+0xa7/0x2f0
Dec  3 23:27:00 notebook kernel: [  162.778805] RSP: 0018:ffff95c50196be68 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff11
Dec  3 23:27:00 notebook kernel: [  162.778808] RAX: ffff88719f762880 RBX: 00000025e65b82c5 RCX: 000000000000001f
Dec  3 23:27:00 notebook kernel: [  162.778809] RDX: 00000025e65b82c5 RSI: fffffff86bc6ac80 RDI: 0000000000000000
Dec  3 23:27:00 notebook kernel: [  162.778810] RBP: ffff95c50196bea8 R08: 00000000000b5a00 R09: 00000000000f13ac
Dec  3 23:27:00 notebook kernel: [  162.778812] R10: ffff95c50196be38 R11: 00000000000b3abe R12: ffff88719cdf5800
Dec  3 23:27:00 notebook kernel: [  162.778813] R13: 0000000000000002 R14: ffffffffb17806f8 R15: 0000000000000000
Dec  3 23:27:00 notebook kernel: [  162.778817]  ? cpuidle_enter_state+0x97/0x2f0
Dec  3 23:27:00 notebook kernel: [  162.778820]  cpuidle_enter+0x17/0x20
Dec  3 23:27:00 notebook kernel: [  162.778824]  call_cpuidle+0x23/0x40
Dec  3 23:27:00 notebook kernel: [  162.778827]  do_idle+0x18c/0x1f0
Dec  3 23:27:00 notebook kernel: [  162.778829]  cpu_startup_entry+0x73/0x80
Dec  3 23:27:00 notebook kernel: [  162.778832]  start_secondary+0x1ab/0x200
Dec  3 23:27:00 notebook kernel: [  162.778836]  secondary_startup_64+0xa5/0xb0
Dec  3 23:27:00 notebook kernel: [  162.778838] Code: 38 00 49 63 4e e8 eb 92 4c 89 ef c6 05 b9 d7 d8 00 01 e8 83 35 fd ff 89 d9 48 89 c2 4c 89 ee 48 c7 c7 f8 98 39 b1 e8 df 95 80 ff <0f> 0b eb c0 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 
Dec  3 23:27:00 notebook kernel: [  162.778880] ---[ end trace 6b2996ceccee82db ]---
Dec  3 23:27:00 notebook kernel: [  162.778887] tg3 0000:02:00.0 enp2s0: transmit timed out, resetting
Dec  3 23:27:00 notebook kernel: [  165.372272] tg3 0000:02:00.0 enp2s0: 0x00000000: 0x168714e4, 0x20100406, 0x02000010, 0x00000000
Dec  3 23:27:00 notebook kernel: [  165.372285] tg3 0000:02:00.0 enp2s0: 0x00000010: 0xe022000c, 0x00000000, 0xe021000c, 0x00000000
Dec  3 23:27:00 notebook kernel: [  165.372291] tg3 0000:02:00.0 enp2s0: 0x00000020: 0xe020000c, 0x00000000, 0x00000000, 0x08141028
Dec  3 23:27:00 notebook kernel: [  165.372297] tg3 0000:02:00.0 enp2s0: 0x00000030: 0x00000000, 0x00000048, 0x00000000, 0x000001ff
Dec  3 23:27:00 notebook kernel: [  165.372302] tg3 0000:02:00.0 enp2s0: 0x00000040: 0x00000000, 0xea000000, 0xc8035001, 0x16002008
Dec  3 23:27:00 notebook kernel: [  165.372308] tg3 0000:02:00.0 enp2s0: 0x00000050: 0x00005803, 0x00000000, 0x0086a005, 0x00000000
Dec  3 23:27:00 notebook kernel: [  165.372313] tg3 0000:02:00.0 enp2s0: 0x00000060: 0x00000000, 0x00000000, 0xf1000298, 0x01f802d1
[... 1000s of lines...]

Also in the news: VIDEO_TDR_FAILURE BSODs in Windows while browsing the internet with a chromium based browser.. Given enough time all devices become terrible.. 

• Trying to boot 32bit Linux resulted in immediate reboots. No output before that happened.
• Most Linux 64bit distributions can be booted by adding noapic (not noacpi!)  intremap=off ivrs_ioapic[32]=00:14.0 ivrs_ioapic[33]=00:00.1 to the kernel boot parameters
• Recent Ubuntu (and most likely also Debian) based distributions need also the boot parameter spec_store_bypass_disable=prctl spec_store_bypass_disable=seccomp. Maybe other distributions/kernel from 2018 will need this, too. Seems that with Ubuntu 18.04 kernel 4.15.0-33 this is no longer needed. So try this omiting this parameter, and check that all devices you need are initalized (-> dmesg), then try seccomp, which disables the mitigations for less code and if still devices are missing, try prctl. 

• null pointer dereference in _raw_spin_lock
• speculative_store_bypass
• ssb_prctrl_set
• arch_seccomp_spec_mitigate
• do_seccomp
• SyS_seccomp
• do_syscall_64
• entry_SYSCALL_64_after_hwframe

Update

After more testing it narrowed down to amd_iommu=off and then to intremap=off 

The final error is "timer doesn't work through interrupt-remapped IO-APIC".

2nd Update

When booting Ubuntu, there is now a stack trace during GPU initialization:

[    1.973028] fbcon: amdgpudrmfb (fb0) is primary device
[    1.992315] [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 1us * 100 tries - tgn10_lock line:566
[    1.992384] WARNING: CPU: 7 PID: 199 at /build/linux-uT8zSN/linux-4.15.0/drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:190 generic_reg_wait+0xe8/0x120 [amdgpu]
[    1.992384] Modules linked in: amdkfd amd_iommu_v2 amdgpu(+) crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc chash i2c_algo_bit aesni_intel ttm aes_x86_64 drm_kms_helper crypto_simd glue_helper syscopyarea cryptd psmouse sysfillrect sysimgblt ahci fb_sys_fops i2c_piix4 libahci drm sdhci_pci r8169 nvme sdhci mii nvme_core wmi video i2c_scmi
[    1.992409] CPU: 7 PID: 199 Comm: systemd-udevd Not tainted 4.15.0-23-generic #25-Ubuntu
[    1.992410] Hardware name: LENOVO 20KU000NGE/20KU000NGE, BIOS R0UET45W (1.25 ) 06/22/2018
[    1.992459] RIP: 0010:generic_reg_wait+0xe8/0x120 [amdgpu]
[    1.992460] RSP: 0018:ffffa857c29bf198 EFLAGS: 00010297
[    1.992462] RAX: 0000000000000001 RBX: 0000000000000065 RCX: 0000000000000001
[    1.992463] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000246
[    1.992463] RBP: ffffa857c29bf1d8 R08: 0000000000000000 R09: 000000000000005e
[    1.992464] R10: 0000000000000002 R11: 0000000000000396 R12: 0000000000000001
[    1.992465] R13: ffff9aadbc798280 R14: 0000000000000100 R15: 0000000000000001
[    1.992466] FS:  00007f85d38bc680(0000) GS:ffff9aadbebc0000(0000) knlGS:0000000000000000
[    1.992467] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.992468] CR2: 00005644b2ea6cf8 CR3: 0000000430046000 CR4: 00000000003406e0
[    1.992469] Call Trace:
[    1.992524]  tgn10_lock+0xa2/0xb0 [amdgpu]
[    1.992574]  program_all_pipe_in_tree+0x804/0x8b0 [amdgpu]
[    1.992621]  ? amdgpu_cgs_write_register+0x14/0x20 [amdgpu]
[    1.992668]  ? generic_reg_update_ex+0xe6/0x150 [amdgpu]
[    1.992714]  ? amdgpu_cgs_read_register+0x14/0x20 [amdgpu]
[    1.992763]  dcn10_apply_ctx_for_surface+0x498/0x4f0 [amdgpu]
[    1.992811]  dc_commit_state+0x2aa/0x500 [amdgpu]
[    1.992862]  amdgpu_dm_atomic_commit_tail+0x2cd/0xa50 [amdgpu]
[    1.992899]  ? amdgpu_bo_pin_restricted+0x1b5/0x2a0 [amdgpu]
[    1.992948]  ? dm_plane_helper_prepare_fb+0x181/0x240 [amdgpu]
[    1.992957]  commit_tail+0x42/0x70 [drm_kms_helper]
[    1.992963]  drm_atomic_helper_commit+0x10c/0x120 [drm_kms_helper]
[    1.993010]  amdgpu_dm_atomic_commit+0x87/0xa0 [amdgpu]
[    1.993026]  drm_atomic_commit+0x51/0x60 [drm]
[    1.993031]  restore_fbdev_mode_atomic+0x178/0x1e0 [drm_kms_helper]
[    1.993037]  restore_fbdev_mode+0x32/0x140 [drm_kms_helper]
[    1.993043]  ? _cond_resched+0x19/0x40
[    1.993048]  drm_fb_helper_restore_fbdev_mode_unlocked.part.32+0x28/0x80 [drm_kms_helper]
[    1.993053]  drm_fb_helper_set_par+0x43/0x70 [drm_kms_helper]
[    1.993058]  fbcon_init+0x493/0x670
[    1.993062]  visual_init+0xdc/0x140
[    1.993065]  do_bind_con_driver+0x207/0x420
[    1.993067]  do_take_over_console+0x82/0x1a0
[    1.993070]  do_fbcon_takeover+0x5c/0xb0
[    1.993072]  fbcon_event_notify+0x58d/0x780
[    1.993077]  notifier_call_chain+0x4c/0x70
[    1.993078]  blocking_notifier_call_chain+0x43/0x60
[    1.993081]  fb_notifier_call_chain+0x1b/0x20
[    1.993082]  register_framebuffer+0x24d/0x360
[    1.993088]  __drm_fb_helper_initial_config_and_unlock+0x1fc/0x400 [drm_kms_helper]
[    1.993093]  drm_fb_helper_initial_config+0x35/0x40 [drm_kms_helper]
[    1.993130]  amdgpu_fbdev_init+0xcd/0x100 [amdgpu]
[    1.993166]  amdgpu_device_init+0xe6c/0x1620 [amdgpu]
[    1.993202]  amdgpu_driver_load_kms+0x8b/0x2e0 [amdgpu]
[    1.993210]  drm_dev_register+0x149/0x1d0 [drm]
[    1.993245]  amdgpu_pci_probe+0x113/0x150 [amdgpu]
[    1.993250]  local_pci_probe+0x47/0xa0
[    1.993253]  pci_device_probe+0x145/0x1b0
[    1.993257]  driver_probe_device+0x31e/0x490
[    1.993258]  __driver_attach+0xa7/0xf0
[    1.993260]  ? driver_probe_device+0x490/0x490
[    1.993262]  bus_for_each_dev+0x70/0xc0
[    1.993264]  driver_attach+0x1e/0x20
[    1.993265]  bus_add_driver+0x1c7/0x270
[    1.993266]  ? 0xffffffffc0671000
[    1.993268]  driver_register+0x60/0xe0
[    1.993269]  ? 0xffffffffc0671000
[    1.993270]  __pci_register_driver+0x5a/0x60
[    1.993310]  amdgpu_init+0x96/0xa9 [amdgpu]
[    1.993314]  do_one_initcall+0x52/0x19f
[    1.993318]  ? __vunmap+0x81/0xb0
[    1.993320]  ? _cond_resched+0x19/0x40
[    1.993323]  ? kmem_cache_alloc_trace+0xa6/0x1b0
[    1.993326]  ? do_init_module+0x27/0x209
[    1.993328]  do_init_module+0x5f/0x209
[    1.993330]  load_module+0x191e/0x1f10
[    1.993334]  ? ima_post_read_file+0x96/0xa0
[    1.993336]  SYSC_finit_module+0xfc/0x120
[    1.993337]  ? SYSC_finit_module+0xfc/0x120
[    1.993340]  SyS_finit_module+0xe/0x10
[    1.993341]  do_syscall_64+0x73/0x130
[    1.993344]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[    1.993345] RIP: 0033:0x7f85d33c6839
[    1.993346] RSP: 002b:00007fff88d70fc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[    1.993347] RAX: ffffffffffffffda RBX: 00005644b2e8bfc0 RCX: 00007f85d33c6839
[    1.993348] RDX: 0000000000000000 RSI: 00007f85d30a50e5 RDI: 0000000000000014
[    1.993348] RBP: 00007f85d30a50e5 R08: 0000000000000000 R09: 00007fff88d710e0
[    1.993349] R10: 0000000000000014 R11: 0000000000000246 R12: 0000000000000000
[    1.993350] R13: 00005644b2e8aef0 R14: 0000000000020000 R15: 00005644b2e8bfc0
[    1.993351] Code: 31 f6 44 8b 45 10 44 89 e1 48 c7 c7 a1 87 60 c0 89 45 d4 52 48 c7 c2 e8 0d 60 c0 e8 83 ad c9 ff 41 83 7d 20 01 58 8b 45 d4 74 02 <0f> 0b 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 c7 45 c4 23 
[    1.993375] ---[ end trace 7e3e1ff95baa3ffb ]---

That's funny, a colleague had the same issue with systemd-udevd today on ouf our servers. With a completely different driver .

3rd Update (2018-07-29)

Ok, this is really a firmware bug, the ACPI IVRS table lacks at least one entry. Adding ivrs_ioapic[32]=00:14.0 instead of intremap=off is sufficient to make the system boot until Lenovo releases an UEFI update with a working IVRS table. At least UEFI 1.27 (2018-07-24) needs this override. And spec_store_bypass_disable=prctl is still needed for Ubuntu & co. 

The clue is the line "[Firmware Bug]: AMD-Vi: IOAPIC[32] not in IVRS table". I decompiled the ACPI tables, started to read the AMD documentation, but in the end I just guessed the 32 from the error message and 00:14.0 from the lspci output and the Stack Overflow/Ubuntu forum entries.  Interesting stuff, but too much to read in my little time. 

What was helpful is the Linux boot parameter amd_iommu_dump=1 which will dump information from the IVRS table:

Resolving devid 00:14.0 was easy via lspci:

 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61)

4th Update (2018-09-01)

At least with Ubuntu kernel 4.15.0-33 spec_store_bypass_disable is no longer needed. At least for my e485. My assumption is that this was a kernel bug in the earlier kernels  with Spectre/Meltdown fixes.. Anyway, if you cannot boot or not all devices initialize, try the option seccomp and if that does not help try prctl. The option seccomp disables less spectre mitigations than prctl: 

https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown/Mi...

5th Update (2018-09-07) 

Just installed BIOS/UEFI 1.32 which fixes the keyboard issue. But Linux still needs the IVRS Table overrride. 

I am currently testing the Dell Latitude 5495, which boots Linux out of the box, but has also a few warnings/errors in the kernel log. I checked their IVRS Table: 

Compare the indexes with the Lenovo IVRS table. My uneducated guess is that these entries should be the same for all mainboards with (Mobile?) Ryzen processors as I assume (guess!! correct me if wrong) that these are CPU internal devices. Maybe the Lenovo IVRS entries are just off by one.

6th Update (2018-09-10)

Pilatomic in the comments pointed out that adding ivrs_ioapic[33]=00:00.1 solves a couple of issues, in his case issues with the SD Card reader. For me this works flawless for all my microSDHC cards, the only write errors I got were caused by ejecting the cards without unmounting them ;-)  Unfortunately I have found no way to remove entry 34 via kernel parameters, the parser will only accept well-formed parameters.So you will have wait for Lenovo to fix this ACPI table. I think by now they should know how to fix this and it's not a big change. But perhaps they do not care for Linux. 

Second Last Update (2018-09-10)

The story ends here for me. I just discarded all data on the SSDs, reimaged the NVMe with the factory image, cleaned up screen, keyboard, touchpad and case. And hopefully I will find a buyer for this fine notebook 

Why not the last update? I hope somebody will notify me when Lenovo releases a new UEFI version which fixes the IVRS ACPI table and Linux distributions will work out of the box. Then there will be a last update....

Another Update (2019-01-11)

According to this comment the IVRS overrides may not be needed anymore. And there are additional settings which should be set.

The steam versions of the following games may not run from an XFS filesystem with the inode64 option:

• Borderlands 2
• Divinity: Original Sin Extended Edition(?)
• Europa Universalis IV
• Sid Meier's Civilization: Beyond Earth
• Sid Meier's Civilization V
• Space Hulk
• Space Hulk Ascension
• Starcom
• Stellaris
• SteamWorld Heist

Possible workarounds are either moving the games to a steam library on a different filesystem like ext4, which is the default for many distributions, or to disable the inode64 mount option for XFS (which is a very bad idea!).

Xming war ja schon immer umstritten.  Der "Autor" von Xming, der eigentlich nur den Open Source Code unter Windows kompiliert und paketiert, bietet sowohl eine Public Version zum freien verwenden an, und eine hm, naja "Nicht Public" gegen eine "Spende".  Die Public Version ist übrigens im Gegensatz zur "Nicht Public" seit 6 Jahren nicht mehr geupdatet worden. 

Immerhin gibt's jetzt einen guten Ersatz: VcXsrv. Neure X-Version und diesmal mit Visual C++ kompiliert und für 32bit und 64bit verfügbar. Tut's genauso wie Xming und ist nicht über 6 Jahre alt.

Tschüss Xming!

Fucking opera crashed again while writing the article. Here the short version:

You try to mount an NFS export which resides on a  xfs file system and the client fails with the message "Stale NFS file handle". A more verbose mount may show these messages: 

mount.nfs: trying text-based options 'vers=3,addr=aaa.bbb.ccc.ddd'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying aaa.bbb.ccc.ddd prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=ddd
mount.nfs: trying aaa.bbb.ccc.ddd prog 100005 vers 3 prot UDP port 4002
mount.nfs: mount(2): Stale NFS file handle
mount.nfs: trying text-based options 'vers=3,addr=aaa.bbb.ccc.ddd'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying aaa.bbb.ccc.ddd prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=ddd
mount.nfs: trying aaa.bbb.ccc.ddd prog 100005 vers 3 prot UDP port 4002
mount.nfs: mount(2): Stale NFS file handle

The server syslog has entries like:

Sep 9 22:39:17 server rpc.mountd[11413]: authenticated mount request from aaa.bbb.ccc.ddd:809 for /srv/file/xxx (/srv/file/xxx)
Sep 9 22:39:19 server rpc.mountd[11413]: authenticated mount request from aaa.bbb.ccc.ddd:971 for /srv/file/xxx (/srv/file/xxx)
Sep 9 22:39:28 server rpc.mountd[11413]: authenticated mount request from aaa.bbb.ccc.ddd:913 for /srv/file/xxx (/srv/file/xxx)
Sep 9 22:40:20 server rpc.mountd[11413]: authenticated mount request from aaa.bbb.ccc.ddd:853 for /srv/file/xyz (/srv/file/xyz)

Before trying any stuff like turning off IPv6 or replacing portmapper with rpcbind as suggested by some folks, try changing the inode numbers of the exported directories as described in the mailing list entry "XFS, NFS and inode64 on 2.6.27" found via this forum entry.

To make this thing even more stupid, it is noted in the offical XFS FAQ, but in a way that you will not  find it if you run into this problem. Second penalty point for XFS (first one is inability to shrink).

So, nach dem Reinfall mit dem Sapphire Pure Black 990fx Board hab ich mir das Gigabyte GA-990FXA-UD5 Board geholt. Damit ist zwar auch nicht alles rosig, aber es läuft immerhin mit Linux.

Im Gegensatz zum Sapphire scheinen die ACPI Tabellen sauber zu sein, und die Kiste bootet ohne Probleme durch. Powersaving funktioniert auch super, in Linux verbraucht die Kiste idle (Board, CPU, 1x8GB Riegel @ 1866Mhz, keine Grafikkarte) ca 48-51Watt. Das ist zwar mehr als mein alter 4450e (TDP 45Watt), aber der FX-8350 hat ja auch die vierfache Anzahl von Kernen, wobei die Bulldozer/Piledriver Kerne ja keine richtigen Kerne sind. Oh, und natürlich sind 4GHz auch ein bisschen mehr als 2,4Ghz.

Probleme gab's nur mit dem Speicher. Zwei Module liefen noch mit 1866 Mhz, mit vier Speicherriegel wollte das Board nicht mehr booten, auch nicht mit dem Standardtakt von 1366Mhz. Gigabyte gibt an 32GB und 1866 zu unterstützen, von beides gleichzeitig steht nirgendwo was ;) Geholfen hat es am Ende in den Advanced Option "Load Line Calibration" von Auto auf Regular zu setzen, jetzt laufen die 4 Riegel mit 32GB. Von dieser "Load Line Calibration" hatte ich vorher auch noch nix gehört. Interessanterweise brauchen die 4 Module nicht mehr Strom als eins.

Ein kleines Problem ist die Sapphire (schon wieder...) Radeon 5450. Mit der Karte steigt der Idle-Verbrauch auf 60-63Watt. Das entspricht so ziemlich dem maximalen Verbrauch der Karte, angegeben ist die mit 6Watt im Idle, und das obwohl Linux im Textmodus ohne Grafik, DRM und Co lief. Also DRM und radeonfb aktiviert um die Power-Einstellungen im sysfs bekommen. Egal, was ich einstelle, am Stromverbrauch ändert sich nix. Richtig kurios ist, dass mit der Einstellung Low GPU und RAM mit der maximalen Geschwindigkeit laufen, während bei High diese auf dem Minimaltakt laufen. Auch wenn der Stromverbrauch gleich ist, läuft die Karte so kühler.

Auch wenn das mit dem Speichertakt ärgerlich ist, hat die Kiste so auch genug Power. Es ist bestimmt schon 10 Jahre her, dass ich zuletzt einen Kernel unter 2 min kompilieren konnte.

Links:
Gentoo Wiki: Radeon
Phoronix: The Current State Of Radeon Power Management (2011!)

Und mal wieder ein Reinfall, diesmal beim Versuch einen neuen Server aufzubauen.Grundlage sollte das AM3+ Mainboard "Sapphire Pure Black 990fx" , ein etwas besser ausgestattetes Mainboard mit 9 SATA Ports, 6 PCIe Slots, 2x Gbit Lan und IOMMU (für Virtualisierung). Diese 3 Probleme haben mir das Wochenende gekillt:

1. Buggy Bios
   Es gibt Optionen im BIOS, beispielsweise "Above 4G Decoding", die die Kiste nicht mehr booten lassen. Nicht booten heisst hier, dass sich das BIOS nicht mehr korrekt initialisert, Es bleibt einfach ohne Bild hängen und die LED Diagnose Anzeige zeigt einige Codes in einer Schleife an. Keiner der Codes zeigt einen Fehler an. Zum glück gibt es da den bequemen CMOS Löschen Button sonst wär's noch nerviger. Naja, hat was gebraucht bis ich es auf eine Option eingrenzen konnte. 
2. Buggy ACPI
   Ich hab zig Linux-Distributionen ausprobiert, mit zig BIOS-Einstellungen.ausprobiert. Alle haben sich aufgehangen. Einige x86er gingen später, die amd64er sind aber alle gestorben.Blöd das die meisten Distributionen heute die Boot-Meldungen unterdrücken, sonst hätte ich das Problem schneller gefunden. Die letzten Zeilen waren immer:

   ACPI: EC: Look up EC in DSDT
   ACPI: Executed 3 blocks of module-level executable AML code

   Also mal noacpi und acpi=off ausprobiert. Und siehe da, die Kiste bootete. Interessanterweise lief FreeBSD 64bit mit ACPI-Unterstützung. Also eigentlich würde Linux ja laufen, aber ohne ACPI möchte man keinen FX-8350 betreiben, das wird zu heiß und zu teuer (100Watt Idle für Minimalsystem...). Und ich vermute dass USB nicht funktionierte war auch eine Folge davon. Ist blöd wenn man von USB bootet und nach dem Kernel load das Bootmedium weg ist. 

3. DDR3-1866 geht nicht
   Der eingesetzte "G.Skill Ares" RAM wollte nicht mit den Nennangaben auf 1866Mhz laufen, 1600MHz waren aber stabil mit den 32GB möglich. Das wäre für mich noch verschmerzbar gewesen, Ein stabiles System ist mir wichtiger als schnelleres unzuverlässiges. Aber ärgerlich ist es trotzdem.
4. Schwarzer Bootbildschirm
   Kein Problem aber auch nicht schön ist dass der Bildschirm erstmal ein paar Sek schwarz bleibt. Ohne die LED Anzeige würde man die Kiste wohl für tot halten. Nach ~5sek meldet sich dann Zusatz onboard SATA Controller, und dann blinkt evt. kurz der übliche POST/Splash Screen auf. Wenn man eine Wartezeit einstellt, dann wartet jetzt das Bios auf eine Eingabe. Wenn nicht, dann hat man hier einen Sekundenbruchteil zeit auf F2/Del zu hämmern um ins Bios zu kommen. Ansonsten startet direkt das OS. 

Das Board ist zum Glück aus dem Verkauf gegangen. Restposten gibt's noch bei ebay. Sapphire ist nicht gerade für seine Mainboards bekannt, vielleicht war es von vornherein eine dumme Idee von denen ein Board zu kaufen. Ich könnt mich jetzt mit deren Support rumschlagen, aber ich glaube nicht dass ich da viel erreichen würde. Vielleicht ist es auch blöd, jetzt hier den Eintrag zu schreiben, ich möchte das Board schliesslich noch bei eBay verticken ;)