Oleg Vinichenko
-
Posts
619 -
Joined
-
Last visited
-
Days Won
53
Content Type
Profiles
Forums
Blogs
Posts posted by Oleg Vinichenko
-
-
correct needed firmware will be loaded automatically, from the list
yes, you likely need new firmware, assuming latest security fixes against Spectre and Meltdown are also provided by microcode updates.
-
what is merged?
-
the ebuilds will be added when they are ready.
-
look in /etc/portage/package.unmask
-
this is indication of initramfs being the main target in tracking the problem. this is must be reported on bugs.funtoo.org. The install guide and update for ZFS should work. Detailed report with what problems are.
-
alternatively, give the SSH (with privileged) access to box to figure things out. it will be explained, then, what is happened and how fixed.
:)
-
@dougbmorris
paste output of
binutils-config -l
-
/boot is never mounted at boot time. Rest of problem is unclear for me out of description.
There will be some fixes in genkernel regarding LVM, which may (or may not) fix this particular one.
-
for the disklabel, you need to recompile the kernel again. the --disklabel argument added while back into the build process. real_root need set explicitly so that it will look
real_root=/dev/mapper/root (exact one on your box).
-
the fix to this will be applied soon.
-
paste output of grep -r systemd /etc/portage
-
there is no native GLSA-like tool in Funtoo but it's being working on. GLSA tool will work with Funtoo but it will produce some false positives. In Gentoo, security fixes are normally performed by bump to a certain upstream version which is acceptable policy but not ideal. In Funtoo, for the ebuiilds that are known of giving problems, security fixes are backported in very much Debian or Red hat manner. Real example:
https://glsa.gentoo.org/glsa/201801-17
states on updating to version 0.57.0-r1. In Funtoo, all mentioned problems are fixed in version 0.52.0-r1. poppler is known of having unstable ABI and it's often an intrusive update on users boxes (not always).
-
this is due to 4.14 kernel. it is known problem and will be sorted asap.
-
paste following output from both working and then non-working box:
ls -dl /var/db/pkg/*/*/*
-
to understand problem, it's required to get the following:
1. the state of working box
2. the state of non-working box
To me it looks that update of some ebuilds, such virtualbox or virtualbox-related ebuilds happened in case 2. Also, it could be kernel update.
-
yes, this is known bug. i reported it to usptream
-
Hi!
Its very difficult to follow the entire thread.
To understand the patterns of a problem a following information could help:
1. using same kernel but different OpenRC versions will reproduce the bug.
2. using same OpenRC version but different kernel will reproduce the bug
-
su - or su -l is recommended as in this case you're getting clean environment not contaminated with any variables such as XDG_CACHE_HOME and which was the origin of a failure.
-
so, that's the problem. normally
XDG_CACHE_HOME=/rootexpected. How do you use your terminal root? Via su, sudo, etc?
-
this failure could happen if your XDG environment incorrectly set. Thats when you start compilation in GUI (terminal emulator), some XDG* variables have special values. TO check, run following in terminal you used:
declare -p ${!XDG*}
-
Hiya!
Having no dedicated stages is indeed because of hardware lack. It is possible to convert the gentoo ppc64 stages into funtoo stages with some efforts, it could be challenging task, though.
-
10 minutes ago, da.ferri said:
Yes, it works... seems to be resolved and the connection is stable.
Funtoo davide # ls -al /etc/init.d/netif.eth0 ls: impossibile accedere a /etc/init.d/netif.eth0: File o directory non esistente Funtoo davide # cat /etc/conf.d/netif.eth0 cat: /etc/conf.d/netif.eth0: File o directory non esistente Funtoo davide # lsmod | grep r8169 r8169 90112 0 mii 16384 1 r8169
netif.eth0 -> no file or directory(maybe I've missed something during configuration?)
what exact guide used for this configuration?
-
well, this is not entirely 100% true about necessity of disabling module in kernel. Because it can be blacklisted at runtime. but it's correct that debian-sources has the r8169 enabled as module. This ebuild maybe need correction
-
peak size used by temporary directory where debian-sources compiling is about 17GB. 20GB is set in ebuild with some exceeding margin to ensure it's enough space.
Why 'Running pre-merge checks for sys-fs/eudev-3.2.2-r1' is so long?
in Portage Help
Posted
rm -rf /var/tmp/portage