After a hiatus of 6 years, it was nice to be back with the ThinkPad. This blog post briefly touches upon my impressions with the current generation ThinkPad T14 Gen2 AMD variant.
It took 8 weeks to get my hands on the machine. Given the pandemic, restrictions and uncertainities, not sure if I should call it an ontime delivery. This was a CTO - Customise-to-order; so was nice to get rid of things I really didn’t care/use much. On the other side, it also meant I could save on some power. It also came comparatively cheaper overall.
- No fingerprint reader
- No Touch screen
There’s still parts where Lenovo could improve. Or less frustate a customer. I don’t understand why a company would provide a full customization option on their portal, while at the same time, not provide an explicit option to choose the make/model of the hardware one wants. Lenovo deliberately chooses to not show/specify which WiFi adapter one could choose. So, as I suspected, I ended up with a
MEDIATEK Corp. Device 7961 wifi adapter.
For the first time in my computing life, I’m now using AMD at the core. I was pretty frustrated with annoying Intel Graphics bugs, so decided to take the plunge and give AMD/ATI a shot, knowing that the
radeon driver does have decent support. So far, on the graphics side of things, I’m glad that things look bright. The stock in-kernel radeon driver has been working perfect for my needs and I haven’t had to tinker even once so far, in my 30 days of use.
On the overall system performance, I have not done any benchmarks nor do I want to do. But wholly, the system performance is smooth.
This is where things need more improvement on the AMD side. This AMD laptop terribly draws a lot of power in suspend mode. And it isn’t just this machine, but also the previous T14 Gen1 which has similar problems. I’m not sure if this is a generic ThinkPad problem, or an AMD specific problem. But coming from the Dell XPS 13 9370 Intel, this does draw a lot lot more power. So much, that I chose to use hibernation instead.
Similarly, on the thermal side, this machine doesn’t cool down well as compared the the Dell XPS Intel one. On an idle machine, its temperature are comparatively higher. Looking at
powertop reports, it does show to consume an average of 10 watts power even while idle.
I’m hoping these are Linux ingeration issues and that Lenovo/AMD will improve things in the coming months. But given the user feedback on the ThinkPad T14 Gen1 thread, it may just be wishful thinking.
The overall hardware support has been surprisingly decent. The MediaTek WiFi driver had some glitches but with Linux 5.15+, things have considerably improved. And I hope the trend will continue with forthcoming Linux releases. My previous device driver experience with MediaTek wasn’t good but I took the plunge, considering that in the worst scenario I’d have the option to swap the card.
There’s a lot of marketing about Linux + Intel. But I took a jibe with Linux + AMD. There are glitches but nothing so far that has been a dealbreaker. If anything, I wish Lenovo/AMD would seriously work on the power/thermal issues.
Other than what’s mentioned above, I haven’t had any serious issues. I may have had some rare occassional hangs but they’ve been so infrequent that I haven’t spent time to investigate those.
Upon receiving the machine, my biggest requirement was how to switch my current workstation from Dell XPS to Lenovo ThinkPad. I’ve been using btrfs for some time now. And over the years, built my own practise on how to structure it. Things like, provisioning [sub]volumes, based on use cases is one thing I see. Like keeping separate subvols for: cache/temporary data, copy-on-write data , swap etc. I wish these things could be simplified; either on the btrfs tooling side or some different tool on top of it.
Below is filtered list of subvols created over years, that were worthy of moving to the new machine.
rrs@priyasi:~$ cat btrfs-volume-layout ID 550 gen 19166 top level 5 path home/foo/.cache ID 552 gen 1522688 top level 5 path home/rrs ID 553 gen 1522688 top level 552 path home/rrs/.cache ID 555 gen 1426323 top level 552 path home/rrs/rrs-home/Libvirt-Images ID 618 gen 1522672 top level 5 path var/spool/news ID 634 gen 1522670 top level 5 path var/tmp ID 635 gen 1522688 top level 5 path var/log ID 639 gen 1522226 top level 5 path var/cache ID 992 gen 1522670 top level 5 path disk-tmp ID 1018 gen 1522688 top level 552 path home/rrs/NoBackup ID 1196 gen 1522671 top level 5 path etc ID 23721 gen 775692 top level 5 path swap 18:54 ♒ ॐ ♅ ♄ ⛢ ☺ 😄
This did come in handy but I sorely missed some feature. Maybe they aren’t there, or are there and I didn’t look close enough. Over the years, different attributes were set to different subvols. Over time I forget what feature was added where. But from a migration point of view, it’d be nice to say, “Take this volume and take it with all its attributes”. I didn’t find that functionality in
get/set-property which I noticed later but by then it was late. So some sort of tooling, ideally something like
btrfs migrate or somesuch would be nicer.
In the file system world, we already have nice tools to take care of similar scenarios. Like with
rsync, I can request it to carry all file attributes.
send/receive works only on
ro volumes. So there’s more work one needs to do in:
- create ro vol
- don’t forget to set rw property
- And then somehow find out other properties set on each individual subvols and [re]apply the same on the destination
I wish this all be condensed into a sub-command.
For my own sake, for this migration, the steps used were:
user@debian:~$ for volume in `sudo btrfs sub list /media/user/TOSHIBA/Migrate/ | cut -d ' ' -f9 | grep -v ROOTVOL | grep -v etc | grep -v btrbk`; do echo $volume; sud o btrfs send /media/user/TOSHIBA/$volume | sudo btrfs receive /media/user/BTRFSROOT/ ; done Migrate/snapshot_disk-tmp At subvol /media/user/TOSHIBA/Migrate/snapshot_disk-tmp At subvol snapshot_disk-tmp Migrate/snapshot-home_foo_.cache At subvol /media/user/TOSHIBA/Migrate/snapshot-home_foo_.cache At subvol snapshot-home_foo_.cache Migrate/snapshot-home_rrs At subvol /media/user/TOSHIBA/Migrate/snapshot-home_rrs At subvol snapshot-home_rrs Migrate/snapshot-home_rrs_.cache At subvol /media/user/TOSHIBA/Migrate/snapshot-home_rrs_.cache At subvol snapshot-home_rrs_.cache ERROR: crc32 mismatch in command Migrate/snapshot-home_rrs_rrs-home_Libvirt-Images At subvol /media/user/TOSHIBA/Migrate/snapshot-home_rrs_rrs-home_Libvirt-Images At subvol snapshot-home_rrs_rrs-home_Libvirt-Images ERROR: crc32 mismatch in command Migrate/snapshot-var_spool_news At subvol /media/user/TOSHIBA/Migrate/snapshot-var_spool_news At subvol snapshot-var_spool_news Migrate/snapshot-var_lib_machines At subvol /media/user/TOSHIBA/Migrate/snapshot-var_lib_machines At subvol snapshot-var_lib_machines Migrate/snapshot-var_lib_machines_DebianSidTemplate ..... snipped .....
And then, follow-up with:
user@debian:~$ for volume in `sudo btrfs sub list /media/user/BTRFSROOT/ | cut -d ' ' -f9`; do echo $volume; sudo btrfs property set -ts /media/user/BTRFSROOT/$volume ro false; done ROOTVOL ERROR: Could not open: No such file or directory etc snapshot_disk-tmp snapshot-home_foo_.cache snapshot-home_rrs snapshot-var_spool_news snapshot-var_lib_machines snapshot-var_lib_machines_DebianSidTemplate snapshot-var_lib_machines_DebSidArmhf snapshot-var_lib_machines_DebianJessieTemplate snapshot-var_tmp snapshot-var_log snapshot-var_cache snapshot-disk-tmp
And then finally, renaming everything to match proper:
user@debian:/media/user/BTRFSROOT$ for x in snapshot*; do vol=$(echo $x | cut -d '-' -f2 | sed -e "s|_|/|g"); echo $x $vol; sudo mv $x $vol; done snapshot-var_lib_machines var/lib/machines snapshot-var_lib_machines_Apertisv2020ospackTargetARMHF var/lib/machines/Apertisv2020ospackTargetARMHF snapshot-var_lib_machines_Apertisv2021ospackTargetARM64 var/lib/machines/Apertisv2021ospackTargetARM64 snapshot-var_lib_machines_Apertisv2022dev3ospackTargetARMHF var/lib/machines/Apertisv2022dev3ospackTargetARMHF snapshot-var_lib_machines_BusterArm64 var/lib/machines/BusterArm64 snapshot-var_lib_machines_DebianBusterTemplate var/lib/machines/DebianBusterTemplate snapshot-var_lib_machines_DebianJessieTemplate var/lib/machines/DebianJessieTemplate snapshot-var_lib_machines_DebianSidTemplate var/lib/machines/DebianSidTemplate snapshot-var_lib_machines_DebianSidTemplate_var_lib_portables var/lib/machines/DebianSidTemplate/var/lib/portables snapshot-var_lib_machines_DebSidArm64 var/lib/machines/DebSidArm64 snapshot-var_lib_machines_DebSidArmhf var/lib/machines/DebSidArmhf snapshot-var_lib_machines_DebSidMips var/lib/machines/DebSidMips snapshot-var_lib_machines_JenkinsApertis var/lib/machines/JenkinsApertis snapshot-var_lib_machines_v2019 var/lib/machines/v2019 snapshot-var_lib_machines_v2019LinuxSupport var/lib/machines/v2019LinuxSupport snapshot-var_lib_machines_v2020 var/lib/machines/v2020 snapshot-var_lib_machines_v2021dev3Slim var/lib/machines/v2021dev3Slim snapshot-var_lib_machines_v2021dev3SlimTarget var/lib/machines/v2021dev3SlimTarget snapshot-var_lib_machines_v2022dev2OspackMinimal var/lib/machines/v2022dev2OspackMinimal snapshot-var_lib_portables var/lib/portables snapshot-var_log var/log snapshot-var_spool_news var/spool/news snapshot-var_tmp var/tmp
Entirely independent of this, but indirectly related. I use
snapper as my snapshotting tool. It worked perfect on my previous machine. While everything got migrated, the only thing that fell apart was
snapper. It just wouldn’t start/run proper. Funny thing is that I just removed the snapper configs and reinitialized with the exact same config again, and voila snapper was happy.
That was pretty much it. With the above and then also migrating
/boot and then just chroot to install the boot loader. At some time, I’d like to explore other boot options but given that that is such a non-essential task, it is low on the list.
The good part was that I booted into my new machine with my exact workstation setup as it was. All the way to the user cache and the desktop session. So it was nice on that part.
But I surely think there’s room for a better migration experience here. If not directly as
btrfs migrate, then maybe as an independent tool. The problem is that such a tool is going to be used once in years, so I didn’t find the motivation to write one. But this surely would be a good use case for the distribution vendors.