Hi all, I have a configuration problem and could use some help. I read every single posting in the xen-devel archives and can''t figure this out. Xen boots xenolinux fine. Full RH9. uname shows the xeno-2.4.22 kernel. xenctl domain list shows domain0. This all looks ok to me. I''m using a drive with 4 partitions and 2 redhats: 1: hdb5 swap hdb6 redhat9 with xen and xenolinux 2: hdb7 swap hdb8 redhat9 with xenolinux hdb6 and hdb8 can be booted natively. hdb6 cleanly loads xen and boots xenolinux. The mount points in /etc/fstab are correct for each. On hdb8 /etc/initab initial runlevel is set to 4. Here''s how I invoke the guest. $xen_nat_enable $xen_read_console | tee /var/log/xen & $xenctl script -f/etc/xen-mydom xen-mynewdom contains: physical grant -phdb7 #swap physical grant -phdb8 #root domain start domain new xenctl.xml contains: <?xml version="1.0"?> <domctl_defaults> <domain_name>XenoLinux</domain_name> <domain_size_kb>98304</domain_size_kb> <domain_image>/boot/xenolinux.gz</domain_image> <domain_vifs>1</domain_vifs> <root_device>/dev/hdb8</root_device> <root_args>ro</root_args> <args>DOMID=1</args> <nw_ip>10.0.0.31</nw_ip> <nw_gw>10.0.0.252</nw_gw> <nw_mask>255.255.255.0</nw_mask> <nw_nfs_server>169.254.1.0</nw_nfs_server> <max_domain_number>10</max_domain_number> <xi_tools_dir>/usr/local/bin/</xi_tools_dir> </domctl_defaults> Here is the part of the boot sequence around where the errors occur: ... [1] Kernel command line: ip=10.0.0.31:169.254.1.0:10.0.0.252:255.255.255.0::eth0:off DOMID=1 root=/dev/hdb8 ro ... [1] XenoLinux Virtual Network Driver installed as eth0 [1] IP-Config: Complete: [1] device=eth0, addr=10.0.0.31, mask=255.255.255.0, gw=10.0.0.252, [1] host=10.0.0.31, domain=, nis-domain=(none), [1] bootserver=169.254.1.0, rootserver=169.254.1.0, rootpath[1] ip_conntrack version 2.1 (768 buckets, 6144 max) - 292 bytes per conntrack [1] ip_tables: (C) 2000-2002 Netfilter core team [1] NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. [1] root_device_name = hdb8 [1] Can''t write to read-only device 03:48 [1] kjournald starting. Commit interval 5 seconds [1] Can''t write to read-only device 03:48 [1] EXT3-fs: mounted filesystem with ordered data mode. [1] VFS: Mounted root (ext3 filesystem) readonly. [1] Freeing unused kernel memory: 60k freed [1] ^MINIT: version 2.84 booting^M^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty1: No such device^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty2: No such device^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty3: No such device^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty4: No such device^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty5: No such device^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty6: No such device^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] /etc/rc.d/rc.sysinit: line 43: /dev/tty7: No such device^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] /etc/rc.d/rc.sysinit: line 44: /dev/tty8: No such device^M [1] Welcome to Red Hat Linux^M [1] Press ''I'' to enter interactive startup.^M [1] Mounting proc filesystem: [ OK ]^M^M [1] Configuring kernel parameters: [ OK ]^M^M [1] modprobe: modprobe: Can''t locate module char-major-10-135^M^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] hwclock is unabl At this point it looks dead but I can ping it. The only public service on it is sshd but that gives connection refused. Its log files are empty. Its iptables is off so it''s not blocking traffic. I hacked /etc/rc.d/rc.sysinit to make the modprobe errors go away but things became very erratic and would appear to halt randomly during the boot. When put back it errs like int the log above every time. Any ideas or pointers on what to try next? All help appreciated, Mike Wright ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> xen-mynewdom contains: > physical grant -phdb7 #swap > physical grant -phdb8 #root > domain start > domain newI''m afraid I haven''t read your failure report in detail, but please can you try: domain new physical grant -phdb7 -w #swap physical grant -phdb8 -w #root domain start ''new'' must come first, and you presumably want read-write access to root and swap. All of this is rather clearer with the new tools in the unstable tree. Expect a 1.2 release fairly soon... Ian ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
xen@theorb.net
2003-Dec-02 18:38 UTC
Re: [Xen-devel] virtual domain partial boot then crash
Ian Pratt wrote:> > I''m afraid I haven''t read your failure report in detail, but > please can you try: > > domain new > physical grant -phdb7 -w #swap > physical grant -phdb8 -w #root > domain startDoh! Thanks, Ian. I knew about the -w. Must''ve been a long day. That allowed it to move into the "Init" stage of the boot process.> All of this is rather clearer with the new tools in the unstable > tree. Expect a 1.2 release fairly soon... >I''m not that uncomfortable with the command line tools, but, aaargh, I don''t know python yet. :( OK, here''s the new status. The guest no longer dies a mysterious death but does crash about the time it tries to set the hardware clock. Following is a partial output from the guest. ... [1] Kernel command line: ip=10.0.0.31:169.254.1.0:10.0.0.252:255.255.255.0::eth0:off DOMID=1 root=/dev/hdb8 ro ...[1] XenoLinux Virtual Network Driver installed as eth0 [1] IP-Config: Complete: [1] device=eth0, addr=10.0.0.31, mask=255.255.255.0, gw=10.0.0.252, [1] host=10.0.0.31, domain=, nis-domain=(none), [1] bootserver=169.254.1.0, rootserver=169.254.1.0, rootpath[1] ip_conntrack version 2.1 (768 buckets, 6144 max) - 292 bytes per conntrack [1] ip_tables: (C) 2000-2002 Netfilter core team [1] NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. [1] root_device_name = hdb8 [1] kjournald starting. Commit interval 5 seconds [1] EXT3-fs: mounted filesystem with ordered data mode. [1] VFS: Mounted root (ext3 filesystem) readonly. [1] Freeing unused kernel memory: 60k freed [1] ^MINIT: version 2.84 booting^M^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty1: No such device^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty2: No such device^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty3: No such device^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty4: No such device^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty5: No such device^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty6: No such device^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] /etc/rc.d/rc.sysinit: line 43: /dev/tty7: No such device^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] /etc/rc.d/rc.sysinit: line 44: /dev/tty8: No such device^M [1] Welcome to Red Hat Linux^M [1] Press ''I'' to enter interactive startup.^M [1] Mounting proc filesystem: [ OK ]^M^M [1] Configuring kernel parameters: [ OK ]^M^M [1] modprobe: modprobe: Can''t locate module char-major-10-135^M^M [1] modprobe: modprobe: Can''t locate module char-major-4^M^M [1] hwclock is unable to get I/O port access: the iopl(3) call failed.^M [1] Setting clock (localtime): And that''s where it goes quiet. Since there won''t be any consoles on a guest I''m guessing that the rc.sysinit complaints don''t matter although I don''t know how to shut them up. So it looks like setting the clock is the problem. Any pointers or ideas, anyone? Thanks, Mike Wright ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> Doh! Thanks, Ian. I knew about the -w. Must''ve been a long day. That allowed it to move into the "Init" stage of the boot process.Excellent.> > All of this is rather clearer with the new tools in the unstable > > tree. Expect a 1.2 release fairly soon... > > > I''m not that uncomfortable with the command line tools, but, aaargh, I don''t know python yet. :(Our view was that the current "xenctl" was unsalvageable -- it was pretty dumb and didn''t really have persistent state or sanity checks, but was complicated enough to obfuscate what was actually going on and hence confuse its users. We''ve replaced the xi_* tools with a C library and created a python wrapper for it. It''s now possible to write relatively simple scripts that set up and control domains (e.g. enabling reboots etc.) They''re rather longer than the old xenctl xml and scripts, but at least its possible to see what''s going on. There''s currently no new high-level tool, but when we get around to doing that we''ll do it properly and use a database back end. I''m afraid that the Virtual Disk management tool that was part of the old xenctl is currently missing and hasn''t been replaced (it requires persistent state). Not many people use this, so its probably not a disaster. It would be nice if someone volunteered to write a replacement...> OK, here''s the new status. The guest no longer dies a mysterious death but does crash about the time it tries to set the hardware clock. Following is a partial output from the guest.My suspicion is that failing to set the hw clock isn''t the real problem. Does the domain still show up in ''domain list''? Is it still pingable? BTW: what distribution is this? Can you see what comes after setting the hwclock in /etc/rc.sysinit ? (you can # out the /sbin/clock line to verify my prior hypothesis) Can you add some debug output e.g. with "logger". Cheers, Ian ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Gregory Newby
2003-Dec-02 19:17 UTC
Re: [Xen-devel] virtual domain partial boot then crash
Hi, Mike. Quick solution, which is suggested in the docs somewhere: Remove the hardware-requiring items from the /etc/rc.d/rc?.d directory. One way to do this is edit /etc/inittab for the virtual domain, changing the default run level from 3 to 4. Then, copy over all the symlinks from /etc/rc.d/rc3.d to /etc/rc.d/rc4.d but *delete* those that involve hardware. This includes hwclock and gpm. Also, for sshd (which is one of the next things to start): I found that sshd was unhappy starting, due to some incompatibility in the libraries available. You might just try adding " -x" to the first line of /etc/rc.d/init.d/sshd (that is, #!/bin/bash -x ) so you can see sshd in action. It will be obvious what is failing, if anything, from the console log. In your current log, though, it looks like you''re never getting beyond the hwclock, so while the system is "up" (that is, lots of services, including network services, are running), sshd never gets started. I hope this helps! -- Greg On Tue, Dec 02, 2003 at 10:38:51AM -0800, xen@theorb.net wrote:> Ian Pratt wrote: > > > >I''m afraid I haven''t read your failure report in detail, but > >please can you try: > > > > domain new > > physical grant -phdb7 -w #swap > > physical grant -phdb8 -w #root > > domain start > > Doh! Thanks, Ian. I knew about the -w. Must''ve been a long day. That > allowed it to move into the "Init" stage of the boot process. > > >All of this is rather clearer with the new tools in the unstable > >tree. Expect a 1.2 release fairly soon... > > > I''m not that uncomfortable with the command line tools, but, aaargh, I > don''t know python yet. :( > > OK, here''s the new status. The guest no longer dies a mysterious death but > does crash about the time it tries to set the hardware clock. Following is > a partial output from the guest. > ... > [1] Kernel command line: > ip=10.0.0.31:169.254.1.0:10.0.0.252:255.255.255.0::eth0:off DOMID=1 > root=/dev/hdb8 ro > ...[1] XenoLinux Virtual Network Driver installed as eth0 > [1] IP-Config: Complete: > [1] device=eth0, addr=10.0.0.31, mask=255.255.255.0, gw=10.0.0.252, > [1] host=10.0.0.31, domain=, nis-domain=(none), > [1] bootserver=169.254.1.0, rootserver=169.254.1.0, rootpath> [1] ip_conntrack version 2.1 (768 buckets, 6144 max) - 292 bytes per > conntrack > [1] ip_tables: (C) 2000-2002 Netfilter core team > [1] NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > [1] root_device_name = hdb8 > [1] kjournald starting. Commit interval 5 seconds > [1] EXT3-fs: mounted filesystem with ordered data mode. > [1] VFS: Mounted root (ext3 filesystem) readonly. > [1] Freeing unused kernel memory: 60k freed > [1] ^MINIT: version 2.84 booting^M^M > [1] modprobe: modprobe: Can''t locate module char-major-4^M^M > [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty1: No such device^M > [1] modprobe: modprobe: Can''t locate module char-major-4^M^M > [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty2: No such device^M > [1] modprobe: modprobe: Can''t locate module char-major-4^M^M > [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty3: No such device^M > [1] modprobe: modprobe: Can''t locate module char-major-4^M^M > [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty4: No such device^M > [1] modprobe: modprobe: Can''t locate module char-major-4^M^M > [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty5: No such device^M > [1] modprobe: modprobe: Can''t locate module char-major-4^M^M > [1] /etc/rc.d/rc.sysinit: line 39: /dev/tty6: No such device^M > [1] modprobe: modprobe: Can''t locate module char-major-4^M^M > [1] /etc/rc.d/rc.sysinit: line 43: /dev/tty7: No such device^M > [1] modprobe: modprobe: Can''t locate module char-major-4^M^M > [1] /etc/rc.d/rc.sysinit: line 44: /dev/tty8: No such device^M > [1] Welcome to Red Hat Linux^M > [1] Press ''I'' to enter interactive startup.^M > [1] Mounting proc filesystem: [ OK ]^M^M > [1] Configuring kernel parameters: [ OK ]^M^M > [1] modprobe: modprobe: Can''t locate module char-major-10-135^M^M > [1] modprobe: modprobe: Can''t locate module char-major-4^M^M > [1] hwclock is unable to get I/O port access: the iopl(3) call failed.^M > [1] Setting clock (localtime): > > And that''s where it goes quiet. > > Since there won''t be any consoles on a guest I''m guessing that the > rc.sysinit complaints don''t matter although I don''t know how to shut them > up. > > So it looks like setting the clock is the problem. Any pointers or ideas, > anyone? > > Thanks, > Mike Wright > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xen-devel------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
xen@theorb.net
2003-Dec-02 20:21 UTC
Re: [Xen-devel] virtual domain partial boot then crash
Ian Pratt wrote: <snip />>>OK, here''s the new status. The guest no longer dies a mysterious death but does crash about the time it tries to set the hardware clock. Following is a partial output from the guest. > > > My suspicion is that failing to set the hw clock isn''t the real > problem. >During bootup of the host machine I see complaints about the char-major-10-135 device (rtc). I wonder if there is some connection? Just in case I added the line "alias char-major-10-135 rtc" to /etc/modules.conf and will see if that solves the problem or at least silences the complaint.> > Does the domain still show up in ''domain list''? Is it still > pingable? >Yes to both.> > BTW: what distribution is this? >xenolinux-1.1.bk on RedHat9.0 standard edition.> Can you see what comes after setting the hwclock in > /etc/rc.sysinit ? (you can # out the /sbin/clock line to verify > my prior hypothesis) >I commented out the /sbin/hwclock line in rc.sysinit and the guest now boots. I can ping and ssh to the guest; execute commands, etc. It seems completely functional now. Yaaaay! Oddly, I have xen_read_console running but the output from the guest still disappears about the same place in the boot sequence (somewhere around the "Init"). The guest''s /var/log/messages file shows no errors although when booting the xenconsole does receive complaints from rc.sysinit about no such /dev/ttyN, but I believe those to be harmless. Thanks to Ian and Greg for their input and to all the Xen contributors for a great project. Mike Wright ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> I commented out the /sbin/hwclock line in rc.sysinit and the > guest now boots. I can ping and ssh to the guest; execute > commands, etc. It seems completely functional now. Yaaaay!Great! I now recall that someone else had problems with hwclock hanging the boot process. I don''t fully understand why, because for us the error messages just seem harmless and the boot continues. I''ll have a think about what the best way of solving this is. Perhaps we should implement a dummy version of the rtc driver just to keep it happy...> Oddly, I have xen_read_console running but the output from the > guest still disappears about the same place in the boot > sequence (somewhere around the "Init").My guess is that this is just a /etc/syslog.conf issue, and the messages aren''t being sent to /dev/console The whole console stuff is in the process of changing in the unstable tree anyhow -- rather than implementing a tty, we''re going to implement a bidirectional console as a new serial device. This should make life rather easier. Also, we''re going to present the console to domain 0 using a new event mechanism, so there''s no problem with people accidentally firewalling off other domain''s console as often happens at the moment.> The guest''s /var/log/messages file shows no errors although when booting the xenconsole does receive complaints from rc.sysinit about no such /dev/ttyN, but I believe those to be harmless.They should be harmless. Again, I guess we could implement dummy ttys, but this might cause more confusion.> Thanks to Ian and Greg for their input and to all the Xen contributors for a great project.Cheers! Ian ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
<snip /> *** WHAT I HAD TO DO TO MAKE MY NEW REDHAT BE A GOOD GUEST *** Apologies, but I didn''t know how to cross reference this to something else; the information may be more useful under a different subject heading. After having enjoyed the CD, and tried many experiments in the following days trying to get the CD stuff to play off the hard drive I learned the very hard way: It''s very doable but requires a very high level of understanding of very low level things. PLEASE, save yourself alot of effort and download the bitkeeper software, retrieve and build xeno-1.1.bk, install it and go from there. You''ll live longer. Caveat: the redhat9 used here was built from iso images downloaded from the redhat site. there were no special configurations done other than installation of java and ant for the (soon to be obsolete) tools. During installation I specified the network parameters and answered "Yes" to firewalling with "Medium security". (iptables expert I''m not; I use the configs as examples) Assumption: 1) you have redhat9 installation on disk which has the new xen and xenolinux kernels and must successfully be able to boot into it. 2) you have a spare partition in which you have installed another redhat. Boot into the new (soon to be guest) installation and login. Run /sbin/chkconfig --list | grep ":on" to see what is running. Using /sbin/chkconfig --level turn off the hardware dependent and X stuff such as xfs, gpm, keytables, and especially iptables, __in level 4__. Don''t lock yourself out with your own rules. You can always turn iptables back on. Edit /etc/fstab and remove any incorrect swaps (redhat loves to include them all) and make sure you and it know where your mount points are. Edit /dev/rc.d/rc.sysinit and find the line with /sbin/hwclock and comment it out. (I like to add the word "NOT" to the second line down that reports the status of that. Makes me happy. Using your magic: find a copy of /lib/modules/2.4.22-xeno and cp it to your guest''s /lib/modules directory. Lastly, edit /etc/inittab and change the initdefault to 4, go down to the mingettys area and remove the runlevels for 45, go to the bottom and comment out the x:5:... line. Note** after those last steps you can still boot; you just won''t be able to talk to it from the console. Type reboot; wait; come up in your domain0 and your new guest should be available for booting from the host. The new domain should be useable from the command line instructions available in the READMEs. Using these rules I can install from CD and modify, ready to boot, a guest in about 10 minutes. Hope this is useful to somebody. Mike Wright ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
xen@theorb.net
2003-Dec-03 14:23 UTC
Re: [Xen-devel] virtual domain partial boot then crash
<snip /> *** WHAT I HAD TO DO TO MAKE MY NEW REDHAT BE A GOOD GUEST *** Apologies, but I didn''t know how to cross reference this to something else; the information may be more useful under a different subject heading. After having enjoyed the CD, and tried many experiments in the following days trying to get the CD stuff to play off the hard drive I learned the very hard way: It''s very doable but requires a very high level of understanding of very low level things. PLEASE, save yourself alot of effort and download the bitkeeper software, retrieve and build xeno-1.1.bk, install it and go from there. You''ll live longer. Caveat: the redhat9 used here was built from iso images downloaded from the redhat site. there were no special configurations done other than installation of java and ant for the (soon to be obsolete) tools. During installation I specified the network parameters and answered "Yes" to firewalling with "Medium security". (iptables expert I''m not; I use the configs as examples) Assumption: 1) you have redhat9 installation on disk which has the new xen and xenolinux kernels and must successfully be able to boot into it. 2) you have a spare partition in which you have installed another redhat. Boot into the new (soon to be guest) installation and login. Run /sbin/chkconfig --list | grep ":on" to see what is running. Using /sbin/chkconfig --level turn off the hardware dependent and X stuff such as xfs, gpm, keytables, and especially iptables, __in level 4__. Don''t lock yourself out with your own rules. You can always turn iptables back on. Edit /etc/fstab and remove any incorrect swaps (redhat loves to include them all) and make sure you and it know where your mount points are. Edit /dev/rc.d/rc.sysinit and find the line with /sbin/hwclock and comment it out. (I like to add the word "NOT" to the second line down that reports the status of that. Makes me happy. Using your magic: find a copy of /lib/modules/2.4.22-xeno and cp it to your guest''s /lib/modules directory. Lastly, edit /etc/inittab and change the initdefault to 4, go down to the mingettys area and remove the runlevels for 45, go to the bottom and comment out the x:5:... line. Note** after those last steps you can still boot; you just won''t be able to talk to it from the console. Type reboot; wait; come up in your domain0 and your new guest should be available for booting from the host. The new domain should be useable from the command line instructions described in the READMEs. Using these rules I can install a minimal RedHat9 from CD and modify it, ready to boot as a guest in about 10 minutes. Hope this is useful to somebody. Mike Wright ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
[sorry for sending twice--I sent using the wrong email address]
We''ve successfully installed Xen on a Redhat machine, and we can start
domains, but they don''t start cleanly.
If we run the xen-mynewdom script, we get the following error from the
physical grant command.
warning: state file not found [/var/lib/xen/vdstate.xml]
Partition /dev/hda2 (resolved to /dev/hda2) does not exist.
/dev/hda2 is our root partition for Redhat. Is this supposed to be the
same partition?
--
If we run xenctl domain new and xenctl domain start ignoring the physical
grant command, the domain says:
...lots of loading
...
Your system appears to have shut down uncleanly
...
...
can''t open /lib/modules/2.4.22-xeno/modules.dep for writing
[FAILED]
Checking filesystems
Checking all file systems
Couldn''t find matching filesyste: LABEL=/boot
[FAILED]
*** An error occurred during the file system check.
*** Dropping you to a shell: the system will reboot
*** when you leave the shell.
Give root password for maintenance
--
We''re also not sure how we communicate to the domain once it''s
started.
We think (possibly) that if it starts up successfully you telnet into it,
but otherwise it looks like there''s no way to give it the root
password.
--
Also, is this error related to the fsck error mentioned earlier?
Thanks,
-Jefferson Ng
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
> If we run the xen-mynewdom script, we get the following error from the > physical grant command. > > warning: state file not found [/var/lib/xen/vdstate.xml] > Partition /dev/hda2 (resolved to /dev/hda2) does not exist. > > /dev/hda2 is our root partition for Redhat. Is this supposed to be the > same partition?The first warning about the state file can safely be ignored. I think the second message may be due to an old bug in the tools -- try ''-phda2'' (removing /dev) [I presume /dev/hda2 is where you have installed your second distribution -- make sure you don''t mount the same partition r/w twice otherwise thew filesystem will be destroyed!]> Couldn''t find matching filesyste: LABEL=/boot > [FAILED] > > *** An error occurred during the file system check. > *** Dropping you to a shell: the system will reboot > *** when you leave the shell. > Give root password for maintenanceCan you edit /etc/fstab so that it names a device (/dev/hda2) rather than using the LABEL=, which (I presume) is a devfs feature. The standard xenolinux kernel does not have devfs built, and I suspect it will need a one line patch to make it work for a root filesystem.> We''re also not sure how we communicate to the domain once it''s started. > We think (possibly) that if it starts up successfully you telnet into it, > but otherwise it looks like there''s no way to give it the root password.Currently, the only way to communicate with a domain is over the network (either the real one, or the virtual internal one), hence you must be running a network service like sshd or inetd/telnetd. Full bidirectional console support will likely be in 1.2.> Also, is this error related to the fsck error mentioned earlier?I don''t recall any fsck related error, other than the ''hang during fsck'' bug that turned out to be specific to Dell PERC RAID 3d/i (aacraid) controllers and traced to a hardware bug (its repeatable on Linux). Thanks, Ian ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > Error writing block 269, (Attempt to write block from filesystemresulted> > in short write) Error writing block 269, (Attempt to write block from > > filesystem resulted in short write) > > I presume you''ve written a script for domain 1 that does a > ''physical grant -phda14 -w'' ? It looks like part of the problem > is that you don''t have write access to the partition.We hadn''t... we were under the impression that physical grant alone gave read and write access, which is why we were wary of it. This fixes that device''s errors.> If you still have problems, please can you tell us a bit more > about your exact file system configuration, your xenctl.xml file, > the scripts you''ve written to start each domain, etc.Great--let us know if there''s any other information you think will help us narrow down what''s going on. The filesystem data is included below, along with xenctl.xml, xen-mynewdom, and our fstab file. We have logs from attempts to start xen if you''d like to see those too.> It''s odd that you''re having so much trouble as at least as far as > I can figure from previous emails you''re not trying to setup a > configuration that''s at all unusual. I''m sure we can get this > figured out...I think part of the problem is that we''re not really strong on kernel hacking and linux installation. I think there''s some background that, if we had it, would make everything we need help on very plain and obvious. We''ve really just been following instructions step by step and hoping it works, and when encountering difficulties it''s hard to guess what the problem is... so we just grope around as best we can trying to see what could correspond to the error, typing things into google like mad. Also, we might not have mentioned this earlier, but earlier than two weeks ago we discovered some of our errors were hardware related(the demo CD wouldn''t run). (We were running on a PII 400mhz w/256mb RAM). Since then we''ve switched to a PIII 633mhz w/256mb RAM. So part of our errors were not-fixable, earlier on. Anyway. Let us know if we can do anything to make things easier--this must be annoying having us ask questions so often =/ -Jefferson -- Some quick questions: -Should there be directories and utilities inside the roots for each xen domain? When we used the demo CD it had data from the initrd.gz, but we''re not sure if that''s necessary. A summary of our errors: -If we give a domain a physical grant of our root(/dev/hda2) readonly, we get a kernel panic--it says the root is unclean, tries to clean it, and finds it doesn''t have write access. -If we give a physical grant of readwrite to a xen partition(100mb ofempty space, /dev/hda14), and readonly to everything else, it tries to recover a journal on one of the other xen partitions and runs out of file descriptors. Data about our filesystem:>From df:Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda2 16128668 2603208 12706148 18% / /dev/hda1 101089 11755 84115 13% /boot none 63820 0 63820 0% /dev/shm **these xens are normally unmounted /dev/hda5 101089 4127 91743 5% /xen10 /dev/hda14 101089 4127 91743 5% /xen1 /dev/hda13 101089 4127 91743 5% /xen2 /dev/hda12 101089 4127 91743 5% /xen3 /dev/hda11 101089 4127 91743 5% /xen4 /dev/hda10 101089 4127 91743 5% /xen5 /dev/hda9 101089 4127 91743 5% /xen6 /dev/hda8 101089 4127 91743 5% /xen7 /dev/hda7 101089 4127 91743 5% /xen8 /dev/hda6 101089 4127 91743 5% /xen9>From /etc/fstab:LABEL=/ / ext3 defaults 1 1 /dev/hda1 /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 #/dev/hda14 /xen1 ext3 defaults 1 2 #/dev/hda5 /xen10 ext3 defaults 1 2 #/dev/hda13 /xen2 ext3 defaults 1 2 #/dev/hda12 /xen3 ext3 defaults 1 2 #/dev/hda11 /xen4 ext3 defaults 1 2 #/dev/hda10 /xen5 ext3 defaults 1 2 #/dev/hda9 /xen6 ext3 defaults 1 2 #/dev/hda8 /xen7 ext3 defaults 1 2 #/dev/hda7 /xen8 ext3 defaults 1 2 #/dev/hda6 /xen9 ext3 defaults 1 2 /dev/hda3 swap swap defaults 0 0 Our /etc/xenctl.xml file: <?xml version="1.0"?> <domctl_defaults> <domain_name>XenoLinux</domain_name> <domain_size_kb>98304</domain_size_kb> <domain_image>/boot/xenolinux.gz</domain_image> <domain_vifs>1</domain_vifs> <root_device>/dev/hda2</root_device> <root_args>ro</root_args> <args>DOMID=+</args> <nw_ip>169.254.1.0+</nw_ip> <nw_gw>169.254.1.0</nw_gw> <nw_mask>255.255.0.0</nw_mask> <nw_nfs_server>169.254.1.0</nw_nfs_server> <max_domain_number>1000</max_domain_number> <xi_tools_dir>/usr/local/bin/</xi_tools_dir> </domctl_defaults> Our /etc/xen-mynewdom file: domain new physical grant -phda14 -w domain start ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Gregory Newby
2003-Dec-08 05:49 UTC
Re: [Xen-devel] virtual domain partial boot then crash
Hi, Jefferson. A few suggestions: Check /etc/fstab on the other domains (i.e., /dev/hda14). Your kernel panic symptom below sounds like it might be trying to mount R+W without the physical grant -w. Also, as previously mentioned, don''t use "LABEL=/" for the virtual domains. You need to supply the actual device node. So, on your xen1, /etc/fstab might look something like this (with a physical grant /dev/hda14 -w): /dev/hda14 / ext3 defaults 1 1 For RO, which will cause some logging to fail but might at least let you get further in the boot process: /dev/hda14 / ext3 defaults,ro 1 1 It might help to put "0 0" in the last columns, which will tell the kernel to not fsck the partitions. Of course, you should also make sure the partition is umounted from the zeroth domain before trying to start another one. I hope this helps! Another solution is to mount / via NFS instead. -- Greg On Sun, Dec 07, 2003 at 06:39:20PM -0800, Jefferson Ng wrote:> > > > Error writing block 269, (Attempt to write block from filesystem > resulted > > > in short write) Error writing block 269, (Attempt to write block from > > > filesystem resulted in short write) > > > > I presume you''ve written a script for domain 1 that does a > > ''physical grant -phda14 -w'' ? It looks like part of the problem > > is that you don''t have write access to the partition. > > We hadn''t... we were under the impression that physical grant alone gave > read and write access, which is why we were wary of it. > > This fixes that device''s errors. > > > If you still have problems, please can you tell us a bit more > > about your exact file system configuration, your xenctl.xml file, > > the scripts you''ve written to start each domain, etc. > Great--let us know if there''s any other information you think will help us > narrow down what''s going on. > > The filesystem data is included below, along with xenctl.xml, > xen-mynewdom, and our fstab file. We have logs from attempts to start xen > if you''d like to see those too. > > > It''s odd that you''re having so much trouble as at least as far as > > I can figure from previous emails you''re not trying to setup a > > configuration that''s at all unusual. I''m sure we can get this > > figured out... > > I think part of the problem is that we''re not really strong on kernel > hacking and linux installation. I think there''s some background that, if > we had it, would make everything we need help on very plain and obvious. > > We''ve really just been following instructions step by step and hoping it > works, and when encountering difficulties it''s hard to guess what the > problem is... so we just grope around as best we can trying to see what > could correspond to the error, typing things into google like mad. > > Also, we might not have mentioned this earlier, but earlier than two weeks > ago we discovered some of our errors were hardware related(the demo CD > wouldn''t run). (We were running on a PII 400mhz w/256mb RAM). Since then > we''ve switched to a PIII 633mhz w/256mb RAM. So part of our errors were > not-fixable, earlier on. > > Anyway. Let us know if we can do anything to make things easier--this > must be annoying having us ask questions so often =/ > > -Jefferson > > -- > > Some quick questions: > -Should there be directories and utilities inside the roots for each xen > domain? When we used the demo CD it had data from the initrd.gz, but > we''re not sure if that''s necessary. > > A summary of our errors: > -If we give a domain a physical grant of our root(/dev/hda2) readonly, we > get a kernel panic--it says the root is unclean, tries to clean it, and > finds it doesn''t have write access. > > -If we give a physical grant of readwrite to a xen partition(100mb ofempty > space, /dev/hda14), and readonly to everything else, it tries to > recover a journal on one of the other xen partitions and runs out of file > descriptors. > > Data about our filesystem: > >From df: > > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/hda2 16128668 2603208 12706148 18% / > /dev/hda1 101089 11755 84115 13% /boot > none 63820 0 63820 0% /dev/shm > **these xens are normally unmounted > /dev/hda5 101089 4127 91743 5% /xen10 > /dev/hda14 101089 4127 91743 5% /xen1 > /dev/hda13 101089 4127 91743 5% /xen2 > /dev/hda12 101089 4127 91743 5% /xen3 > /dev/hda11 101089 4127 91743 5% /xen4 > /dev/hda10 101089 4127 91743 5% /xen5 > /dev/hda9 101089 4127 91743 5% /xen6 > /dev/hda8 101089 4127 91743 5% /xen7 > /dev/hda7 101089 4127 91743 5% /xen8 > /dev/hda6 101089 4127 91743 5% /xen9 > > >From /etc/fstab: > > LABEL=/ / ext3 defaults 1 1 > /dev/hda1 /boot ext3 defaults 1 2 > none /dev/pts devpts gid=5,mode=620 0 0 > none /proc proc defaults 0 0 > none /dev/shm tmpfs defaults 0 0 > #/dev/hda14 /xen1 ext3 defaults 1 2 > #/dev/hda5 /xen10 ext3 defaults 1 2 > #/dev/hda13 /xen2 ext3 defaults 1 2 > #/dev/hda12 /xen3 ext3 defaults 1 2 > #/dev/hda11 /xen4 ext3 defaults 1 2 > #/dev/hda10 /xen5 ext3 defaults 1 2 > #/dev/hda9 /xen6 ext3 defaults 1 2 > #/dev/hda8 /xen7 ext3 defaults 1 2 > #/dev/hda7 /xen8 ext3 defaults 1 2 > #/dev/hda6 /xen9 ext3 defaults 1 2 > /dev/hda3 swap swap defaults 0 0 > > Our /etc/xenctl.xml file: > > <?xml version="1.0"?> > <domctl_defaults> > <domain_name>XenoLinux</domain_name> > <domain_size_kb>98304</domain_size_kb> > <domain_image>/boot/xenolinux.gz</domain_image> > <domain_vifs>1</domain_vifs> > <root_device>/dev/hda2</root_device> > <root_args>ro</root_args> > <args>DOMID=+</args> > <nw_ip>169.254.1.0+</nw_ip> > <nw_gw>169.254.1.0</nw_gw> > <nw_mask>255.255.0.0</nw_mask> > <nw_nfs_server>169.254.1.0</nw_nfs_server> > <max_domain_number>1000</max_domain_number> > <xi_tools_dir>/usr/local/bin/</xi_tools_dir> > </domctl_defaults> > > Our /etc/xen-mynewdom file: > domain new > physical grant -phda14 -w > domain start > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xen-devel------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel