*SOLVED* CentOS5 Template Metadata package?
Greetings, Any timeframe for a CentOS 5 Template Metadata package? I saw that someone has created a howto upgrade a CentOS 4 VPS to CentOS 5 from which they make a template cache... but how about a metadata package? Are there any technical reasons keeping this from happening or is it basically a time-to-do-it issue? Thanks in advance for any consideration!
Hello, Quote: Are there any technical reasons keeping this from happening or is it basically a time-to-do-it issue? It's basically a time-to-do-it problem. We plan to create such metadata, but no ETA at the moment, sorry. Thank you, Vasily.
I've created the metadata for CentOS 5 but it gave me the initscripts error when creating from scratch (works fine with my centos 4>5 upgrade template) Quote: --> Running transaction check --> Processing Conflict: initscripts conflicts kernel < 2.6.12 --> Finished Dependency Resolution Error: initscripts conflicts with kernel < 2.6.12 ERROR: yum failed with 1 exit code Quote: Linux got-it.fast 2.6.18-ovz028stab031.1-enterprise #1 SMP Thu Apr 26 21:10:46 MSD 2007 i686 athlon i386 GNU/Linux
Using the Fedora Core 5 vz-addons and Centos 5 config files the result is: Cache file centos-5-i386-minimal.tar.gz [44M] created. Cache file centos-5-i386-default.tar.gz [121M] created.
Hello, Thank you for the work! Where can we download this metadata and precreated template? Thank you, Vasily.
Is there a way to obtain information as to how these metadata files are created? I've been using OpenVZ for some time now and notice that most of the development effort goes into the OpenVZ kernel patches. While the matching kernel for RHEL 5 was available almost immediately, the CentOS 5 metadata (perhaps the ugly stepchild of the project) is still not available. If I could obtain instructions on how to create it (I see that is a todo item on the wiki) I would be happy to create it and contribute it back to the project.
You can easily create a new metadata using an old one Tale a look at /vz/templates/$OS/
sspt wrote on Sat, 09 June 2007 14:20 You can easily create a new metadata using an old one Tale a look at /vz/templates/$OS/ I actually looked through there before I posted. It seems to me that there are packages in vz-addons that depend specifically on the OS version (dummy-centos-4-1.0-3.swsoft). Aren't the two other packages (MAKEDEV and vzdev) also quite different for CentOS 5? I'm asking since I've read of some difficulties with devices in the /dev directory when using CentOS 5 VPSs. If this is really this easy why hasn't SWSoft released it yet? I feel like I'm missing something here.
Anything new to this subject? I going to move a couple of systems to OpenVZ VPS, and feel it is a little odd to start with centos-4 when centos-5 has been ready for some time. The problem is that I dont have enough knowledge or experince to create the metadata template my self. I have found the centos-5-i386-XXX.tar.gz and is able to install a centos-5 system, but without the abillity to run vzyum install or update (because of lacking metadata) it is useless. Any pointers to contributed centos-5 metadata ? /Thomas
Re: *SOLVED* CentOS5 Template Metadata package?
OK, I've finally managed to get this to work. (If anything besides frustrating, it's made me appreciate the hard work that's gone into all of this.) After seeing posts from sspt getting the template metadata for CentOS 5 to work using the Fedora 5 package I started combing through the Fedora 5 package to see what was different. As it turns out, the only significant difference is that the dummy package is created so as to provide kernel 2.6.9 which is, of course, too old for many of the packages that come with CentOS 5. Simply changing the value in this package to 2.6.18 appears to work. I then worked my way through the remaining files changing references to CentOS 4 to CentOS 5. I also changed the rpm version from 4.3 to 4.4, updated the repo data, changed the GPG keys, and other small, mostly cosmetic changes. I'm certainly not an rpm expert, but I have created a new rpm for CentOS 5 metadata. I have successfully installed it and created a CentOS 5 minimal cache file from it with no errors. Perhaps one of the developers can check it out and if it's OK I will be happy to contribute it. As it's only 129kb I've attached the rpm here.
Hey steve I have tried your RPM. Build the cache files work fine. The creation of the VPS went fine: # vzctl create 206 --ostemplate centos-5-i386-minimal Creating VE private area (centos-5-i386-minimal) Performing postcreate actions VE private area was created and it seems like it will start: # vzctl start 206 Starting VE ... VE is mounted Setting CPU units: 1000 VE start in progress... but I cant do any thing useful: # vzctl enter 206 enter into VE 206 failed Unable to open pty: No such file or directory My host system is a FC5 with a /vmlinuz-2.6.18-8.el5.028stab027.1 kernel, and I have no problems creating and running centos 4 VPS. I have tried to ssh into the centos 5 VPS but it says connection refused, which often means no sshd. vzctl exec works, and ps shows: # vzctl exec 206 ps PID TTY TIME CMD 1 ? 00:00:00 init 16341 ? 00:00:00 udevd 17608 ? 00:00:00 syslogd 17636 ? 00:00:00 ps Any suggestions? /Thomas
Thomas, well I should have done this earlier, but I just tried creating a VPS with the minimal template I built and everything works great. I am using a CentOS 4 system with a CentOS 4 kernel although I don't think that really has anything to do with template creation. Here are some possibilities: 1. Corrupt template image - I've had that happen to me several times while transferring the image to another server. Have you tried erasing and re-creating the template? No need to delete the yum-cache, just the image and re-issue the vzpkgcache centos-5-i386-minimal command. 2. Not enough memory. Every time my VPS doesn't have enough memory, I get the "Unable to open pty" error. 3. What does /vz/private/206/dev show for you? By the way, my ps shows: # vzctl exec 129 ps PID TTY TIME CMD 1 ? 00:00:00 init 13420 ? 00:00:00 syslogd 13440 ? 00:00:00 sshd 13723 ? 00:00:00 ps
Hi Steve I tried again on another of my servers - a FC6 host running the same kernel, and every thing worked. So with a little more work I'm sure the FC5 server will work too. Thanks for your effort. regards Thomas
Hi steve (or others) I have tried different aproached to getting the centos-5 templates to run on my FC5-server. The cache has been rebuild, and I have verified that no ressources has run into limits via /proc/user_beancounters. It seems that /dev causes some problems. As shown in a previous post to this thread udevd seems to hang, and the content of /dev is limits to: # vzctl exec 208 ls /dev MAKEDEV X0R console core fd initctl log loop0 loop1 loop2 loop3 loop4 loop5 loop6 loop7 mapper net null parport0 parport1 parport2 parport3 ppp pts shm stderr stdin stdout tty urandom zero As I mentioned in my last post, a FC6 based server works fine. IT seems like both FC5-host and FC6-host uses udev. But still something around udevs seems to cause trouble in the centos 5 VPS. Any ideas is apreciated. /Thomas
Re: *SOLVED* CentOS5 Template Metadata package? (udev problem)
Hi steve (and others) Now I have found a solution, and have centos-5 vps running on my FC5 server. BUT I still dont understand til problem. /sys/class/tty/console is missing. This causes /sbin/start_udev to fail. From the web (something about coLinux) a similiar problems was seen. And they changed /etc/rc.d/rc.sysinit line /sbin/start_udev to [ -f /sys/class/tty/console/uevent ] && /sbin/start_udev If I make this change in the centos 5 VPS and restart it, it seems to work. If I run /sbin/start_udev manually it complains about "kernel too old for this udev". This seems strange since i'm running the newest el5 kernel (2.6.18-8.1.4.el5.028stab035.1). I dont like to use this rc.sysinit hack, when i dont understand the problem. Any ideas about what is going on? /Thomas
Thomas, I don't have a Fedora 5 system to try this on anymore, but thinking maybe it was a problem with udev, I tried the template on a CentOS 5 system. It worked just as well as the CentOS 4 system I previously used it on. You mention that /sys/class/tty/console is missing. It is on mine too, but I can login just fine (both using vzctl and ssh). The only thing I can think of perhaps changing is the MAKEDEV package. However, I'm not sure that the devices created by that package are significantly different to make any change worthwhile. I also can't imagine this working on CentOS 5 (based on FC6) and not on FC5 as FC5 and FC6 were very similar.
Steve, Thanks for building this package. I know I'm the one who originally asked for it (in this forum topic thread anyway)... but I just got around to trying your vztmpl-centos-5 package out. I installed it on a RHEL 5 system and when I tried to build a centos-5 template cache I got the following error messages: Transaction Check Error: file /sbin/insmod conflicts between attempted installs of dummy-centos-5-1.0-4.swsoft and module-init-tools-3.3-0.pre3.1.16.0.1.el5 file /sbin/insmod.static conflicts between attempted installs of dummy-centos-5-1.0-4.swsoft and module-init-tools-3.3-0.pre3.1.16.0.1.el5 file /sbin/lsmod conflicts between attempted installs of dummy-centos-5-1.0-4.swsoft and module-init-tools-3.3-0.pre3.1.16.0.1.el5 file /sbin/modprobe conflicts between attempted installs of dummy-centos-5-1.0-4.swsoft and module-init-tools-3.3-0.pre3.1.16.0.1.el5 ERROR: yum failed with 1 exit code Darn the luck.
Steve, Say... are you the one that created/posted the pre-created CentOS-5 OS template that is found in the pre-created OS template download section? If so, please edit the default.list file from your vztmpl-centos-5 and add yum to it. As it is, vzyum from the HN doesn't work... and using rpm to install yum from within a CentOS-5 based VPS I created is a MAJOR PAIN as it shows a dependency tree that is very hard to satisfy. If you do rebuild your centos-5 OS template to include yum... please let me know where I can download it. As it is, having a centos-5 based VPS that I can't easily install software on makes it almost useless. Thanks in advance for any consideration, Scott Dowdle
Steve, Ok, I found a work around... vzyum from the HN wouldn't work because it complained that there was no such OS template... which makes sense since I installed the VPS in question from a pre-created OS template rather than installing the metadata package and creating my own. I installed your vztmpl-centos-5 package again (I had removed it after it didn't work for me) and now vzyum worked and did install yum into the VPS. That certainly isn't the best way to go about it... but hey, it got me going.
dowdle- No, I'm not the one who created the pre-created CentOS 5 template. You've already found out that if you go that way without a matching template cache, you can't use yum to update the VPSs from the host node. Having said that, I'm not sure why you received error messages when trying to build a template cache. Were you able to get it to work? I really like being able to update each VPS running vzyum on the host node. It really comes in handy as you don't have to recreate a yum cache on each VPS. I followed the lead of the CentOS 4 template by not including it in the cache. However, if you want to change this it is easy to add yum. Just edit /vz/template/centos/5/i386/config/default.list and add yum to the list. Better yet, create a new file by copying the default.list to say default-with-yum.list and add yum. Now, delete your existing template from /vz/template/cache and then run vzpkgcache centos-5-i386-default-with-yum. When you do this, yum should automatically pick up its dependencies and add them to the image. It's really ingenious how these guys have created this. It makes it so easy to create multiple templates and keep them up to date.
Steve, No, I tried it on a RHEL5 and a CentOS5 based machine and no matter what I did, I still got those error messages... when trying to vzpkgcache using your vztmpl-centos-5 metadata package... which is really weird... because it seems to be trying to compare the package set to that of the hardware node, yes? Yes, I'm familiar with the default.list file. In the Introduction to OpenVZ Screencast that I did, I mention that file and edit it before building a CentOS 4 cache. Since I have LAN based copies of all of the repos I use, I also alter the yum.conf file and have it point to my repos rather than the stock ones... and it makes it a lot faster. I have also run into the issue when I create VPSes from the pre-created centos-5 os template... where when I tried to vzctl enter it, it says that pty is missing and fails. I tried the fix that was mentioned in this thread (edit the start_udev line in the /etc/rc.sysinit) but that works for me sometimes and other times it doesn't. Basically trying to get a centos 5 VPS is problematic but I'm sticking with it. I'm guessing it is something with the dummy-udev package but I have no idea what.
Hi I was the one that have described the pty problem earlier on this thread. I have later found out that it is caused by some kind of error that occurs when running vzpkgcache. I have not been able find out what is wrong. My original test - that gave the pty error - was when I ran vzpkgcache on a FC5 server behind a firewall (with squid proxy - which means no direct internet access). This test scenario gave me a template-cache from which I could create a VPS - but the VPS had the pty error. On another location I tries the same with an FC6 server with direct internet access. The templatecache created here with vzpkgcahe work perfectly well. I thought it was an FC5/FC6 issue, and tried to create the templatecache on a FC6 behind the squid-proxy. This image gave the same pty error in VPS on this FC6 server. Then I tried to move the template-cache created on the FC6-server with direct internet-access to the original FC5 server behind firewall and squid-proxy. VPS's created from the template worked perfectly well, which out the pty error. I'm still confused but happy that I don't have to patch any setup files, when using the "well-created" template. If any one can cast light on this issue, it would be nice. Any one that have experienced the pty problem can try to download my centos5-i386-minimal-template created from the FC6 with direct internet-access, and see if it works (no pty problem, vzyum working) It is created from an unmodified version of Steve's template, and required Steve's template to be installed to run vzyum. It can be found on http:/www.sonnet.dk/centos-5-i386-minimal.tar.gz look forward to hear feedback. /Tpso
So I'm trying to get the Centos5 template installed on Centos5 and with the current OVZ toolset installed via Yum, I'm getting: rpm -ivh vztmpl-centos-5-2.0-2.i386.rpm error: Failed dependencies: vzrpm43 is needed by vztmpl-centos-5-2.0-2.i386 It seems that using "--nodeps" will get me past this but if someone could post the SRPM, I can try to get this cleaned up and maybe we can get it posted to the Wiki. Anyway.. I'm using the one template file included in this thread and so far running vzpkgcache seems to be ok.
dranch- Is there some reason that you don't want to install vzrpm43? (http://openvz.org/download/template/utils/)
tpso wrote on Wed, 15 August 2007 11:26 Hi I was the one that have described the pty problem earlier on this thread. I have later found out that it is caused by some kind of error that occurs when running vzpkgcache. I have not been able find out what is wrong. /Tpso tpso- I really don't get this. The only packages that I think would affect the /dev/pty files in the image are in the /vz/templates/centos/5/i386/vz-addons directory after you install vztmpl-centos-5-2.0-2.i386.rpm. vzdev-3.3.13-1.3.swsoft in particular as it actually contains the /dev/pty's that appear in each VPS. Therefore, I don't think Internet connectivity would matter (it obviously would for the remaining packages, but I don't think those are at issue). Just out of curiosity what is the full command line when you run vzpkgcache? Also, if you are able to actually get into one of your created VPS's on the bad system, does the vzdev rpm package exist on the VPS? If you can't get into the VPS, can you see ptys in the /vz/private/{VPSid}/dev/ directory from the host node?
dowdle wrote on Wed, 15 August 2007 08:21 Steve, No, I tried it on a RHEL5 and a CentOS5 based machine and no matter what I did, I still got those error messages... when trying to vzpkgcache using your vztmpl-centos-5 metadata package... which is really weird... because it seems to be trying to compare the package set to that of the hardware node, yes? I don't think it compares any packages to the host node. As I see yum operates within the self-contained environment of /vz/templates/centos/5/i386. The vzpkgcache program does reference the host node (/usr/share/vzpkg/functions), but, I believe for other things (still warrants investigation though). Quote: Yes, I'm familiar with the default.list file. In the Introduction to OpenVZ Screencast that I did, I mention that file and edit it before building a CentOS 4 cache. Since I have LAN based copies of all of the repos I use, I also alter the yum.conf file and have it point to my repos rather than the stock ones... and it makes it a lot faster. Great idea on the local repos. I should do that too. Quote: I have also run into the issue when I create VPSes from the pre-created centos-5 os template... where when I tried to vzctl enter it, it says that pty is missing and fails. I tried the fix that was mentioned in this thread (edit the start_udev line in the /etc/rc.sysinit) but that works for me sometimes and other times it doesn't. Basically trying to get a centos 5 VPS is problematic but I'm sticking with it. I'm guessing it is something with the dummy-udev package but I have no idea what. When you say dummy-udev package are you referring to the vzdev package with all of the ptys? If you take the image you generate with vzpkgcache and run tar tzf centos-5-i386-minimal.tar.gz on it do you see the /dev/ptys inside? One other thing, the package in the contributed section was built by tweaking the FC5 package and not from a metadata package ( http://forum.openvz.org/index.php?t=msg&th=2486&star t=0&) so I'm not sure how well this would work with my template. They even make reference to an "ugly" udev solution. That's what got me started on this in the first place.
I'm running that version because that's what yum installed following the OpenVZ Wiki docs: # rpm -qa | grep vzrpm vzrpm44-python-4.4.1-22.5 vzrpm43-python-4.3.3-7_nonptl.6 vzrpm44-4.4.1-22.5
Steve, > I don't think it compares any packages to the host node. > As I see yum operates within the self-contained environment > of /vz/templates/centos/5/i386. The vzpkgcache program does > reference the host node (/usr/share/vzpkg/functions), but, > I believe for other things (still warrants investigation > though). Look again at the error message: - - - - Transaction Check Error: file /sbin/insmod conflicts between attempted installs of dummy-centos-5-1.0-4.swsoft and module-init-tools-3.3-0.pre3.1.16.0.1.el5 - - - - The module-init-tools-3.3-0.pre3.1.16.0.1.el5 is NOT a CentOS package. My hn is running RHEL5 and that package IS installed on the hardware node. I searched the entire vz template cache and could not find the module-init-tools package anywhere... so it looks like it is indeed conflicting with a package on the hardware node. I know that it shouldn't even be comparing to a package on the hardware node, right?... so I'm not sure why this is happening but that is the error message I get when I try to run vzpkgcache. > When you say dummy-udev package are you referring to the > vzdev package with all of the ptys? If you take the image > you generate with vzpkgcache and run tar tzf > centos-5-i386-minimal.tar.gz on it do you see the >/dev/ptys inside? I don't know because I can't generate a template. It figures out all of the deps, downloads all of the packages but when it tries to install them to a temp dir... that is when I get the package conflict error... so the packages are not installed... and a .tar.gz file is never created... so I can't check if the ptys are there. Yes, I was referring to the vzdev package. It'll be nice if we get a working vztmpl-centos-5 packages someday. At least someone uploaded new pre-created OS templates for CentOS 5 yesterday... and the new one seems to be working for me with the single VPS I've created with it. I don't know if I create more VPSes with it if I'll run into the ptys problem or not. It seemed to me that the previous pre-created OS template would hit or miss for me. Sometimes the VPS would work just fine and other times I'd get the pty error.
So I too am seeing the PTY issue (using this thread's centos5 rpm template modified to support yum in both the minimal and default cache files. Interestingly enough, it seems the /dev/pty* files *are* present. The cache creation went fine though the only warnings I saw were: -- Complete! chmod: cannot access `/etc/cron.daily/slocate.cron': No such file or directory chmod: cannot access `/etc/cron.daily/makewhatis.cron': No such file or directory Packing cache file centos-5-i386-minimal.tar.gz ... Cache file centos-5-i386-minimal.tar.gz [46M] created. -- Here is the entire breakdown of creating the VE and trying to get into it: dolly-compiler:~# /usr/sbin/vzctl create 100 --ostemplate centos-5-i386 Creating VE private area (centos-5-i386-default) Performing postcreate actions VE private area was created dolly-compiler:~# /usr/sbin/vzctl set 100 --ipadd 10.150.52.8 --save Saved parameters for VE 100 dolly-compiler:~# /usr/sbin/vzctl set 100 --nameserver 172.18.28.100 --save Saved parameters for VE 100 dolly-compiler:~# /usr/sbin/vzctl start 100 Starting VE ... VE is mounted Adding IP address(es): 10.150.52.8 Aug 16 09:21:02 dolly-compiler kernel: VE: 100: started Setting CPU units: 1000 Configure meminfo: 49152 File resolv.conf was modified VE start in progress... dolly-compiler:~# /usr/sbin/vzctl exec 100 ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.3 2028 664 ? Ss 09:21 0:00 init [3] root 32119 0.0 0.2 2120 424 ? S<s 09:21 0:00 /sbin/udevd -d root 32179 0.1 0.6 2404 1220 ? Ss 09:21 0:00 /bin/bash /etc/rc.d/rc 3 root 32378 0.0 0.2 1692 572 ? Ss 09:21 0:00 syslogd -m 0 root 32410 0.0 0.4 2668 860 ? Ss 09:21 0:00 xinetd -stayalive -pidfile /var/run/xinetd.pid root 32413 0.0 0.6 2408 1216 ? S 09:21 0:00 /bin/bash /etc/rc3.d/S80sendmail start root 32420 0.0 0.9 7316 1956 ? S 09:21 0:00 /usr/bin/newaliases root 32425 0.0 0.4 2140 828 ? Rs 09:21 0:00 ps aux dolly-compiler:~# /usr/sbin/vzctl enter 100 enter into VE 100 failed Unable to open pty: No such file or directory dolly-compiler:/vz/private/100/dev# ls pty* ptya0 ptyb8 ptyd0 ptye8 ptyq0 ptyr8 ptyt0 ptyu8 ptyw0 ptyx8 ptyz0 ptya1 ptyb9 ptyd1 ptye9 ptyq1 ptyr9 ptyt1 ptyu9 ptyw1 ptyx9 ptyz1 ptya2 ptyba ptyd2 ptyea ptyq2 ptyra ptyt2 ptyua ptyw2 ptyxa ptyz2
Should vzdev be installed? Though my cache does have the ptys in /vz/private/100/dev, I don't have this "vzdev" RPM installed: # rpm -qa | grep vz vzctl-3.0.18-1 vzrpm44-python-4.4.1-22.5 ovzkernel-2.6.18-8.1.8.el5.028stab039.1 vzctl-lib-3.0.18-1 vzyum-2.4.0-11 vzpkg-2.7.0-18 vzrpm43-python-4.3.3-7_nonptl.6 vzquota-3.0.11-1 vzrpm44-4.4.1-22.5 vztmpl-centos-5-2.0-2
Here's another problem I've encountered with VPSes created from the previous and recent pre-created centos-5 OS template caches... I see the following error spit out whenever certain commands are run (like yum update for example): Failed to set locale, defaulting to C ...but the error doesn't seem to harm anything... so far. Any ideas on that?
dranch wrote on Thu, 16 August 2007 09:29 I'm running that version because that's what yum installed following the OpenVZ Wiki docs: # rpm -qa | grep vzrpm vzrpm44-python-4.4.1-22.5 vzrpm43-python-4.3.3-7_nonptl.6 vzrpm44-4.4.1-22.5 I would just install both vzrpm43 and vzrpm44. I'm not really sure why. Every time I've tried using only one set, I always get some type of error. I'm not sure why.
dranch wrote on Thu, 16 August 2007 09:42 Should vzdev be installed? Though my cache does have the ptys in /vz/private/100/dev, I don't have this "vzdev" RPM installed: # rpm -qa | grep vz vzctl-3.0.18-1 vzrpm44-python-4.4.1-22.5 ovzkernel-2.6.18-8.1.8.el5.028stab039.1 vzctl-lib-3.0.18-1 vzyum-2.4.0-11 vzpkg-2.7.0-18 vzrpm43-python-4.3.3-7_nonptl.6 vzquota-3.0.11-1 vzrpm44-4.4.1-22.5 vztmpl-centos-5-2.0-2 Yes, it should be installed--it's on all my VPSs. As far as I understand, the vzdev rpm contains the ptys (along with other devices) that would normally be created by udev. I am under the impression that udev will not work properly in a VPS and thus the vzdev package compensates for it by adding the devices manually, the way they used to be done. (Do a rpm -qf /dev/ptya1 on your host node and it should say file is not owned by any package, while if you do the same command in a VPS is should say vzdev-3.3.13-1.3.swsoft) This is a wild guess, but I'm thinking that udev *is* trying to create those devices in your VPS with varying degrees of luck (works/doesn't work).
steve wrote on Thu, 16 August 2007 08:40 tpso wrote on Wed, 15 August 2007 11:26 Hi I was the one that have described the pty problem earlier on this thread. I have later found out that it is caused by some kind of error that occurs when running vzpkgcache. I have not been able find out what is wrong. /Tpso tpso- I really don't get this. The only packages that I think would affect the /dev/pty files in the image are in the /vz/templates/centos/5/i386/vz-addons directory after you install vztmpl-centos-5-2.0-2.i386.rpm. vzdev-3.3.13-1.3.swsoft in particular as it actually contains the /dev/pty's that appear in each VPS. Therefore, I don't think Internet connectivity would matter (it obviously would for the remaining packages, but I don't think those are at issue). Just out of curiosity what is the full command line when you run vzpkgcache? Also, if you are able to actually get into one of your created VPS's on the bad system, does the vzdev rpm package exist on the VPS? If you can't get into the VPS, can you see ptys in the /vz/private/{VPSid}/dev/ directory from the host node? Hi again Steve the vzpkgcache command line was very simple: vzpkgcache centos-5-i386-minimal I cant enter the bad system, but I can "vzctl exec " and run commands. if I run : vzctl exec 207 rpm -qa I can see I have vzdev-3.3.13-1.3.swsoft installed, and yes I have plenty of pty special-files in /vz/private/207/dev Regards tpso alias Thomas
i'm in the same boat as Tpso. vzdev installed. can vzctl exec but not enter. all my pty devices are in check. did anyone ever figure this out?
Additionally, here's whats in /var/log/messages on the VE: Aug 17 16:33:59 testdog syslogd 1.4.1: restart. Aug 17 16:33:59 testdog xinetd[14040]: xinetd Version 2.3.14 started with libwrap loadavg labeled-networking options compiled in. Aug 17 16:33:59 testdog xinetd[14040]: Started working: 0 available services Aug 17 16:34:00 testdog init: no more processes left in this runlevel
On a lark, I tried the method mentioned here: http://forum.openvz.org/index.php?t=msg&goto=10801&& amp;srch=Unable+to+open+pty#msg_10801 but to no avail.
I don't have vzdev installed in VE#0 though it is installed in say VE#100. Even then, I had this famous PTY problem. Early on in this thread someone recommended doing the following to each VE: /etc/rc.d/rc.sysinit from /sbin/start_udev to [ -f /sys/class/tty/console/uevent ] && /sbin/start_udev This works for me 100% of the time but I don't understand why udev doesn't fully run in the VEs without this hack. --David
O.k., so i finally got in, but it took a bit of hackery. Here's what i had to do: strace -f vzctl enter <VEID> Then look for something like the following near the end: [pid 19407] open("/dev/ptmx", O_RDWR) = -1 ENOENT (No such file or directory) [pid 19407] open("/dev/ptyp0", O_RDWR) = -1 ENOENT (No such file or directory) Identify the ptyp device then run the following: vzctl exec <VEID> MAKEDEV ptyp0 (replacing this with your device). Now, possibly, you will need to run this again. I had to do this twice and afterwards was able to get into the VE properly.
Hi, This thread describe a number of ways to avoid the pty problem, but the pty problem is a symptom of something going wrong. That was why I stopped just hacking the rc.sysinit, in newly created VPS's. As mentioned earlier I have managed to create a template-cache, that when I moves it to systems, showing pty-problems, can create VPS that work perfect in any way with no hacking at all. If you : David and/or alticon-brian could try to se if the templatecache I have put on my server works for you, It maybe possible to find out where template-creation fails. As mentioned earlier in the thread it can be found on http://www.sonnet.dk/centos-5-i386-minimal.tar.gz It still requires Steve's template to be installed, since it is only a cache-file. Regards Tpso alias Thomas
If you post the "standard" one, I can try it out and see what happens. --David
Hi David I have put the default version on my server: http://www.sonnet.dk/centos-5-i386-default.tar.gz approx. 125Mb /tpso
I also encountered this problem using the meta data rpm of the openvz site. I noticed that unlike the centos 4 meta data package, the centos 5 one was installing the udev package, and that simply disabling udev from running fixed the pty issue. However I wanted udev not to be installed in the first place, so I added the following line to the bottom of "install-post" in the meta data directory: $RPM --root $VE_ROOT -e udev --nodeps
tomp wrote on Sat, 25 August 2007 10:15 I also encountered this problem using the meta data rpm of the openvz site. I noticed that unlike the centos 4 meta data package, the centos 5 one was installing the udev package, and that simply disabling udev from running fixed the pty issue. However I wanted udev not to be installed in the first place, so I added the following line to the bottom of "install-post" in the meta data directory: $RPM --root $VE_ROOT -e udev --nodeps When creating the CentOS 5 meta data package, I did not specifically add the udev package to the template. It must have been picked up by yum because of a dependency. I'm wondering why it's causing problems for some though. Looking at /sbin/start_udev in a minimal VPS, I'm not sure it should really even do anything considering that /sys in my VPS is empty. As I understand it, udev only mounts devices that are listed in /sys, no? Perhaps /sys is not always empty?
Steve, Perhaps you already know this, but if udev gets installed after the fact... every case I've seen (and not just with CentOS 5)... the VPS will continue to run until you attempt a restart... and it is dead after that. Having udev installed is not good. Perhaps your metadata package ends up with both vzdev and udev installed in the OS Template it creates?!? On systems where I've accidentally nuked a VPS because udev got installed to satisfy a dependency, I think it always removed vzdev as part of the process. I'm not helping, but as long as I'm not hurting...
Steve, Ok, your vztmpl-centos-5 package is working for me now. I believe that the vast amount of replies to this topic has really muddled things here so I'll try to backup and start over. Issues I was having: 1) Originally I was having a problem with it... running into a package conflict problem that made it fail before even attempting to create the OS Template. I don't know what resolved that issue for me, but I don't think it was the fault of your package anyway. That must have been an issue with my RHEL5 based host... so we won't worry about that. 2) As it is, your package (probably because of dependencies) creates an OS Template with both udev and vzdev installed. So, I did exactly what was recently recommended... I added the following line to very end of /vz/template/centos/5/i386/config/install-post $RPM --root $VE_ROOT -e udev --nodeps So, the OS Template is still broken, but any VPSes created from it can be fixed by adding that udev removal step to the VPS creation process. To clarify... on working VPSes (mostly CentOS 4 or Fedora based ones I've used), I've noticed that if I install something that drags udev along with it... and if I allow it to install udev into the VPS, the VPS is basically toast after that. I don't recall exactly how they misbehave... but I've gone so far as do the following inside of a VPS to keep udev from ever really being installed: rpm -ivh --justdb {urls for udev package and its [if any] dependencies} And then it is good idea to add udev as an exclude in the yum.conf of the VPS (I always install yum inside my VPSes) so if an updated package for udev comes along, that won't try to upgrade. Your comment about /sys not being in the VPS... perhaps that was what was causing udev to misbehave if installed. Who knows?!? It would be nice if we could fix it by having udev not get installed into the OS Template to begin with... but I don't know of a way to make that happen... so the install-post hack is good enough for now. I appreciate your work.
On second thought... Is the install-post used by vzpkgcache or vzctl create?
Greetings! I'm trying to work my way getting CentOS 5-based VPS work. Problem is: I'm on x64. Is there a timeframe for a metadata pkg? sspt already build templates, but vzyum is useless with these as dowdle already stated. How about sources for the rpm? I'm not to deep into metadata creation, but I would like to have a try.
Scott- I just can't seem to figure out why udev is causing all of these problems for you and others. Suffice it to say though that it really makes me uncomfortable. I have udev and vzdev both installed on all my CentOS 5-based VPSs and not a hint of a problem yet. Now I don't have anything as advanced as a GNOME GUI image created from the repository yet, however, I can restart them, stop them, and run them without any problems whatsoever. At this point I'm trying to determine what is different on my systems vs yours. If you leave in udev after creating a VPS: 1. Are there any files in /sys inside the VPS? 2. What is the contents of /proc/mounts inside the VPS? I've done some reading about udev and my understanding is that in it's configuration within the VPS's it basically does nothing (or should do nothing). My supposition is that in your case (and everyone else's that doesn't work) it is trying to create devices and getting stuck after a conflict with the manually created vzdev devices. If we can find out why this is happening, perhaps we can stop this bad behavior of udev, and, thus, solve your problem.
Steve, I've had a problem with udev breaking systems (if it gets installed to satisfy a dependency) for a long time now. It I recall correctly, I broke a FC5 VPS over a year ago... which I was able to salvage by removing udev. In any event, I think you are asking the wrong question. To the best of my knowledge, none of the OS Templates have udev installed and vzdev was created for a reason, right? Regarding your question about /sys, I just checked a CentOS 4 based VPS (on a CentOS 4 based HN) and indeed /sys is empty. Regarding /proc/mount, the same system has: [root@vps1 ~]# cat /proc/mounts simfs / simfs rw 0 0 proc /proc proc rw,nodiratime 0 0 devpts /dev/pts devpts rw 0 0 [root@vps1 ~]# Now I'll check a CentOS 5 based VPS on a CentOS 5 based HN: [root@img ~]# ls -lR /sys /sys: total 0 drwxr-xr-x 4 root root 0 Aug 22 14:35 class /sys/class: total 0 drwxr-xr-x 4 root root 0 Aug 22 14:35 net drwxr-xr-x 3 root root 0 Aug 22 14:35 tty /sys/class/net: total 0 drwxr-xr-x 2 root root 0 Aug 22 14:35 lo drwxr-xr-x 3 root root 0 Aug 22 14:35 venet0 /sys/class/net/lo: total 0 lrwxrwxrwx 1 root root 0 Sep 10 08:09 subsystem -> ../../../class/net --w------- 1 root root 4096 Sep 10 08:09 uevent /sys/class/net/venet0: total 0 drwxr-xr-x 2 root root 0 Aug 22 14:35 statistics lrwxrwxrwx 1 root root 0 Sep 10 08:09 subsystem -> ../../../class/net --w------- 1 root root 4096 Sep 10 08:09 uevent /sys/class/net/venet0/statistics: total 0 -r--r--r-- 1 root root 4096 Sep 10 08:09 collisions -r--r--r-- 1 root root 4096 Sep 10 08:09 multicast -r--r--r-- 1 root root 4096 Sep 10 08:09 rx_bytes -r--r--r-- 1 root root 4096 Sep 10 08:09 rx_compressed -r--r--r-- 1 root root 4096 Sep 10 08:09 rx_crc_errors -r--r--r-- 1 root root 4096 Sep 10 08:09 rx_dropped -r--r--r-- 1 root root 4096 Sep 10 08:09 rx_errors -r--r--r-- 1 root root 4096 Sep 10 08:09 rx_fifo_errors -r--r--r-- 1 root root 4096 Sep 10 08:09 rx_frame_errors -r--r--r-- 1 root root 4096 Sep 10 08:09 rx_length_errors -r--r--r-- 1 root root 4096 Sep 10 08:09 rx_missed_errors -r--r--r-- 1 root root 4096 Sep 10 08:09 rx_over_errors -r--r--r-- 1 root root 4096 Sep 10 08:09 rx_packets -r--r--r-- 1 root root 4096 Sep 10 08:09 tx_aborted_errors -r--r--r-- 1 root root 4096 Sep 10 08:09 tx_bytes -r--r--r-- 1 root root 4096 Sep 10 08:09 tx_carrier_errors -r--r--r-- 1 root root 4096 Sep 10 08:09 tx_compressed -r--r--r-- 1 root root 4096 Sep 10 08:09 tx_dropped -r--r--r-- 1 root root 4096 Sep 10 08:09 tx_errors -r--r--r-- 1 root root 4096 Sep 10 08:09 tx_fifo_errors -r--r--r-- 1 root root 4096 Sep 10 08:09 tx_heartbeat_errors -r--r--r-- 1 root root 4096 Sep 10 08:09 tx_packets -r--r--r-- 1 root root 4096 Sep 10 08:09 tx_window_errors /sys/class/tty: total 0 drwxr-xr-x 2 root root 0 Aug 22 14:35 ptmx /sys/class/tty/ptmx: total 0 -r--r--r-- 1 root root 4096 Sep 10 08:09 dev lrwxrwxrwx 1 root root 0 Sep 10 08:09 subsystem -> ../../../class/tty --w------- 1 root root 4096 Sep 10 08:09 uevent [root@img ~]# Now for /proc/mounts: [root@img ~]# cat /proc/mounts simfs / simfs rw 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 devpts /dev/pts devpts rw 0 0 iso9660 /var/www/html/linux/centos/4.5/i386/base iso9660 ro 0 0 iso9660 /var/www/html/linux/centos/5.0/i386/base iso9660 ro 0 0 iso9660 /var/www/html/linux/centos/5.0/x86_64/base iso9660 ro 0 0 [root@img ~]# It's an image server so I have some isos mounted too.
[quote title=dowdle wrote on Mon, 10 September 2007 05:12]Steve, I've had a problem with udev breaking systems (if it gets installed to satisfy a dependency) for a long time now. It I recall correctly, I broke a FC5 VPS over a year ago... which I was able to salvage by removing udev. In any event, I think you are asking the wrong question. To the best of my knowledge, none of the OS Templates have udev installed and vzdev was created for a reason, right? Regarding your question about /sys, I just checked a CentOS 4 based VPS (on a CentOS 4 based HN) and indeed /sys is empty. [quote] Scott- For some reason since I've been running on a RHEL 4 system, my /sys is always empty when VPS's are created--so, even if udev *is* installed it does nothing. However, I have a CentOS 5 system and see that there is indeed a populated /sys directory for each VPS created (minimal, but there nonetheless). This, of course, puts udev into action if it is installed, which, of course, causes problems. Thus, I have tried to extricate udev from any VPS created from the template. As I've mentioned before, I'm far from an expert on RPM creation, however, I've created another template metadata rpm that attempts to accomplish this goal. It informs the system that vzdev will suffice for udev and also includes a yum configuration entry to prevent udev from being installed. I have attached it to this post. Can you please give it a try and let me know if it works. I have incremented the release number so it should be a simple rpm upgrade.
Steve, Seems to be a winner dude!!! Here's what I did to test it out to the max: 1) Edited the /vz/template/centos/5/i386/config/default.list and added mc, nano and yum. 2) Built a template with vzpkgcache -f centos-5. That went perfectly. 3) Created a CentOS 5 a VPS with a 10GB diskspace and lots of resources. 4) Entered the VPS and configured yum to use my LAN based repos. 5) Used yum groupinstall to install almost all package groups that were available: yum groupinstall "Office/Productivity" "Engineering and Scientific" "MySQL Database" "Development Libraries" "Editors" "GNOME Software Development" "X Software Development" "GNOME Desktop Environment" "Authoring and Publishing" "Games and Entertainment" "Legacy Software Development" "Emacs" "Legacy Software Support" "X Window System" "Graphics" "Ruby" "Printing Support" "KDE Software Development" "Sound and Video" "Administration Tools" "Development Tools" "Graphical Internet" "KDE (K Desktop Environment)" That was about 1GB worth of packages but over the LAN it was very fast. Oddly enough that installed a kernel package... so I immediately did: rpm -e kernel systemtap-runtime systemtap gnome-volume-manager gnome-session I had to add the additional packages to the removal list to keep rpm from griping about requirements. I wonder what would have happened if I left the kernel installed? Probably nothing bad, eh? 6) Created a regular user, logged in as that user, created a .vnc/xstartup that starts KDE and started vncserver with: vncserver -geometry 1024x768 -depth 16 7) Ran vncviewer on my desktop and connected... installed a ton more applications including Sun's JDK 6u2 with Netbeans 5.5.1, Eclipse, flash-plugin, Acrobat Reader 8.1.1 (released last week). I did all of this stuff to configure the machine just like one of my CS lab machines. Everything worked great. I shut the VPS down. Started it again, and repeated the VNC test and everything worked great. I can't seem to break it. I copied all of the commands I did into a text file while I was doing all of the testing. I destroyed the VPS and then repeated everything again, and it worked fine. Anything else you can think of that you'd like me to test??? Good job!
dowdle wrote on Thu, 20 September 2007 13:26 Steve, Seems to be a winner dude!!! Here's what I did to test it out to the max: 1) Edited the /vz/template/centos/5/i386/config/default.list and added mc, nano and yum. 2) Built a template with vzpkgcache -f centos-5. That went perfectly. 3) Created a CentOS 5 a VPS with a 10GB diskspace and lots of resources. 4) Entered the VPS and configured yum to use my LAN based repos. 5) Used yum groupinstall to install almost all package groups that were available: yum groupinstall "Office/Productivity" "Engineering and Scientific" "MySQL Database" "Development Libraries" "Editors" "GNOME Software Development" "X Software Development" "GNOME Desktop Environment" "Authoring and Publishing" "Games and Entertainment" "Legacy Software Development" "Emacs" "Legacy Software Support" "X Window System" "Graphics" "Ruby" "Printing Support" "KDE Software Development" "Sound and Video" "Administration Tools" "Development Tools" "Graphical Internet" "KDE (K Desktop Environment)" That was about 1GB worth of packages but over the LAN it was very fast. I'd say that's a pretty good test. Quote: Oddly enough that installed a kernel package... so I immediately did: rpm -e kernel systemtap-runtime systemtap gnome-volume-manager gnome-session I came so close to excluding the kernel from yum updates as well, but I didn't think it would ever get pulled in. I'll add it the next time I roll the package. Quote: I had to add the additional packages to the removal list to keep rpm from griping about requirements. I wonder what would have happened if I left the kernel installed? Probably nothing bad, eh? 6) Created a regular user, logged in as that user, created a .vnc/xstartup that starts KDE and started vncserver with: vncserver -geometry 1024x768 -depth 16 7) Ran vncviewer on my desktop and connected... installed a ton more applications including Sun's JDK 6u2 with Netbeans 5.5.1, Eclipse, flash-plugin, Acrobat Reader 8.1.1 (released last week). I did all of this stuff to configure the machine just like one of my CS lab machines. Everything worked great. I shut the VPS down. Started it again, and repeated the VNC test and everything worked great. I can't seem to break it. I copied all of the commands I did into a text file while I was doing all of the testing. I destroyed the VPS and then repeated everything again, and it worked fine. Anything else you can think of that you'd like me to test??? Good job! Just keep me updated if anything breaks. I'm determined to keep this working as I'm using it in production now and I really don't want any surprises. Wow, you've peaked my interest. I've just got to do the graphical thing now....
I am very interested in this working X-package that you have created, would you be willing to share the template cache? Matt
Can you create your own using the somewhat vague recipe I gave? If not, I can give you a URL for the finished OS Template. I don't recall how big it is but I'd probably want to install it, change the yum.repos.d stuff back to the regular repos, and change the user from my last name to something more generic... and then tar.gz that up into a more generic OS Template. Just email me: dowdle@montanalinux.org