Re: Some progress, Guix rumpdisk still crashes...
Svante Signell writes: Hi! > On Wed, 2023-05-17 at 20:24 +0200, Janneke Nieuwenhuizen wrote: >> rumpdisk still crashes, but the good news (I guess) is that it seems to [..] > I use for hurdX (hurd-cross): > qemu-system-x86_64 -chardev stdio,id=char0,logfile=serial.log,signal=off > -serial > chardev:char0 -m 2048 -enable-kvm -drive file=hurd-cross-serial.img > And added to /boot/grub/grub.cfg: > set serial --speed=9600 --unit=0 --word=8 --parity=no --stop=1 > set terminal_input serial > set terminal_output serial > set timeout=5 Thanks, but rumpdisk now boots, see https://lists.gnu.org/archive/html/bug-hurd/2023-05//msg00331.html (it's not being used yet, we're working on that ;-) Greetings, Janneke -- Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Re: Some progress, Guix rumpdisk still crashes...
On Wed, 2023-05-17 at 20:24 +0200, Janneke Nieuwenhuizen wrote: > Hi! > > With this newly patched glibc > > https://gitlab.com/janneke/guix/-/tree/wip-hurd12 > > rumpdisk still crashes, but the good news (I guess) is that it seems to > get somewhat further, or at least it crashes differently. Here are the > last 24 (WTF, 1980 wants their screensize back!?) lines (I don't know > how to get the full log from QEMU): I use for hurdX (hurd-cross): qemu-system-x86_64 -chardev stdio,id=char0,logfile=serial.log,signal=off -serial chardev:char0 -m 2048 -enable-kvm -drive file=hurd-cross-serial.img And added to /boot/grub/grub.cfg: set serial --speed=9600 --unit=0 --word=8 --parity=no --stop=1 set terminal_input serial set terminal_output serial set timeout=5
Booted Debian with noide => rumpdisk! [WAS Re: Guix hurd with rumpdisk boots! [WAS Re: Some progress, Guix rumpdisk still crashes...]]
Janneke Nieuwenhuizen writes: > Sergey Bugaev writes: > >> On Fri, May 19, 2023 at 1:20 PM Janneke Nieuwenhuizen >> wrote: [..] >> Using rumpdisk on Debian should be a matter of changing >> part:1:device:hd0 to part:1:device:wd0 (why part:2?), and adding >> noide. (Unless I'm misremembering, of course, and note I'm not at all >> qualified to talk about any of this). > > Hmm, the image above already has wd0 (part:2:device:wd0)...but it does > not use rump, now it really gets confusing... Okay, so rumpdisk "just works"(TM) on latest Debian. After discussing on IRC https://logs.guix.gnu.org/hurd/2023-05-18.log#091300 using https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd-20220824.img I upgraded to lastest greatest: --8<---cut here---start->8--- wget http://ftp.de.debian.org/debian/pool/main/d/debian-ports-archive-keyring/debian-ports-archive-keyring_2023.02.01_all.deb dpkg -i debian-ports-archive-keyring_2023.02.01_all.deb apt-get update apt-get dist-upgrade --8<---cut here---end--->8--- changed /boot/grub/grub.cfg --8<---cut here---start->8--- # multiboot /boot/gnumach-1.8-486.gz root=part:2:device:hd0 console=com0 multiboot /boot/gnumach-1.8-486.gz root=part:2:device:wd0 console=com0 noide --8<---cut here---end--->8--- and /etc/fstab --8<---cut here---start->8--- #/dev/hd0s2 / ext2defaults0 1 /dev/wd0s2 / ext2defaults0 1 #/dev/hd0s1 noneswapsw 0 0 /dev/wd0s1 noneswapsw 0 0 #/dev/hd2/media/cdrom0 iso9660 noauto 0 0 /dev/wd2/media/cdrom0 iso9660 noauto 0 0 --8<---cut here---end--->8--- I got: Checking root file system.../dev/wd0s2: clean, 42057/259072 files, 416312/1035776 blocks full log attached. Now to replicate this on Guix...I already notice that this setup uses acpi, which is broken an has been disabled in the latest rumpkernel build... Thanks for all the help! Greetings, Janneke upgraded-noide.log Description: Binary data -- Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Re: Guix hurd with rumpdisk boots! [WAS Re: Some progress, Guix rumpdisk still crashes...]
Sergey Bugaev writes:
> On Fri, May 19, 2023 at 1:20 PM Janneke Nieuwenhuizen wrote:
>> Okay, yeah I tried
>>
[..]
> See, it's only seeing a single bootstrap module, treating
> hurd/exec.static and the rest as just further arguments to
> hurd/ext2fs.static. I believe you have to separate modules with a
> comma -- see how I've done it in my previous letter. Here's what man
> qemu says:
>
> -initrd "file1 arg=foo,file2"
> This syntax is only available with multiboot. Use file1 and file2 as
> modules and pass arg=foo as parameter to the first module.
Oops, yes I missed that. New try:
--8<---cut here---start->8---
guix shell qemu -- qemu-system-i386 \
-m 4096 \
--enable-kvm \
--device rtl8139,netdev=net0 \
--netdev user,id=net0,hostfwd=tcp:0.0.0.0:11022-: \
--snapshot \
--no-reboot \
--device virtio-serial-pci \
--nographic \
--serial mon:stdio \
--hda debian-hurd-20220824.img \
--kernel gnumach-1.8-486 \
--append "root=part:2:device:wd0 console=com0" \
--initrd "hurd/ext2fs.static ex2fs \
--multiboot-command-line='\${kernel-command-line}' \
--host-priv-port='\${host-port}' \
--device-master-port='\${device-port}' \
--exec-server-task='\${exec-task}' \
--store-type=typed \
--x-xattr-translator-records \
'\${root}' \
'\$(task-create)' \
'\$(task-resume)' \
,hurd/exec.static exec \
'\$(exec-task=task-create)'"
--8<---cut here---end--->8---
gives
--8<---cut here---start->8---
module 0: hurd/ext2fs.static ex2fs
--multiboot-command-line='${kernel-command-line}'
--host-priv-port='${host-port}' --device-master-port='${device-port}'
--exec-server-task='${exec-task}' --store-type=typed
--x-xattr-translator-records '${root}' '$(task-create)' '$(task-resume)'
module 1: hurd/exec.static exec '$(exec-task=task-create)'
2 multiboot modules
[hang]
--8<---cut here---end--->8---
>> When I use noide with
>>
>> http://cdimage.debian.org/cdimage/ports/latest/hurd-i386/
>> debian-hurd-20220824.img
>>
>> like so
>>
>> multiboot /boot/gnumach-1.8-486.gz root=part:2:device:wd0 console=com0
>> noide
>>
>> I get
>>
>> ext2fs: part:2:device:wd0: No such device or address
>
> Wait, no, don't try that with an installer image (that's what
> "cdimage" is, right?).
No, it's not a cdimage (the name of the url is fu), this is a
pre-installed qemu qcow image. The README says
To give Debian GNU/Hurd a try, it is probably easier to simply run the
preinstalled image, which is provided here: [...]
so using this instead of installing something myself ensures we are
looking an the same thing. Is there any newer image that I could try?
> Install it properly first and boot the installed system. The
> installation image, as I understand from Samuel's explanations, does
> not actually access the drive/cdrom, it's located on a ramdisk that is
> loaded into RAM by GRUB.
Yeah, so what I've tried should really work, right?
>> see full log attached. The root (disk) is already in the format that
>> rump expects, rigth?
>
> Not that I know anything about rump, but my understanding is it does
> not care about the format, it's ext2fs that does. rumpdisk simply
> exposes the device.
Ah, that makes sense, right.
>> Is there anything else I'd need to do; I would
>> like to get this to work on Debian first!
>
> Using rumpdisk on Debian should be a matter of changing
> part:1:device:hd0 to part:1:device:wd0 (why part:2?), and adding
> noide. (Unless I'm misremembering, of course, and note I'm not at all
> qualified to talk about any of this).
Hmm, the image above already has wd0 (part:2:device:wd0)...but it does
not use rump, now it really gets confusing...
Greetings,
Janneke
--
Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Re: Guix hurd with rumpdisk boots! [WAS Re: Some progress, Guix rumpdisk still crashes...]
On Fri, May 19, 2023 at 1:20 PM Janneke Nieuwenhuizen wrote:
> Okay, yeah I tried
>
> --8<---cut here---start->8---
> guix shell qemu -- qemu-system-i386 \
> -m 4096 \
> --enable-kvm\
> --device rtl8139,netdev=net0\
> --netdev user,id=net0,hostfwd=tcp:0.0.0.0:11022-: \
> --snapshot \
> --no-reboot \
> --device virtio-serial-pci \
> --nographic \
> --serial mon:stdio \
> --hda debian-hurd-20220824.img \
> --kernel gnumach-1.8-486\
> --append "root=part:2:device:wd0 console=com0" \
> --initrd "hurd/ext2fs.static ex2fs \
> --multiboot-command-line='\${kernel-command-line}' \
> --host-priv-port='\${host-port}' \
> --device-master-port='\${device-port}' \
> --exec-server-task='\${exec-task}' \
> --store-type=typed \
> --x-xattr-translator-records \
> '\${root}' \
> '\$(task-create)' \
> '\$(task-resume)' \
> hurd/exec.static exec \
> '\$(exec-task=task-create)'"
> --8<---cut here---end--->8---
>
> but that stops here
>
> --8<---cut here---start->8---
> module 0: hurd/ext2fs.static ex2fs
> --multiboot-command-line='${kernel-command-line}'
> --host-priv-port='${host-port}'
> --device-master-port='${device-port}'
> --exec-server-task='${exec-task}' --store-type=typed
> --x-xattr-translator-records
>'${root}'
> '$(task-create)' '$(task-resume)'
> hurd/exec.static exec
> '$(exec-task=task-create)'
> 1 multiboot modules
> --8<---cut here---end--->8---
See, it's only seeing a single bootstrap module, treating
hurd/exec.static and the rest as just further arguments to
hurd/ext2fs.static. I believe you have to separate modules with a
comma -- see how I've done it in my previous letter. Here's what man
qemu says:
-initrd "file1 arg=foo,file2"
This syntax is only available with multiboot. Use file1 and file2 as
modules and pass arg=foo as parameter to the first module.
> When I use noide with
>
>
> http://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd-20220824.img
>
> like so
>
> multiboot /boot/gnumach-1.8-486.gz root=part:2:device:wd0 console=com0
> noide
>
> I get
>
> ext2fs: part:2:device:wd0: No such device or address
Wait, no, don't try that with an installer image (that's what
"cdimage" is, right?). Install it properly first and boot the
installed system. The installation image, as I understand from
Samuel's explanations, does not actually access the drive/cdrom, it's
located on a ramdisk that is loaded into RAM by GRUB.
> see full log attached. The root (disk) is already in the format that
> rump expects, rigth?
Not that I know anything about rump, but my understanding is it does
not care about the format, it's ext2fs that does. rumpdisk simply
exposes the device.
> Is there anything else I'd need to do; I would
> like to get this to work on Debian first!
Using rumpdisk on Debian should be a matter of changing
part:1:device:hd0 to part:1:device:wd0 (why part:2?), and adding
noide. (Unless I'm misremembering, of course, and note I'm not at all
qualified to talk about any of this).
Sergey
Re: Guix hurd with rumpdisk boots! [WAS Re: Some progress, Guix rumpdisk still crashes...]
Sergey Bugaev writes:
Hi!
> On Thu, May 18, 2023 at 11:07 AM Janneke Nieuwenhuizen
> wrote:
>> Now that was really a great help, thanks!
>>
>> Ah, I had no idea; this is so helpful. Maybe a good idea to have this
>> on the website/wiki, right?
>
> Glad I was able to help :D
>
>> Is there a way to pass the "console=com0" argument from the QEMU command
>> line? That would be nice!
>
> I don't think you can alter the GRUB script from QEMU cmdline, but
> note that on 32-bit x86 (i?86) you don't even technically need GRUB:
> QEMU itself can act as a multiboot bootloader. Something like the
> following should work:
>
> $ qemu-system-x86_64 -other-args -kernel /path/to/gnumach -append
> "console=com0 other kernel args" -initrd "/path/to/pci-arbiter.static
> pci-arbiter args,/path/to/rumpdisk.static rumpdisk
> args,/path/to/ext2fs.static ext2fs args"
>
> (but I've only tried that with a single bootstrap task).
Okay, yeah I tried
--8<---cut here---start->8---
guix shell qemu -- qemu-system-i386 \
-m 4096 \
--enable-kvm\
--device rtl8139,netdev=net0\
--netdev user,id=net0,hostfwd=tcp:0.0.0.0:11022-: \
--snapshot \
--no-reboot \
--device virtio-serial-pci \
--nographic \
--serial mon:stdio \
--hda debian-hurd-20220824.img \
--kernel gnumach-1.8-486\
--append "root=part:2:device:wd0 console=com0" \
--initrd "hurd/ext2fs.static ex2fs \
--multiboot-command-line='\${kernel-command-line}' \
--host-priv-port='\${host-port}' \
--device-master-port='\${device-port}' \
--exec-server-task='\${exec-task}' \
--store-type=typed \
--x-xattr-translator-records \
'\${root}' \
'\$(task-create)' \
'\$(task-resume)' \
hurd/exec.static exec \
'\$(exec-task=task-create)'"
--8<---cut here---end--->8---
but that stops here
--8<---cut here---start->8---
module 0: hurd/ext2fs.static ex2fs
--multiboot-command-line='${kernel-command-line}'
--host-priv-port='${host-port}'
--device-master-port='${device-port}'
--exec-server-task='${exec-task}' --store-type=typed
--x-xattr-translator-records
'${root}' '$(task-create)'
'$(task-resume)'
hurd/exec.static exec
'$(exec-task=task-create)'
1 multiboot modules
--8<---cut here---end--->8---
>> Just for fun, find the succesful log attached.
>
> But that... does not look like rumpdisk actually gets used? The
> in-kernel IDE drivers are enabled, as you can see here:
Ah, uh oh...
> pass "noide" on gnumach cmdline to disable them, or just compile them
> out. I don't see it in your rumpdisk output, but when run this way it
> typically discovers that the kernel is already driving IDE, and does
> nothing.
Okay, make sense.
> Then you're passing "hd0s1" to ext2fs as the device to open; that's
> again a reference to the Mach-implemented device (and partition). The
> rumpdisk drive is named 'wd0', and you also have to do partitions
> libstore-side, so: root=part:1:device:wd0
Thanks.
When I use noide with
http://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd-20220824.img
like so
multiboot /boot/gnumach-1.8-486.gz root=part:2:device:wd0 console=com0 noide
I get
ext2fs: part:2:device:wd0: No such device or address
see full log attached. The root (disk) is already in the format that
rump expects, rigth? Is there anything else I'd need to do; I would
like to get this to work on Debian first!
Greetings,
Janneke
noide.log
Description: Binary data
--
Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Re: Guix hurd with rumpdisk boots! [WAS Re: Some progress, Guix rumpdisk still crashes...]
Joshua Branson writes: > Janneke Nieuwenhuizen writes: > >> Sergey Bugaev writes: >> >> Hello Sergey, >> >>> On Wed, May 17, 2023 at 9:25 PM Janneke Nieuwenhuizen >>> wrote: >> >>> I've recently been doing this kind of debugging early boot-up process >>> *a lot*, so maybe I could provide some tips indeed. For getting more >>> lines of output, try console=com0 on gnumach cmdline, and run qemu >>> with -nographic -serial stdio or something like that. >> >>> Other than that, just attach gdb and see what it crashes on? Like this: >>> >>> $ gdb /path/to/gnumach >>> (gdb) tar rem :1234 >>> (gdb) b i386_exception >>> (gdb) b task_terminate >>> (gdb) b Panic >>> (gdb) add-symbol-file /path/to/rumpdisk.static >>> blah-blah (y/n?) y >>> (gdb) c >> >> [..] >> >> Ah, I had no idea; this is so helpful. Maybe a good idea to have this >> on the website/wiki, right? > > Yes it will be. I will send a patch for it soon. Adding it for my todo > list. Actually where should I add this on the wiki? I think Samuel put some Possibly here: open_issues/debugging_gnumach_startup_qemu_gdb.html > >> >> Greetings, >> Janneke -- Joshua Branson Sent from the Hurd
Re: Guix hurd with rumpdisk boots! [WAS Re: Some progress, Guix rumpdisk still crashes...]
Janneke Nieuwenhuizen writes: > Sergey Bugaev writes: > > Hello Sergey, > >> On Wed, May 17, 2023 at 9:25 PM Janneke Nieuwenhuizen >> wrote: > >> I've recently been doing this kind of debugging early boot-up process >> *a lot*, so maybe I could provide some tips indeed. For getting more >> lines of output, try console=com0 on gnumach cmdline, and run qemu >> with -nographic -serial stdio or something like that. > > Now that was really a great help, thanks! It helped me (e)diff many > different qemu runs: plain debian, debian+guix/pci-arbiter, > debian+guix/pci-arbiter+guix/rumpdisk, plain guix, > guix+debian/pci-arbiter, guix+debian/pci-arbiter+debian/rumpdisk... > > It was immediately obvious that the messages from rumpdisk were (nearly) > identical. As the boot went silent at the end I assumed a crash or a > hang in rumpdisk. After inspecting the diffs and seeing nothing really > different, I noticed that I used -m 4096 for debian and -m 1024 for guix > on the qemu command line. Do'h, turns out rumpdisk needs at least > 1200MB... > > With > > https://gitlab.com/janneke/guix/-/tree/wip-hurd > > I've now succesfully been doing > > --8<---cut here---start->8--- > ./pre-inst-env guix system image -t hurd-raw > gnu/system/examples/bare-hurd.tmpl > cp /gnu/store/r5dpblnfsj08jh3hdmn8s6l9xaczwn65-disk-image guix.img > sudo losetup -o $((512*2048)) /dev/loop0 guix.img > sudo mount /dev/loop0 /mnt > edit /mnt/boot/grub/grub.cfg, adding console=com0 > sudo umount /mnt > --8<---cut here---end--->8--- > > > and then > > --8<---cut here---start->8--- > guix shell qemu -- qemu-system-i386 \ > -m 4096 \ > --enable-kvm\ > --device rtl8139,netdev=net0\ > --netdev user,id=net0,hostfwd=tcp:0.0.0.0:11022-: \ > --snapshot \ > --no-reboot \ > --device virtio-serial-pci \ > --nographic \ > --serial mon:stdio \ > --hda r5dpblnfsj08jh3hdmn8s6l9xaczwn65-disk-image+CONSOLE=COM0 > --8<---cut here---end--->8--- > > Just for fun, find the succesful log attached. > > Is there a way to pass the "console=com0" argument from the QEMU command > line? That would be nice! > >> Other than that, just attach gdb and see what it crashes on? Like this: >> >> $ gdb /path/to/gnumach >> (gdb) tar rem :1234 >> (gdb) b i386_exception >> (gdb) b task_terminate >> (gdb) b Panic >> (gdb) add-symbol-file /path/to/rumpdisk.static >> blah-blah (y/n?) y >> (gdb) c > > [..] > > Ah, I had no idea; this is so helpful. Maybe a good idea to have this > on the website/wiki, right? Yes it will be. I will send a patch for it soon. Adding it for my todo list. > > Greetings, > Janneke -- Joshua Branson Sent from the Hurd
Re: Guix hurd with rumpdisk boots! [WAS Re: Some progress, Guix rumpdisk still crashes...]
On Thu, May 18, 2023 at 11:07 AM Janneke Nieuwenhuizen wrote: > Now that was really a great help, thanks! > > Ah, I had no idea; this is so helpful. Maybe a good idea to have this > on the website/wiki, right? Glad I was able to help :D > Is there a way to pass the "console=com0" argument from the QEMU command > line? That would be nice! I don't think you can alter the GRUB script from QEMU cmdline, but note that on 32-bit x86 (i?86) you don't even technically need GRUB: QEMU itself can act as a multiboot bootloader. Something like the following should work: $ qemu-system-x86_64 -other-args -kernel /path/to/gnumach -append "console=com0 other kernel args" -initrd "/path/to/pci-arbiter.static pci-arbiter args,/path/to/rumpdisk.static rumpdisk args,/path/to/ext2fs.static ext2fs args" (but I've only tried that with a single bootstrap task). > Just for fun, find the succesful log attached. But that... does not look like rumpdisk actually gets used? The in-kernel IDE drivers are enabled, as you can see here: > ide: Intel 82371 PIIX3 (dual FIFO) DMA Bus Mastering IDE > Controller on PCI bus 0 function 9 > ide: BM-DMA feature is not enabled (BIOS), enabling > ide0: BM-DMA at 0xc140-0xc147 > ide1: BM-DMA at 0xc148-0xc14f > hd0: got CHS=677/64/63 CTL=c8 from BIOS > intnull(14) > hd0: QEMU HARDDISK, 1333MB w/256kB Cache, CHS=677/64/63 > intnull(15) > hd2: QEMU DVD-ROM, ATAPI CDROM drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > ide1 at 0x170-0x177,0x376 on irq 15 pass "noide" on gnumach cmdline to disable them, or just compile them out. I don't see it in your rumpdisk output, but when run this way it typically discovers that the kernel is already driving IDE, and does nothing. Then you're passing "hd0s1" to ext2fs as the device to open; that's again a reference to the Mach-implemented device (and partition). The rumpdisk drive is named 'wd0', and you also have to do partitions libstore-side, so: root=part:1:device:wd0 Sergey
Guix hurd with rumpdisk boots! [WAS Re: Some progress, Guix rumpdisk still crashes...]
Sergey Bugaev writes: Hello Sergey, > On Wed, May 17, 2023 at 9:25 PM Janneke Nieuwenhuizen wrote: > I've recently been doing this kind of debugging early boot-up process > *a lot*, so maybe I could provide some tips indeed. For getting more > lines of output, try console=com0 on gnumach cmdline, and run qemu > with -nographic -serial stdio or something like that. Now that was really a great help, thanks! It helped me (e)diff many different qemu runs: plain debian, debian+guix/pci-arbiter, debian+guix/pci-arbiter+guix/rumpdisk, plain guix, guix+debian/pci-arbiter, guix+debian/pci-arbiter+debian/rumpdisk... It was immediately obvious that the messages from rumpdisk were (nearly) identical. As the boot went silent at the end I assumed a crash or a hang in rumpdisk. After inspecting the diffs and seeing nothing really different, I noticed that I used -m 4096 for debian and -m 1024 for guix on the qemu command line. Do'h, turns out rumpdisk needs at least 1200MB... With https://gitlab.com/janneke/guix/-/tree/wip-hurd I've now succesfully been doing --8<---cut here---start->8--- ./pre-inst-env guix system image -t hurd-raw gnu/system/examples/bare-hurd.tmpl cp /gnu/store/r5dpblnfsj08jh3hdmn8s6l9xaczwn65-disk-image guix.img sudo losetup -o $((512*2048)) /dev/loop0 guix.img sudo mount /dev/loop0 /mnt edit /mnt/boot/grub/grub.cfg, adding console=com0 sudo umount /mnt --8<---cut here---end--->8--- and then --8<---cut here---start->8--- guix shell qemu -- qemu-system-i386 \ -m 4096 \ --enable-kvm\ --device rtl8139,netdev=net0\ --netdev user,id=net0,hostfwd=tcp:0.0.0.0:11022-: \ --snapshot \ --no-reboot \ --device virtio-serial-pci \ --nographic \ --serial mon:stdio \ --hda r5dpblnfsj08jh3hdmn8s6l9xaczwn65-disk-image+CONSOLE=COM0 --8<---cut here---end--->8--- Just for fun, find the succesful log attached. Is there a way to pass the "console=com0" argument from the QEMU command line? That would be nice! > Other than that, just attach gdb and see what it crashes on? Like this: > > $ gdb /path/to/gnumach > (gdb) tar rem :1234 > (gdb) b i386_exception > (gdb) b task_terminate > (gdb) b Panic > (gdb) add-symbol-file /path/to/rumpdisk.static > blah-blah (y/n?) y > (gdb) c [..] Ah, I had no idea; this is so helpful. Maybe a good idea to have this on the website/wiki, right? Greetings, Janneke guix-glibc.log Description: Binary data -- Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Re: Some progress, Guix rumpdisk still crashes...
Janneke Nieuwenhuizen, le jeu. 18 mai 2023 09:48:11 +0200, a ecrit: > > Try '-M q35' passed to qemu as this will use a newer chipset emulation > > that includes AHCI controller by default. Im not sure if IDE is > > working at this point. > > As this was by far the easiest change, I tried this first. It turns out > that even my debian image (debian-hurd-20220824.img) doesn't boot for me > using this flag (see log below). part:2:device:hd0: No such device or address With AHCI your disk is called sd0, not hd0. Samuel
Re: Some progress, Guix rumpdisk still crashes...
Damien Zammit writes: Hi Damien, > Try '-M q35' passed to qemu as this will use a newer chipset emulation > that includes AHCI controller by default. Im not sure if IDE is > working at this point. As this was by far the easiest change, I tried this first. It turns out that even my debian image (debian-hurd-20220824.img) doesn't boot for me using this flag (see log below). Greetings, Janneke -M_q35.log Description: Binary data -- Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Re: Some progress, Guix rumpdisk still crashes...
IDE is working, this is what I use every time I'm on hurd. It's just a bit slower because it can't use DMA (except if you patch gnumach: vm_allocate_contiguous to allow palign to be greater than page size but still multiple of it) Le jeu. 18 mai 2023 à 01:35, Damien Zammit a écrit : > Try '-M q35' passed to qemu as this will use a newer chipset emulation > that includes AHCI controller by default. Im not sure if IDE is working at > this point. > > Damien > > > Sent from ProtonMail mobile > > > > Original Message > On 18 May 2023, 4:24 am, Janneke Nieuwenhuizen < jann...@gnu.org> wrote: > > > Hi! > > So, Guix's glibc-2.35 has patches for centiseconds and monotonic (and > others) that were forward ported since glibc 2.31, instead of refreshed > from upstream Debian Salsa: > > > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/glibc-hurd-clock_gettime_monotonic.patch > > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/glibc-hurd-clock_t_centiseconds.patch > > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/glibc-hurd-gettyent.patch > > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/glibc-hurd-mach-print.patch > > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/glibc-hurd-signal-sa-siginfo.patch > > As discussed on IRC, I reverted > > glibc-hurd-clock_gettime_monotonic.patch > glibc-hurd-clock_t_centiseconds.patch > > and applied > > > https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/hurd-i386/local-clock_gettime_MONOTONIC.diff > > https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/hurd-i386/unsubmitted-clock_t_centiseconds.diff > > I disregarded/kept the others as they were (gettyent, mach-print, > signal-sa-siginfo). > > With this newly patched glibc > > https://gitlab.com/janneke/guix/-/tree/wip-hurd12 > > rumpdisk still crashes, but the good news (I guess) is that it seems to > get somewhat further, or at least it crashes differently. Here are the > last 24 (WTF, 1980 wants their screensize back!?) lines (I don't know > how to get the full log from QEMU): > > --8<---cut here---start->8--- > [..] ??? how to capture these? using --display curses > [ 1.040] timecounter: Timecounter "clockinterrupt" frequency 100 Hz > qualit > y 0 > [ 1.050] cpu0 at thinair0: rump virtual cpu > [ 1.050] entropy: WARNING: extracting entropy too early > [ 1.0200050] root file system type: rumpfs > [ 1.0200050] kern.module.path=/stand/i386/9.99.88/modules > [ 1.0200050] mainbus0 (root) > [ 1.0200050] pci0 at mainbus0 bus 0 > [ 1.0200050] pci0: i/o space, memory space enabled, rd/line, rd/mult, > wr/inv o > k > [ 1.0200050] vendor 8086 product 1237 (host bridge, revision 0x02) at pci0 > dev > 0 function 0 not configured > [ 1.0200050] vendor 8086 product 7000 (ISA bridge) at pci0 dev 1 function > 0 no > t configured > [ 1.0200050] vendor 8086 product 7010 (IDE mass storage, interface 0x80) > at pc > i0 dev 1 function 1 not configured > [ 1.0200050] vendor 8086 product 7113 (miscellaneous bridge, revision > 0x03) at > pci0 dev 1 function 3 not configured > [ 1.0200050] vendor 1234 product (VGA display, revision 0x02) at pci0 > dev > 2 function 0 not configured > [ 1.0200050] vendor 10ec product 8139 (ethernet network, revision 0x20) at > pci > 0 dev 3 function 0 not configured > [ 1.350] blake2s: self-test passed > [ 1.350] chacha: Portable C ChaCha > --8<---cut here---end--->8--- > > I'm aware that > > > https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/hurd-i386 > > has an odd 50 patches that we are not using in Guix...Also, we're using > a much newer rumpkernel source (latest), so it could be anything... > > Again, any help or insights higly appreciated! > > Greetings, > Janneke > > -- > Janneke Nieuwenhuizen | GNU LilyPond > https://LilyPond.org > Freelance IT https://www.JoyOfSource.com | Avatar® > https://AvatarAcademy.com > >
Re: Some progress, Guix rumpdisk still crashes...
Try '-M q35' passed to qemu as this will use a newer chipset emulation that includes AHCI controller by default. Im not sure if IDE is working at this point. Damien Sent from ProtonMail mobile Original Message On 18 May 2023, 4:24 am, Janneke Nieuwenhuizen wrote: > Hi! > > So, Guix's glibc-2.35 has patches for centiseconds and monotonic (and > others) that were forward ported since glibc 2.31, instead of refreshed > from upstream Debian Salsa: > > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/glibc-hurd-clock_gettime_monotonic.patch > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/glibc-hurd-clock_t_centiseconds.patch > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/glibc-hurd-gettyent.patch > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/glibc-hurd-mach-print.patch > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/glibc-hurd-signal-sa-siginfo.patch > > As discussed on IRC, I reverted > > glibc-hurd-clock_gettime_monotonic.patch > glibc-hurd-clock_t_centiseconds.patch > > and applied > > https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/hurd-i386/local-clock_gettime_MONOTONIC.diff > https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/hurd-i386/unsubmitted-clock_t_centiseconds.diff > > I disregarded/kept the others as they were (gettyent, mach-print, > signal-sa-siginfo). > > With this newly patched glibc > > https://gitlab.com/janneke/guix/-/tree/wip-hurd12 > > rumpdisk still crashes, but the good news (I guess) is that it seems to > get somewhat further, or at least it crashes differently. Here are the > last 24 (WTF, 1980 wants their screensize back!?) lines (I don't know > how to get the full log from QEMU): > > --8<---cut here---start->8--- > [..] ??? how to capture these? using --display curses > [ 1.040] timecounter: Timecounter "clockinterrupt" frequency 100 Hz qualit > y 0 > [ 1.050] cpu0 at thinair0: rump virtual cpu > [ 1.050] entropy: WARNING: extracting entropy too early > [ 1.0200050] root file system type: rumpfs > [ 1.0200050] kern.module.path=/stand/i386/9.99.88/modules > [ 1.0200050] mainbus0 (root) > [ 1.0200050] pci0 at mainbus0 bus 0 > [ 1.0200050] pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv o > k > [ 1.0200050] vendor 8086 product 1237 (host bridge, revision 0x02) at pci0 dev > 0 function 0 not configured > [ 1.0200050] vendor 8086 product 7000 (ISA bridge) at pci0 dev 1 function 0 no > t configured > [ 1.0200050] vendor 8086 product 7010 (IDE mass storage, interface 0x80) at pc > i0 dev 1 function 1 not configured > [ 1.0200050] vendor 8086 product 7113 (miscellaneous bridge, revision 0x03) at > pci0 dev 1 function 3 not configured > [ 1.0200050] vendor 1234 product (VGA display, revision 0x02) at pci0 dev > 2 function 0 not configured > [ 1.0200050] vendor 10ec product 8139 (ethernet network, revision 0x20) at pci > 0 dev 3 function 0 not configured > [ 1.350] blake2s: self-test passed > [ 1.350] chacha: Portable C ChaCha > --8<---cut here---end--->8--- > > I'm aware that > > https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/hurd-i386 > > has an odd 50 patches that we are not using in Guix...Also, we're using > a much newer rumpkernel source (latest), so it could be anything... > > Again, any help or insights higly appreciated! > > Greetings, > Janneke > > -- > Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org > Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Re: Some progress, Guix rumpdisk still crashes...
On Wed, May 17, 2023 at 9:25 PM Janneke Nieuwenhuizen wrote: > Hi! Hi, > Here are the > last 24 (WTF, 1980 wants their screensize back!?) lines (I don't know > how to get the full log from QEMU): > > --8<---cut here---start->8--- > --8<---cut here---end--->8--- > > Again, any help or insights higly appreciated! I've recently been doing this kind of debugging early boot-up process *a lot*, so maybe I could provide some tips indeed. For getting more lines of output, try console=com0 on gnumach cmdline, and run qemu with -nographic -serial stdio or something like that. Other than that, just attach gdb and see what it crashes on? Like this: $ gdb /path/to/gnumach (gdb) tar rem :1234 (gdb) b i386_exception (gdb) b task_terminate (gdb) b Panic (gdb) add-symbol-file /path/to/rumpdisk.static blah-blah (y/n?) y (gdb) c This is *so much* easier to do with statically linked non-PIE binaries loaded by gnumach/GRUB at startup compared to hunting for shared library .text addresses and single-stepping through code pages getting paged in upon first access (can't place a breakpoint before the page gets paged in!), so enjoy it while it lasts :) If you do hit i386_exception, you can look at active_threads[0]->task->name to understand what task it is (though it's likely to be just the rumpdisk in your case). If you step up several frames (perhaps just one), you'll find a 'regs' argument being passed to a function; from there you can extract the faulting %eip, and then can disas around it to see what it is (again, much easier with symbols!). The trick I like to use is I, upon hitting an exception, re-set all the registers to the values described by 'regs', just like this: (gdb) set $rsp = $2.uesp (gdb) set $rip = $2.eip ...and so on (don't forget to switch back to the topmost frame first, with 'down' or 'select-frame') and that basically rewinds time to when the fault has happened, and from there you can see the userland backtrace and inspect the full state at the time of the fault. Sergey
Some progress, Guix rumpdisk still crashes...
Hi! So, Guix's glibc-2.35 has patches for centiseconds and monotonic (and others) that were forward ported since glibc 2.31, instead of refreshed from upstream Debian Salsa: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/glibc-hurd-clock_gettime_monotonic.patch https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/glibc-hurd-clock_t_centiseconds.patch https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/glibc-hurd-gettyent.patch https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/glibc-hurd-mach-print.patch https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/glibc-hurd-signal-sa-siginfo.patch As discussed on IRC, I reverted glibc-hurd-clock_gettime_monotonic.patch glibc-hurd-clock_t_centiseconds.patch and applied https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/hurd-i386/local-clock_gettime_MONOTONIC.diff https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/hurd-i386/unsubmitted-clock_t_centiseconds.diff I disregarded/kept the others as they were (gettyent, mach-print, signal-sa-siginfo). With this newly patched glibc https://gitlab.com/janneke/guix/-/tree/wip-hurd12 rumpdisk still crashes, but the good news (I guess) is that it seems to get somewhat further, or at least it crashes differently. Here are the last 24 (WTF, 1980 wants their screensize back!?) lines (I don't know how to get the full log from QEMU): --8<---cut here---start->8--- [..] ??? how to capture these? using --display curses [ 1.040] timecounter: Timecounter "clockinterrupt" frequency 100 Hz qualit y 0 [ 1.050] cpu0 at thinair0: rump virtual cpu [ 1.050] entropy: WARNING: extracting entropy too early [ 1.0200050] root file system type: rumpfs [ 1.0200050] kern.module.path=/stand/i386/9.99.88/modules [ 1.0200050] mainbus0 (root) [ 1.0200050] pci0 at mainbus0 bus 0 [ 1.0200050] pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv o k [ 1.0200050] vendor 8086 product 1237 (host bridge, revision 0x02) at pci0 dev 0 function 0 not configured [ 1.0200050] vendor 8086 product 7000 (ISA bridge) at pci0 dev 1 function 0 no t configured [ 1.0200050] vendor 8086 product 7010 (IDE mass storage, interface 0x80) at pc i0 dev 1 function 1 not configured [ 1.0200050] vendor 8086 product 7113 (miscellaneous bridge, revision 0x03) at pci0 dev 1 function 3 not configured [ 1.0200050] vendor 1234 product (VGA display, revision 0x02) at pci0 dev 2 function 0 not configured [ 1.0200050] vendor 10ec product 8139 (ethernet network, revision 0x20) at pci 0 dev 3 function 0 not configured [ 1.350] blake2s: self-test passed [ 1.350] chacha: Portable C ChaCha --8<---cut here---end--->8--- I'm aware that https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/hurd-i386 has an odd 50 patches that we are not using in Guix...Also, we're using a much newer rumpkernel source (latest), so it could be anything... Again, any help or insights higly appreciated! Greetings, Janneke -- Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
