For Vserver there is baselayout-vserver which is used by the vserver stages. Building a new system from stage1 (following the VServer HowTo by Hollow) fails on bootstrap.sh wanting to install sys-apps/baselayout instead of sys-apps/baselayout-vserver. In addition when pretending to emerge system (emerge -p system) it blocks on baselayout because of udev. Reproducible: Always Steps to Reproduce:
use the vserver/x86 profile...
vserver/x86 is the profile selected by default by the stage1 mentionned in the HowTo. (http://dev.gentoo.org/~hollow/vserver/stages/) There might be an issue with udev being pulled-in and causing itself that normal baselayout is pulled-in. I'm wondering why bootstrap.sh even thinks about looking for normal baselayout as it's masked. Does the initial portage call in bootstrap.sh just ignore masked status of packages? (/usr/bin/python import portage; print portage.settings.packages). This call always wants sys-apps/baselayout...
There is some fuzz .. at first you have to merge baselayout-vserver and unmerge baselayout-vserver (this should not happen with the vserver-stages AFAIK this only happens while using regular stages). After that you should be able to bootstrap your system. $ USE="build" emerge baselayout-vserver $ emerge -C baselayout
probably you want to run even this, to save you from more fuzz..: $ CONFIG_PROTECT="-*" emerge baselayout-vsever $ emerge -C baselayout
On the vserver stage1 I tried Christian's suggestion (comment #3) as well as Benedikt's one without success, baselayout-vserver emerges fine, but bootstrapping always want's to put in sys-apps/baselayout. Using a normal stage I get: 1) update /etc/make.profile to point to portage/profiles/vserver/x86 2) USE=build CONFIG_PROTECT="-*" emerge baselayout-vserver -> baselayout-vserver is blocked by baselayout 3) emerge unmerge sys-apps/baselayout -> mentionned as system package! (doing it anyhow) 4) USE=build CONFIG_PROTECT="-*" emerge baselayout-vserver -> fails: baselayout-vserver.ebuild: ebegin: command not found baselayout-vserver.ebuild: eend: command not found !!! ERROR: sys-apps/baselayout-vserver-1.11.13 failed. !!! Function src_install, line 318, Exitcode 127 The way I got vserver guest installed is to skip bootstrapping and build system twice with empty-tree (doing at the same time an upgrade to gcc-3.4)
Would you mind telling us, exactly which stage-tarball you are using ?! An emerge --info ouput from inside your chroot would also be nice.
Created attachment 69516 [details] Output of emerge --info and bootstrap.sh -p VServer stage: http://dev.gentoo.org/~hollow/vserver/stages/stage1-x86-2005.0.tar.bz2 Normal stage: releases/x86/2005.1/stages/x86/stage1-x86-2005.1.tar.bz2 Note: /usr/portage is a rsync snapshot mounted read-only. (snapshots tried, yesterday, and others over past few weeks) /usr/portage/distfiles is read-write. Attached: - output of emerge -i in the chroot - output of scripts/bootstrap.sh -p
*** Bug 108426 has been marked as a duplicate of this bug. ***
i don't know why bootstrap wants to pull in (or (bug 108426) why you want to install kde inside a vserver, hu?) but nevertheless, udev should DEPEND on virtual/baselayout, not sys-apps/baselayout
KDE inside vserver? A KDE session available through tightvnc because I want my favourite LaTeX-frontend Kile (and not some @%@! on windoze) when I'm at the university or at the school where I'm working part-time as physics teacher... And since my hosting company gives me 32 IPs for free I'm doing something for security and separate the tightvnc X session from the rest of the server!
I have KDE installed in my VServer guest, but running it on a Xserver running on the host there are long delays at session starting/ending. In addition some programs are started multiple time (e.g. kgpg) and xterm/konsole and friends don't want to start (hidden /dev/pts/*), only sshd knows how to get one without seeing it. Just masked udev and thing went fine (using monolitic KDE). Aim is to have multiple fully separate DE on same box usable at SAME time.
(In reply to comment #11) > I have KDE installed in my VServer guest, but running it on a Xserver running > on the host there are long delays at session starting/ending. In addition some > programs are started multiple time (e.g. kgpg) and xterm/konsole and friends > don't want to start (hidden /dev/pts/*), only sshd knows how to get one > without seeing it. the problem here is you won't get a pts on "vserver ... enter" because it just creates a bash process inside the guests context. if you enter the guest via ssh you'll get a pts entry...
(In reply to comment #12) > the problem here is you won't get a pts on "vserver ... enter" because it just > creates a bash process inside the guests context. if you enter the guest via > ssh you'll get a pts entry... > I have tried both ways, starting the KDE session from a vserver ... enter as well as from a SSH session to the guest. In both cases it's impossible to get a console under X because of the /dev/pts being hidden unless used in the guest. SSH works fine obtaining a /dev/pts/ device, but all the others don't. This is probably not directly a vserver issue, but more something on the side of those apps.
Setting the USE flag "-alsa" in /etc/make.conf works for the KDE problem. I found this by applying the trick from Bruno (#11) recursively until I got a "dependency required by kdebase/kde-libs" after I masked a few alsa packages. Thanks, friends, for the hints!
(In reply to comment #14) > Setting the USE flag "-alsa" in /etc/make.conf works for the KDE problem. I > found this by applying the trick from Bruno (#11) recursively until I got a > "dependency required by kdebase/kde-libs" after I masked a few alsa packages. > > Thanks, friends, for the hints! I have alsa, what you need to do is add "media-sound/alsa-driver" (in a recent enough version) to /etc/portage/profile/package.provide.
I'm using hollow's stage3-i686-2005.1-r1.tar.bz2 (made yesterday?) and still get the udev wanting baselayout error with vserver/x86 (deprecated, it said) and x86/2005.1/vserver profiles... Any advice, please?
Why is this assigned to me? What does udev have to do with this?
because udev depends on sys-apps/baselayout instead of virtual/baselayout
(In reply to comment #18) > because udev depends on sys-apps/baselayout instead of virtual/baselayout And it still does in udev-078.ebuild...
Hm, I looked into this for the 079 release, but how do I specify a specific version of a virtual? I need a newer baselayout for udev to work properly, does all of the other virtual providers of baselayout work properly with the udev specific things?
There is a lot of noise in the information on this bug, but if I understand you right is the issue connected to creating vserver stage1 tarballs. I suppose the howto that is referenced is http://www.gentoo.org/doc/en/vserver-howto.xml - however I've been unable to locate the instructions given to bootstrap a vserver build in that HowTo. On the other hand I've been able to verify this bug using dev-util/catalyst-1.1.10.10 and todays portage. Quick tests reveals that the following changes seems to solve the problem changing portage/profiles/default-linux/packages.build to hold virtual/baselayout (instead of sys-apps/baselayout) and echo virtual/baselayout sys-apps/baselayout >> portage/profiles/default-linux/virtuals Please crosscheck that these changes works for you and that is is not breaking any other profiles (before commiting the changes.)
well, only changing packages.build wouldn't suffice here, since baselayout is hardcoded everywhere in the profiles.. currently vserver stage1 is done manually by extracting a normal stage1 and replace baselayout with baselayout-vserver.. i know this is not an elegant solution, but as there is a new virtual system which accepts versions for virtuals this could be done now i guess
really bad - udev depends on sys-apps/baselayout gregkh: could you please change the DEPEND? either virtual/baselayout or ( sys-apps/baselayout || sys-apps/baselayout-vserver) should work, but right now udev is blocked in baselayout-vserver :-(
(In reply to comment #20) > Hm, I looked into this for the 079 release, but how do I specify a specific > version of a virtual? I need a newer baselayout for udev to work properly, > does all of the other virtual providers of baselayout work properly with > the udev specific things? > If you need for example >=sys-apps/baselayout-1.11.14, then you would replace the following: RDEPEND="${DEPEND} >=sys-apps/baselayout-1.11.14" RDEPEND="${DEPEND} >=virtual/baselayout-1.11.14" But I've got no idea, if that's working with older portage (and if it wouldn't be better to create a new virtual in virtual/baselayout as described in GLEP 37)
*** Bug 120381 has been marked as a duplicate of this bug. ***
you can workaround this issue by adding sys-fs/udev-<version> to /etc/portage/profile/package.provided
*** Bug 122776 has been marked as a duplicate of this bug. ***
Didn't had time to read all the comments. I had that problem while installing the sun-jdk package. After an equery depgraph sun-jdk, I found out that the problem was with the "alsa" package, which depends on "udev" So USE="-alsa" solved my problem.
(In reply to comment #28) > Didn't had time to read all the comments. > > I had that problem while installing the sun-jdk package. After an equery > depgraph sun-jdk, I found out that the problem was with the "alsa" package, > which depends on "udev" > > So USE="-alsa" solved my problem. > the problem is not alsa depending on udev, but udev depending on sys-apps/baselayout instead of virtual/baselayout, please see bug 123284 for details
today i discovered the real root of this evil. kernel-2.eclass depends on virtual/dev-manager, and alsa depends on virtual/alsa which in turn is provided by kernel sources, which in turn depend on udev because that's the default virtual. i just commited a fix to the default-linux/{amd64,x86}/2005.1/vserver profiles to fix this issue. thanks go to jonas pfenniger who made me look at alsa
