The standard ebuild will create a symbolic link in /boot . This makes the ebuild fail if the FS on which /boot is does not support links. I'd like a flag added to suppress this behaviour. Reproducible: Always Steps to Reproduce: 1. Have a FAT File System for /boor 2. emerge sys-apps/memtest86+ Actual Results: Fails installation due to "Operation not supported" (the operation being the creation of the symbolic link in the installation directory). Expected Results: Installation complete!
Created attachment 286287 [details, diff] Exaple of implementation of the request Very simple implementation of this request; this patch is to be applied on the ebuild sys-apps/memtest-86+/memtest86+-4.20.ebuild . A flag is added, on by default, which creates the symbolic link as usual. If it's disabled, a copy of the file is installed instead of the link. Note that the name of the use flag is conflicting with an existing one for the kernel... probably not the best choice.
Ran into this again for sys-apps/memtest86+-4.20-r1.
Uhm I didn't check the memtest86 backlog of bugs, to be honest, as I was solving some other issues. Honestly after considering this I'd probably just drop the symlink, I don't see much point in it. Given that memtest86+-5 is supposed to come out soon, would you mind if I waited for that?
(In reply to comment #3) > Honestly after considering this I'd probably just drop the symlink, I don't > see much point in it. Given that memtest86+-5 is supposed to come out soon, > would you mind if I waited for that? I can workaround it until then.
(In reply to Diego Elio Pettenò from comment #3) > Honestly after considering this I'd probably just drop the symlink, I don't > see much point in it. Given that memtest86+-5 is supposed to come out soon, > would you mind if I waited for that? sys-apps/memtest86+-5.01 is out (bug #486564). Any news on this issue here?
I hit the same issue today with 5.0.1
I just ran into this problem as well -- it seems like this will become an increasingly common issue, since /boot is typically a FAT32 partition on EFI systems (which is how I ran into this problem).
I don't want to be rude or anything, but I do not understand why this bug is still open: * It is open since 2011 (almost 5 years!) * It has a simple and effective PATCH without any significant downsides. * It probably affects the majority of users of this ebuild because FAT boot partitions are the default for EFI systems and EFI mode is the default for x86 for some years now. Therefore its priority should not be "Low" or "enhancement". It is a major bug. So please go ahead and apply this patch! Or at least set the correct properties for this bug report. Instead of introducing another use flag the ebuild maybe could also auto-detect if /boot's filesystem supports symlink, but that would already be an enhancement. Priority is now fixing this problem soon.
same problem here, updates are stalled
i've changed memtest86+ to not use symlinks at all. instead, we use the file names that upstream documents everywhere. namely: - memtest.bin is a raw bootable image - memtest is a bare metal ELF that means memtest.netbsd has been deleted. it never was related to netbsd ... it was just the naming convention picked because we were using grub's netbsd boot logic, and we picked that simply because it supported ELF images. see bug 267592 for details there. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=08eded4644881cf6de9a4acd78f047ed86d27276
the same bug still exists for memtest86, can we get that patched as well?
(In reply to Eugene Cormier from comment #11) you've filed bug 613228 for this now, so memtest86 will be handled there