Tassie_Tux

Try issuing the command # dispatch-conf

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.

(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.

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.

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'.

Now instead of python-updater simply update your world set according to the last step in the instructions that cardinal posted above. ;)

Try eselect python list --python3 eselect python set --python3 X where X is the number from eselect python list.

Of course. I was meaning more in a general sense for any of the threads under the Help Central section.

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.

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.

It is unfortunate that boot has been unsuccessful. Comments left on the Talk page.

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

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. ;)

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.

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.

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. ;)

nvidia-drivers + mesa with abi_x86_32

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.

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).

app-portage/cpuinfo2cpuflags seems to achieve that goal in the context of adding a suitable CPU_FLAGS_X86 entry to make.conf

Overheating CPU? While compiling perhaps in a separate terminal run dmesg -w and look for messages indicating a reason why it shuts down.

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.

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

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

I have not installed LXQt but will try to help. :) Normally the X Window System (x11-base/xorg-x11) is merged first as a separate step before merging a desktop environment such as LXQt. Unfortunately the LXQt wiki page is currently lacking a reminder/warning about xorg-x11. I too would have expected portage to have complained about X being absent when merging LXQt. I had a similar issue once with enlightenment (forgetting xorg-x11). EDIT: I have updated the LXQt wiki to mention xorg-x11 on clean installs. Do you recall why portage asked you to create /etc/portage/profile/use.mask? Before merging x11-base/xorg-x11 one needs to set the variables VIDEO_CARDS and INPUT_DEVICES in /etc/portage/make.conf (see http://www.funtoo.org/X_Window_System). With those set emerge xorg-x11 should pull in xorg-drivers (e.g. x11-drivers/xf86-video-* packages) Portage is telling you that x11-terms/qterminal requires one (and only one) of the USE flags "qt4" and "qt5". The fact that it reported "-qt4 -qt5" indicates that neither one was enabled'. Adding USE="qt5" to /etc/portage/make.conf certainly solved that problem. Now I could be wrong but it seems strange to me that neither one was set for you. After the base (stage3) install but before emerge lxqt-meta, did you add any profile mix-ins such as 'lxqt'? (In other words, what does eselect profile list or epro show give you?) What do you mean by "flashes back to the xdm screen"? Back to the terminal? Have you considered using a Display Manager? (see http://www.funtoo.org/Package:XDM_(Display_Manager)). That may be easier and give you a nice login screen. ;) You have described a tricky experience but well done for getting there in the end. :) Having merged x11-base/xorg-x11 first before LXQt would have been helpful but unfortunately the current LXQt page lacks a reminder. Regarding LXQt applications - I do not know the answer to that. Was the lack of qt4 or qt5 USE flags a bug? It would help to know first what profile/mix-ins you set (if any). Need more information on your xdm problem.