IRC.

1 files changed, 173 insertions, 0 deletions

diff --git a/grub.mdwn b/grub.mdwn
index 8cbfcde7..0f7e968a 100644
--- a/grub.mdwn
+++ b/grub.mdwn
@@ -31,3 +31,176 @@ supports the multiboot standard, necessary to boot the Hurd.
         			'$(task-create)' '$(task-resume)'
             module /lib/ld.so.1 exec /hurd/exec '$(exec-task=task-create)'
         }
+
+
+# syslinux' `mboot.c32`
+
+## IRC, freenode, #hurd, 2014-02-08
+
+    <anonymuouss> hey I am runnign debian GNU/hurd , si sthe best release? I
+      would like to write a guide on multibooting, GNU/linux, NetBSD, and
+      GNU/Hurd from the same live OS image
+    <anonymuouss> I can basically handle all of the linux stuff, but native
+      booting NetBSD and , i am guessing Hurd, are going to be pretty hard
+    <anonymuouss> i want to focus on using syslinux's mboot.c32 module, though
+      i have no ttested, i think it will boot hurd just fine
+    <anonymuouss> as hurd is so firmly connected to multiboot specfication..
+    <anonymuouss> soem background history is that apparently there is something
+      wrong with FreeBSD multibooting
+    <anonymuouss> So it has spawned a huge amount of public testing regarding
+      dual booting iso9660 with GNU/linux and FreeBSD
+    <anonymuouss> come to find out NetBSD is actually the main group supporting
+      multiboot compliancy
+    <anonymuouss> bleh anyway, if you guys can help me will all of this, that
+      would be great. but either way, i wanted to gicve a long winded thanks
+    <anonymuouss> the main problem i am having is tell given kernel, that i
+      need it to load a ram based file system
+    <anonymuouss> with linux this is easy, just because i have used it so
+      much. i nkow how to attach a fileystem to the kernel, and embed a boot
+      command line
+    <youpi> anonymuouss: for the hurd case, you can have a  look at the debian
+      installer cd, it uses some sort of initrd
+    <anonymuouss> lol xorg works.. i was not expecting that!
+    <anonymuouss> youpi: thanks
+    <anonymuouss> yeah looking at the live distributions has been a mainstay , 
+    <anonymuouss> youpi: right, becasue debian will usually make their install
+      have an option to totally run in ram
+    <anonymuouss> they may have already fighured this out
+    <anonymuouss> I am impressed as hell with hurd kernel
+    <youpi> well, "they" is the same as "hurd maintainers", mostly :)
+    <anonymuouss> going to work picking around at this multiboot code a bit
+      later, looks the GNU doc on that is meant to be very educational
+    <anonymuouss> ok nice, so i verfied that hurd kernel is multiboot
+      compliant, and successfully loads with syslinux's mboot.c32
+
+
+## IRC, freenode, #hurd, 2014-02-09
+
+    <anonymuo1ss> I need to boot Hurd into ram off of iso9660 or vfat , or ext
+      using syslinux' mboot.c32 multiboot module. One of my reasons for
+      shoosing hurd kernel was multiboot compliancy to test this feature. So i
+      have aunique use case, of needing to load the hurd kernel an root
+      filesystem into memory. as using the root of the disk, is likeley
+      unsuitable. as with any live OS. I have acquired the components of the
+      debian install release. http://ftp.debian-po
+    <anonymuo1ss> what arguments can i pass to my multiboot "kernel"
+      "mboot.c32", in order to get this to boot to a simple example system (
+      full functionality is not required) 
+    <anonymuo1ss> Additionally i am willing to try putting hurd on the root
+      filsystem, but i would still like to boot it "natively" with the
+      mboot.c32 from syslinux. partially just to help expand documentation on
+      thier project
+    <anonymuo1ss> so i could use ext2 for the base i guess, if that would help
+    <braunr> anonymuo1ss: install debian hurd and look at the grub
+      configuration
+    <braunr> you'll have the command line arguments there
+    <braunr> use the preinstalled image in the topic to quickly boot one in a
+      virtual machine
+    <anonymuo1ss> that line is so long i am not sure it even will load with
+      systelinux
+    <anonymuo1ss> syslinux*
+    <anonymuo1ss> took me years to learn to boot linux to ram, no one helped
+    <anonymuo1ss> this is apparently is going to be more difficult, if i dont
+      get your guys help, i might be able to "install hurd" but i certainly
+      wont be able to use it or write about how to use it
+    <braunr> don't get it wrong but we're not very interested in making it boot
+      with syslinux
+    <anonymuo1ss> and multiboot code documentation is dwindling.. basically no
+      one gies a shit, not about syslinux, not about hurd, except for me. i
+      have read the same paragraphs from mailing lists 100s of times
+    <braunr> it works with grub, it complies with the mb spec
+    <anonymuo1ss> well look at how heavily it is depending on grub, i cant
+      reaally even pretend to understand how that works
+    <anonymuo1ss> and it is kind of obvious that you can not either
+    <braunr> no it's not
+    <braunr> i do
+    <anonymuo1ss> anyway , if you dont know how to help, it is ok
+    <braunr> i have implemented my own boot loader long ago
+    <braunr> and i have read about the boot scripts of gnu mach
+    <braunr> i know that part and i can help
+    <anonymuo1ss> i will just keep on doing all of this work on my own for fre,
+      with no bebefit and no help
+    <braunr> i won't fix the mboot code of syslinux for you though
+    <anonymuo1ss> well maybe sysylinux is the problem
+    <anonymuo1ss> it is sort of a toss up trying to decide who cares less abotu
+      this, hurd or syslinux
+    <braunr> noone cares
+    <anonymuo1ss> pretty even tie, for not giving a flying shit either way
+    <anonymuo1ss> obvious thumb down on the little guy
+    <anonymuo1ss> from both gnu and peter alvin
+    <braunr> i don't see syslinux as being something that was intended to
+      support anything else than linux in the first place
+    <anonymuo1ss> well that is where you are wrong
+    <braunr> no i'm not
+    <braunr> :)
+    <anonymuo1ss> obviously anything that has multiboot modules supports other
+      OS
+    <anonymuo1ss> lol
+    <anonymuo1ss> idiot
+    <braunr> if written right and well maintained
+    <braunr> and mboot support came very late in syslinux
+    <anonymuo1ss> seriosuly if you are brains behind this, i see why there are
+      no docs
+    <braunr> uh, you're the noob here, you're whining, and now you're insulting
+    <anonymuo1ss> no im no noob
+    <anonymuo1ss> im writing free guides to help people, and they are damn
+      concise
+    <braunr> if you weren't, you would understand how to adapt grub conf to
+      syslinux quickly
+    <anonymuo1ss> i have people making whole linux systems and frebsd is the
+      length of that damn grub line
+    <braunr> despite the "long line"s as you call them
+    <anonymuo1ss> lol
+    <braunr> the number of parameters is very short
+    <braunr> like 2 per module
+    <braunr> just copy them verbatim, what's hard with that ?
+    <antrik> anonymuouss: a followup remark regarding syslinux: does it really
+      have full multiboot support, including additional modules? or maybe it
+      only implements as much of the specification as necessary to load only
+      the kernel itself?
+    <anonymuouss> antrik: I wrote the syslinux mailing list this morning, with
+      details about some simple ways to download "ext2fs.static   gnumach.gz
+      initrd.gz  and  ld.so.1" from
+      http://ftp.debian-ports.org/debian-cd/hurd-i386/current/ and package them
+      to boot with the syslinux "mboot.c32" from iso9660. And showed them the
+      proper kernel and module configuration lines from the netinstall's
+      "grub.cfg". So I am hoping to get a reponse soon from Peter Alvin or G
+
+
+## IRC, freenode, #hurd, 2014-02-10
+
+    <anonymuouss> I am readin here in multiboot specifications,
+      http://www.gnu.org/software/grub/manual/multiboot/multiboot.html#Boot-modules
+      , that it is optional for designers of bootloaders to include this
+      ability to load modules. So I am guessing the syslinux devs made ample
+      use of that allowance. 
+    <anonymuouss> as you were suggesting. I will try to take the code apart and
+      read it some. But it is looking like maybe grub is the more stabke choice
+      for multibooting.
+    <anonymuouss> probably even a bit of magic with packaging hurd would make
+      it possible. but only 1 out of 10,000 people even know how to properly do
+      that with linux kernel main, so will take some time i guess
+    <anonymuouss> jus to quote, because the multiboot spec is written by
+      someone smarter than me " While these additional modules could be
+      embedded in the main OS image along with the kernel itself, and the
+      resulting image be split apart manually by the operating system when it
+      receives control"
+    <anonymuouss> I am guessing they are referring to some remote potential for
+      Hurd kernel to compiled that way, though i am merely speculating
+    <anonymuouss> So i am hunting down docs on doing this with Hurd. Who knows
+      maybe somethign fun and interesting will come of it
+    <antrik> anonymuouss: IIRC Hurd in Xen used one-file archieves initially
+      before pv-grub was operational. but the "ordinary" way to load the Hurd
+      is using modules, which I suspect is not implemented by syslinux...
+    <antrik> I don't think there is another system beside the Hurd using the
+      modules feature of multiboot. in fact, GRUB and the multiboot
+      specification were originally written for the Hurd...
+    <anonymuouss> I am hopeful about including the files (into the kernel) for
+      simplicities sake, as an experiemnet. And and in the meantime, continiung
+      to learn about grub's model for accomplishing this. Everythign is going
+      fine on my ned, I am working with a simple qemu install of debian
+      GNU/hurd. Hopefully will be compiling some kernels later tonight. thought
+      i may need to switch to reral hard ware for that 
+    <anonymuouss> thank you for the input antrik , I have not heard back from
+      syslinux devs yet, my guess is that they are thinking hard abotu how to
+      solve this, and dont want to "jump the gun"