Re: [gentoo-user] Is there a reason why LLVM/Clang ebuilds don't support "mutislot"?

[Deven Lahoti]

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"?

[P Levine]

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

[J. Roeleveld]

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

Re: [gentoo-user] USB crucial file recovery

[Grant]

>> 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 

Re: [gentoo-user] USB crucial file recovery

[Mick]

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

[Neil Bothwick]

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

[Grant]

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

[P Levine]

>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

[Peter Humphrey]

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

[Mike Gilbert]

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

[Peter Humphrey]

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

[Neil Bothwick]

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

[Peter Humphrey]

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

Re: [gentoo-user] removal of bopm before hopm is in tree

[Daniel Campbell]

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



signature.asc
Description: OpenPGP digital signature