I recently moved to UEFI booting my system completely removing any bootloader from the system and having all my kernels on /boot This makes /boot a vfat filesystem since it's the best for efi booting. It happens that xen ebuild tries to copy it's kernels to /boot and, even worse, create a link on that partition. Since vfat doesn't support links, the installation fails. I also tried exporting DONT_MOUNT_BOOT=1 as suggested by the ebuild but the problem still occured. Anyway, this doesn't look like a solution to me. I shouldn't be required to export that var everytime I emerge xen. Reproducible: Always Steps to Reproduce: 1. have /boot on a separate partition with a vfat filesystem 2. emerge xen Actual Results: >>> Installing (1 of 8) app-emulation/xen-4.2.1-r1 * checking 5 files for package collisions >>> Merging app-emulation/xen-4.2.1-r1 to / --- /boot/ !!! failed to properly create symlink: !!! /boot/xen-4.gz -> xen-4.2.1.gz !!! [Errno 1] Operation not permitted !!! Failed to move file. !!! /boot/xen-4.gz -> xen-4.2.1.gz Expected Results: Don't create the links, or just don't copy the kernels at all to /boot. # emerge --info Portage 2.1.11.52 (default/linux/amd64/13.0/desktop, gcc-4.6.3, glibc-2.16.0, 3.8.0-gentoo x86_64) ================================================================= System uname: Linux-3.8.0-gentoo-x86_64-Intel-R-_Core-TM-_i7-3820_CPU_@_3.60GHz-with-gentoo-2.2 KiB Mem: 16372920 total, 9272600 free KiB Swap: 16501756 total, 16501756 free Timestamp of tree: Sat, 23 Feb 2013 23:30:01 +0000 ld GNU ld (GNU Binutils) 2.23.1 app-shells/bash: 4.2_p42 dev-java/java-config: 2.1.12-r1 dev-lang/python: 2.7.3-r3, 3.2.3-r2 dev-util/cmake: 2.8.10.2-r1 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.6 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.4_p6-r1, 1.9.6-r3, 1.10.3, 1.11.6, 1.12.6, 1.13.1 sys-devel/binutils: 2.23.1 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.7 (virtual/os-headers) sys-libs/glibc: 2.16.0 Repositories: gentoo steam-overlay r3pek ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=corei7-avx -O3 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /usr/share/maven-bin-3.0/conf" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=corei7-avx -O3 -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j9" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/steam /home/r3pek/projects/portage-overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac aacplus aacs acl acpi alsa amd64 amr apng autoipd avahi avx bash-completion bazaar berkdb bidi bluetooth bluray branding btrfs bzip2 cairo cdda cddb cdio cdparanoia cdr cg cli collada colord connection-sharing consolekit cracklib crypt cuda cups curl cvs cxx cycles dbus demosaic devhelp dhcp dirac dmraid drawing dri dts dv dvb dvd dvdr eap-tls egl emboss encode exif extensions fam fat fax fdt ffmpeg fftw firefox flac fontconfig fortran frei0r fuse g3dvl gconf gd gdbm gdu geoip gflags gif gimp git glade gles gles1 gles2 gphoto2 gpm grc gsm gssapi gstreamer gtk gtk3 gtkhotkey gudev hddtemp hires-icons hpijs http httpd hvm hwdb iconv idn ieee1394 imagemagick infinality intel_led introspection ipv6 java jpeg jpeg2k keymap lame lcms ldap led libass libcanberra libnotify lua lua-cairo lua-imlib mad madwifi matroska mdadm mdnsresponder-compat melt mercurial minizip mms mmx mng modules mono mp3 mp4 mpeg mudflap multilib nat-pmp ncat ncurses ndiff network networkmanager new-login nfs nfsv3 nfsv4 nfsv41 nls nmap-update nping nptl nsplugin ntfs ntfsprogs nvidia odf ogg opencl opengl openmp openrc openssl osmesa pam pango pbins pcap pcre pdf pdfimport perl phyp pic player plugins png policykit portage postproc postscript ppds pulseaudio pygrub python qemu qt3support quicktime raw readline realtime redcode reiser4 reiserfs resolvconf roe rtmp samba sasl scanner schroedinger script sdl session shout skins slideshow slp smp sna sndfile snmp spell spice sqlite sse sse2 sse3 sse4_1 ssh ssl ssse3 startup-notification subversion svg tcpd theora threads thunar tiff tk truetype tweak-mode udev udisks uml unicode upnp upower urandom usb v4l vaapi vcd vdpau video vim vim-syntax virt-network virtfs virtualbox visibility vorbis vpx wavelet wavpack weather-metar webinterface webkit webkit2 wmf wps wxwidgets x264 xa xcb xcomposite xinerama xml xmp xosd xpm xrandr xscreensaver xv xvid xvmc zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="*" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" GRUB_PLATFORMS="emu efi-32 efi-64 pc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_US" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" QEMU_USER_TARGETS="*" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
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
