Re: [gentoo-user] SNAFU

[antlists]

On 02/09/2021 23:11, Neil Bothwick wrote:

On Thu, 2 Sep 2021 23:49:40 +0200, David Haller wrote:


Yes it does, but only on the testing version. If you are running
stable, you won't have it.


I beg to differ on that point:


My bad, I was looking in the wrong part of the eix output.

It seems a trip to Barnard Castle is in order...


You might just need a case of BrewDog ...

Cheers,
Wol

Re: [gentoo-user] SNAFU

[Neil Bothwick]

On Thu, 2 Sep 2021 23:49:40 +0200, David Haller wrote:

> >Yes it does, but only on the testing version. If you are running
> >stable, you won't have it.  
> 
> I beg to differ on that point:

My bad, I was looking in the wrong part of the eix output.

It seems a trip to Barnard Castle is in order...


-- 
Neil Bothwick

Modulation in all things.


pgpAvW2nqn0nb.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] SNAFU

[David Haller]

Hello,

On Thu, 02 Sep 2021, David Haller wrote:
>On Thu, 02 Sep 2021, Neil Bothwick wrote:
>>Yes it does, but only on the testing version. If you are running stable,
>>you won't have it.
>
>I beg to differ on that point:
>
>$ cd $(portageq get_repo_path / gentoo)
>$ for f in sys-libs/glibc/glibc-*.ebuild; do \
>if grep -q 'KEYW.* amd64' "$f"; then \
>  printf "${f##*\/}:"; \
>  sed -n -e 's/IUSE.*\( +\?crypt \).*/\1/p' "$f"; \
>fi; \
>  done
>glibc-2.25-r11.ebuild:glibc-2.30-r9.ebuild: +crypt 
>glibc-2.31-r7.ebuild: +crypt 
>glibc-2.32-r8.ebuild: +crypt 
>glibc-2.33-r1.ebuild: +crypt 
>glibc-2.33.ebuild: +crypt 
>
>$ [same as above but with 'KEYW.* ~amd64']:
>glibc-2.33-r6.ebuild: +crypt 
>glibc-2.33-r7.ebuild: +crypt 
>glibc-2.34.ebuild: +crypt 
>glibc-.ebuild: +crypt
>
>Repo synced earlier today.

Ah yes, of course there is this:

$ grep -r sys-libs/glibc.*crypt  profiles/
profiles/base/package.use.force:=sys-libs/glibc-2.33-r2 crypt

-dnh

-- 
panic("huh?\n");
linux-2.2.16/arch/i386/kernel/smp.c

Re: [gentoo-user] SNAFU

[David Haller]

Hello,

On Thu, 02 Sep 2021, Neil Bothwick wrote:
>Yes it does, but only on the testing version. If you are running stable,
>you won't have it.

I beg to differ on that point:

$ cd $(portageq get_repo_path / gentoo)
$ for f in sys-libs/glibc/glibc-*.ebuild; do \
if grep -q 'KEYW.* amd64' "$f"; then \
  printf "${f##*\/}:"; \
  sed -n -e 's/IUSE.*\( +\?crypt \).*/\1/p' "$f"; \
fi; \
  done
glibc-2.25-r11.ebuild:glibc-2.30-r9.ebuild: +crypt 
glibc-2.31-r7.ebuild: +crypt 
glibc-2.32-r8.ebuild: +crypt 
glibc-2.33-r1.ebuild: +crypt 
glibc-2.33.ebuild: +crypt 

$ [same as above but with 'KEYW.* ~amd64']:
glibc-2.33-r6.ebuild: +crypt 
glibc-2.33-r7.ebuild: +crypt 
glibc-2.34.ebuild: +crypt 
glibc-.ebuild: +crypt

Repo synced earlier today.

HTH,
-dnh

-- 
printk(KERN_ERR "happy meal: Eieee, rx config register gets greasy fries.\n");
linux-2.6.19/drivers/net/sunhme.c

Re: [gentoo-user] SNAFU

[Neil Bothwick]

Replied to the list.

On Thu, 2 Sep 2021 15:50:37 -0400, Alan Grimes wrote:

> Neil Bothwick wrote:
> 
> If you wish to manually migrate now, there are a series
> of steps described on the wiki (see below), but the outline is:
> * unforce the crypt USE flag of sys-libs/glibc and disable it
> * unmask the system and split-usr (if applicable) USE flag of
> sys-libs/libxcrypt and enable it
> * unmask ~virtual/libcrypt-2
> 
> ###
> 
> Glibc simply DOES NOT HAVE a "crypt" useflag... so FALSE

Yes it does, but only on the testing version. If you are running stable,
you won't have it. But if you are running stable, why are you trying to
emerge libxcrypt-4.4.25?

It appears that your problem may be caused by trying to mix stable and
testing packages with inter-dependencies.


-- 
Neil Bothwick

All generalizations are false, including this one.


pgpbgi7J5lr2C.pgp
Description: OpenPGP digital signature

[gentoo-user] SNAFU

[Alan Grimes]

Chromium has been a heaping pile of crash these days so I've been
running update every few days to try to get a working version.


Ok, apparently gcj is not a thing anymore and has broken libidn (iirc), 

I got around that with a useflag...

As always, Gentoo finds new and more bizare ways to FAIL.

I noticed that udev wasn't building which is instantly a 3-alarm fire,
if not worse...

Library dl found: YES

../systemd-249/meson.build:910:0: ERROR: C shared or static library
'crypt' not found

A full log can be found at
/var/tmp/portage/sys-fs/udev-249-r2/work/systemd-249-abi_x86_32.x86/meson-logs/meson-log.txt
 * ERROR: sys-fs/udev-249-r2::gentoo failed (configure phase):
 *   (no error message)
 *
 * Call stack:
 * ebuild.sh, line  127:  Called src_configure
 *   environment, line 4090:  Called multilib-minimal_src_configure
 *   environment, line 2862:  Called multilib_foreach_abi
'multilib-minimal_abi_src_configure'
 *   environment, line 3115:  Called multibuild_foreach_variant
'_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure'
 *   environment, line 2792:  Called _multibuild_run
'_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure'
 *   environment, line 2790:  Called _multilib_multibuild_wrapper
'multilib-minimal_abi_src_configure'
 *   environment, line  710:  Called multilib-minimal_abi_src_configure
 *   environment, line 2856:  Called multilib_src_configure
 *   environment, line 3341:  Called meson_src_configure
 *   environment, line 2726:  Called die
 * The specific snippet of code:
 *   "${mesonargs[@]}" ) || die
 *
 * If you need support, post the output of `emerge --info
'=sys-fs/udev-249-r2::gentoo'`,
 * the complete build log and the output of `emerge -pqv
'=sys-fs/udev-249-r2::gentoo'`.
 * The complete build log is located at
'/var/tmp/portage/sys-fs/udev-249-r2/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/sys-fs/udev-249-r2/temp/environment'.
 * Working directory:
'/var/tmp/portage/sys-fs/udev-249-r2/work/systemd-249-abi_x86_32.x86'
 * S: '/var/tmp/portage/sys-fs/udev-249-r2/work/systemd-249'
sys-fs/udev-249-r2/temp/build.log lines 156-206/206 (END)


Libxcrypt, I guess???


Ok, so what's wrong with libxcrypt...

make[2]: Leaving directory
'/var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25-xcrypt_nocompat-abi_x86_64.amd64'
make[1]: Leaving directory
'/var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25-xcrypt_nocompat-abi_x86_64.amd64'
>>> Completed installing sys-libs/libxcrypt-4.4.25 into
/var/tmp/portage/sys-libs/libxcrypt-4.4.25/image

 * Final size of build directory: 11572 KiB (11.3 MiB)
 * Final size of installed tree:   1808 KiB ( 1.7 MiB)

 * checking 38 files for package collisions
 * This package will overwrite one or more files that may belong to other
 * packages (see list below). You can use a command such as `portageq
 * owners / ` to identify the installed package that owns a
 * file. If portageq reports that only one package owns a file then do
 * NOT file a bug report. A bug report is only useful if it identifies at
 * least two or more packages that are known to install the same file(s).
 * If a collision occurs and you can not explain where the file came from
 * then you should simply ignore the collision since there is not enough
 * information to determine if a real problem exists. Please do NOT file
 * a bug report at https://bugs.gentoo.org/ unless you report exactly
 * which two packages install the same file(s). See
 * https://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how
 * to solve the problem. And once again, please do NOT file a bug report
 * unless you have completely understood the above message.
 *
 * Detected file collision(s):
 *
 *  /usr/include/crypt.h
 *  /lib64/libcrypt.so.1
 *
 * Searching all installed packages for file collisions...
 *
 * Press Ctrl-C to Stop
 *
 * sys-libs/glibc-2.33-r7:2.2::gentoo
 *  /lib64/libcrypt.so.1
 *
 * Package 'sys-libs/libxcrypt-4.4.25' NOT merged due to file collisions.
 * If necessary, refer to your elog messages for the whole content of the
 * above message.


Obviously, anything associated with glibc is protected by the DO NOT
TOUCH ANYTHING ASSOCIATED WITH GLIBC FOR ANY REASON, EVER. rule...

So I'm roadblocked. =(

-- 
Beware of Zombies. =O 
#EggCrisis  #BlackWinter
White is the new Kulak.
Powers are not rights.

Re: [gentoo-user] SNAFU

[Neil Bothwick]

On Thu, 2 Sep 2021 10:35:49 -0400, Alan Grimes wrote:

> Chromium has been a heaping pile of crash these days so I've been
> running update every few days to try to get a working version.
> 
> 
> Ok, apparently gcj is not a thing anymore and has broken libidn (iirc), 
> 
> I got around that with a useflag...
> 
> As always, Gentoo finds new and more bizare ways to FAIL.
> 
> I noticed that udev wasn't building which is instantly a 3-alarm fire,
> if not worse...
> 
> Library dl found: YES
> 
> ../systemd-249/meson.build:910:0: ERROR: C shared or static library
> 'crypt' not found
> 
> A full log can be found at
> /var/tmp/portage/sys-fs/udev-249-r2/work/systemd-249-abi_x86_32.x86/meson-logs/meson-log.txt
>  * ERROR: sys-fs/udev-249-r2::gentoo failed (configure phase):
>  *   (no error message)
>  *
>  * Call stack:
>  * ebuild.sh, line  127:  Called src_configure
>  *   environment, line 4090:  Called multilib-minimal_src_configure
>  *   environment, line 2862:  Called multilib_foreach_abi
> 'multilib-minimal_abi_src_configure'
>  *   environment, line 3115:  Called multibuild_foreach_variant
> '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure'
>  *   environment, line 2792:  Called _multibuild_run
> '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure'
>  *   environment, line 2790:  Called _multilib_multibuild_wrapper
> 'multilib-minimal_abi_src_configure'
>  *   environment, line  710:  Called multilib-minimal_abi_src_configure
>  *   environment, line 2856:  Called multilib_src_configure
>  *   environment, line 3341:  Called meson_src_configure
>  *   environment, line 2726:  Called die
>  * The specific snippet of code:
>  *   "${mesonargs[@]}" ) || die
>  *
>  * If you need support, post the output of `emerge --info
> '=sys-fs/udev-249-r2::gentoo'`,
>  * the complete build log and the output of `emerge -pqv
> '=sys-fs/udev-249-r2::gentoo'`.
>  * The complete build log is located at
> '/var/tmp/portage/sys-fs/udev-249-r2/temp/build.log'.
>  * The ebuild environment file is located at
> '/var/tmp/portage/sys-fs/udev-249-r2/temp/environment'.
>  * Working directory:
> '/var/tmp/portage/sys-fs/udev-249-r2/work/systemd-249-abi_x86_32.x86'
>  * S: '/var/tmp/portage/sys-fs/udev-249-r2/work/systemd-249'
> sys-fs/udev-249-r2/temp/build.log lines 156-206/206 (END)
> 
> 
> Libxcrypt, I guess???
> 
> 
> Ok, so what's wrong with libxcrypt...
> 
> make[2]: Leaving directory
> '/var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25-xcrypt_nocompat-abi_x86_64.amd64'
> make[1]: Leaving directory
> '/var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25-xcrypt_nocompat-abi_x86_64.amd64'
> >>> Completed installing sys-libs/libxcrypt-4.4.25 into  
> /var/tmp/portage/sys-libs/libxcrypt-4.4.25/image
> 
>  * Final size of build directory: 11572 KiB (11.3 MiB)
>  * Final size of installed tree:   1808 KiB ( 1.7 MiB)
> 
>  * checking 38 files for package collisions
>  * This package will overwrite one or more files that may belong to
> other
>  * packages (see list below). You can use a command such as `portageq
>  * owners / ` to identify the installed package that owns a
>  * file. If portageq reports that only one package owns a file then do
>  * NOT file a bug report. A bug report is only useful if it identifies
> at
>  * least two or more packages that are known to install the same
> file(s).
>  * If a collision occurs and you can not explain where the file came
> from
>  * then you should simply ignore the collision since there is not enough
>  * information to determine if a real problem exists. Please do NOT file
>  * a bug report at https://bugs.gentoo.org/ unless you report exactly
>  * which two packages install the same file(s). See
>  * https://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how
>  * to solve the problem. And once again, please do NOT file a bug report
>  * unless you have completely understood the above message.
>  *
>  * Detected file collision(s):
>  *
>  *  /usr/include/crypt.h
>  *  /lib64/libcrypt.so.1
>  *
>  * Searching all installed packages for file collisions...
>  *
>  * Press Ctrl-C to Stop
>  *
>  * sys-libs/glibc-2.33-r7:2.2::gentoo
>  *  /lib64/libcrypt.so.1
>  *
>  * Package 'sys-libs/libxcrypt-4.4.25' NOT merged due to file
> collisions.
>  * If necessary, refer to your elog messages for the whole content of
> the
>  * above message.
> 
> 
> Obviously, anything associated with glibc is protected by the DO NOT
> TOUCH ANYTHING ASSOCIATED WITH GLIBC FOR ANY REASON, EVER. rule...
> 
> So I'm roadblocked. =(
> 
Did you read the news item from 23/7/21? It will have popped up when you
synced.

https://www.gentoo.org/support/news-items/2021-07-23-libxcrypt-migration.html


-- 
Neil Bothwick

You couldn't get a job as a firing squad target.


pgpHGbNATXVQH.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] SNAFU: TO THE N'TH POWER!

[Daniel Frey]

On 01/29/2017 09:29 AM, Alan Grimes wrote:
> Mick wrote:
>> - You have run the efibootmgr command with the right syntax, options and 
>> parameters and have run it a second time as 'efibootmgr -v' to verify its 
>> output shows correctly the path to your gentoo kernel image.
> 
> Can't do this step because of chicken and egg conflict.
> 

You need to boot from a UEFI-enabled live cd.

Dan

Re: [gentoo-user] SNAFU: TO THE N'TH POWER!

[Daniel Frey]

On 01/29/2017 09:07 AM, Alan Grimes wrote:
> Mick wrote:
>> On Saturday 28 Jan 2017 20:24:34 Alan Grimes wrote:
> 
> Dudes, sorry, I obviously have a crossed-neuron in my brain and can't
> remember MFT versus GPT because they are so conceptually similar, Give
> it a rest. Please don't waste more than a single line correcting me. =(
> I'll be first in line when they start selling RAM upgrades for brains.
> 

Sure, but you are asking for help. If you want relevant responses it
really helps when you refer to things correctly. When I was reading
through this thread I thought you were trying to EFI boot an NTFS
partition, and it looks like others were thinking the same thing.

At least here a few point it out, I've seen on other lists/forums/etc
they are not so forgiving.

Dan

Re: [gentoo-user] SNAFU: TO THE N'TH POWER!

[Neil Bothwick]

On Sun, 29 Jan 2017 12:29:52 -0500, Alan Grimes wrote:

> > - You have run the efibootmgr command with the right syntax, options
> > and parameters and have run it a second time as 'efibootmgr -v' to
> > verify its output shows correctly the path to your gentoo kernel
> > image.  
> 
> Can't do this step because of chicken and egg conflict.

You can do it from a live CD, as long as it is EFI enabled.


-- 
Neil Bothwick

Please rotate your phone 90 degrees and try again.


pgp14MwHG849h.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] SNAFU: TO THE N'TH POWER!

[Alan Grimes]

Mick wrote:
> - You have run the efibootmgr command with the right syntax, options and 
> parameters and have run it a second time as 'efibootmgr -v' to verify its 
> output shows correctly the path to your gentoo kernel image.

Can't do this step because of chicken and egg conflict.

-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.

Re: [gentoo-user] SNAFU: TO THE N'TH POWER!

[Alan Grimes]

Mick wrote:
> On Saturday 28 Jan 2017 20:24:34 Alan Grimes wrote:

Dudes, sorry, I obviously have a crossed-neuron in my brain and can't
remember MFT versus GPT because they are so conceptually similar, Give
it a rest. Please don't waste more than a single line correcting me. =(
I'll be first in line when they start selling RAM upgrades for brains.

-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.

Re: [gentoo-user] SNAFU: TO THE N'TH POWER!

[Neil Bothwick]

On Sat, 28 Jan 2017 20:24:34 -0500, Alan Grimes wrote:

> Neil Bothwick wrote:
> > On Sat, 28 Jan 2017 12:11:28 -0500, Alan Grimes wrote:
> >
> > It appears to be a 2-stage boot process:
> >
> > BIOS boot -> Binary of GRUB bootstrap loader.
> > You don't have a BIOS with a UEFI system.  
> 
> We were discussing BIOS boot on a MFT partition scheme, which is what
> I'm using right now.

There is no such thing as an MFT pattition scheme, and you have mentioned
UEFI several times, so you do not have BIOS (unless you are booting in
compatibility mode).

> > The boot manager in the firmware picks an EFI boot image from the ESP,
> > usually sda1. Once it loads that it's job is done. The boot image can
> > be a kernel or a secondary bootloader like GRUB.
> >
> > Really, there is rarely a point in using GRUB on a UEFI system. Any
> > bootloader adds extra complication, GRUB does it in spades. Just use a
> > boot manager like rEFInd or systemd-boot - the latter is the simpler
> > to work with AFAICT.  
> 
> I would tend to agree with you except I tried booting my kernel with the
> EFI stub loader by copying it to BOOTx64.EFI (the specification has the
> X lower case but actual implementations seem to be case insensitive),
> and the system would lock up. I have no idea what to read into that. The
> contribution of GRUB is that it makes it easier to change kernel
> parameters without recompiling the kernel.

That's why we have boot managers, such as systemd-boot (which doesn't
require systemd) and rEFInd. They allow you to boot with alternative
configurations in the same way that a bootloader like GRUB or syslinux
does with a BIOS system.

I think you need to stop poking around at this and take a step back to do
some reading to understand the EFI boot process. Then start again with a
clean slate and an EFI boot manager. I would recommend systemd-boot, it
is simple and slimline, but I haven't tried rEFInd, which does look a lot
prettier.

To give an idea of the simplicity of systemd-boot, here is the config file

timeout 3
default 00-*

Then you have a separate file for each kernel, or set of kernel options,
here is the default on my system.

title   Desktop
version 4.9.6-gentoo
linux   /vmlinuz-4.9.6-gentoo
options root=LABEL=vranx rd.luks.uuid=luks-69776234-fbf3-4455-9d39-cc5f2dcc33eb 
rootfstype=btrfs rootflags=rw,noatime,ssd,space_cache i915.enable_ips=0 
rd.shell net.ifnames=0 init=/usr/lib/systemd/systemd
initrd  /initramfs-4.9.6-gentoo.img

Seven lines of configuration in total, and at least two of those are
optional!


-- 
Neil Bothwick

Yeah, but what's the speed of dark?


pgp5M5eTx2Xic.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] SNAFU: TO THE N'TH POWER!

[Mick]

On Saturday 28 Jan 2017 20:24:34 Alan Grimes wrote:
> Neil Bothwick wrote:
> > On Sat, 28 Jan 2017 12:11:28 -0500, Alan Grimes wrote:
> > 
> > It appears to be a 2-stage boot process:
> > 
> > BIOS boot -> Binary of GRUB bootstrap loader.
> > You don't have a BIOS with a UEFI system.
> 
> We were discussing BIOS boot on a MFT partition scheme, which is what
> I'm using right now.

MFT is a table with file metadata within an NTFS partition:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365230(v=vs.85).aspx

Are you saying you are booting your system by chainloading the gentoo kernel 
(or GRUB) from an NTFS partition, with the MSWindows boot loader?

> > >Boot -> Grub libraries, config, and kernels.
> > 
> > The boot manager in the firmware picks an EFI boot image from the ESP,
> > usually sda1. Once it loads that it's job is done. The boot image can be
> > a kernel or a secondary bootloader like GRUB.
> > 
> > Really, there is rarely a point in using GRUB on a UEFI system. Any
> > bootloader adds extra complication, GRUB does it in spades. Just use a
> > boot manager like rEFInd or systemd-boot - the latter is the simpler to
> > work with AFAICT.
> 
> I would tend to agree with you except I tried booting my kernel with the
> EFI stub loader by copying it to BOOTx64.EFI (the specification has the
> X lower case but actual implementations seem to be case insensitive),
> and the system would lock up. I have no idea what to read into that. 

Can you please post the kernel error message?  Build the kernel with debugging 
support initially, to get some meaningful output.  Some things to check while 
troubleshooting it:

- Your Linux filesystem is built in the kernel
- You have also built in your kernel EFI and EFI stub support
- You have specified in your kernel the path to the / partition along with any 
other parameters e.g. CONFIG_CMDLINE="/dev/sda2 rootfstype=btrfs".
- The path to initramfs if you are using one is either specified on the 
CONFIG_CMDLINE as above, or it is built in the kernel itself as a cpio 
archive.
- You have run the efibootmgr command with the right syntax, options and 
parameters and have run it a second time as 'efibootmgr -v' to verify its 
output shows correctly the path to your gentoo kernel image.

> The
> contribution of GRUB is that it makes it easier to change kernel
> parameters without recompiling the kernel.

GRUB, gummiboot/systemd-boot, rEFInd and friends are all practical and 
potentially necessary means of switching between kernels and operating systems 
in a multiboot installation.  Otherwise you have to drop into your OS BIOS 
settings to select a boot image from there, or install and use UEFI shell.

Check the gentoo handbook and wiki pages for more details on this subject and 
post back any questions if something is not clear.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] SNAFU: TO THE N'TH POWER!

[Daniel Frey]

On 01/28/2017 05:24 PM, Alan Grimes wrote:
> Neil Bothwick wrote:
>> On Sat, 28 Jan 2017 12:11:28 -0500, Alan Grimes wrote:
>>
>> It appears to be a 2-stage boot process:
>>
>> BIOS boot -> Binary of GRUB bootstrap loader.
>> You don't have a BIOS with a UEFI system.
> 
> We were discussing BIOS boot on a MFT partition scheme, which is what
> I'm using right now.

There's no such thing as a MFT partition scheme. There's BIOS and GPT,
that's it (well, in this context.)

MFT is used by ntfs (a filesystem, not a partition layout) to store
metadata on files and directories on an ntfs partition.

They're very different things.

Dan

Re: [gentoo-user] SNAFU: TO THE N'TH POWER!

[Alan Grimes]

Neil Bothwick wrote:
> On Sat, 28 Jan 2017 12:11:28 -0500, Alan Grimes wrote:
>
> It appears to be a 2-stage boot process:
>
> BIOS boot -> Binary of GRUB bootstrap loader.
> You don't have a BIOS with a UEFI system.

We were discussing BIOS boot on a MFT partition scheme, which is what
I'm using right now.

> >Boot -> Grub libraries, config, and kernels.
> The boot manager in the firmware picks an EFI boot image from the ESP,
> usually sda1. Once it loads that it's job is done. The boot image can be
> a kernel or a secondary bootloader like GRUB.
>
> Really, there is rarely a point in using GRUB on a UEFI system. Any
> bootloader adds extra complication, GRUB does it in spades. Just use a
> boot manager like rEFInd or systemd-boot - the latter is the simpler to
> work with AFAICT.

I would tend to agree with you except I tried booting my kernel with the
EFI stub loader by copying it to BOOTx64.EFI (the specification has the
X lower case but actual implementations seem to be case insensitive),
and the system would lock up. I have no idea what to read into that. The
contribution of GRUB is that it makes it easier to change kernel
parameters without recompiling the kernel.

Damint, my e-mail editor is freezing and not showing my text for several
seconds... =( I can type through the pauses but can't read what I'm
misspelling during them. =/

-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.

Re: [gentoo-user] SNAFU: TO THE N'TH POWER!

[Neil Bothwick]

On Sat, 28 Jan 2017 12:11:28 -0500, Alan Grimes wrote:

> >> Device  Start   End   Sectors   Size Type
> >> /dev/sdc12048264191262144   128M EFI System
> >> /dev/sdc2  526336 537233407 536707072 255.9G Linux filesystem
> >> /dev/sdc3  264192526335262144   128M BIOS boot  
> > You don't have a BIOS boot partition on a UEFI system. They are for
> > compatibility when using GPT disks with BIOS systems, and even hen you
> > don't put anything on them.
> >
> > Just create an EFI System partition, formatted using FAT and mounted
> > at /boot as the first partition, then divide the rest of the disk
> > between /, /home swap as you see fit.  
> 
> It appears to be a 2-stage boot process:
> 
> BIOS boot -> Binary of GRUB bootstrap loader.

You don't have a BIOS with a UEFI system.
 
> Boot -> Grub libraries, config, and kernels.

The boot manager in the firmware picks an EFI boot image from the ESP,
usually sda1. Once it loads that it's job is done. The boot image can be
a kernel or a secondary bootloader like GRUB.

Really, there is rarely a point in using GRUB on a UEFI system. Any
bootloader adds extra complication, GRUB does it in spades. Just use a
boot manager like rEFInd or systemd-boot - the latter is the simpler to
work with AFAICT.


-- 
Neil Bothwick

"We demand rigidly defined areas of doubt and uncertainty!"


pgpIvT7HiXFLf.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] SNAFU: TO THE N'TH POWER!

[Tom H]

On Fri, Jan 27, 2017 at 10:07 AM, Alan Grimes  wrote:
>
> Had another learning experience with respect to how GPT disks work.,
> system is buttoned up and operating in GPT mode. In old systems, the
> boot sectors and bootstrap loaders were kinda consigned to a digital
> pergatory on the drive, now you just have to give it its own 1mb
> partition...

efi/gpt aren't more buttoned up; just different.

For example, for grub:

bios + msdos label
boot.img - embedded in mbr
core.img - embedded in post-mbr gap

bios + gpt label
boot.img - embedded in mbr
core.img - embedded in bios_boot partition

efi + gpt label
efi (pe/coff) executable on a fat partition

Re: [gentoo-user] SNAFU: TO THE N'TH POWER!

[Alan Grimes]

Neil Bothwick wrote:
> On Fri, 27 Jan 2017 08:41:44 -0500, Alan Grimes wrote:
>
>> Device  Start   End   Sectors   Size Type
>> /dev/sdc12048264191262144   128M EFI System
>> /dev/sdc2  526336 537233407 536707072 255.9G Linux filesystem
>> /dev/sdc3  264192526335262144   128M BIOS boot
> You don't have a BIOS boot partition on a UEFI system. They are for
> compatibility when using GPT disks with BIOS systems, and even hen you
> don't put anything on them.
>
> Just create an EFI System partition, formatted using FAT and mounted
> at /boot as the first partition, then divide the rest of the disk
> between /, /home swap as you see fit.

It appears to be a 2-stage boot process:

BIOS boot -> Binary of GRUB bootstrap loader.

Boot -> Grub libraries, config, and kernels.



-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.

Re: [gentoo-user] SNAFU: TO THE N'TH POWER!

[Neil Bothwick]

On Fri, 27 Jan 2017 08:41:44 -0500, Alan Grimes wrote:

> Device  Start   End   Sectors   Size Type
> /dev/sdc12048264191262144   128M EFI System
> /dev/sdc2  526336 537233407 536707072 255.9G Linux filesystem
> /dev/sdc3  264192526335262144   128M BIOS boot

You don't have a BIOS boot partition on a UEFI system. They are for
compatibility when using GPT disks with BIOS systems, and even hen you
don't put anything on them.

Just create an EFI System partition, formatted using FAT and mounted
at /boot as the first partition, then divide the rest of the disk
between /, /home swap as you see fit.


-- 
Neil Bothwick

Drink varnish and you'll have a lovely finish.


pgpzElG0x3awt.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] SNAFU: TO THE N'TH POWER!

[Alan Grimes]

Alan Grimes wrote:
[]

Had another learning experience with respect to how GPT disks work.,
system is buttoned up and operating in GPT mode. In old systems, the
boot sectors and bootstrap loaders were kinda consigned to a digital
pergatory on the drive, now you just have to give it its own 1mb
partition... *sigh*.

Oh well, at least I learned something from this ordeal...

-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.

[gentoo-user] SNAFU: TO THE N'TH POWER!

[Alan Grimes]

To make a boot disk in DOS you have two options.

Format /s  x:
and
Sys x:

Once this is done, the new disk will boot perfectly [period] .

So what I did was I deleted my botched UEFI partition, and created two
new partitions, each of half-size.
I mark ... well.:

#33
localhost ~ # fdisk -l /dev/sdc
Disk /dev/sdc: 256.2 GiB, 275064201216 bytes, 537234768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 00C7D602-412C-4505-8992-0482855EDEF9

Device  Start   End   Sectors   Size Type
/dev/sdc12048264191262144   128M EFI System
/dev/sdc2  526336 537233407 536707072 255.9G Linux filesystem
/dev/sdc3  264192526335262144   128M BIOS boot

Partition table entries are not in disk order.
localhost ~ #



I then set up my crap. on the BIOS boot partition, adjust the grub.cfg
entries on that partition to expect to show up as hd0/sda[*] and try to
boot the mofo...
I got some BIOS errors regarding a boot failure, I'm not sure what
that's about. =(
I adjusted my d-ram voltage back to 1.475 which is what I think it needs
to be... Have no idea, probably a red herring...

After that, u know what happened?

REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!
REBOOT LOOP!

Re: [gentoo-user] snafu: the update

[Tom H]

On Wed, Jan 25, 2017 at 6:58 PM, Alan Grimes  wrote:
> Tom H wrote:


>> AFAIK, when you load the kernel directly from the EFI firmware, it has
>> to have the ".efi" suffix. But that doesn't explain why it would stall
>> when loaded from grub...
>>
>> Somewhat OT: Regarding grub, your "/boot/" is messy. It might not be
>> making a difference for (efi)-grub2's functioning but you have grub1
>> files (*stage1_5), grub2 bios files (i386-pc/), as well as grub2 efi
>> files (x86_64-efi/).
>
> Yeah, I've been using that directory for many many long years, I ended
> up removing the grub directory completely and re-installing, it's much
> cleaner now.

ACK. I just thought that I'd point it out.


> I think there's something with how I'm compiling the kernel and the EFI
> boot requirements aren't quite being met and the loader is trying to
> execute non-code or some other error of that general nature. But that's
> just a brainstorm, I really hate it when my machine gives me this kind
> of problem where I don't even have an error message.

If you're loading the kernel from grub, you don't have to compile the
efi stub/stuff into the kernel.


>  FROM GRUB.CFG #
>
> echo 'Loading Linux 4.6.7 ...'
>  it successfully executes this line
> linux /vmlinuz-4.6.7 root=/dev/sda2 ro
>  but fails before the first output from the kernel
>
> 

Looking at your grub.cfg, I wonder whether "linux /vmlinuz-4.6.7 ..."
is correct.

Looking at your original "tree" output, it looks like you're mounting
the ESP at "/boot" and that grub's being loaded from
"/boot/EFI/gentoo/grubx64.efi".

What are the grub.cfg lines that start with "search" and "set root"?

Re: [gentoo-user] SNAFU: The plot thickens!

[Alan Grimes]

Bill Kenworthy wrote:
> On 27/01/17 08:33, Alan Grimes wrote:
>> Neil Bothwick wrote:
>>> On Thu, 26 Jan 2017 17:07:03 -0500, Alan Grimes wrote:
>>>
 4. Create MFT partition table.
>>> MFT? Isn't that something to do with NTFS? You need a GPT partition table
>>> if you want to boot with UEFI.
>>>
>> yeah, my bad memory, it was MFT, as offered by gparted. I don't seem to
>> have any tool to inspect the state of the partition tables like the old
>> Norton Utilities. =(
>>
> fdisk -l /dev/...
>
> BillK

localhost ~ # fdisk -l /dev/sdc
Disk /dev/sdc: 256.2 GiB, 275064201216 bytes, 537234768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 00C7D602-412C-4505-8992-0482855EDEF9

Device  Start   End   Sectors   Size Type
/dev/sdc12048526335524288   256M EFI System
/dev/sdc2  526336 537233407 536707072 255.9G Linux filesystem
localhost ~ #


Things tried since last post:

*Flashed the firmware on the drive, bumped it several release numbers...
*Tried waiting out the kernel pause, waited about 4 minutes, some post
just said it was slow by a factor of 30 seconds...
*Searching GooG for gripes about Grub on SSD systems.

No change in symptoms.


Check out this smartctl stat for my v-raptor: 

  4 Start_Stop_Count0x0032   100   100   000Old_age   Always   
-   206
  9 Power_On_Hours  0x0032   021   021   000Old_age   Always   
-   58325




-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.

Re: [gentoo-user] SNAFU: The plot thickens!

[Bill Kenworthy]

On 27/01/17 08:33, Alan Grimes wrote:
> Neil Bothwick wrote:
>> On Thu, 26 Jan 2017 17:07:03 -0500, Alan Grimes wrote:
>>
>>> 4. Create MFT partition table.
>> MFT? Isn't that something to do with NTFS? You need a GPT partition table
>> if you want to boot with UEFI.
>>
> 
> yeah, my bad memory, it was MFT, as offered by gparted. I don't seem to
> have any tool to inspect the state of the partition tables like the old
> Norton Utilities. =(
> 

fdisk -l /dev/...

BillK

Re: [gentoo-user] SNAFU: The plot thickens!

[Alan Grimes]

Neil Bothwick wrote:
> On Thu, 26 Jan 2017 17:07:03 -0500, Alan Grimes wrote:
>
>> 4. Create MFT partition table.
> MFT? Isn't that something to do with NTFS? You need a GPT partition table
> if you want to boot with UEFI.
>

yeah, my bad memory, it was MFT, as offered by gparted. I don't seem to
have any tool to inspect the state of the partition tables like the old
Norton Utilities. =(

-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.

Re: [gentoo-user] SNAFU: The plot thickens!

[Neil Bothwick]

On Thu, 26 Jan 2017 17:07:03 -0500, Alan Grimes wrote:

> 4. Create MFT partition table.

MFT? Isn't that something to do with NTFS? You need a GPT partition table
if you want to boot with UEFI.


-- 
Neil Bothwick

deja vous - the act of forgetting someone's name /again/ despite being
introduced to them several times.


pgpLjqPuYbOBv.pgp
Description: OpenPGP digital signature

[gentoo-user] SNAFU: The plot thickens!

[Alan Grimes]

My ordeal with grub continues.

I tried the bleeding edge GRUB, no change in behavior.


I realized that I had an additional source of information that I had
been neglecting. The boot fixer thumb drive I had in the back of the
mascheen was booting UEFI into a crappy bloating debian-ish thingy. It's
using an ubuntu fork of Grub and kernel 3.13 (!!!)

I tried to get it to load my main kernel, same error: Invalid sector
size: [2^16 - 1]

Which is an indictment of how I set up my SSD.

My procedure was as follows:

1. Take SSD out of shrink wrap.
2. Plug some random wires in.   (I have a motherboard with a marvell
secondary controller with a driver that doesn't request required
resources from the IOMMU stack so I had to move things down to a working
port, but well..)
3. Open Gparted
4. Create MFT partition table.
5. Allocate 0.1% of the drive to fat32 boot. (Okay, wasn't thinking too
hard, it's pretty excessively big but well...)
6. Format everything else ext4, which some random website says was good
for SSDs.

So obviously I did everything completely, hopelessly, wrong, as usual.

Maybe there is some issue where the drive negotiated some state of the
art protocol with the chipset that grub doesn't support?

I have no idea what happens when I select the menu item that is supposed
to load the kernel, I cannot prove that it's even loading the kernel
image into memory.

Linux is going to need a much lower fail factor for me to like it. =|

-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.

Re: [gentoo-user] snafu: the update

[Alan Grimes]

Tom H wrote:
> On Wed, Jan 25, 2017 at 1:05 PM, Alan Grimes  wrote:
>> The linux kernel stalls stone cold dead in either direct from firmware
>> or pass through grub mode.
> AFAIK, when you load the kernel directly from the EFI firmware, it has
> to have the ".efi" suffix. But that doesn't explain why it would stall
> when loaded from grub...
>
> Somewhat OT: Regarding grub, your "/boot/" is messy. It might not be
> making a difference for (efi)-grub2's functioning but you have grub1
> files (*stage1_5), grub2 bios files (i386-pc/), as well as grub2 efi
> files (x86_64-efi/).

Yeah, I've been using that directory for many many long years, I ended
up removing the grub directory completely and re-installing, it's much
cleaner now.

I think there's something with how I'm compiling the kernel and the EFI
boot requirements aren't quite being met and the loader is trying to
execute non-code or some other error of that general nature. But that's
just a brainstorm, I really hate it when my machine gives me this kind
of problem where I don't even have an error message.

 FROM GRUB.CFG #

echo'Loading Linux 4.6.7
...'    it successfully executes
this line.
linux   /vmlinuz-4.6.7 root=/dev/sda2 ro
check_enable_amd_mmconf amd_iommu=fullflush iommu=soft

 but fails before the first output from the kernel.


Hmm, I just realized that I had been assuming my machine had a proper 64
bit loader, maybe it's 32 bit for some stupid reason, enabling kernel
flag and doing another test (after dinner and some youtube vids...)

-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.

Re: [gentoo-user] snafu: the update

[Tom H]

On Wed, Jan 25, 2017 at 1:05 PM, Alan Grimes  wrote:
>
> The linux kernel stalls stone cold dead in either direct from firmware
> or pass through grub mode.

AFAIK, when you load the kernel directly from the EFI firmware, it has
to have the ".efi" suffix. But that doesn't explain why it would stall
when loaded from grub...

Somewhat OT: Regarding grub, your "/boot/" is messy. It might not be
making a difference for (efi)-grub2's functioning but you have grub1
files (*stage1_5), grub2 bios files (i386-pc/), as well as grub2 efi
files (x86_64-efi/).

[gentoo-user] snafu: the update

[Alan Grimes]

I re-installed grub and now it boots through the grub menu to the point
of handing off to the linux kernel. The linux kernel stalls stone cold
dead in either direct from firmware or pass through grub mode.

So I think Grub is 97.6% exonerated at this point.

This is my standard kernel.org pure vanilla 4.6.7 kernel, the obvious
EFI config variables have been set... No idea, will be trolling the
##linux channel for the next few hours...

-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.

[gentoo-user] SNAFU!!!! Boot drive modernization.

[Alan Grimes]

After 7 long years, the peace of mind feature on my Velociraptor HD had
finally given up the ghost.

So I get a new SSD, that's slightly smaller but still a large multiple
of what I actually need the drive for. =P

To be fully trendy (and finally wanting to put the 1980's to bed) I try
to set up UEFI on gpt partitions, so the new boot partition, which is
also excessively large, now has a EFI directory.



localhost new_uefi # tree -L 2
.
├── config-4.6.7
├── EFI
│   ├── BOOT
│   └── gentoo
├── grub
│   ├── default
│   ├── device.map
│   ├── e2fs_stage1_5
│   ├── fat_stage1_5
│   ├── ffs_stage1_5
│   ├── fonts
│   ├── grub.cfg
│   ├── grubenv
│   ├── i386-pc
│   ├── iso9660_stage1_5
│   ├── jfs_stage1_5
│   ├── locale
│   ├── minix_stage1_5
│   ├── reiserfs_stage1_5
│   ├── splash.xpm.gz
│   ├── stage1
│   ├── stage2
│   ├──
stage2_eltorito 


   

│   ├──
themes  


   

│   ├──
ufs2_stage1_5   


   

│   ├──
vstafs_stage1_5 


   

│   ├──
x86_64-efi  


   

│   └──
xfs_stage1_5


   

├──
memtest86plus   


   

│   ├──
memtest 


   

│   └──
memtest.netbsd  


   

├──
System.map-4.6.7


   

└──
vmlinuz-4.6.7   


   




   

10 directories, 23
files   




localhost new_uefi #


Okay,

I copy GRUB into BOOT and test it, I unplugged the 'raptor to make it a
good test. It got to the point of kernel loading where it stalled
presumably because the kernel couldn't find root. But I had TESTED GRUB
AND IT WORKED!!!11



Okay...

I then use a parted CD and tried to rsync my data across, got bitten by
the goddamned trailing / missfeature, ended up using mv and fixed the
directory entries instead of putting another 50gb of wear on my