Summary: | app-emulation/xen should not install kernels in /boot | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Carlos Silva <r3pek> |
Component: | Current packages | Assignee: | Ian Delaney (RETIRED) <idella4> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | xen |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
fix symlink issue when USE=efi and /boot is vfat
fix symlink issue when USE=efi and /boot is vfat |
Description
Carlos Silva
2013-02-24 00:03:53 UTC
Also, using the EFI use flag makes the package non-instalable. look at the deps: RDEPEND="efi? ( >=sys-devel/binutils-2.22[multitarget] ) >=sys-devel/binutils-2.22[-multitarget]" :) Additionally, xen-4-efi.patch seems a bit suspect I left some more useful feedback on bug 458160. (In reply to comment #1) > Also, using the EFI use flag makes the package non-instalable. > look at the deps: > RDEPEND="efi? ( >=sys-devel/binutils-2.22[multitarget] ) > >=sys-devel/binutils-2.22[-multitarget]" > > > :) not any more >xen ebuild tries to copy it's kernels to /boot ??????????? Initially I was confused, now I figure by kernels you mean the xen-4.2.x.gz and its companions. in or from src_install emake LDFLAGS="$(raw-ldflags)" DESTDIR="${D}" -C xen ${myopt} install This installs to /boot. This looks like changing the goal posts on every other xen user. However, the efi capable form I have manufactured only in response to Bug 458160, making it as new as you can get. What would be feasible at a glance is if this is restricted to the build with USE=efi. Pointing the install elsewhere requires no less than what I just did to install the efi executable. This beckons the question, "Is this suiting only your preferred setup at the cost of changing the goal posts to all others"? <This makes /boot a vfat filesystem since it's the best for efi booting. Rather, this required you to create, or this essentially requires, such a boot folder. What to me is as clear as mud is the degree to which you as a user have to manually customise this, primarily because you know about how to setup efi and I don't. I just found myself making the xen ebuild capable of it because it was required to fix the build in the aforementioned bug, the cause of which took some digging. That said, I'm more than happy to learn about efi. <Steps to Reproduce: <1. have /boot on a separate partition with a vfat filesystem <2. emerge xen Well, I see. Not until now have I see such a case for /boot, i.e. not your typical gentoo system /boot setup. Know the 20/80 rule? <Expected Results: <Don't create the links, or just don't copy the kernels at all to /boot Editing the ebuild to duplicate them to an alternate dir is simple. Editing to refrain from the symlinks equally so. The latter and substituting /boot as such is not the solution for obvious and already cited reasons. >I also tried exporting DONT_MOUNT_BOOT=1 as suggested by the ebuild testuser@archtester ~/cvsPortage/gentoo-x86/app-emulation/xen $ grep DONT_MOUNT_BOOT ./* yields blank. This is not from any xen ebuild, this would be from the xen source, but it could be set within an ebuild. I can make a fix for this, however the first attempt at the efi capable drew the 'above' points of (valid) critique requiring a revamp, and I'm not leaping into the next without a clearer view of what's required. (In reply to comment #4) > Editing the ebuild to duplicate them to an alternate dir is simple. Editing > to > refrain from the symlinks equally so. The latter and substituting /boot as > such is not the solution for obvious and already cited reasons. No problem with that. I only have xen installed because of virt-manager, i really don't use that files. Anyway, in the case of efi use flag is set, only the efi images should be installed, or install all the images for that files .gz and .efi. currently .efi are being installed to /usr/lib64/efi/. For me, the correct approach would be to install everything to /boot/ but without symlinks. > > >I also tried exporting DONT_MOUNT_BOOT=1 as suggested by the ebuild > > testuser@archtester ~/cvsPortage/gentoo-x86/app-emulation/xen $ grep > DONT_MOUNT_BOOT ./* > yields blank. > This is not from any xen ebuild, this would be from the xen source, but it > could be set within an ebuild. It comes from the mount-boot inherit. maybe this eclass should be fixed? > I can make a fix for this, however the first attempt at the efi capable drew > the 'above' points of (valid) critique requiring a revamp, and I'm not > leaping into the next without a clearer view of what's required. Hope my comments help now ;) (In reply to comment #5) > Anyway, in the case of efi use flag is set, > only the efi images should be installed, or install all the images for that > files .gz and .efi. currently .efi are being installed to /usr/lib64/efi/. What exactly are the efi images? I'm guessing 'they' include the .efi executable. > For me, the correct approach would be to install everything to /boot/ but > without symlinks. > Well that's quite a departure from installing into /usr/lib64/efi/. Firstly your /boot is assumed a vfat filesystem which can't use symlinks, secondly you're aslo second guessing the xen devs who decided on /usr/lib64/efi/. The correctness of this approach requires a major departure from not one but two norms!!! It's easy to make a duplicate target folder, let's say /usr/lib64/efi/boot, which you can copy to boot in making a custom setup post install @ your pleasure. However your above recipe, to me, ventures far outside anything resembling a generic approach that suits a generic user, if there is such a creature in the realm of xen + efi. I'll ponder. (In reply to comment #6) > (In reply to comment #5) > > Anyway, in the case of efi use flag is set, > > only the efi images should be installed, or install all the images for that > > files .gz and .efi. currently .efi are being installed to /usr/lib64/efi/. > > What exactly are the efi images? I'm guessing 'they' include the .efi > executable. Yep. It's just like a kernel, but loadable via UEFI. > > For me, the correct approach would be to install everything to /boot/ but > > without symlinks. > > > > Well that's quite a departure from installing into /usr/lib64/efi/. Firstly > your /boot is assumed a vfat filesystem which can't use symlinks, secondly > you're aslo second guessing the xen devs who decided on /usr/lib64/efi/. > The correctness of this approach requires a major departure from not one but > two norms!!! Really?! Changing the install location of 3 files?! Come on. EFI booting, requires the partition to be vfat so the EFI can read the files. So, /boot is a vfat partition. vfat doesn't allow symlinks. Don't install symlinks, or don't install anything at all on /boot. > It's easy to make a duplicate target folder, let's say /usr/lib64/efi/boot, > which you can copy to boot in making a custom setup post install @ your > pleasure. However your above recipe, to me, ventures far outside anything > resembling a generic approach that suits a generic user, if there is such a > creature in the realm of xen + efi. I'll ponder. Really, I can't understand why xen "kernels", or whatever they are, get to be installed on /boot but efi images don't. They serve the exact same purpose I think: to boot a xen enabled kernel. So why the difference? just that efi images *need* to be on a vfat filesystem. <Really?! Changing the install location of 3 files?! Come on. EFI booting, <requires the partition to be vfat so the EFI can read the files. So, /boot is a <vfat partition. vfat doesn't allow symlinks. Don't install symlinks, or don't <install anything at all on /boot. Really. Now let me get this, you don't consider having boot made to be a separate partition in a vfat file system a major departure from the norm. Need I cite the install manual? < Changing the install location of 3 files?! Come on. You are trivialising the non trivial. Now that said, the above points aren't dismissed out of hand because 1) I know better, and 2) and efi setup by its nature (apparently) re-writes the norm. I'm guessing yr view is blinkered to accommodate only your desired goal. The point is that however that efi suddenly makes it an issue. This turns the norm on its head. More importantly, this exact topic is currently in play in a thread in gentoo dev ML in which all your cited concerns are cited, particularly the notion of installing content currently installed to /usr/lib64/efi/ content directly into boot. In short, gentoo devs who forge gentoo such practices that deal with efi haven't got that far. We're working on it. (In reply to comment #8) > Really. Now let me get this, you don't consider having boot made to be a > separate partition in a vfat file system a major departure from the norm. > Need I cite the install manual? You don't ;) > Now that said, the above points aren't dismissed out of hand because 1) I > know better, and 2) and efi setup by its nature (apparently) re-writes the > norm. I'm guessing yr view is blinkered to accommodate only your desired > goal. The point is that however that efi suddenly makes it an issue. This > turns the norm on its head. More importantly, this exact topic is currently > in play in a thread in gentoo dev ML in which all your cited concerns are > cited, particularly the notion of installing content currently installed to > /usr/lib64/efi/ content directly into boot. > > In short, gentoo devs who forge gentoo such practices that deal with efi > haven't got that far. We're working on it. Well... EFI is a PITA :) but useful. I changed my system based on grub2 to a pure EFI one, so I know all the conversions I had to make. My PC was moving partitions for almost 24h just to get this right :P Still, if you have any doubts, or need any kind of info, i'm glad to help :) Created attachment 341236 [details, diff]
fix symlink issue when USE=efi and /boot is vfat
Final score; xen should not install kernels in /boot.
Something got lost in the translation here. The final outcome is that xen should and now install 'kernels' in /boot.
Point 1. For USE efi, in light of the need for /boot to be a vfat fs, /boot is assumed to be set and mounted vfat,
Point 2. The libdir efi binary is already duplicated to the /boot/efi/gentoo subdir,
Point 3. The symlinks are substituted with copies in the case of the xen.gz binary.
Anything beyond that is beyond the scope of a xen ebuild
Created attachment 341240 [details, diff]
fix symlink issue when USE=efi and /boot is vfat
clean-up diff header of previous patch
07 Mar 2013; Ian Delaney <idella4@gentoo.org> files/xen-4.2-efi.patch, xen-4.2.1-r2.ebuild: Deps corrected in 4.2.1-r2, patch addressing efi upgraded for newly made efi build, fixes Bug #458926 by Carlos Silva, patched prepared, tested by Paul Freeman |