Summary: | sys-apps/memtest86+ : make symlink creation optional | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Hamlet <hamletghost> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | andre.reinke, cyshei, dschridde+gentoobugs, eugenecormier, gentoo, kingjon3377, lucas.yamanishi, tobias.pal |
Priority: | Low | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=267592 https://bugs.gentoo.org/show_bug.cgi?id=613228 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Exaple of implementation of the request |
Description
Hamlet
2011-09-12 23:09:11 UTC
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 |