IRC channel logs

<rrq>yes. hmm the first boot log diff are that debian reports 3M more free pages, and different CHS ..

<youpi>I don't mean the kernel details :)

<youpi>I mean the module list

<youpi>about ext2fs.static and exec

<rrq>yes they are the same (except hd0s1)

<youpi>ok so no more idea from my side, would need more investigation

<rrq>no. hmm some diff...

<rrq>firstly that for debian, the program's are reported as "ext2fs" and "exec" while my reports "/hurd/ext2fs.static

<rrq>" and "/lib/ld.so.1" (then /hurd/exec)

<rrq>hmm and the "--kernel-task" parameter is removed from the module 0 loading output

<rrq>I mean it's removed in debian and not in my boot

<rrq>.. and debian also has --readonly added which my doesn't (it's supposedly the same servers.boot file)

<rrq>it is

<youpi>you probably got trapped by the first parameter of the module command

<youpi>in grub the first parameter just gives the name of the task, and not a parameter

<youpi>module /lib/ld.so.1 exec /hurd/exec

<youpi>means loading ld.so.1, calling the task exec, and giving it "/hurd/exec" as parameter

<youpi>(in grub)

<youpi>servers.boot is *not* used in multiboot booting

<youpi>and details *do* always matter

<rrq>yes I had copied servers.boot for module arguments... (sloppy)

<rrq>hmm no it stopped with "start /hurd/ext2fs.static:" ... like waiting for me to type somthing?

<rrq>but not taking input

<rrq>that's with the "module 0" boot line difference that my includes the $0 argument for both modules, and debian's doesn't.. and

<rrq>the "task loaded" line has the "/boot/gnumach-1.8-486.gz" bit included in the --command-line part

<rrq>(--multiboot-command-line=/boot/gnumach-1.8-486.gz console=com0 root=device:hd0s1)

<damo22>rrq: are you using a template from something that works?

<damo22>eg an existing hurd install

<rrq>yes, the filesystem is from debian's image, which boots up fine (same qemu setup)

<rrq>it looks to me like grub does things to the multiboot module arguments (that syslinux doesn't do)

<youpi>see what I said

<youpi>module /lib/ld.so.1 exec /hurd/exec

<youpi>means loading ld.so.1, calling the task exec, and giving it "/hurd/exec" as parameter

<youpi>you need to make sure syslinux does something like that

<youpi>exactly

<youpi>and make sure the replacement of vars etc. is behaving correctly

<youpi>possibly you need to escape $, { } and whatnot

<rrq>yes. it seems like syslinux offers $0 as module argument while grub removes that

<rrq>and that ${kernelcommand} is "demangled" similarly

<youpi>it's gnumach that does that latter thing

<youpi>but for that $ {} need to be kept as is, and not interpreted

<damo22>maybe syslinux does not do variable substitution

<youpi>gnumach is supposed to be doing it

<damo22>oh

<youpi>see all the other variables

<damo22>yeah you probably need to escape the $ and {}

<youpi>such as fs-task, root, and whatnot

<rrq>hmm the "module 0" lines look exctly the same except that my has "/hurd/ext2fs.static" first.. that would be a syslinux thing I guess?

<youpi>that should be fine

<youpi>syslinux is just taking the file instead of $0 for the task name

<rrq>then, yes, the grub line does include single-quotes which my doesn't, but when I give those to syslinux, they get shown in the "module 0" line

<youpi>possibly you need \ instead

<youpi>read syslinux' documentation about m ultiboot and escaping

<youpi>if it's not documented, reach for information from them

<rrq>the "module" arguments for grub starts "/hurd/ext2fs.static ext2fs --readonly" and apparently grub removes that $0 when presenting it to the module (?)

<youpi>yes

<youpi>it uses it as task name

<youpi>like I wrote above

<rrq>yes; the "module" arguments for syslinux are the same and in that case that $0 is shown

<rrq>so that part would be a difference between grub and syslinux

<youpi>I wouldn't be surprised so, Xen also is different from grub on that ponit

<rrq>perhaps I should drop the $1 argument ? (for both)

<youpi>you mean the $0 ?

<youpi>anyway, as I said, make sure to have the same module details

<youpi>only the very first part (which is just the task name) can be different

<youpi>the rest has to be the same

<youpi>otherwise you'd be departing from what is known to work

<rrq>the first need to be a pthnam that grub/extlinux understands I guess

<rrq>pathname

<youpi>a file nedes to be loaded of course

<rrq>so only $1 can be dropped

<youpi>ok, so we just didn't call $0 / $1 the same thing :)

<rrq>nope. dropping $1 is not right.. but the handling of quotes differs too btw grub/syslinux ... I might need to patch syslinux for that

<rrq>looks syslinux passes on the arguments verbatim, i.e. without worrying about quoting, whereas grub seems to use them (like sh)

<rrq>I patched mboot (syslinux' multiboot) to not include the filename, and now it progresses down to "/usr/libexec/console-run: /dev/console: Read-only file system"

<damo22>rrq: maybe fsck your fs offline

<rrq>done

<damo22>and?

<rrq>sorry. yes, no luck still...

<rrq>checking the filesystems, my ext2 has "Linux" as OS type while debian's ha "Hurd" .. but that can't make a difference?

<damo22>0x83/0x82

<damo22>for partition type

<rrq>0x83

<damo22>that is correc

<damo22>t

<rrq>and content-wise the filesystems are equal except for /boot and /etc/fstab

<rrq>(acording to "diff -r")

<damo22>i would check your root=

<damo22>maybe its sd0 or hd0

<damo22>it depends which controller the disk is attached to

<rrq>--multiboot-command-line=root=device:hd0s1 console=com0

<rrq>same qemu setup

<rrq>different raw disk images

<rrq>(of course)

<rrq>is it possible there's something else done by grub re console, that is not done by syslinux? otherwise I would have thought the pre-boot is irrelevant once the modules are started

<rrq>I noticed gnumach reporting an int(6) with debian's boot that is not happening with mine

<rrq>intnull(6)

<rrq>trying without the --readonly module argument it runs to the same spot but says "/usr/libexec/console-run: /dev/console: Not a terminal" instead

<youpi>rrq: you *do* need os as hurd in the ext2fs, otherwise translators will just not work

<youpi>again, details do matter

<rrq>yes. the filesystems are exactly the same, except for the /boot tree and /etc/fstab

<rrq>but ok; how do I set that?

<rrq>it's not offered by tune2fs it seems

<youpi>mke2fs-o hurd

<youpi>+

<rrq>so I can't change it on exisitng fs?

<rrq>(should be "Hurd" with uppercase "H" I guess)

<rrq>hmm apparently ext2/hurd has slightly different inodes from linux... so maybe it's not just to change that.. lookss like the variants are linux(0), hurd(1) or masix(2) (?)

<rrq>does my linux write files nicely into a hurd ext2fs ?

<rrq>this kind of incompatibility was a little deeper than I had expected. Obviously I've skimmed doc's too fast.

<rrq>ore there more things of significance with teh filesystem? like "Inodes per group", "Inode blocks per group" etc?

<rrq>(I'll see when testing it I suppose :)

<rrq>right. same point & problem

<rrq>my disk image has CHS=700/128/63 (default from mke2fs) vs debian image has CHS=637/255/63 ... surely can't be important(?)

<rrq>my boot still lacks "intnull(6)"

<rrq>I rsynced (on linux) from debian's image part 2 mounted to my image part 1 mounted, then replaced /boot and /etc/fstab... presumably that rsync or the mounting fails to preserve the extra inode bits from the hurd-ext2fs onto the new hurd2-ext2fs ... how could I tell?

<rrq>at a guess it would promaril concerne /dev/console (well, /dev pathnams in particular) (?)

<rrq>primarily

<youpi>there are the translator records, that linux doesn't know about at all

<youpi>really you should just use the same image

<youpi>to actually reduce the difference to the syslinux question

<rrq>thanks. yes when replacing /boot to my tree, adjusting to use hd0s2, plus the usual extlinux boot fiddling, it boots nicely ... which at least means my previous problem is not syslinux vs grub, but either seem deep-down sensitivity in ext2fs setup, or perhaps possibly that the code has some got the partition index compiled into something

<rrq>seem => some

<rrq>as a test, I split the swap so that the rootfs is at hd0s3 ... and it sill boots nicely

<rrq>hmm "stat" say "Device: 7,0" for /dev/console on working fs, and "7,16" on the broken (rsync copy). seems the /dev/* inodes are used differently in significant ways

<rrq>how do I mount a second disk (hd1)? fdisk is quite unhappy with "hd1: dma_intr: status=0x41 { DriveReady Error }"

<rrq>(user error)

<rrq>is there a program for me to make a /dev/console "dev node" ? (mknod doesn't seem to be right)

<youpi>/dev/MAKEDEV

<rrq>hmm tried "/sbin/MAKEDEV console" (on second disk) and stat says "Device: 350h/848d" rather than "Device: 9h/9d" (which is /dev/console)

<rrq>(this is all within hurd)

<rrq>(with hurd)

<youpi>the device numbers don't actually matter

<youpi>what matters is the passive translator set up on it

<youpi>showtrans /dev/console

<rrq>ok; shows same /dev/console and /mnt/dev/console ... hmm maybe I need to run MAKEDEV on all /mnt/dev/* to prepare those for separate boot ? i.e. copying doesn't work

<youpi>cp doesn't know about translators

<youpi>better chroot into your chroot and run dpkg-reconfigure hurd

<youpi>to re-setup translators

<rrq>hmm but I can't unmount it now

<rrq>it's a qemu VM where I added my disk to the working system

<youpi>4

<youpi>EWIN

<rrq>I'm getting convinced I need to study it all a bit more... thanks for your help!

<natsukao>hello at all

IRC channel logs

2023-12-04.log