Riddling absence of /usr/lib/libattr.la
Hi, since yesterday i am proud operator of a Debian GNU/Hurd installed via http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/netinst.iso in a kvm image file on Debian GNU/Linux 6.0.2 amd64. Building my projects GNU xorriso or libisofs from source tarball failed with missing /usr/lib/libattr.la if libacl-dev is installed. I solved this by copying /usr/lib/libattr.la from the hosting system to Hurd, where i had to change its content from libdir='/usr/lib' to libdir='/lib/i386-gnu' But libisofs-1.1.4 builds fine on buildd (bach) for hurd-i386. The version numbers of libacl and libattr packages match mine. So i am riddling what might be the decisive difference in my installation. The tarball and its build system are generated by autotools. I did: $ wget http://files.libburnia-project.org/releases/libisofs-1.1.4.tar.gz $ tar xzf libisofs-1.1.4.tar.gz $ cd libisofs-1.1.4 $ ./configure make [...] checking sys/acl.h usability... yes checking sys/acl.h presence... yes checking for sys/acl.h... yes checking for acl_to_text in -lacl... yes checking attr/xattr.h usability... yes checking attr/xattr.h presence... yes checking for attr/xattr.h... yes checking for listxattr in -lc... yes [... more configuration and lots of compilation ...] /bin/bash ./libtool --silent --tag=CC --mode=link [...] [...] libisofs/libisofs_libisofs_la-md5.lo -lpthread -lz -lacl grep: /usr/lib/libattr.la: No such file or directory /bin/sed: can't read /usr/lib/libattr.la: No such file or directory libtool: link: `/usr/lib/libattr.la' is not a valid libtool archive make: *** [libisofs/libisofs.la] Error 1 $ libacl-dev was installed by apt-get from the default location http://jk.fr.eu.org/debian/hurd-installer/mirror dpkg -l reports: libacl12.2.47-3 libacl1-dev2.2.47-3 apt-file on the hosting GNU/Linux says that /usr/lib/libattr.la would belong to libattr1-dev which i installed for xattr support anyway. But there was no such file installed here. libattr1 1:2.4.46-3 libattr1-dev 1:2.4.46-3 buildd log (from bach) reports Setting up libattr1-dev (1:2.4.46-3) ... Setting up libacl1-dev (2.2.47-3) ... and the same ./configure messages about acl and xattr as my Hurd. After copying and adapting the missing file, GNU xorriso gets linked with libattr.so.1 = /lib/i386-gnu/libattr.so.1 (0x0106c000) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/98960612519734@192.168.2.69
Re: Riddling absence of /usr/lib/libattr.la
Hi, harish badrinath wrote on debian-hurd@lists.debian.org: I have posted a bug report,http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639517 Niv Sardi wrote to 639...@bugs.debian.org: http://wiki.debian.org/ReleaseGoals/LAFileRemoval IIRC, It's a release goal. I do wonder, how my generated Makefile comes to the idea to expect libattr.la if it is removed from the system. None of my files mentions libattr. This idea must come from libacl-dev. And really in /lib/libacl.la i read dependency_libs=' /usr/lib/libattr.la' Following the prescriptions in LAFileRemoval i change it to dependency_libs='' Suddenly my libisofs source builds without the need for libattr.la. libisofs.la has now dependency_libs=' -lpthread -lz /lib//libacl.la' rather than dependency_libs=' -lpthread -lz /lib//libacl.la /usr/lib/libattr.la' GNU xorriso builds too. So probably one should re-name the bug to libacl-dev on hurd-i386 depends on LAFileRemoval victim libattr.la Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/98961825130110@192.168.2.69
-reply:20110829090112.gc4...@type.u-bordeaux.fr
Hi, Samuel Thibault wrote: libisofs not building was becoming more and more a problem, so I patched the libacl.la file by hand (yes, a bad thing). A change in the Debian package configurations of libisofs and libisoburn for hurd-i386 would avoid unnecessary problems. Currently the support for ACL and xattr on Hurd ends up in a dummy adapter of libisofs. Its Linux adapter would be usable, but ends up in a more-or-less-dummy version of libacl and libattr on Hurd. It would suffice to simply not install libacl1-dev and libattr1-dev, when libisofs and libisoburn get built. ./configure will then create a Makefile which does not try to use libacl or xattr functions. Another possibility would be ./configure --disable-libacl --disable-xattr On the other hand, libisofs is a test case for the libraries and headers. So the opportunity for problems might actually be desirable. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/98974208911537@192.168.2.69
Re: Must i worry about errno == -303 EMIG_BAD_ID ?
Hi,
does errno -303 announce bigger trouble ?
Probably yes: the query/reply IPC ping-pong got disturbed somehow.
Here is a minimal C example:
#include unistd.h
#include stdio.h
#include errno.h
int main()
{
int ret;
printf(Hello world\n);
ret = fsync(1);
fprintf(stderr, fsync(1)= %d , errno = %d\n, ret, errno);
}
Test runs
$ ./a.out | cat /dev/null
fsync(1)= -1 , errno = -303
$ ./a.out
Hello world
fsync(1)= 0 , errno = 0
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/98940818827672@192.168.2.69
Why does su change PATH on amd64 but not on hurd-i386 ?
Hi, i guess it is not intentional that on a freshly installed Debian GNU/Hurd $ su Password: # apt-get install libacl1-dev fails with ... Get:2 http://jk.fr.eu.org/debian/hurd-installer/mirror/ sid/main libacl1-dev hurd-i386 2.2.47-3 [78.1 kB] Fetched 119 kB in 0s (373 kB/s) dpkg: warning: 'ldconfig' not found in PATH or not executable. dpkg: warning: 'start-stop-daemon' not found in PATH or not executable. dpkg: error: 2 expected programs not found in PATH or not executable. Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin. E: Sub-process /usr/bin/dpkg returned an error code (2) # PATH looks like inherited from my normal user. # echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/thomas On the hosting Debian GNU/Linux amd64 i see $ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/thomas $ su Password: # echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin The same i get if i login to Hurd at the kvm console without intermediate user thomas. So what shell setup script is run on am64 but not on hurd-i386 when command su is performed ? It is not /etc/profile, where i can see the root PATH, but where i cannot cause any visible side effects by running su. (I edited /etc/profile and inserted the line echo Executing amd64 /etc/profile : $(/bin/date) /tmp/profile.log It gets not performed on su. ) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/98957653532064@192.168.2.69
Why does su change PATH on amd64 but not on hurd-i386 ?
Hi, Svante Signell wrote: Debian has fixed this already. Samuel Thibault wrote In Debian Linux, yes. But we still have the issue on Debian Hurd. There is no reason why we shouldn't be able to get the same behavior. I would like to understand how this miracle works on my amd64 installation of 6.0.2. Meanwhile google found me /etc/login.defs which obviously is the source of the su PATH on amd64. If i change this line ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin then the next su gets the changed PATH. But the same file and line are visible on hurd-i386 too. So why doesn't it get into effect, as on amd64 ? In man login.defs (on amd64) i read: BUGS Much of the functionality that used to be provided by the shadow password suite is now handled by PAM. Thus, /etc/login.defs is no longer used by passwd(1), or less used by login(1), and su(1). Please refer to the corresponding PAM configuration files instead. Might this be the difference ? Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/98956232814354@192.168.2.69
cd issues: Re: Why ...
Hi, Thomas do you need mount.h? Not yet. But i am having trouble with udev (or udisks ?) on amd64 which interfere with burn runs. So it might become necessary to care about umounting before burning. Quite a nightmare. I would have the choice between forking shell commands or using system dependent C interfaces. I'm porting other packages and it is not available on GNU/Hurd. Any workarounds? Maybe fake a mount.h ? Well, this won't satisfy the expectations of the programs towards an existing mount facility. Probably one would have to fake more. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/98603066712751@192.168.2.69
Re: SCSI for Hurd
Hi, Ritesh Raj Sarraf wrote: A quick search for scsi related items on Hurd shows nothing interesting Samuel Thibault wrote: You can look on the bug-hurd mailing list, Interface for SCSI transactions, Thomas Schmitt proposed to work on a generic interface, I don't know its status. Well, it is being left behind, currently. The last technical discussion was in october 2012. My youngest proposal seems to be in http://lists.gnu.org/archive/html/bug-hurd/2011-10/msg00053.html (I found a sketch on my local disk which contains this proposal and the elder one with a more generic RPC.) The most disputed issue in the discussion was how to design and integrate the RPC call. I got half an ok for my proposal by Olaf Buddenhagen. I then tried to get a real DVD burner accessible via qemu. This succeeded for a Debian GNU/Linux guest: http://libburnia-project.org/wiki/QemuXorriso but the emulated controllers were not supported by Hurd then. I have watched progress reports about DDE here on the list, but did not yet explore whether this work affects my roughly sketched path through the compoments of Hurd. Actually i do not see myself qualified as kernel hacker. My role would normally be the one of a skilled user of an SCSI passthrough interface: Telling what's needed, testing, maybe digging for bug hideouts in the code, ... So i would not mind if anybody else takes on the task. As soon as there is a userspace interface for SCSI passthrough and Hurd can access a real DVD burner, i am committed to test it Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/18553996814032387...@scdbackup.webframe.org
Re: Debian GNU/Hurd 2017 released!
Hi, i found https://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/util/x86-image which indeed produces a file grub_embed. But it uses a blob as first part of that file: cat "/usr/lib/grub/$platform/boot.img" "$workdir/core.img" > "$outdir/boot/grub/grub_embed" I have one on my Debian 8: -rw-r--r-- 1 root root 512 Mar 23 2015 /usr/lib/grub/i386-pc/boot.img This blob already has the bytes in the partition table which cause the insane numbers in fdisk and other partition table interpreters. Disassembling does not look as if the code would try to hop over the table beginning at 0x1be. I got this command on my cheat sheet: objdump -D -b binary -mi386 -Maddr16,data16 $mbr_file | less but lack true assembler knowledge. Nevertheless i can see that the MBR of grub-mkrescue has a "ret" before the partition table begins and that its jumps go either below 0x1b0 or above 0x1ff. Now i wonder whether i should ask Debian's GRUB2 maintainers or directly at grub-devel about the use cases where this would be appropriate. I could declare it a matter of coordination among GNU projects. :)) Have a nice day :) Thomas
Re: Debian GNU/Hurd 2017 released!
Hi, i wrote: > > https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.0.0-amd64 -netinst.iso > > With OVMF, GRUB2 is in charge and works fine. Samuel Thibault wrote: > That's probably sheer luck. > [ Part 2, Image/PNG 545 KB. ] Wow. That's really unusable. The appearance of Hurd's GRUB menu is ill, but because of the correct graphics every second arrow key one can navigate and trust the result of the key even if it is not visible. Did you already talk to Steve McIntyre about the appearance of amd64 on your VM ? > > -rw-r--r-- 1 root root 512 Mar 23 2015 /usr/lib/grub/i386-pc/boot.img > Note that the script gets executed on Debian GNU/Hurd, not Debian > GNU/Linux. Perhaps for some reason there's a bug in the Hurd version. > ... > Better investigate the Hurd version first before contacting them, > perhaps it's a target-specific issue. It looks as if already the blob boot.img on my amd64 Debian 8 has the problem with the misused partition table byte range. (On GNU/Hurd it could only be better than that.) The first 512 bytes of the 2017 Hurd ISO are the same as in my locally installed file /usr/lib/grub/i386-pc/boot.img . The GRUB targets are the same in both cases: "i386-pc", which i understand is initially the 16 bit aspect of x86 plus BIOS INT services, and maybe later 32 bit code. There are no indications that 64 and 32 bit machines are distinguished at that level. > Coordination between GNU projects? You're dreaming a bit :) rms urges us to do so. Since we don't follow his wish to use Lisp we have to find other ways to please him. :)) Have a nice day :) Thomas
Re: Debian GNU/Hurd 2017 released!
Hi, i wrote: > > I would need to know how the MBR and the subsequent data blocks > > are produced. Samuel Thibault wrote: > The build log is available on > https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/daily/debian-cd.log This mentions grub_embed two times when xorriso gets its name and when xorriso reports to have used it. But i see no hint how this files gets created. It would be interesting to know which documentation and which GRUB modules lead to that binary. I googled for "grub_embed". The best match was your changelog entry from 2014: Add usb key boot support for kfreebsd & hurd images. This needs another grub image, grub_embed, which has to be very small. Add x86-image script, similar to efi-image script, with factorized grub-cpmodules part, to build minimal grub images with iso9660 and biosdisk support, and put GRUB modules on the ISO image. I was unable to find kFreeBSD ISOs which have an MBR. Would that "x86-image script" explain more ? (https://sources.debian.net/src/debian-cd/unstable/ throws "Internal Server Error", so i cannot currently explore debian-cd myself.) > xorriso is version 1.3.2 It's fully sufficient, although quite old. > > > > with horizontal and vertical roll-over > > Do you see the same effects in your tests ? > Yes. And also with linux/kfreebsd images. Not with amd64 (can't get i386 to boot with -bios OVMF.fd on my amd64 machine). https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.0.0-amd64-netinst.iso With SeaBIOS, ISOLINUX is in charge and works fine. With OVMF, GRUB2 is in charge and works fine. The kFreeBSD mini ISOs i have indeed show the same display problem as the newest Hurd NETINST. But debian-7.9.0-kfreebsd-amd64-netinst.iso is OK with SeaBIOS. It has GRUB 1.99 (which is a GRUB2 before its first official release). So currently it looks like the problem is with GRUB 2.02 on (Sea)BIOS. I will ponder how to reproduce it with grub-mkrescue. Have a nice day :) Thomas
Re: Debian GNU/Hurd 2017 released!
Hi, my assembler reading skills are obviously insufficient. It turns out that the bytes in the MBR partition table range are not significant for booting the ISO from qemu -hda. I boldly zeroed them in a copy of the GNU/Hurd ISO and it still boots. (To make sure that it does not boot by El Torito i copied the terminating volume descriptor from block 19 to block 17.) Encouraged by this outcome, i repacked the ISO by these commands: # Obtain GRUB image file from start of original ISO dd if=debian-hurd-2017-i386-NETINST-1.iso bs=2048 count=16 of=grub_embed mount debian-hurd-2017-i386-NETINST-1.iso /mnt/iso # Most options as learned from file /mnt/iso/.disk/mkisofs # but adding option --protective-msdos-label to create a partition table. xorriso -as mkisofs \ -o test.iso \ -J -joliet-long -r \ -V 'Debian 9.0 h-i386 n' \ --embedded-boot grub_embed \ --protective-msdos-label \ -cache-inodes \ -c boot/boot.cat \ -b boot/grub/grub_eltorito \ -no-emul-boot -boot-load-size 4 -boot-info-table -no-pad \ /mnt/iso The resulting test.iso boots as qemu -hda to the same GRUB menu as the original ISO. The partition table is what grub-mkrescue would ask for in case of i386-pc without any efi platform: $ sbin/fdisk -lu test.iso ... Disklabel type: dos ... Device Boot StartEnd Sectors Size Id Type test.iso1 *1 311555 311555 152.1M cd unknown This partition is not mountable because of its start offset 1. But that's how Vladimir wanted it for grub-mkrescue. -- Udate after receiving reply on grub-devel: http://lists.gnu.org/archive/html/grub-devel/2017-06/msg00043.html Vladimir 'phcoder' Serbinenko wrote: > Those are only for floppies with old BIOS. If your image is over 2.88 MiB > and thus never useful on floppies, it's safe to overwrite. This explains why it looks like somewhat plausible executable code and why i386-pc/boot.img of Debian 8 is in the state it is in. -- So my proposal to Debian GNU/Hurd is to boldly add option --protective-msdos-label to the debian-installer run of xorriso -as mkisofs for hurd. If an empty partition table is desired instead, then at least zeroize the 64 bytes beginning at offset 446 of file "grub_embed" before it gets handed over to xorriso. Have a nice day :) Thomas
Re: Debian GNU/Hurd 2017 released!
Hi, Samuel Thibault wrote: > I rather guess the double-buffering support in grub. But where would that be controllable ? grub-mkimage --help has no options for that. Google does not find me any clue about grub.cfg statements which would promise to do it. Have a nice day :) Thomas
Re: Debian GNU/Hurd 2017 released!
Hi, Samuel Thibault wrote: > Files on > https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/daily/ > are now updated accordingly Oh yes. Now it looks much better and should be digestible for partition editors. https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/daily/debian-sid-hurd-i386-NETINST-1.iso boots on my qemu-system-i386 from -hda. No unexpectable miracle cure with menu graphics, though. - If i only knew what Vladimir meant with "disable double buffering and try again" to diagnose the menu graphics problem. Maybe the X extension about double frame buffering: https://www.x.org/releases/X11R7.7/doc/libXext/dbelib.html But i fail to find info how to inquire whether my X can do it and whether qemu's graphics window uses it. (Further i would be reluctant to play with the X server on my real workstation.) I tested with a BIOS equipped real 64 bit machine from USB stick. It shows the GRUB menu just fine. I did not go further, because the box is full of SATA and other witches' brew from around 2010. Have a nice day :) Thomas
Re: iso_not_recognised
Hi, Graham Cunnington wrote: > my computer does not even > see the DVD-1 in the DVD drive, although it sees all Linux bootable isos and > the Haiku iso when a disk is put in the hard drive. Most GNU/Linux Installation- or Live-ISOs are prepared for booting via BIOS and EFI firmware. The Debian GNU/Hurd ISOs DVD-1 and NETINST only offer starting points for BIOS, not for EFI. (I am not sure whether Hurd would run on hardware from modern EFI times.) The image wget http://ftp.ports.debian.org/debian-ports-cd/hurd-i386/debian-hurd-2017/debian-hurd-2017-i386-DVD-1.iso works for me on qemu virtual machines with SeaBIOS from virtual DVD or virtual hard disk (or USB stick). haiku-r1alpha4.iso is exotic. It boots by an emulated 2.8 MB floppy in the El Torito boot image. (GRUB and ISOLINUX boot by no-emulation boot images, which are x86 programs.) > Have you any idea on what the iso recognition problem is and how to overcome > it? You will have to tell more about your computer. Especially its processor (e.g. 32 bit Intel Pentium) and the boot firmware (e.g. Phoenix-Award BIOS vX.YZ). Then you will have to give the exact URL of the ISO which does not work for you. Have a nice day :) Thomas
Why are the 2017 DVD ISOs so small ?
Hi, the DVD images 1 to 3 in http://ftp.ports.debian.org/debian-ports-cd/hurd-i386/debian-hurd-2017/ are listed with sizes 1.6G, 1.7G, and 1.7G respectively. At least DVD-1 really has only 1,680,308,224 bytes (and is not truncated or rolled over). Is the small size intentional ? A normal DVD has a capacity of 4482.625 MiB = 4.378 GiB. So most of the data would fit onto a single medium. Other Debian DVD-1 ISOs are a bit smaller than 4 GiB to fit on a "4 GB" USB stick. See for example https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/ Have a nice day :) Thomas
Re: Debian GNU/Hurd 2017 released!
Hi, i wrote: > > i see a quite insane MBR partition table: Samuel Thibault wrote: > That's not surprising by nowadays' """ISO""" image standard: they are > both valid as CD image, usb stick image, etc. Sure. But normally the MBR has a valid partition table. Not only the ISOLINUX MBR of Debian x86 ISOs but also the MBR of grub-mkrescue. My program xorriso writes those partition tables if it is told to do so. But in the case of the grub_embed MBR there seems to be code where the partition tables is supposed to be. So it would not be a good idea to simply add option --protective-msdos-label to the xorriso -as mkisofs run. > > One should ask the provider of grub_embed > Ask grub people then :) I would need to know how the MBR and the subsequent data blocks are produced. (And for what device an MBR with garbled partition table would be deemed suitable, if that is known.) The code in the MBR of grub-mkrescue obviously hops onto the program in the El Torito boot image. So it can be small enough to leave bytes 446 ff. unused. I refer to grub-mkrescue because it is the official upstream proposal to prepare the GRUB2 entrails and the xorrisofs options for a GRUB2 bootable ISO. > > although the menu switches by every press of an arrow key from dark purple > > with horizontal and vertical roll-over to grey cyan with correct geometry. > Again, a grub issue :) Do you see the same effects in your tests ? If not, with what virtual firmware do you test ? (And why is your /boot/grub/grub_eltorito not needy of xorrisofs option --grub2-boot-info ?) Have a nice day :) Thomas
Re: Debian GNU/Hurd 2017 released!
Hi, in http://ftp.ports.debian.org/debian-ports-cd/hurd-i386/debian-hurd-2017/debian-hurd-2017-i386-NETINST-1.iso i see a quite insane MBR partition table: $ /sbin/fdisk -lu debian-hurd-2017-i386-NETINST-1.iso ... Disklabel type: dos ... Device Boot StartEndSectors Size Id Type debian-hurd-2017-i386-NETINST-1.iso1 ?3451924861 3662313359 210388499 100.3G 0 Empty debian-hurd-2017-i386-NETINST-1.iso2 ?2766929882 4653280287 1886350406 899.5G be Solaris debian-hurd-2017-i386-NETINST-1.iso3 ? 28891953 3082391602 3053499650 1.4T 0 Empty debian-hurd-2017-i386-NETINST-1.iso4 4278184271 4278184271 0 0B d4 unknown The bytes of the MBR stem obviously from this xorrisofs option (learned from file /.disk/mkisofs in the ISO): --embedded-boot boot1/boot/grub/grub_embed One should ask the provider of grub_embed whether it is intentional to have a MBR signature in bytes 510 and 511 and to have the cleartext word "Floppy" in the range where the MBR is supposed to expose its partition table. Especially strange is that the MBR code contains lots of zeros in its first 80 bytes. Can it be that the code should be moved ~ 80 bytes lower and rather hop over a more plausible partition table beginning at byte 446 ? The MBR code itself seems to be functional. I get to a GRUB menu by $ qemu-system-x86_64 -enable-kvm -m 4096 -hda debian-hurd-2017-i386-NETINST-1.iso although the menu switches by every press of an arrow key from dark purple with horizontal and vertical roll-over to grey cyan with correct geometry. This menu display defect is not bound to MBR booting. If i erase the MBR and boot by -cdrom, i get to the same situation. (It is not 100% sure that -hda uses MBR and -cdrom uses El Torito because some virtual BIOSes are known to boot El Torito from -hda and MBR from -cdrom. So to be sure, one has to cripple the unwanted boot starting point. The default virtual BIOS of Debian 8 qemu is ok in this aspect, nevertheless.) Have a nice day :) Thomas
Re: UEFI PC?
Hi, Samuel Thibault wrote: > Mmm, actually I had tested with the amd64 debian iso image , not the > i386. The i386 http://cdimage.debian.org/cdimage/release/10.2.0/i386/iso-cd/debian-10.2.0-i386-netinst.iso > has the same issue, Aren't amd64 and i386 GNU/Linux systems ? Those have ISOLINUX equipment for PC-BIOS and GRUB for EFI. CD and USB stick. Don't we talk about ISOs like https://cdimage.debian.org/cdimage/ports/current-hurd-i386/iso-cd/debian-hurd-2019-i386-NETINST-1.iso It has a GRUB El Torito image for CD via PC-BIOS. No recognizable MBR code for booting via PC-BIOS from USB stick. Can it be that hurd-i386 is prepared by https://sources.debian.org/src/debian-cd/3.1.27/tools/boot/bullseye/boot-hurd-common whereas i386 and amd64 are prepared by https://sources.debian.org/src/debian-cd/3.1.27/tools/boot/bullseye/boot-x86 ? Both tinker with xorrisofs boot options. boot-x86 is much more elaborate than boot-hurd-common. In both it seems that ISOLINUX and GRUB binaries are already prepared. Dunno where this is done. The hurd script shows no traces of xorrisofs options for EFI, which would be --efi-boot or -e. No option --grub2-mbr is to see for booting via PC-BIOS from USB stick. As said, it uses GRUB for PC-BIOS, whereas i386/amd64 use ISOLINUX. (In case you plan to join boot-x86 with EFI: I have a change proposal pending for i386 and amd64 images. Motivated in detail at: https://lists.debian.org/debian-cd/2019/07/msg7.html It would be worth to adopt it if you copy all the boot-x86 stuff. I should prod Steve again. His excuse about the old xorriso version is gone meanwhile. The i386 ISO has Preparer Id : XORRISO-1.5.0 2018.09.15.133001, ... ) --- xorriso offers commands for inspection of boot equipment. E.g. xorriso -indev debian-hurd-2019-i386-NETINST-1.iso \ -report_system_area plain \ -report_el_torito plain yields ... Volume id: 'Debian 2019 h-i386 n' System area options: 0x0201 System area summary: MBR protective-msdos-label cyl-align-off ISO image size/512 : 457764 Partition offset : 0 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x80 0xcd1 457763 El Torito catalog : 804 1 El Torito cat path : /boot/boot.cat El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x 0x00 4 53448 El Torito img path : 1 /boot/grub/grub_eltorito El Torito img opts : 1 boot-info-table With i386 GNU/Linux: Volume id: 'Debian 10.2.0 i386 n' System area options: 0x0102 System area summary: MBR isohybrid cyl-align-on GPT APM ISO image size/512 : 872448 Partition offset : 0 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x80 0x000 872448 MBR partition : 2 0x00 0xef 3856 4416 MBR partition path : 2 /boot/grub/efi.img ... ... invalid GPT and useless APM ... ... El Torito catalog : 963 1 El Torito cat path : /isolinux/boot.cat El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x 0x00 42068 El Torito boot img : 2 UEFI y none 0x 0x00 4416 964 El Torito img path : 1 /isolinux/isolinux.bin El Torito img opts : 1 boot-info-table isohybrid-suitable El Torito img path : 2 /boot/grub/efi.img With Guix (made by grub-mkrescue): Volume id: 'GUIXSD_IMAGE' System area options: 0x4201 System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off GPT APM ISO image size/512 : 2109436 Partition offset : 0 MBR heads per cyl : 65 MBR secs per head : 32 MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x00 0xee1 2109435 GPT: N Info GPT disk GUID : 38bec621914e604ea91884e71f367b5c GPT entry array: 20 176 separated GPT lba range : 64 2109390 2109435 GPT partition name : 1 4700610070003000 GPT partname local : 1 Gap0 GPT partition GUID : 1 38bec621914e604ea91984e71f367b5c GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x1001 GPT start and size : 1 64 34424 GPT partition name : 2 450046004900200062006f006f007400200070006100720074006900740069006f006e00 GPT partname local : 2 EFI boot partition GPT partition GUID : 2 38bec621914e604ea91a84e71f367b5c GPT type GUID : 2 28732ac11ff8d211ba4b00a0c93ec93b GPT partition flags: 2 0x1001 GPT start and size : 2 34488 2880 GPT partition path : 2 /efi.img GPT
Re: UEFI PC?
Hi, Samuel Thibault wrote: > kvm -cdrom debian-sid-hurd-i386-NETINST-1.iso -bios OVMF.fd > doesn't manage to boot it. Perhaps that's a kvm issue, or perhaps that's > a grub-ia32 issue (since I can't boot a linux-i386 image either) Indeed, this gives a "UEFI Interactive Shell" prompt and no Debian menu qemu-system-x86_64 -enable-kvm -m 512 \ -cdrom debian-10.2.0-i386-netinst.iso \ -bios /usr/share/ovmf/OVMF.fd But it boots to a GRUB/Debian menu with qemu-system-i386 ... > http://people.debian.org/~sthibault/hurd-i386/installer/cdimages/daily/debian-sid-hurd-i386-NETINST-1.iso (Find the surplus "s" in this URL.) qemu-system-i386 ... debian-sid-hurd-i386-NETINST-1.iso ... does not boot, i fear. The most obvious difference is in the two EFI System Partitions: $ cd /mnt/fat_hurd $ find . . ./efi ./efi/boot ./efi/boot/bootia32.efi $ cd /mnt/fat_i386 $ find . . ./efi ./efi/boot ./efi/boot/bootia32.efi ./efi/boot/grubia32.efi ./efi/debian ./efi/debian/grub.cfg bootia32.efi in hurd has 278,528 bytes. In i386 it's 1,065,120 for bootia32.efi, which says "Microsoft" 53 times, and 1,156,464 for grubia32.efi. The file grub.cfg contains only the instruction to use the grub.cfg in the ISO filesystem: search --file --set=root /.disk/info set prefix=($root)/boot/grub source $prefix/i386-efi/grub.cfg (In the hurd ISO, the EFI image is not marked in the partition table. Thus according to specs no booting from USB stick. But OVMF would boot by -hda nevertheless if it would work by -cdrom.) Have a nice day :) Thomas
Re: UEFI PC?
Hi, Samuel Thibault wrote: > Indeed, a 32bit version of OVMF is needed. I could grab one, This explains why i could not repeat my success with qemu-system-i386. (Now i wonder what i did to fall victim to that illusion.) > grub boots fine. gnumach however doesn't. Good luck with the rest of the journey. :)) Have a nice day :) Thomas
