summaryrefslogtreecommitdiff log msg author committer range
path: root/hurd/subhurd.mdwn
blob: c9fe15d271e4e22bdfd0604bb8d1415335d7317b (plain)
 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559  [[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] A sub-Hurd is like a [[neighbor_Hurd|neighborhurd]], however, makes use of some resources provided by another Hurd. For instance, backing store and the console. Sub-hurds are extremely useful for debugging core servers as it is possible to attach to them with gdb from the parent ([[debugging_via_subhurds|debugging/subhurd]]). This avoids deadlock, e.g., when the instance of gdb stops the server but requires its use. (Note: it is possible to use [[debugging/gdb/noninvasive_debugging]], but this is less flexible.) Vice versa, it is also possible to use a subhurd to debug the *main* Hurd system, for example, the latter's root file system, but that requires a privileged subhurd. [[!toc levels=2]] # Howto ## Preparing To run a subhurd, you need an additional partition with an installed Hurd system. In principle, you can also use your main partition in read-only mode; but this obviously will create severe limitations. Usually, you will want a complete independent system. The system for the subhurd is a normal Hurd installation, which could just as well run standalone. You can use any of the various possible installation methods, or reuse an existing installation if you already have several. If using [[Debian_GNU/Hurd|running/debian]], the easiest is probably to use debootstrap as root: mke2fs /dev/hd0s6 settrans -ca mnt /hurd/ext2fs /dev/hd0s6 debootstrap sid mnt/ http://httpredir.debian.org/debian settrans -fga mnt ### IRC, freenode, #hurd, 2013-09-15 Never dared to try a subhurd, any link to the howto? gnu_srs: I followed http://www.gnu.org/software/hurd/hurd/subhurd.html though using crosshurd didn't work for me, I just used debootstrap gnu_srs: and you need a separate filesystem translator (i.e. not /) for that the easiest way is to add another virtual disk to you qemu setup use the qemu image directly simplest way to set up a subhurd just change fstab from the host before the first boot to avoid making the subhurd use the same hd0 drive as the host braunr: nice idea :) ## Booting If you are using a recent version of the Hurd (>= 0.9), then you can simply boot the subhurd as an unprivileged user by issuing boot /dev/hd0s6 (Replace hd0s6 by the name of your partition or backing file for the subhurd.) /!\ The partition must be unmounted (or mounted read-only) before you boot from it! ## Networking You can provide the subhurd with a network card by passing a -f option to boot. For instance, if you have a second network card /dev/eth1 in your host hurd, pass -f eth0=/dev/eth1 to make it appear as device eth0 in the subhurd. If you don't have a second network card, you can setup the eth-multiplexer to share one network card. To do so, install the multiplexer settrans -c /dev/eth0m /hurd/eth-multiplexer --interface=/dev/eth0 Then configure your main Hurd system to use a virtual network interface (e.g. /dev/eth0m/0) instead. On Debian/Hurd, this can be accomplished using ifdown /dev/eth0 sed -i -e s#/dev/eth0#/dev/eth0m/0# /etc/network/interfaces ifup /dev/eth0m/0 You can now pass -f eth0=/dev/eth0m/1 to boot. ## Booting and shutting down Now the subhurd should boot just like a normal Hurd started directly from GRUB, finally presenting a login prompt. The boot program serves as proxy for the subhurd, so you can control it from the terminal where you issued the boot command. To exit the subhurd, issue halt or reboot. This should exit it cleanly, but for some reason it doesn't always work; sometimes it will output various errors and then hang. If that happens, you need to kill the boot process manually from a different terminal. If the boot process dies, the proc server will kill all tasks belonging to the Subhurd. ## Using In the subhurd, you can do basically all the same things as in the main Hurd. You can even set up networking: Just invoke settrans on the /servers/socket/2 as usual inside the subhurd, using /dev/eth0, only using a different local IP than in the main Hurd. This way, the subhurd will be able to communicate to the outside world with its own IP -- allowing for example to do apt-get inside the subhurd, or to ssh directly into the subhurd. If you want to access the subhurd processes from the outside, e.g. for [[debugging_purposes|debugging/subhurd]] (or to get rid of a subhurd that didn't exit cleanly...), you need to find out how main Hurd [[PID]]s correspond to subhurd processes: the subhurd processes appear in the main Hurd (e.g. if doing ps -e) as unknown processes, but the [[PID]]s are different! To find out which process is which, you can simply compare the order -- while the numbers are different, the order should usually match. Often it also helps to look at the number of threads (e.g. using ps -l), as many servers have very characteristic thread counts. ### IRC, freenode, #hurd, 2013-08-09 btw, is there a way to get dde-based networking into a subhurd? the wiki instructions look like they're for the mach driver and starting the dde translator inside the subhurd does not work for me that's probably a good thing though the netdde process will need privileged access to mach for hardware access you can't easily use netdde from a subhurd, unless with a different nic i usually rebuild mach with in kernel devices so both the main and subhurd can share on nic one* could a port to netdde perhaps forwarded to the subhurd? zengh da wrote the eth-multiplexer for that iirc it's a matter of making it appear as an eth0 device on the master port aiui zheng* yes, I looked at that what is the master port? on a plain hurd system it's the port that privileged processes can use to access mach devices in a subhurd, it's the same for the subhurd, to access some devices that you choose to give access to its real name is the "device master port" ah yes #### IRC, freenode, #hurd, 2013-08-10 teythoon: use eth-multiplexer to use the NIC within a subhurd. that's exactly what it was created for. I don't remember whether it's even possible to share a "raw" netdde device... I don't think I ever tried that; and I don't remember enough of the theory to tell whether it should be possible but I really don't see the reason to, when eth-multiplexer is available (IMHO running an eth-multiplexer on top of netdde should be the default setup in fact) as for actually passing on the device, that should be perfectly possible with zhengda's modified subhurd... but I don't remember whether that was ever merged upstream (you will definitely need that for using netdde in a subhurd, regardless whether through eth-multiplexer or directly) #### IRC, freenode, #hurd, 2013-09-15 I wonder if we can modify the boot program so that it passes ports from the mother hurd to the subhurd so that we could pass in a port to the eth-multiplexer or use like /hurd/remap as the root translator for the subhurd [[open_issues/virtualization/remap_root_translator]]. eth-multiplexer was created exactly for that iirc, so it's probably already done somewhere #### IRC, freenode, #hurd, 2013-09-16 braunr: regarding subhurd did you mean to install sthibault/hurd-i386/debian-hurd.img.tar.gz on a separate partition and booting using the instructions for subhurds on the web. gnu_srs: yes be careful that the subhurd doesn't use the same partition as the main hurd, that's all what about changing fstab? 12:17 < braunr> be careful that the subhurd doesn't use the same partition as the main hurd, that's all gnu_srs: yes, you need to change the fstab currently it is used for fscking stuff, so if it points to your main partition it will cause severe corruption gnu_srs: you also have to specify the right partition in the servers.boot file fstab of the subhurd image? yes how to unpack the .img file (just to be sure)? gnu_srs: you don't need to, just use the img file as secondary hard disk image Then how should I be able to change fstab of the image? boot your hurd box, mount the partition and change it I missed something here: on my partition /my_chroot I have have the file debian-hurd-20130504.img gnu_srs: ah, you copied it to the partition, braunr meant to use it as the secondary disk, e.g. qemu ... -hdb debian-hurd-20130504.img ... That is the same as installing another cd image, where does the subhurd come into play? mount the partition on the secondary hd, fix the fstab there, mount it r/o, get the servers.boot file from the wiki, modify it so that it points to the right partition, execute boot servers.boot /dev/, probably /dev/hd1s1 BTW: unpacking was problematic: tar: debian-hurd-20130504.img: Cannot seek to 2147696640 (2G limitations) I wonder why you did this on your hurd system in the first place... I thought I could use that partition, /my_chroot as a chroot place. So it won't work for subhurds? well, there are several ways to setup a subhurd. one is to already have a spare partition for that and use crosshurd or as I did debootstrap to install a debian system there braunr suggested an even easier way, download the .img file and use it as secondary hard disk you ended up doing kind of both I tried once with debootstrap and that created a disaster... how so? The install errored out, and the whole filesystem (including /) was left in a broken state. Maybe I tried that without using a separate partition. Don't remember any longer. So you say it's safe now? I used it successfully to setup my subhurd and you have your subhurd in a separate partition, installed from there too, as root? the web page only mentions crosshurd, and that failed for you? yes, having a separate partition is (currently) necessary to run a subhurd yes, I used debootstrap as root, afaics that is necessary and yes, as I said the other day, I tried crosshurd first and it failed then again, I fail to see any reason to use crosshurd these days it's only a wrapper around debootstrap anyway, using it with --foreign and fixing up stuff later one has more control over the process if one uses debootstrap directly I still don't dare to do it yet. I'll create another image using netinst with a separate partition and try out first. When installing a new image using netinst.iso (2013-06-30) and rebooting /proc does not get mounted? gnu_srs: is that a statement or a question? A statement. it's not customary to end statements with question marks ;) s/mounted?/mounted, why?/ well, you seem to be the last person to perform such an installation, so you are in the perfect position to answer this question. cat /var/log/dmesg? On other images I have: fsysopts /proc; /hurd/procfs --clk-tck=100 --stat-mode=444 --fake-self=1 gnu_srs: no, check the installation log gnu_srs: and what does showtrans say? showtrans /proc; which log file to look for? the installation log, somewhere in /var/log probably I only find /proc in /var/log/installer/syslog, mainly printing out errors not finding /proc/mounts iirc the /proc translator should be set during the hurd package configuration you should probably look for that part in the log Setting up translators: /hurd/exec /hurd/proxy-defpager /hurd/pflocal (+link) /hurd/pfinet (+link) (+link) /hurd/procfs -c /hurd/password crash-kill crash-suspend crash-dump-core crash. that part debootstrap: /hurd/procfs -c and in-target: /hurd/procfs -c No errors I don't understand what that means please explain in more details see: http://paste.debian.net/41195/ makes much more sense :) Where is the 'Setting up translators' done? I cannot find anything in /var/lib/dpkg/info/hurd* or /etc/init.d/... /usr/lib/hurd/setup-translators, called in hurd.postinst tks:) Hi, when installing a new image with debootstrap to /chroot the script boot/servers.boot is already there (as well as in /boot/ + grub) Is it OK to use that file to boot the subhurd? using /boot/servers.boot or /chroot/boot/servers.boot (if the /chroot partition is unmounted it cannot be used?) and how to unmount /chroot: umount does not work? braunr: I'm also trying to find out what's wrong with glibc, when my subhurd is up and running 2.13-39 (if possible) I know I should issue settrans command, but I'm not yet fluent in translators. sorry:-/ Now this, after a reboot: unknown code P 30 while trying to open /dev/hd0s3 (/chroot) Disk write protected: use the -n option to do a read-only check of the device. fsysopts /dev/&hd0s1 --writable: Operation not supported?? OK, I'm giving up for now, no subhurd:-( and a broken install. Which terminal to use in rescue mode, TERM is not set, dumb,mach,hurd does not work with nano? e2fsck /dev/ho0s3; e2fsck: Unknown code P 2 while trying to open /dev/ho0s3; Possibly non-existent device? mke2fs /dev/hd0s3; /dev/hd0s3 is not a block special device.; Proceed anyway? (y,n) n: What's going on (hd0s3 not mounted)?? anybody, help? after removing and creating the partition again:mke2fs /dev/hd0s3, , mke2fs: Unknown code P 13 while trying to determine filesystem size: What's going on? Where to find the glibc-2.13 versions which used to be at debian-ports?. seems they can be found on snapshot.debian.org #### IRC, freenode, #hurd, 2013-09-17 teythoon: Installing subhurd via debootstrap on partition /chroot fails miserably. Install hangs, and after reboot \rm -r /chroot/* fails for dev and proc Are there translators running there already? I have not booted the subhurd. translators for hd0s3 (/chroot) are storeio and ex2fs.static. Do I have to stop them to be able to clean out /chroot? mount -v /chroot; settrans -a /chroot /hurd/ext2fs /dev/hd0s3; ext2fs: /dev/hd0s3: panic: main: device too small for superblock (0 bytes); mount: cannot start translator /hurd/ext2fs: Translator died Please, somebody! don't ask to ask, just ask, right? we've already told you everything you need just get it right for example, i told you to be careful about fstab so that the subhurd wouldn't use the main hurd partition but you managed to screw that good job I installed the subhurd in a partition /chroot /dev/hd0s3 using debootstrap i don't know deboostrap, it may be broken, use the disk image youpi maintains ant the install screwed up with debootstrap ok; then I cannot use a partition, but another disk in kvm, e.g. hdb? gnu_srs: hd1 something is fishy with glibc, definitely, that's why I'm trying to set up a subhurd to revert to 2.13-39 hi, when trying to boot a subhurd: /hurd/ext2fs.static: hd0s3: Gratuitous error; bye gnu_srs: why hd0s3 ? it should be hd1s1 I'm still using a separate partition /my_chroot /hd0s3. Will switch to hd1 next. teythoon? the servers.boot script use absolute paths:/hurd/ext2fs.static and /lib/ld.so.1 /hurd/exec, shouldn't they be relative to /my_chroot? no they're actually from your host teythoon: please, how did you succeed to boot a subhurd in a partition? using debootstrap gnu_srs: from my shell history: : 1374672426:0;debootstrap sid /mnt http://http.debian.net/debian/ : 1374673020:0;cp /etc/hosts /etc/resolv.conf /mnt/etc : 1374673048:0;cp /etc/passwd /etc/shadow /mnt/etc teythoon: so it does work fine ? great yes, why wouldn't it? gnu_srs: I then remounted that partition r/o and used the servers.boot file from the wiki to boot it braunr: why wouldn't it? (you do mean the debootstrap part, don't you?) teythoon: i don't know i've heard it wasn't maintained any more not being maintained is a good reason for something to become unusable/untrustable with time o_O it is at the heart of d-i, isn't it? I actually do most Debian installations using debootstrap directly ah ok :) teythoon: even hurd ones ? braunr: well, just the subhurd installation, but that went as expected good Finally: I found the reason for Gratuitous error, I used the /boot/servers.boot script, that being different to the one on the wiki:-/ Is it possible to copy files between a host hurd and subhurd, what about access to eth0? Hi, when starting the subhurd I see some warnings/error: http://paste.debian.net/41963/ 1) A spelling error execunable-> executable 2) libports: invalid destination port 3) mach-defpager: another already running "execunable" is not a typo, but just "exec" and "unable ..." without a space-type character OK, sounds more plausible Ah, the printouts are mixed, no bug When setting up nework in the subhurd: /hurd/pfinet: file_name_lookup /dev/eth0: Translator died /hurd/pfinet: device_open(/dev/eth0): (os/device) no such device settrans: /hurd/pfinet: Translator died #### IRC, freenode, #hurd, 2013-09-18 priority does not matter much memory manager is not really surprising, there's indeed already one what is actually the problem? So these are merely warnings? gnu_srs: yes Real problems are I cannot set up networking, e.g. wget ...: Connecting to ... failed: Address family not supported by protocol. gnu_srs: did you give the subhurd a network card? How? and do I need to set up fstab, for now it's empty. I just installed the base with dbootstrap gnu_srs: -f option of boot e2fsck will need fstab for sure otherwise it can't divine what should be checked Why is the /boot/servers.boot different from the subhurd one on the wiki? Is it used at all, I thought grub was in charge. it's not used at all maybe better to put in the subhurd one there then, with a comment? no, since /boot/servers.boot is supposed to be used for machine boot not subhurd boot what about putting a copy of the suhurd one there, with a different name? probably a good idea, yes matter of making it happen the wiki page on subhurd does not say how to set up networking, only that you can do it. matter of adding the information I remember it's the -f option of boot make it work, and add the information for others I could try, but don't know how to add a network card to the subhurd, and e.g. how to set up swap see -f option of boot? "gnu_srs: -f option of boot" if you could read what we write, that'd make things happen way faster yes I saw your comment above, it was just to be 100% sure:-D device_file=/dev/eth0 or something else? eth0 is used by the host already did you read boot --help ? iirc it's not a problem, both will receive all frames yes I did then I don't see where you took device_file from at least in that form --device=device_name=device_file that means rather something like --device=foo=bar so -f /dev/eth0 is correct usage then? didn't you see that in what I wrote, there was a "=" in there? -f is the short option, --device is the long, I don't see the need for = in the short option? in the long option there are *two* = yes, but in the short no? why not? long -> short usually drops one = to summarize: -f=/dev/eth0 or --device=eth_sub=/dev/eth0? why shouldn't there be a eth_sub in the short version? 10:15:49) youpi: long -> short usually drops one = yes, it drops the = but nothing else if the long option needs some information, the short needs it too? -? correct now? -f eth_sub=/dev/eth0 or --device=eth_sub=/dev/eth0? yes k! # Further Info Read about using a subhurd for [[debugging_purposes|debugging/subhurd]]. Roland's tutorial about [[running_a_subhurd]]. # Use Cases ## Debugging the *Main* Hurd System Note: This only works with privileged subhurds. A subhurd can be used for debugging the *main* Hurd system. This works as long as the subhurd doesn't use any services provided by the main Hurd. For example, if you already have a subhurd running at the time it happens, you can use that one to debug a deadlocked [[translator/ext2fs]] root file system in the *main* Hurd. For this, you need to get a handle to the main Hurd's [[ext2fs translator|translator/ext2fs]]'s [[PID]], but this is no problem, as currently [[PID]]s are visible across subhurd boundaries. (It is a [[!taglink open_issue_hurd]] whether this is the right thing to do in [[open_issues/virtualization]] contexts, but that's how it currently is.) ## Unit Testing freenode, #hurd channel, 2011-03-06: From [[open_issues/unit_testing]]. it could be interesting to have scripts that automatically start a sub-hurd to do the tests though that'd catch sub-hurd issues :) so a sub-hurd is a hurd that I can run on something that I know works(like linux)? Virtual machine I would think and over a network connection it would submit results back to the host :p * foocraft brain damage sub-hurd is a bit like chroot except that it's more complete oh okay i.e. almost everything gets replaced with what you want, except the micro-kernel that way you can even test the exec server for instance, without risks of damaging the host OS and we know the micro-kernel works correctly, right youpi? well, at least it's small enough that most bugs are not there 1) all tests run in subhurd 2) output results in a place in the subhurd 3) tester in the host checks the result and pretty-prints it 4) rinse & repeat the output can actually be redirected iirc since you give the sub-hurd a "console" youpi, yup yeah, so now it's more like chroot if that's the case it really looks like chroot, yes but again, there's this subset of tests that we need to have that ensures that even the tester running on the subhurd is valid, and it didn't break because of a bug in the subhurd As long as you do in-system testing, you'll always (have to) rely on some functionality provided by the host system. the worst thing that could happen with unit testing is false results that lead someone to try to fix something that isn't broken :p Yes. usually one tries to repeat the test by hand in a normal environment