Lines Matching refs:it
115 13.13 When you run UML, it immediately segfaults
163 hardware, it talks to a `real' Linux kernel (called the `host kernel'
197 6. You can use it as a sandbox for testing new apps.
237 3. Make a directory and unpack the kernel into it.
285 you want to change something, go ahead, it probably won't hurt
376 4. boot the kernel on it
435 Booting UML is straightforward. Simply run 'linux': it will try to
437 run it as root. If your root filesystem is not named `root_fs', then
465 variety of commands and utilities installed (and it is fairly easy to
476 /dev and /etc/inittab runs a getty on it) will come up in its own
510 machine and log in to it. See ``Setting up the network'' to learn
513 When you're done using it, run halt, and the kernel will bring itself
555 in the middle of the kernel address space, so UML won't even load - it
567 where it will run fine. See ``Compiling the kernel and modules'' if
639 device. The terminal that it got will be announced in the boot
640 log. You access it by attaching a terminal program to the
650 o kermit - start it up, 'open' the device, then 'connect'
678 UML will run an xterm and the device will be attached to it.
707 port than UML devices attached to it, then the extra telnet sessions
712 devices to it and know how to access them without reading the UML boot
721 appear to hang. In reality, it's waiting for a telnet to connect, at
732 attach a UML device to it. This is most commonly used to put the
804 so that when you switch to it, you will see the UML login prompt
824 Look at the boot log to see what pty it got (this example will assume
825 that it got /dev/ptyp1).
836 Log in, make sure that it has no getty on that serial line, attach a
837 terminal program like minicom to it, and you should see the login
850 As of 2.4.5, UML networking has been completely redone to make it much
890 machines on it is acting as a gateway.
896 o ethertap - if you want access to the host networking and it is
899 o TUN/TAP - if you want access to the host networking and it is
901 preconfigured device, allowing it to avoid using the setuid uml_net
921 to it because it has better performance and ethertap is officially
924 it does with ethertap. This is a slight security advantage since
925 it provides fewer opportunities for a nasty UML user to somehow
939 This is done by describing it on the kernel command line.
959 host /dev/tap0, assigns it an ethernet address, and assigns the host
973 Also note that when you configure the host side of an interface, it is
974 only acting as a gateway. It will respond to pings sent to it
975 locally, but is not useful to do that since it's a host interface.
1019 specific reason to do it, you probably shouldn't. If one is not
1087 This is wrong, because it will cause UML to try to figure out hardware
1090 with two nodes on it (UML and the host) and arp requests don't cross
1092 is for UML to just blindly throw all packets at the host and let it
1098 ethernet, it's probably because of a network route that's
1111 with a mask that's not 255.255.255.255, then replace it with a route
1145 To use it, run two UMLs with
1208 the setuid helper, use it to get up and running, then read the next
1228 available tap device and assign an ethernet address to it based on its
1241 TUN/TAP device on the host. You can use a different one, but it won't
1336 ration is not stored across host reboots. So, it's probably a good
1337 idea to stick it in an rc file. An even better idea would be a little
1425 for it. The simplest thing to do is
1433 Making it world-writable looks bad, but it seems not to be
1434 exploitable as a security hole. However, it does allow anyone to cre-
1442 (i.e. 'eth0=tuntap,tap0') on the command line (or do it with the
1447 If you don't want that tap device any more, you can make it non-
1456 Finally, tunctl has a -b (for brief mode) switch which causes it to
1457 output only the name of the tap device it created. This makes it
1492 attaches the UML eth0 device to the host /dev/tap0, assigns it the
1499 ethernet address is omitted, one will be assigned to it.
1508 If it is absent, then you must configure the tap device and whatever
1510 case, the uml_net helper still needs to be in your path and it must be
1517 setup - uml_net will do it for you. You just need to make sure you
1523 appropriate /dev entry exists. If it doesn't, become root and create
1524 it as follows:
1571 totally virtual network. By default, it provides no connection to the
1575 The first thing you need to do is run the daemon. Running it with no
1576 arguments will make it listen on a default pair of unix domain
1580 If you want it to listen on a different pair of sockets, use
1589 If you want it to act as a hub rather than a switch, use
1622 The reason it doesn't background by default is that it listens to
1623 stdin for EOF. When it sees that, it exits.
1637 specify the ethernet address if the one that will be assigned to it
1657 transport any higher-level protocol, it can only be used to transport
1671 host end of the slip device. If it is specified, the helper will run
1672 and will set up the host so that the virtual machine can reach it and
1705 interface. The slirp path is generally /usr/bin/slirp, although it
1717 although you can use anything as long as it is not used by a network
1735 is limited to 115200. If you need it to go faster, the slirp binary
1818 proxy arp is set up for it.
1861 private one if the requested block is valid in it, the shared one if
1864 has a much smaller file containing the changes that it has made. With
1884 the existing shared filesystem. The COW file need not exist. If it
1885 doesn't, the driver will create and initialize it. Once the COW file
1886 has been initialized, it can be used on its own on the command line:
1894 The name of the backing file is stored in the COW file header, so it
1895 would be redundant to continue specifying it on the command line.
1914 Doesn't look like much saved space, does it? Well, here's 'ls -ls':
1932 file, do not boot directly from it or modify it in any way. Doing so
1933 will invalidate any COW files that are using it. The mtime and size
1949 backing file and expecting that all of the COW files using it will see
1957 Depending on how you use UML and COW devices, it may be advisable to
1974 merged file, and if you're happy with it, move it over the old backing
1983 when the backing file only has one COW file associated with it. If
1985 one of them will invalidate all of the others. However, it is
1986 convenient if you're short of disk space, and it should also be
1993 UML from one of those packages, you can also get it from the UML
2021 file of the appropriate size. I usually make it sparse to save time
2022 and to avoid allocating disk space until it's actually used. For
2080 Now, mount it:
2103 can treat it as a separate machine and either nfs mount directories
2105 However, since UML is running on the host, it can access those
2110 This is now possible with the hostfs virtual filesystem. With it, you
2112 files contained in it just as you would on the host.
2125 . hostfs should be listed. If it's not, either rebuild the kernel
2126 with hostfs configured into it or make sure that hostfs is built as a
2127 module and available inside the virtual machine, and insmod it.
2194 UML should then boot as it does normally.
2199 If you need to build hostfs because it's not in your kernel, you have
2215 /lib/modules/`uname -r`/fs in the virtual machine, boot it up, and
2285 UML. Run it with either the umid or the full path as its argument:
2339 often causing it to appear to hang. Sending such a UML the mconsole
2340 version command is a good way to 'wake it up' before networking has
2341 been enabled, as it does not do anything to the function of the UML.
2420 up doing is up to /etc/inittab. Normally, it reboots the machine.
2456 crazy, running all the jobs it didn't do earlier.
2472 Since the user-mode kernel runs as a normal Linux process, it is
2473 possible to debug it with gdb almost like any other process. It is
2479 In order to debug the kernel, you need build it from source. See
2492 xterm with gdb running inside it. The kernel will send some commands
2493 to gdb which will leave it stopped at the beginning of start_kernel.
2510 What you want is the stack of whatever process is sleeping when it
2549 thread and continue it
2591 - it will just sit there after you hit return
2618 object file you just loaded into UML and where in memory it is. Then,
2619 it can read the symbol table, and figure out where all the symbols are
2631 First, you must tell it where your modules are. There is a list in
2643 are going to debug. Then you run it from the toplevel directory of
2644 your UML pool and it basically tells you what to do:
2657 welcome to change it and/or distribute copies of it under certain conditions.
2668 After you run UML and it sits there doing nothing, you hit return at
2669 the 'att 1' and continue it:
2757 is at module_list. If it's not, walk down the next links, looking at
2760 2.4.10 kernels is 96 (0x60)) to it. Gdb can make this hard addition
2772 it was module.size_of_struct + 4), so it's a good idea to check the
2783 Tell gdb you really want to do it, and you're in business.
2788 check it by looking at the module structure. The init and cleanup
2804 is to tell gdb to forget about all symbols that it knows about:
2829 it later by sending the tracing thread a SIGUSR1. The first line of
2836 When you send it the signal:
2844 you will get an xterm with gdb running in it.
2856 will fire up an xterm with gdb running in it.
2864 I sent it to Alan for inclusion in the ac tree, and it will be in my
2873 To do this, you need to get the pid of the debugger and pass it in
2877 If you are using gdb under some UI, then tell it to 'att 1', and
2882 you'll need to get it to do the equivalent of 'att 1' if it doesn't do
2883 it automatically.
3015 welcome to change it and/or distribute copies of it under certain conditions.
3055 It is, so let's see what it thinks it's up to:
3075 the defines in include/asm-um/arch/unistd.h), and that it never
3077 arch/um/include/user_util.h). These mean that it went into a write,
3081 The fact that it never returned from write means that its stack should
3083 process is being ptraced by the signal thread, so it must be detached
3084 before gdb can attach it:
3168 The initial faulting address is interesting because it is on the idle
3239 Specifically, it's in pte_alloc:
3332 these structures. Maybe it's a stack overflow from the next page:
3396 stick a trap on the segfault handler which will stop if it sees any
3398 first, and it may be that if I can catch it immediately, what's going
3467 attach to it with gdb. This is done by sending it a SIGUSR1, which is
3477 Now I can run gdb on it:
3495 welcome to change it and/or distribute copies of it under certain conditions.
3507 The backtrace shows that it was in a write and that the fault address
3546 the code the access happened shows that it happened near line 110 of
3616 I need to figure out what bh is, and it just so happens that bh is
3659 Now, I look at the structure to see what's in it, and particularly,
3684 0x50000000 page. Looking at it shows the kernel's idea of the state
3704 and the page_struct itself should be mem_map[0], since it represents
3756 manager, which marks it all reserved. The free_bootmem call frees up
3757 all of it, except for the first two pages. This looks correct to me.
3760 So, I decide to see init_bootmem run and make sure that it is marking
3765 at what it contains shows the following:
3798 As of test11, it is necessary to have "ARCH=um" in the environment or
3820 point to /usr/src/linux/asm-um. Make it point back to
3822 build it there. Also see below, where a more specific set of symptoms
3830 I saw this on reiserfs 3.5.21 and it seems to be fixed in 3.5.27.
3866 If you build UML with gprof support and, early in the boot, it does
3933 to create a static rule to enable it:
3982 root device is, so it panics.
4006 way around it besides upgrading.
4013 to calculate the BogoMips rating, using the TSC if it's there or using
4015 loop. UML uses the loop, since it has nothing resembling a TSC, and
4022 13.13. When you run UML, it immediately segfaults
4046 happening and it acts strangely, then it could be a problem in the
4052 Otherwise, let me know about it. Send a message to one of the UML
4057 it and that a fix is imminent.
4069 dot sourceforge dot net (subscription info). When you do, it is
4070 likely that I will want more information. So, it would be helpful to
4084 you will need to run it under the debugger (add 'debug' to the command
4085 line). An xterm will start up with gdb running inside it. Continue
4086 it when it stops in start_kernel and make it crash. Now ^C gdb and
4134 panics. In this case, the kernel debugger will be useless because it
4137 figuring out what its pid is, firing up gdb, and attaching it to that
4178 attach to it. So, this is how the fancy footwork goes:
4194 If you get a segfault, do it again. It always works the second time.
4236 You can tell that it's the idle thread if the stack looks like this:
4251 sleep when it shouldn't have. Run ps on the host and figure out which
4253 to it with gdb and get a backtrace as described in case 3.
4284 o prodded me into making this project official and putting it on
4322 code so that it would work on machines with Large File Support
4337 to allow it to layer a COW file on a shared read-only filesystem and
4358 is doing a real nice job of it. He also noticed and fixed a number of
4364 driver and is doing a nice job of it.
4559 <http://www.oss.sgi.com> . The bandwidth there made it possible to
4564 Debian filesystem that I've been distributing and updated it to 2.2.
4571 wrong with it, letting me fix a long-standing (several weeks) and