Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 382757 - sys-apps/memtest86+ : make symlink creation optional
Summary: sys-apps/memtest86+ : make symlink creation optional
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Low enhancement with 1 vote (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-12 23:09 UTC by Hamlet
Modified: 2017-03-20 07:10 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Exaple of implementation of the request (memtest86+-4.20.patch,692 bytes, patch)
2011-09-12 23:14 UTC, Hamlet
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Hamlet 2011-09-12 23:09:11 UTC
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!
Comment 1 Hamlet 2011-09-12 23:14:44 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.
Comment 2 Dennis Schridde 2012-07-03 19:10:11 UTC
Ran into this again for sys-apps/memtest86+-4.20-r1.
Comment 3 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-07-03 23:26:16 UTC
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?
Comment 4 Dennis Schridde 2012-07-05 02:57:37 UTC
(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.
Comment 5 Dennis Schridde 2014-11-02 09:50:26 UTC
(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?
Comment 6 Stefan G. Weichinger 2015-02-04 09:31:58 UTC
I hit the same issue today with 5.0.1
Comment 7 cyshei 2016-03-09 03:16:04 UTC
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).
Comment 8 Fabian Köster 2016-07-14 06:38:51 UTC
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.
Comment 9 Eugene Cormier 2017-03-14 22:30:42 UTC
same problem here, updates are stalled
Comment 10 SpanKY gentoo-dev 2017-03-14 23:55:57 UTC
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
Comment 11 Eugene Cormier 2017-03-19 15:13:42 UTC
the same bug still exists for memtest86, can we get that patched as well?
Comment 12 SpanKY gentoo-dev 2017-03-20 07:10:38 UTC
(In reply to Eugene Cormier from comment #11)

you've filed bug 613228 for this now, so memtest86 will be handled there