These are my notes from installing Debian and Kubuntu on HP EliteBook Folio G1 with Intel Core m7-6Y75. This is a second gist for this machine (I've already described my experience with Manjaro installation).
- Host: HP EliteBook Folio G1 (P2C90AV)
- Resolution: 1920x1080
- CPU: 6th gen Intel Core m7-6Y75
- GPU: Intel HD Graphics 515
- Memory: 8 GB (soldered)
- SSD: 240 GB (Samsung MZVLW256HEHP-000H1 (originally from HP Elite x2 1012 G2))
- Network: Intel Wireless 8260
As I stated above, I've started with Manjaro on this device. It was mostly because Manjaro became my go-to distro when I need to install Linux on anything and don't think much about it. So why would I change? Well, it seemed I was forced to reinstall OS anyway, so I used it as the opportunity to think more about the distro.
I don't use this PC very often and when I do, I mostly use it for browsing the web or other simple stuff. That's why I decided there is literally zero benefit of having rolling release here. Additionally given how rarely I use it I know I would be updating it rarely and rolling release OSs don't like it. So, I decided I want to go with something more stable and preferably with long-term support. So, I decided that I'd give Debian a try. However, after I spent about 5h and couldn't properly install Debian (more on that later) I decided to install Kubuntu. In the end, however, I was able to properly install Debian and I was able to achieve what I wanted with my old Manjaro installation. Then I decided to go back to Manjaro for now and change it to Debian when I have time. I will update this gist if I encounter more issues.
Well - it is kinda an old laptop and I bought it as a post-leasing machine. I hoped everything would be ok with it but sadly it turns out it has a defective RAM module. It wouldn't be much of a hassle to just replace the RAM stick, but it is a laptop with soldered RAM and because of that the repair cost is huge (around the value of this PC). That's why the only feasible option for me was to go with a BadRam solution. When I started the whole process, I couldn't properly use BadRam and I wanted to use memmap kernel param, but memmap can't be used with UEFI installation. My Manjaro installation was using UEFI so I thought I have to reinstall the OS (I thought that BadRam will not work with UEFI as well because I couldn't find any info about that).
Installing Kubuntu was pretty straightforward, and the OS ran properly.
The main issue I encounter was the fact that when using msdos disk table I couldn't create the second primary partition (from the installer, I believe if I had partitioned the disk before starting the installer using KDE Partition Manager, I could do it properly). That's why I had to recreate the second partition (swap area) after the installation. After recreating swap partition as primary, I had to update /etc/fstab with the correct UUID for swap. To check the UUID of a partition you can use blkid command.
I also encountered the situation that the built-in touchpad wasn't responding SOMETIMES, and I had to reboot PC for it to start working again. I wasn't investigating what was the reason for that tho.
Debian installation on the other hand was a mistake. I started with Debian (longer LTS than Kubuntu and generally more stable OS), couldn't install it properly, gave up after 5h of trying, then after some conversation with my friend I decided to try few more things which in the end worked and I was able to properly install Debian on this machine.
The main issue I had with Debian was the fact that GRUB couldn't properly install, and laptop showed that there is no bootable device when restarting after successful installation. Turns out the issue was with the partition layout, even the one done with "guided partitioning" mode.
My desired partition table was straight-forward:
Disk table: msdos (mbr)
Partition #1: 240GB, primary, ext4, mounted as /
Partition #2: 16GB, primary, swap, used as swap
I tried reinstalling Debian many times with a similar partition layout, and it never worked. Turns out the issue was the fact that I hadn't set the bootable flag on the partition #1. What's the most irritating thing was that the "guided partitioning" setup also hadn't set the bootable flag and Debian wasn't properly installed.
Other issues that I encountered aren't issues that are specific to this machine but to Debian config/way of working in general.
The first thing was that the default user isn't in the sudoers list (workaround - using su).
The second one was that there is a different PATH for normal user and super user and doing su doesn't load the superuser PATH resulting in the issue with running some commands such as: update-grub. In Debian you need to add /usr/sbin into the PATH to be able to successfully run update-grub command. You can do it with running export PATH="/usr/sbin:$PATH", adding it to the ~/.bashrc or by editing /etc/profile.
Two other minor ones - not having alias ll (for ls -alF) and not having memtest86+ installed (you can install it via apt install memtest86+ and it will automatically add needed entries in GRUB). If you want to have more recent memtest86+ you can download the binary files from the official site and replace the x64 memtest .bin file present in /boot (remember to name it the same way it was named because otherwise you would need to update grub config to detect this file). Note: The .bin file is enough only for MBR installation, for UEFI you need to use the .efi file.
Finding any info about BadRam or using a PC with faulty RAM generally was difficult for me. Mostly because it was a lot more common 10-20 years ago when RAM was expensive and nowadays almost no one does it (but here comes devices with fricking soldered RAM...).
I've written another gist which is all about BadRAM and how to use it. It's available here.
So, I ended up using BadRam which to my knowledge started as a Linux kernel patch, but now is a part of official Linux kernel (which means that you can use it in any distro running moderately new kernel - I believe anything higher than 2.6 will do).
The first step is to get info which RAM sectors are faulty - the easiest way is to use any modern version of memtest86+ (any version will do, but modern ones can output BadRam patterns). Switching the memtest output mode is available in its setting - F1 Configurations -> F4 Error Reporting Mode -> F4 BadRam patters -> F10 -> F10. It is advised to let memtest do few passes as one might not show all the issues (some also suggest running it hotter than usual as overheating RAM might show more faults). When you finish few runs and your RAM is faulty you should get something similar to: badram=0xa84c8b0c,0xfffffffc,0xa04c8ca8,0xfffffffc,0xa84c8c88,0xfffffffc.
The second step is to update GRUB with the BadRam pattern. You can do it by booting the PC (if it's possible) or by connecting the root drive to another PC and chrooting into it. To update a grub, you need to uncomment a line (or add in case of Manjaro) with GRUB_BADRAM and change the default pattern with yours: GRUB_BADRAM="0xa84c8b0c,0xfffffffc,0xa04c8ca8,0xfffffffc,0xa84c8c88,0xfffffffc". After saving the file all you need to do is to update-grub and reboot the PC. You may run memtest86+ again to check if you correctly excluded all faulty spots (you need to boot the memtest86+ from your GRUB, most distro came with memtest preinstalled, in case of Debian you need to install it manually).
As already described in Manjaro gist this laptop has an issue with Intel GPU driver which results in occasional (every few seconds) screen tear. I was able to fix that with adding these two kernel params (in /etc/default/grub):
i915.enable_psr=0 intel_idle.max_cstate=2
After changing the kernel params you need to recreate GRUB with update-grub command.
Note: In Debian you need to add /usr/sbin into the PATH to be able to successfully run update-grub command. You can do it with running export PATH="/usr/sbin:$PATH", adding it to the ~/.bashrc or by editing /etc/profile.
Both Kubuntu and Debian install without the support for hibernation. When the swap is correctly visible in the system (correctly specified in /etc/fstab; you may list swap areas with swapon -v) you need to add resume kernel param:
resume=UUID=<UUID>
replacing <UUID> with the correct UUID. After that you need to recreate GRUB with update-grub.
To make hibernation work in Kubuntu you need to do two additional things.
Some say that you need to create a /etc/initramfs-tools/conf.d/resume file with RESUME=UUID=<UUID> and then regenerate initramfs with update-initramfs -c -k all, but I didn't do it and everything works fine.
However, what you need to do for sure is to create a hibernation policy which allows hibernation by creating /etc/polkit-1/localauthority/50-local.d/com.ubuntu.enable-hibernate.pkla file with the following content.
[Re-enable hibernate by default in upower]
Identity=unix-user:*
Action=org.freedesktop.upower.hibernate
ResultActive=yes
[Re-enable hibernate by default in logind]
Identity=unix-user:*
Action=org.freedesktop.login1.hibernate;org.freedesktop.login1.handle-hibernate-key;org.freedesktop.login1;org.freedesktop.login1.hibernate-multiple-sessions;org.freedesktop.login1.hibernate-ignore-inhibit
ResultActive=yes
After creating that file, you need to log-off and log-on and the hibernate option should show up in KDE Plasma.