summaryrefslogtreecommitdiff
path: root/hurd/running
diff options
context:
space:
mode:
Diffstat (limited to 'hurd/running')
-rw-r--r--hurd/running/chroot.mdwn2
-rw-r--r--hurd/running/debian.mdwn84
-rw-r--r--hurd/running/debian/dhcp.mdwn77
-rw-r--r--hurd/running/qemu.mdwn19
-rw-r--r--hurd/running/virtualbox.mdwn39
5 files changed, 217 insertions, 4 deletions
diff --git a/hurd/running/chroot.mdwn b/hurd/running/chroot.mdwn
index ea08ec48..38bab04e 100644
--- a/hurd/running/chroot.mdwn
+++ b/hurd/running/chroot.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013 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
diff --git a/hurd/running/debian.mdwn b/hurd/running/debian.mdwn
index 39c7d1a6..ac40ce79 100644
--- a/hurd/running/debian.mdwn
+++ b/hurd/running/debian.mdwn
@@ -22,3 +22,87 @@
*Debian GNU/Hurd*, [[MichaelBanck]], LinuxTag 2004 Karlsruhe
- [[Status]]
- [Archive Qualification](http://wiki.debian.org/ArchiveQualification/hurd-i386)
+
+
+# IRC, freenode, #hurd, 2014-01-18
+
+ <anatoly> From http://darnassus.sceen.net/~hurd-web/hurd/running/debian/
+ "Just in case you were wondering: the root password is root.". I think
+ it's not correct because it allows me to login witout password in hurd
+ console
+ <anatoly> Tried it in latest qemu image (from 2013 05 04)
+ <braunr> anatoly: you probably can change it yourself since it's a wiki
+ <anatoly> braunr: ok
+
+
+# `/etc/mtab` -> `/proc/mounts`
+
+## IRC, freenode, #hurd, 2014-02-12
+
+ <braunr> hm, there is something weird
+ <braunr> after successfully installing (with the new installer cd), and
+ rebooting, system init fails because fsck can't be run on /home (a
+ separate partition)
+ <braunr> it can't fsck because at that point, /home is already mounted, and
+ indeed the translator is running
+ <braunr> teythoon: any idea what might cause that ?
+ <teythoon> me ?
+ <teythoon> no
+ <braunr> ok
+ <braunr> ah no, actually /home isn't mounted oO
+ <braunr> but fsck still refuses to check it, stating that reason
+ <braunr> hm, /etc/mtab isn't a link to /proc/mounts here, might explain
+
+
+## IRC, freenode, #hurd, 2014-02-12
+
+ <braunr> yes, better with a proper symlink :)
+ <teythoon> good
+ <youpi> Mmm, what is supposed to create that symlink?
+ <teythoon> one debian init script did that at one time
+ <teythoon> i believe they dropped that
+ <youpi> err, but something must be creating it for newer systems
+ <teythoon> good point
+ <braunr> well, except for these small details, everything went pretty
+ smooth
+ <braunr> both on ide and ahci
+ <youpi> it seems /etc/mtab gets created at boot
+ <youpi> (on Linux I mean)
+ <teythoon> youpi: i cannot find the init script, but i'm sure that it was
+ there
+ <youpi> I can't find it either on the installed system...
+ <azeem> maybe pere or rleigh in #debian-hurd can help
+
+
+## IRC, freenode, #hurd, 2014-02-13
+
+ <braunr> 6<--60(pid1698)->dir_lookup ("var/run/mtab" 4194305 0) = 0 3
+ "/run/mtab" (null)
+ <braunr> looks like /etc/mtab isn't actually used anymore
+ <teythoon> it never was on hurd
+ <tomodach1> braunr: well it is generated i believe from mounted filesystems
+ <tomodach1> if its still around there is a reason for it, like posix
+ compatiblity perhaps?
+ <braunr> well the problem is that, as mentioned in pere's thread on
+ bug-hurd, some tools now expect /var/run/mtab instead of /etc/mtab
+ <braunr> and since nothing currently creates this file, these tools, such
+ as df, are lost
+ <braunr> they can't find the info they're looking for
+
+
+## IRC, freenode, #hurd, 2014-02-17
+
+ <braunr> i still don't have mtab at the proper location on darnassus
+ <pere> is there something missing with sysvinit on hurd?
+ <braunr> is that normal ?
+ <pere> yes. I recommended fixing it in the hurd package. (BTS #737759)
+ <braunr> yes i saw but was there any action taken ?
+ <pere> did not check
+ <teythoon> i thought youpi mentioned that it is fixed in the libc and we
+ just need to rebuild coreutils or something
+ <pere> yes
+ <braunr> oh ok
+ <braunr> but doesn't that mean it will use /etc/mtab ?
+ <pere> if I was a hurd porter, I would fix it in hurd while waiting for a
+ fix in coreutils, just to save people for wondering about the breakage,
+ but I am not the most patient of developers. :)
diff --git a/hurd/running/debian/dhcp.mdwn b/hurd/running/debian/dhcp.mdwn
index 849ff382..8846769a 100644
--- a/hurd/running/debian/dhcp.mdwn
+++ b/hurd/running/debian/dhcp.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation,
+[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -124,3 +124,78 @@ scripts, but has its own `/libexec/rc` script -- which integrates scripts from
in /dev/eth0)
<teythoon> I tried to rebuild the package served on debian-ports, but
that failed
+
+ IRC, freenode, #hurd, 2014-01-03:
+
+ <congzhang> dhcp 4.3 alpha released
+ <congzhang> and PATH_MAX issue was fixed
+
+ IRC, freenode, #hurd, 2014-01-21:
+
+ <gnu_srs> teythoon: what about this? *** stack smashing detected ***:
+ dhclient terminated
+ <teythoon> gnu_srs: well, dhclient dies
+ <teythoon> i've seen this, it comes and goes
+ <teythoon> not sure what happens, but i tend to blame it on our
+ custom-built dhcp package
+ <teythoon> from debian-ports, and it's outdated
+ <teythoon> it's most likely not your fault
+ <gnu_srs> i thought there was a new upstream by now
+ <teythoon> and the network configuration can be done with passive
+ translators as it was always done
+ <teythoon> there was ?
+ <gnu_srs> there is one recently released, haven't checked yet
+ <gnu_srs> in experimental: 4.3.0a1-2, does still not build out of the
+ box
+ <teythoon> there was, but it does not seem to build on the hurd
+ <teythoon>
+ https://buildd.debian.org/status/logs.php?pkg=isc-dhcp&arch=hurd-i386
+ <teythoon> the most recent version is from debian-ports
+
+
+ IRC, freenode, #hurd, 2014-01-24:
+
+ <braunr> stack smashing detected ***: dhclient terminated
+ <braunr> how nice
+ <tschwinge> braunr: dhclient:
+ http://news.gmane.org/find-root.php?message_id=%3C874ngfvwn4.fsf%40kepler.schwinge.homeip.net%3E
+ <tschwinge> braunr: And I thought, teythoon had found this to be a
+ buffer overflow; something like char dev[10], and for us the path to
+ the dev (/dev/eth0) was longer (but I may be misremebering).
+ <braunr> tschwinge: sounds reasonable
+ <tschwinge> braunr: By the way: I'm seeing this segfault all the time
+ during boot, but when I again run it manually (root login), it works
+ fine.
+ <braunr> tschwinge: you mean the dhclient one µ?
+ <tschwinge> Yes.
+ <braunr> mhm
+ <teythoon> braunr, tschwinge: i never found the cause of the dhclient
+ issue
+ <teythoon> i blame the (outdated) build on debian-ports
+
+
+ IRC, freenode, #hurd, 2014-01-30:
+
+ <youpi> err, still nobody found the dhclient bug?
+ <gnu_srs> youpi: You found the dh-client bug, right?
+ <youpi> gnu_srs: yes, the dhclient bug was in libc, as tschwinge
+ guessed
+ <youpi> I'll probably upload a fixed glibc on debian-ports
+
+ <gnu_srs> youpi: dhclient starts OK with libc 2.17-98~0
+
+ <youpi> btw, the experimental version of isc-dhcp has a newer
+ occurrence of PATH_MAX
+ <gnu_srs> :-(
+ <youpi> (aside from not including the needed debian files for
+ hurd-i386)
+
+ * IPv6
+
+ IRC, freenode, #hurd, 2014-02-23:
+
+ <gg0> seems dhclient can't also set ipv6 translator
+ <gg0> cheated by setting it manually, i had probably screwed it up
+ somehow
+ <gg0> exim was complaining 2014-02-23 22:26:41 IPv6 socket creation
+ failed: Address family not supported by protocol
diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn
index a0b9e6da..df65eb7b 100644
--- a/hurd/running/qemu.mdwn
+++ b/hurd/running/qemu.mdwn
@@ -1,5 +1,5 @@
[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012,
-2013 Free Software Foundation, Inc."]]
+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
@@ -275,6 +275,23 @@ but note that `ping` doesn't work with QEMU's user-networking stack.
If you want to connect from the host system to the Hurd system running in QEMU, you can use port forwarding in QEMU or to setup something more advanced, like bridged networking.
+
+### IRC, freenode, #hurd, 2014-02-12
+
+ <braunr> youpi: also, the problems i had with regard to accessing the
+ debian repository were caused by a qemu bug where, in nat mode, qemu is
+ unable to handle dns requests if the host dns servers are ipv6 ones
+ <youpi> yes, we've noticed that with a student of mine
+ <youpi> you may be interested by a patch we submitted to qemu-devel, that
+ adds ipv6 support to -net user :)
+ <braunr> :)
+ <braunr> for now i directly change resolv.conf
+ <youpi> braunr: the issue is that you have only ipv6 nameservers, right?
+ <braunr> yes
+ <youpi> there's not much better to do than that
+ <youpi> (patching resolv.conf inside the guest, or apply the ipv6 patch)
+
+
## Port Forwarding in QEMU
(In the following we assume we use kvm!)
diff --git a/hurd/running/virtualbox.mdwn b/hurd/running/virtualbox.mdwn
index 822f771d..23a0b156 100644
--- a/hurd/running/virtualbox.mdwn
+++ b/hurd/running/virtualbox.mdwn
@@ -40,7 +40,44 @@ To convert the image you need the VirtualBox package properly installed with a V
If [[QEMU with KVM|qemu]] is not available, VirtualBox reportedly has better
performance.
-IRC, freenode, #hurd, 2011-10-31:
+
+# Open Issues
+
+## IRC, freenode, #hurd, 2011-10-31
<youpi> I don't know what virtualbox does with hardware emulation, but
gnumach is awfully slow to probe things there
+
+
+## IRC, freenode, #hurd, 2013-09-28
+
+ <snadge> the problem is if i giveit more than 1855 it says truncating to
+ that
+ <snadge> so i give it that.. then it has kmem alloc error
+ <snadge> 1536mb same.. 1024 isok
+ <braunr> hum
+ <braunr> that's weird
+ <braunr> virtual box ?
+ <snadge> yeah
+ <snadge> i wonder what cpu features i should enable/disable
+ <snadge> pae ?
+ <braunr> make sure vbox doesn't count on the so called memory balloon
+ <braunr> pae isn't used except on xen
+ <braunr> disable apic
+ <braunr> enable host io cache in disk controllers
+ <youpi> do we have these written on the wiki?
+ <braunr> no because i didn't run into these problems
+ <braunr> but since i know the system well enough to avoid them in the first
+ place ..
+ <braunr> we need real users to report them
+ <braunr> i'm not sure we have anything about vbox in the wiki actually
+ <youpi> ./hurd/running/virtualbox.mdwn
+ <youpi> we seem to have a page at least
+ <snadge> it seems to be okay with 1024MiB
+ <braunr> still weird
+ <braunr> looks more random than buggy with more memory
+ <braunr> do you have the exact error message you got during your previous
+ attempts ?
+ <snadge> no.. i should have taken a screenshot.. its easy enough to
+ reproduce though
+ <snadge> i'll wait until after its installed