Jump to content
funtoo forums

Tassie_Tux

Members
  • Content Count

    53
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by Tassie_Tux

  1. Tassie_Tux

    Tassie_Tux

  2. Try issuing the command # dispatch-conf
  3. I am looking at doing the same thing - starting with the gentoo guide - but do not have much spare time at the moment to invest in this. If/when I do, if I have progress I can let you know. ? The approach that I am now considering is to first follow that Gentoo guide to install arm64 Gentoo on the Rpi 3 B+. Then follow the Funtoo install guide using arm64 generic stage3 from within gentoo on RPi; including building a basic arm64 kernel and installing onto another micro SD card via USB. The downside of this approach is the compilation speed on the RPi being slow. I would prefer to cross compile Funtoo arm64 for RPi however I have so far been unable to successfully create a cross aarch64-unknown-linux-gnu toolchain.
  4. (Disregard my earlier theory. The absence of /dev/disk/by-id/ symlinks is not the issue as my old/working Funtoo on ZFS root install does not have these in the initramfs yet boot successfully.) At the GRUB command line, editing the parameters to boot with 'real_root=ZFS' is indeed successful, although there are several seconds delay. In the initramfs shell I am able to successfully import the pool manually with 'zpool import -N -d /dev rpool'. The command 'zpool import -N -c /etc/zfs/zpool.cache rpool' however fails with the same message reported by rspartz.
  5. Hi folks. I have spent most of last week working through https://www.funtoo.org/ZFS_Install_Guide again, with a view to update/fix the guide where needed. I too am facing the exact same issue. With over 8 retry-from-scratch attempts so far, the initramfs cannot import the pool. I am using a QEMU/KVM virtual machine as the install environment and I have tried using Ubuntu 16.04 and 17.10. All unsuccessful. The build is funtoo-current x86-64bit intel64-sandybridge. My current thinking is that the problem lies with the initramfs created by sys-kernel/genkernel. On pool import failure I go into the initramfs shell and see that there are no /dev/disk/by-id/ symlinks. Given that these links were used at pool creation and are referenced by zpool.cache, their absence in the initramfs is perhaps the cause of this import failure. (I cannot remember now whether or not I tried 'zpool import -d /dev rpool' from the initramfs shell. Too many attempts to keep track of!) Anyhow... that is my theory. On a Windows PC I have Funtoo on ZFS root in VirtualBox. That instance of Funtoo is what I used as the basis of updating https://www.funtoo.org/ZFS_Install_Guide back in late 2016. My goal this weekend is to look at that initramfs to confirm or exclude my theory that the issue is initramfs lacking /dev/disk/by-id/ symlinks. I will let you know what I find out. PS: 'swapoff /dev/zvol/rpool/swap' is indeed required to export rpool prior to first boot.
  6. Did you update portage as well? The guide http://www.funtoo.org/News:Python_Updater_Deprecation recommended this. # emerge --ask --nodeps --oneshot sys-apps/portage If emerge is not indicating updates or rebuilds then I would take that as 'all complete'.
  7. Now instead of python-updater simply update your world set according to the last step in the instructions that cardinal posted above. ;)
  8. Try eselect python list --python3 eselect python set --python3 X where X is the number from eselect python list.
  9. Of course. I was meaning more in a general sense for any of the threads under the Help Central section.
  10. Let's give it a go. :) Also, if reddit does not work out there is nothing stopping us restarting a forum or even moving on to another platform altogether. Before 'deactivating' the Forum we should try to transfer these guides to the Wiki.
  11. I too have noticed this when testing Funtoo on ZFS root. The storage pool containing root is exported during shutdown so this message suggests that the export is occurring before OpenRC is finished with writing to /lib64/rc/cache. The seriousness of this is debatable given that the system restarts without any obvious problems. Some research would be required.
  12. It is unfortunate that boot has been unsuccessful. Comments left on the Talk page.
  13. This (also) appears when performing a fresh merge of kde-base/kde-meta (i.e. KDE SC 4). The workaround that I have had success with is to first merge virtual/mysql (a dependency of KDE SC 4) emerge --oneshot virtual/mysql then retry the merge of kde-base/kde-meta emerge -atuvDN --with-bdeps=y @world kde-meta
  14. A new mix-in has been added to Funtoo Linux specifically for KDE Plasma 5. :) Installing KDE Plasma 5 (kde-plasma/plasma-meta)? Add the new mix-in kde-plasma-5. Installing KDE Plasma 4/KDE SC 4 (kde-base/kde-meta)? Add the existing mix-in kde. Do not add both at the same time. They are not configured to be combined. ;) (See www.funtoo.org/Funtoo_Profiles for help on adding or removing mix-ins.) I have started a general guide for installing the KDE Plasma Desktop (4 or 5) on Funtoo Linux - www.funtoo.org/KDE_Plasma_Desktop. The previously mentioned KDE Plasma 5 guide (www.funtoo.org/KDE_Plasma_5) remains as this provides instructions for installing KDE Plasma 5 with ebuilds from an external repository (overlay). N.B.: KDE Plasma 5 is really nice however I do experience occasional crashes/segmentation faults. If stability is critical then consider sticking with KDE Plasma 4 (KDE SC 4) for the time being. ;)
  15. I too would have chosen intel64-sandybridge. Your issues are either more complicated than simply your choice in subarch, or are indeed related to some other factor. For compilation issues I encourage you to report them on bugs.funtoo.org (see http://www.funtoo.org/Reporting_Bugs). When you do you will need to attach supporting information such as the output of 'emerge --info' and the particular package's build.log. The effort is however worth it as reporting like this is arguably the best way to receive timely assistance with build failures. As for the "illegal instruction" messages when running a successfully merged package, I would say in the first instance that more information is going to be required to assist you. Additionally, the information required will depend on the package causing problems for you.
  16. The kde mix-is is optimised for KDE SC 4 not KDE Plasma 5. While setting this for KDE Plasma 5 is probably helpful additional global USE flags in /etc/portage/make.conf and package-specific USE flags in /etc/portage/package.use will be required. There have been proposals for a KDE Plasma 5 mix-in (see https://bugs.funtoo.org/browse/FL-2373) however this is currently work-in-progress.
  17. When I first started with Funtoo I had attempted to install with a separate /var but was unable to get it to work smoothly. It is a configuration that most likely requires initramfs to mount pre-sysvinit/OpenRC. Well guess what? I am currently reading about LVM2! :D As for ZFS (which I run for non-root storage) I am not aware of a way to use ZFS zpools (i.e. logical volumes) with non-ZFS file systems. Keep reading. ;)
  18. nvidia-drivers + mesa with abi_x86_32
  19. Moving /usr/portage/distfiles and /var/lib/mysql from your SSD (/dev/sda3) to your HDD (/dev/sdb) would give you that needed space for LFS. Both can be mounted via /etc/fstab instead of an initramfs. Moving /var to a separate partition would most certainly require an initramfs. With /var/lib/mysql on its own partition you could then employ filesystem options that are tuned for optimal mysql performance. :) / (root) on /dev/sda with ext4 allows you the option of TRIM. LVM, ZFS and Btrfs allow snapshots/rollbacks.
  20. Perhaps a font error? Perhaps emerge media-fonts/font-bitstream-100dpi and/or media-fonts/corefonts as per this (https://wiki.gentoo.org/wiki/Steam#Missing_fonts).
  21. app-portage/cpuinfo2cpuflags seems to achieve that goal in the context of adding a suitable CPU_FLAGS_X86 entry to make.conf
  22. Overheating CPU? While compiling perhaps in a separate terminal run dmesg -w and look for messages indicating a reason why it shuts down.
  23. Are you recommending install with (VIDEO_CARDS) 'nouveau' first, confirm that X is working, and then reinstall with proprietary 'nvidia'? Yes one has to wonder what they are thinking! That must be why the nvidia-drivers ebuild is multilib by default.
  24. You are on the right track. :) Installing Funtoo with a x86-64bit stage3 can allow 32-bit versions of certain packages to run on 64-bit (amd64) systems. In your case the default configuration of x11-drivers/nvidia-drivers is to install 64-bit AND 32-bit libraries (as indicated by nvidia-drivers USE=?(multilib) ?? in your portage output above). This however requires other packages to also be built with 32-bit libraries. Portage is indicating this following the ?The following USE changes are necessary to proceed? line. To proceed you can follow the instructions that portage indicated in its last (long) message. Emerge xorg-x11 with emerge --ask --autounmask-write xorg-x11 Portage will indicate configuration files (package.use) requires updating. Run etc-update and accept/merge the changes (i.e. replace/discard old file). Now retry your original xorg-x11 emerge emerge --ask xorg-x11
  25. Like you I also use a custom kernel together with the following external kernel modules delivered via portage: sys-kernel/spl sys-fs/zfs-kmod sys-fs/vhba x11-drivers/nvidia-drivers When one of these packages is emerged - for the first time or for an update - the module is (as I understand) being built to work with the currently installed kernel. I have never seen portage request that the kernel is rebuilt. Now if I update my kernel I do need to re-emerge these kernel module ebuilds to work against the newer kernel. I find the easiest way to do this is to issue this command emerge -av @module-rebuild
×
×
  • Create New...