But
# apt-get build-dep gnumach
did not install mig package.
I have done pretty much the same under Gnu HURD, and got master (today)
compiled and run without problems.
I have tried to compile older versions like with:
make clean
git checkout `git rev-list -1 --before="August 01 2018" master`
make gnumach.gz
but I get the same result: hanging on start ext2fs:
If I get much before like Jan 1 2018, I get an error about applying a configure
patch... sorry for
Last time, after compiling my new gnumach.gz on Ubuntu, I did not tried it.
I tested it on my QEMU environment (Gnu Hurd from this morning)...
and it stop on:
start ext2fs:
with cursor flashsing after.
I have tried to reverse the printk line I had added to ahci driver (that was
printed)
> grub does find both headers indeed, but that doesn't boot, it says
> "
> error: you need to load the kernel first.
> "
> as if it doesn't recognize the gnumach file as being a proper ELF kernel
> file.
Thanks for testing!
I get the same message when using "multiboot2". In my case I
> Le dim., 07 févr. 2021 13:02:58 -0500 Paul Dufresne
> écrit
>
> > I suspect CAP.SAM was 0 in previous versions... did not check.
> > But that most computers now have CAP.SAM to 1, so that GHC.AE should be
> written, even if already to 1, to "wake up" the device.
> > I
Andrea G. Monaco, le mar. 09 févr. 2021 01:11:11 +0100, a ecrit:
> I think that keeping both headers is ok, because they are very small and
> have different magic numbers. You can choose which one to use at grub2,
> since "multiboot" and "multiboot2" are different commands.
>
> I checked that both
Hello,
while trying to figure out uefi, I wrote a multiboot2 header. It's an
exercise, but I'll share it anyway.
I think that keeping both headers is ok, because they are very small and
have different magic numbers. You can choose which one to use at grub2,
since "multiboot" and "multiboot2" a
Hello,
Damien Zammit, le lun. 08 févr. 2021 20:33:16 +1100, a ecrit:
> I'm getting very close to working pci + rump.
Did you manage to find answers to your previous questions?
(I have to admit I didn't have time to dive into them)
> In pci-arbiter, what port rights do I return in device_open?
T
Paul Dufresne, le lun. 08 févr. 2021 10:18:47 -0500, a ecrit:
> Thanks! Will try it.
>
> But for now, I'd like to attract your attention on two things about the build:
That's a known general problem (see
http://d-i.debian.org/daily-images/daily-build-overview.html),
it is being handled by the deb
Thanks! Will try it.
But for now, I'd like to attract your attention on two things about the build:
xorriso : NOTE : Copying to System Area: 26764 bytes from file
'/home/sthibault/tmp/sid/boot1/boot/grub/grub_embed'libisofs:
WARNING : Can't add /debian to Joliet tree. Symlinks can only be added
Samuel Thibault, le mer. 03 févr. 2021 14:40:49 +0100, a ecrit:
> Paul Dufresne, le mer. 03 févr. 2021 06:57:10 -0500, a ecrit:
> > daily image of february 3, base installation:
> >
> > emacs depends on emacs-gtk >= 1:27.1 | emacs-lucid >= 1:27.1 | emacs-nox >=
> > 1:27.1 but none of them is inst
Hi,
I'm getting very close to working pci + rump.
In pci-arbiter, what port rights do I return in device_open?
I am currently doing this:
static io_return_t
device_open (mach_port_t reply_port, mach_msg_type_name_t reply_port_type,
dev_mode_t mode, char *name, device_t * devp,
13 matches
Mail list logo
