Re: [gentoo-user] Is there a reason why LLVM/Clang ebuilds don't support "mutislot"?
This also makes it difficult to use GHC's LLVM backend, since its compatible versions usually lag behind the current one.
[gentoo-user] Is there a reason why LLVM/Clang ebuilds don't support "mutislot"?
Other distros like Ubuntu support the installation of multiple versions of LLVM/Clang side by side. One of the things Clang is really good at is support for the most recently approved upcoming features of the C++17 standard. The best support for testing such features is with the latest sys-devel/llvm-. However if I want to compile Mesa against a stable version LLVM/Clang as well, I don't get that option.
Re: [gentoo-user] USB crucial file recovery
On August 29, 2016 3:24:18 AM GMT+02:00, Grant wrote: >>> I have a USB stick with a crucial file on it (and only an old backup >>> elsewhere). It's formatted NTFS because I wanted to be able to open >>> the file on various Gentoo systems and my research indicated that >NTFS >>> was the best solution. >>> >>> I decided to copy a 10GB file from a USB hard disk directly to the >USB >>> stick this morning and I ran into errors so I canceled the operation >>> and now the file manager (thunar) has been stuck for well over an >hour >>> and I'm getting errors like these over and over: >>> >>> [ 2794.535814] Buffer I/O error on dev sdc1, logical block 2134893, >>> lost async page write >>> [ 2794.535819] Buffer I/O error on dev sdc1, logical block 2134894, >>> lost async page write >>> [ 2794.535822] Buffer I/O error on dev sdc1, logical block 2134895, >>> lost async page write >>> [ 2794.535824] Buffer I/O error on dev sdc1, logical block 2134896, >>> lost async page write >>> [ 2794.535826] Buffer I/O error on dev sdc1, logical block 2134897, >>> lost async page write >>> [ 2794.535828] Buffer I/O error on dev sdc1, logical block 2134898, >>> lost async page write >>> [ 2794.535830] Buffer I/O error on dev sdc1, logical block 2134899, >>> lost async page write >>> [ 2794.535832] Buffer I/O error on dev sdc1, logical block 2134900, >>> lost async page write >>> [ 2794.535835] Buffer I/O error on dev sdc1, logical block 2134901, >>> lost async page write >>> [ 2794.535837] Buffer I/O error on dev sdc1, logical block 2134902, >>> lost async page write >>> [ 2842.568843] sd 9:0:0:0: [sdc] tag#0 FAILED Result: >>> hostbyte=DID_ERROR driverbyte=DRIVER_SENSE >>> [ 2842.568849] sd 9:0:0:0: [sdc] tag#0 Sense Key : Hardware Error >[current] >>> [ 2842.568852] sd 9:0:0:0: [sdc] tag#0 Add. Sense: No additional >sense >>> information >>> [ 2842.568857] sd 9:0:0:0: [sdc] tag#0 CDB: Write(10) 2a 00 01 04 a4 >>> 58 00 00 f0 00 >>> [ 2842.568859] blk_update_request: I/O error, dev sdc, sector >17081432 >>> [ 2842.568862] buffer_io_error: 20 callbacks suppressed >>> >>> nmon says sdc is 100% busy but doesn't show any reading or writing. >I >>> once pulled the USB stick in a situation like this and I ended up >>> having to reformat it which I need to avoid this time since the file >>> is crucial. What should I do? >>> >>> - Grant >> >> Whatever you do, do NOT try to unplug the USB you were writing to >unless you >> first manage to successfully unmount it. If you do pull the USB >stick >> regardless of its current I/O state you will likely corrupt whatever >file you >> were writing onto, or potentially more. >> >> You could well have a hardware failure here, which manifested itself >during >> your copying operation. Things you could try: >> >> Run lsof to find out which process is trying to access the USB fs and >kill it. >> Then see if you can remount it read-only. >> >> Run dd, dcfldd, ddrescue to make an image of the complete USB stick >on your >> hard drive and then try to recover any lost files with testdisk. >> >> Use any low level recovery tools the manufacturer may offer - they >will likely >> require MSWindows. >> >> Shut down your OS and disconnect the USB stick, then reboot and try >again to >> access it, although I would first create an image of the device using >any of >> the above tools. > > >dd errored and lsof returned no output at all so I tried to reboot but >even that hung after the first 2 lines of output so I did a hard reset >after waiting an hour or so. Once it came back up I tried to do 'dd >if=/dev/sdb1 of=usbstick' but I got this after awhile: > >dd: error reading ‘/dev/sdb1’: Input/output error >16937216+0 records in >16937216+0 records out >8671854592 bytes (8.7 GB) copied, 230.107 s, 37.7 MB/s > >It's a 64GB USB stick. dmesg says: > >[ 744.729873] sd 8:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK >driverbyte=DRIVER_SENSE >[ 744.729879] sd 8:0:0:0: [sdb] tag#0 Sense Key : Medium Error >[current] >[ 744.729883] sd 8:0:0:0: [sdb] tag#0 Add. Sense: Unrecovered read >error >[ 744.729886] sd 8:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 01 02 78 e0 >00 00 f0 00 >[ 744.729889] blk_update_request: critical medium error, dev sdb, >sector 16939232 >[ 744.763468] sd 8:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK >driverbyte=DRIVER_SENSE >[ 744.763472] sd 8:0:0:0: [sdb] tag#0 Sense Key : Medium Error >[current] >[ 744.763474] sd 8:0:0:0: [sdb] tag#0 Add. Sense: Unrecovered read >error >[ 744.763478] sd 8:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 01 02 79 00 >00 00 04 00 >[ 744.763480] blk_update_request: critical medium error, dev sdb, >sector 16939264 >[ 744.763482] Buffer I/O error on dev sdb1, logical block 4234304, >async page read >[ 744.786743] sd 8:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK >driverbyte=DRIVER_SENSE >[ 744.786747] sd 8:0:0:0: [sdb] tag#0 Sense Key : Medium Error >[current] >[ 744.786750] sd 8:0:0:0: [sdb] tag#0 Add. Sense: Unrecovered read >error >[ 744.786753]
Re: [gentoo-user] USB crucial file recovery
>> I have a USB stick with a crucial file on it (and only an old backup >> elsewhere). It's formatted NTFS because I wanted to be able to open >> the file on various Gentoo systems and my research indicated that NTFS >> was the best solution. >> >> I decided to copy a 10GB file from a USB hard disk directly to the USB >> stick this morning and I ran into errors so I canceled the operation >> and now the file manager (thunar) has been stuck for well over an hour >> and I'm getting errors like these over and over: >> >> [ 2794.535814] Buffer I/O error on dev sdc1, logical block 2134893, >> lost async page write >> [ 2794.535819] Buffer I/O error on dev sdc1, logical block 2134894, >> lost async page write >> [ 2794.535822] Buffer I/O error on dev sdc1, logical block 2134895, >> lost async page write >> [ 2794.535824] Buffer I/O error on dev sdc1, logical block 2134896, >> lost async page write >> [ 2794.535826] Buffer I/O error on dev sdc1, logical block 2134897, >> lost async page write >> [ 2794.535828] Buffer I/O error on dev sdc1, logical block 2134898, >> lost async page write >> [ 2794.535830] Buffer I/O error on dev sdc1, logical block 2134899, >> lost async page write >> [ 2794.535832] Buffer I/O error on dev sdc1, logical block 2134900, >> lost async page write >> [ 2794.535835] Buffer I/O error on dev sdc1, logical block 2134901, >> lost async page write >> [ 2794.535837] Buffer I/O error on dev sdc1, logical block 2134902, >> lost async page write >> [ 2842.568843] sd 9:0:0:0: [sdc] tag#0 FAILED Result: >> hostbyte=DID_ERROR driverbyte=DRIVER_SENSE >> [ 2842.568849] sd 9:0:0:0: [sdc] tag#0 Sense Key : Hardware Error [current] >> [ 2842.568852] sd 9:0:0:0: [sdc] tag#0 Add. Sense: No additional sense >> information >> [ 2842.568857] sd 9:0:0:0: [sdc] tag#0 CDB: Write(10) 2a 00 01 04 a4 >> 58 00 00 f0 00 >> [ 2842.568859] blk_update_request: I/O error, dev sdc, sector 17081432 >> [ 2842.568862] buffer_io_error: 20 callbacks suppressed >> >> nmon says sdc is 100% busy but doesn't show any reading or writing. I >> once pulled the USB stick in a situation like this and I ended up >> having to reformat it which I need to avoid this time since the file >> is crucial. What should I do? >> >> - Grant > > Whatever you do, do NOT try to unplug the USB you were writing to unless you > first manage to successfully unmount it. If you do pull the USB stick > regardless of its current I/O state you will likely corrupt whatever file you > were writing onto, or potentially more. > > You could well have a hardware failure here, which manifested itself during > your copying operation. Things you could try: > > Run lsof to find out which process is trying to access the USB fs and kill it. > Then see if you can remount it read-only. > > Run dd, dcfldd, ddrescue to make an image of the complete USB stick on your > hard drive and then try to recover any lost files with testdisk. > > Use any low level recovery tools the manufacturer may offer - they will likely > require MSWindows. > > Shut down your OS and disconnect the USB stick, then reboot and try again to > access it, although I would first create an image of the device using any of > the above tools. dd errored and lsof returned no output at all so I tried to reboot but even that hung after the first 2 lines of output so I did a hard reset after waiting an hour or so. Once it came back up I tried to do 'dd if=/dev/sdb1 of=usbstick' but I got this after awhile: dd: error reading ‘/dev/sdb1’: Input/output error 16937216+0 records in 16937216+0 records out 8671854592 bytes (8.7 GB) copied, 230.107 s, 37.7 MB/s It's a 64GB USB stick. dmesg says: [ 744.729873] sd 8:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 744.729879] sd 8:0:0:0: [sdb] tag#0 Sense Key : Medium Error [current] [ 744.729883] sd 8:0:0:0: [sdb] tag#0 Add. Sense: Unrecovered read error [ 744.729886] sd 8:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 01 02 78 e0 00 00 f0 00 [ 744.729889] blk_update_request: critical medium error, dev sdb, sector 16939232 [ 744.763468] sd 8:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 744.763472] sd 8:0:0:0: [sdb] tag#0 Sense Key : Medium Error [current] [ 744.763474] sd 8:0:0:0: [sdb] tag#0 Add. Sense: Unrecovered read error [ 744.763478] sd 8:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 01 02 79 00 00 00 04 00 [ 744.763480] blk_update_request: critical medium error, dev sdb, sector 16939264 [ 744.763482] Buffer I/O error on dev sdb1, logical block 4234304, async page read [ 744.786743] sd 8:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 744.786747] sd 8:0:0:0: [sdb] tag#0 Sense Key : Medium Error [current] [ 744.786750] sd 8:0:0:0: [sdb] tag#0 Add. Sense: Unrecovered read error [ 744.786753] sd 8:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 01 02 79 04 00 00 04 00 [ 744.786755] blk_update_request: critical medium error, dev sdb, sector 16939268 [ 744.786758] Buffer I/O erro
Re: [gentoo-user] USB crucial file recovery
On Sunday 28 Aug 2016 11:49:44 Grant wrote: > I have a USB stick with a crucial file on it (and only an old backup > elsewhere). It's formatted NTFS because I wanted to be able to open > the file on various Gentoo systems and my research indicated that NTFS > was the best solution. > > I decided to copy a 10GB file from a USB hard disk directly to the USB > stick this morning and I ran into errors so I canceled the operation > and now the file manager (thunar) has been stuck for well over an hour > and I'm getting errors like these over and over: > > [ 2794.535814] Buffer I/O error on dev sdc1, logical block 2134893, > lost async page write > [ 2794.535819] Buffer I/O error on dev sdc1, logical block 2134894, > lost async page write > [ 2794.535822] Buffer I/O error on dev sdc1, logical block 2134895, > lost async page write > [ 2794.535824] Buffer I/O error on dev sdc1, logical block 2134896, > lost async page write > [ 2794.535826] Buffer I/O error on dev sdc1, logical block 2134897, > lost async page write > [ 2794.535828] Buffer I/O error on dev sdc1, logical block 2134898, > lost async page write > [ 2794.535830] Buffer I/O error on dev sdc1, logical block 2134899, > lost async page write > [ 2794.535832] Buffer I/O error on dev sdc1, logical block 2134900, > lost async page write > [ 2794.535835] Buffer I/O error on dev sdc1, logical block 2134901, > lost async page write > [ 2794.535837] Buffer I/O error on dev sdc1, logical block 2134902, > lost async page write > [ 2842.568843] sd 9:0:0:0: [sdc] tag#0 FAILED Result: > hostbyte=DID_ERROR driverbyte=DRIVER_SENSE > [ 2842.568849] sd 9:0:0:0: [sdc] tag#0 Sense Key : Hardware Error [current] > [ 2842.568852] sd 9:0:0:0: [sdc] tag#0 Add. Sense: No additional sense > information > [ 2842.568857] sd 9:0:0:0: [sdc] tag#0 CDB: Write(10) 2a 00 01 04 a4 > 58 00 00 f0 00 > [ 2842.568859] blk_update_request: I/O error, dev sdc, sector 17081432 > [ 2842.568862] buffer_io_error: 20 callbacks suppressed > > nmon says sdc is 100% busy but doesn't show any reading or writing. I > once pulled the USB stick in a situation like this and I ended up > having to reformat it which I need to avoid this time since the file > is crucial. What should I do? > > - Grant Whatever you do, do NOT try to unplug the USB you were writing to unless you first manage to successfully unmount it. If you do pull the USB stick regardless of its current I/O state you will likely corrupt whatever file you were writing onto, or potentially more. You could well have a hardware failure here, which manifested itself during your copying operation. Things you could try: Run lsof to find out which process is trying to access the USB fs and kill it. Then see if you can remount it read-only. Run dd, dcfldd, ddrescue to make an image of the complete USB stick on your hard drive and then try to recover any lost files with testdisk. Use any low level recovery tools the manufacturer may offer - they will likely require MSWindows. Shut down your OS and disconnect the USB stick, then reboot and try again to access it, although I would first create an image of the device using any of the above tools. Good luck. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] USB crucial file recovery
On Sun, 28 Aug 2016 11:49:44 -0700, Grant wrote: > I have a USB stick with a crucial file on it (and only an old backup > elsewhere). It's formatted NTFS because I wanted to be able to open > the file on various Gentoo systems and my research indicated that NTFS > was the best solution. If it's only to be used on Gentoo (or Linux) systems, why not ext2? > [ 2794.535837] Buffer I/O error on dev sdc1, logical block 2134902, > lost async page write > [ 2842.568843] sd 9:0:0:0: [sdc] tag#0 FAILED Result: > hostbyte=DID_ERROR driverbyte=DRIVER_SENSE > [ 2842.568849] sd 9:0:0:0: [sdc] tag#0 Sense Key : Hardware Error > [current] [ 2842.568852] sd 9:0:0:0: [sdc] tag#0 Add. Sense: No > additional sense information > [ 2842.568857] sd 9:0:0:0: [sdc] tag#0 CDB: Write(10) 2a 00 01 04 a4 > 58 00 00 f0 00 > [ 2842.568859] blk_update_request: I/O error, dev sdc, sector 17081432 > [ 2842.568862] buffer_io_error: 20 callbacks suppressed > > nmon says sdc is 100% busy but doesn't show any reading or writing. I > once pulled the USB stick in a situation like this and I ended up > having to reformat it which I need to avoid this time since the file > is crucial. What should I do? That looks horribly like a hardware failure. The first step should be to see if you can dd the stick to an image file (without mounting it). Then you can work on the image file, or a copy of it, and try things like testdisk. If dd also gives hardware errors, ddrecsue may be able to recover some of it, hopefully including the important bits, but I'm not holding my breath for you :( -- Neil Bothwick When there's a will, I want to be in it. pgpKI2tw10OQb.pgp Description: OpenPGP digital signature
[gentoo-user] USB crucial file recovery
I have a USB stick with a crucial file on it (and only an old backup elsewhere). It's formatted NTFS because I wanted to be able to open the file on various Gentoo systems and my research indicated that NTFS was the best solution. I decided to copy a 10GB file from a USB hard disk directly to the USB stick this morning and I ran into errors so I canceled the operation and now the file manager (thunar) has been stuck for well over an hour and I'm getting errors like these over and over: [ 2794.535814] Buffer I/O error on dev sdc1, logical block 2134893, lost async page write [ 2794.535819] Buffer I/O error on dev sdc1, logical block 2134894, lost async page write [ 2794.535822] Buffer I/O error on dev sdc1, logical block 2134895, lost async page write [ 2794.535824] Buffer I/O error on dev sdc1, logical block 2134896, lost async page write [ 2794.535826] Buffer I/O error on dev sdc1, logical block 2134897, lost async page write [ 2794.535828] Buffer I/O error on dev sdc1, logical block 2134898, lost async page write [ 2794.535830] Buffer I/O error on dev sdc1, logical block 2134899, lost async page write [ 2794.535832] Buffer I/O error on dev sdc1, logical block 2134900, lost async page write [ 2794.535835] Buffer I/O error on dev sdc1, logical block 2134901, lost async page write [ 2794.535837] Buffer I/O error on dev sdc1, logical block 2134902, lost async page write [ 2842.568843] sd 9:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE [ 2842.568849] sd 9:0:0:0: [sdc] tag#0 Sense Key : Hardware Error [current] [ 2842.568852] sd 9:0:0:0: [sdc] tag#0 Add. Sense: No additional sense information [ 2842.568857] sd 9:0:0:0: [sdc] tag#0 CDB: Write(10) 2a 00 01 04 a4 58 00 00 f0 00 [ 2842.568859] blk_update_request: I/O error, dev sdc, sector 17081432 [ 2842.568862] buffer_io_error: 20 callbacks suppressed nmon says sdc is 100% busy but doesn't show any reading or writing. I once pulled the USB stick in a situation like this and I ended up having to reformat it which I need to avoid this time since the file is crucial. What should I do? - Grant
Re: [gentoo-user] removal of bopm before hopm is in tree
>From the dev mailing list: # Pacho Ramos (21 Aug 2016) # Dead for a long time in favour of hopm, bug #473754. # Removal in a month. net-misc/bopm On Sun, Aug 28, 2016 at 2:40 AM, Daniel Campbell wrote: > On 08/25/2016 07:29 PM, Raymond Jennings wrote: > > I still use bopm, and it built fine last time I emerged it. > > > > If hopm isn't in the tree yet, why was bopm still pmasked for removal? > > > > Reason for asking is I'm curious about removal procedures. I was under > > the impression that replacement packages get added to the tree before > > their obsolete predecessors get pmasked for booting out. > > > > And if that's not the case, should it be? > That's a good question, best answered by the developer who chose to have > the package removed. > > -- > Daniel Campbell - Gentoo Developer > OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net > fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 > >
Re: [gentoo-user] UEFI booting
On Sunday 28 Aug 2016 10:26:15 Mike Gilbert wrote: > On Sun, Aug 28, 2016 at 6:55 AM, Peter Humphrey wrote: --->8 > > ... part of the output of "bootctl status": > > > > Boot Loader Binaries: > > ESP: > > /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5 > > > > File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 231) > > File: └─/EFI/BOOT/BOOTX64.EFI > > > > Those binaries have been built on my system: by what process? > > When you run bootctl install, it copies > /usr/lib/systemd/boot/efi/systemd-bootx64.efi to > /boot/EFI/systemd/systemd-bootx64.efi and /boot/EFI/BOOT/BOOTX64.EFI. Ah, so when one of those is started, all it does (for present purposes) is to load the kernel specified in the appropriate /boot/loader/entries entry. > BOOTX64.EFI is only there as a fallback; if your EFI variables get > reset for some reason, most EFI firmwares will look for a file by that > name as a failsafe. I think I'd more-or-less inferred that, but thanks for the confirmation. -- Rgds Peter
Re: [gentoo-user] UEFI booting
On Sun, Aug 28, 2016 at 6:55 AM, Peter Humphrey wrote: > On Sunday 28 Aug 2016 10:55:56 Neil Bothwick wrote: >> On Sun, 28 Aug 2016 10:43:17 +0100, Peter Humphrey wrote: >> > I'd still like to know where the directory /usr/lib64/systemd/boot/efi >> > came from though. >> >> Surely it's from systemd-boot, it is installed by systemd here. What does >> qfile tell you? >> >> $ qfile /usr/lib/systemd/boot/efi > > Yes, it is. I was puzzling over the wrong thing. Here's part of the output > of "bootctl status": > > Boot Loader Binaries: > ESP: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5 > File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 231) > File: └─/EFI/BOOT/BOOTX64.EFI > > Those binaries have been built on my system: by what process? When you run bootctl install, it copies /usr/lib/systemd/boot/efi/systemd-bootx64.efi to /boot/EFI/systemd/systemd-bootx64.efi and /boot/EFI/BOOT/BOOTX64.EFI. BOOTX64.EFI is only there as a fallback; if your EFI variables get reset for some reason, most EFI firmwares will look for a file by that name as a failsafe.
Re: [gentoo-user] UEFI booting
On Sunday 28 Aug 2016 10:55:56 Neil Bothwick wrote: > On Sun, 28 Aug 2016 10:43:17 +0100, Peter Humphrey wrote: > > I'd still like to know where the directory /usr/lib64/systemd/boot/efi > > came from though. > > Surely it's from systemd-boot, it is installed by systemd here. What does > qfile tell you? > > $ qfile /usr/lib/systemd/boot/efi Yes, it is. I was puzzling over the wrong thing. Here's part of the output of "bootctl status": Boot Loader Binaries: ESP: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5 File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 231) File: └─/EFI/BOOT/BOOTX64.EFI Those binaries have been built on my system: by what process? -- Rgds Peter
Re: [gentoo-user] UEFI booting
On Sun, 28 Aug 2016 10:43:17 +0100, Peter Humphrey wrote: > I'd still like to know where the directory /usr/lib64/systemd/boot/efi > came from though. Surely it's from systemd-boot, it is installed by systemd here. What does qfile tell you? $ qfile /usr/lib/systemd/boot/efi -- Neil Bothwick I get enough exercise just pushing my luck. pgpYREJBNQBOP.pgp Description: OpenPGP digital signature
Re: [gentoo-user] UEFI booting
On Friday 26 Aug 2016 16:13:53 Mike Gilbert wrote: > On Fri, Aug 26, 2016 at 4:32 AM, Peter Humphrey wrote: > > In my search for a suitable boot method, I'm trying Mike G's > > systemd-boot > > ebuild. I've installed it with no problem, and now I reach the heart-in- > > mouth stage of actually replacing gummiboot with it. But first, the > > backup, including dd of what used to be called the MBR (what is it > > now?). > It should be basically a drop-in replacement, with a slightly > different name. It should not require any modification to your disk > layout. I've learned a few things over the last day, and now I have systemd-boot installed and gummiboot gone (late and somewhat lamented). # bootctl status System: Firmware: UEFI 2.31 (American Megatrends 5.09) Secure Boot: disabled Setup Mode: setup Loader: Product: systemd-boot 231 Partition: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5 File: └─/EFI/SYSTEMD/SYSTEMD-BOOTX64.EFI Boot Loader Binaries: ESP: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5 File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 231) File: └─/EFI/BOOT/BOOTX64.EFI Boot Loader Entries in EFI Variables: Title: Linux Boot Manager ID: 0x0001 Status: active, boot-order Partition: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5 File: └─/EFI/SYSTEMD/SYSTEMD-BOOTX64.EFI Title: UEFI OS ID: 0x000C Status: active, boot-order Partition: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5 File: └─/EFI/BOOT/BOOTX64.EFI I'd still like to know where the directory /usr/lib64/systemd/boot/efi came from though. https://wiki.archlinux.org/index.php/systemd-boot was the last link I needed; I hadn't realised until then that bootctl uses the same /boot/loader/... arrangement as gummiboot, Mike's "drop-in replacement" comment notwithstanding. I suggest that the Gentoo docs could use a version of this web page. > Also, you should be able to configure your firmware to load either > gummiboot or systemd-boot, so you have a fallback if the new code > fails. I did that, but now I'm happy with bootctl I've removed gummiboot. I took the opportunity of changing the partition layout somewhat. When I restored all my backups I found errors from polkit and dbus, which were preventing KDE from running properly. I assume this was because the partitions had new UUIDs. A quick "emerj -1av $(eix -cI# polkit)" and ditto dbus fixed it. alias emerj='sudo emerge --jobs=24 --load-average=48 --keep-going --nospinner' So thanks to Mike I now have a stable, maintainable system that suits me. -- Rgds Peter