hurd_0.9.git20210811-5_source-all.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 24 Aug 2021 12:14:51 + Source: hurd Binary: hurd hurd-dbgsym hurd-dev hurd-dev-dbgsym hurd-doc hurd-libs0.3 hurd-libs0.3-dbgsym hurd-prof Built-For-Profiles: noudeb Architecture: source all Version: 1:0.9.git20210811-5 Distribution: unstable Urgency: medium Maintainer: GNU Hurd Maintainers Changed-By: Samuel Thibault Description: hurd - GNU Hurd hurd-dev - GNU Hurd (development files) hurd-doc - GNU Hurd manual hurd-libs0.3 - GNU Hurd (libraries) hurd-prof - GNU Hurd Changes: hurd (1:0.9.git20210811-5) unstable; urgency=medium . * patches/git-rump_alloc.patch: Ensure physical allocation of memory for DMA reads. * patches/git-notirpc: Really make libtirpc optional, for bootstrap. Checksums-Sha1: 06e02d987e29f964d762ad766941adc40c638e87 4579 hurd_0.9.git20210811-5.dsc 2b6a6a49292be54aeaaf5da35b50e5ba359beaff 107948 hurd_0.9.git20210811-5.debian.tar.xz a42a88f8e835d8b2e85492872364862173a5de97 178096 hurd-doc_0.9.git20210811-5_all.deb Checksums-Sha256: 45ccc552a2e382d4eeb42fd736774a58e3e4bb0a472fe1499dedc0b255a3bdde 4579 hurd_0.9.git20210811-5.dsc e0a24f24cffcf2a00fe679610f87b88e4ee3df598c0544e15f193a98e8ab1057 107948 hurd_0.9.git20210811-5.debian.tar.xz 2052f2c0cf3df23e3cf37855e1835ed191e035334a52b3db8abc3bf56680b7d0 178096 hurd-doc_0.9.git20210811-5_all.deb Files: 91982aa9f9cfb5b8c809bd0d9fb58498 4579 admin required hurd_0.9.git20210811-5.dsc ca86bab7ca72d6f55a606edcb6772ebe 107948 admin required hurd_0.9.git20210811-5.debian.tar.xz 2d732377236a9e1df44d8439338b1fbd 178096 doc optional hurd-doc_0.9.git20210811-5_all.deb -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE59DSENomQIYa2nfqRdTszGSEm3kFAmEqUaYACgkQRdTszGSE m3mXyhAArGptK6yfRLYUeO3CRJ5t62xMGd1+Q2KFfDRIa4g/BqqTJnbKe234hjuX FlmNhbzir/BuQ0HIpa8ez6yOkYvrDY1TuwxhBm9BC3XhqxywZgYyRjOS0gVSvhdw 83HgeG7HiU5hOLCdo1ZMGrgE1xKiOzgQYOUdi1Exi05pqkfQBGojvlOcGs0fhl5v z7qFz4wrhw2xGCbXjwqJVCafMIFoLoYZRBY2yXJPRStiFvP+Wj+m4nkDSnLJcUzY 7dOqI/sfgbDq/T8+usl51uFhfNH8F4iJtDagglBQ3bETLcCmPIRV9n8oU4tnDhr0 eQnWKFqXn5oSJBb6SUoAg//bi7m6/M2dCg4vpUhtf4wY42ZcW6pl3CWPqpVhZKkm MFTJ3+ffDs+oGN52+wdM1T5pRljzcb4NhIQlWoZ3fJMWK+JDF65vkKWASkNS/ty/ mwcVn2KsuVlTjHYalKF67FDJ9D4vWxr2UnZhQ0pirMkR6HWLer5gMQ0XMyfjwND7 O4VsFgcV97G1uZh8UrC/TdRADlf3H1dLdz/agehjR+WPxf/AeIdbYT3FU0en113h zxtsUwQoRwxvmdyIGG/nqNFWgHWPrxq30w+sU/dfpnTwZqUs9JjD+8BBbTEAyjkz 0BF9BcMUSkniC3cmBreGycnnhPd7iKL19a6ouGV1T3PYh+ggra4= =x8fR -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of hurd_0.9.git20210811-5_source-all.changes
hurd_0.9.git20210811-5_source-all.changes uploaded successfully to localhost along with the files: hurd_0.9.git20210811-5.dsc hurd_0.9.git20210811-5.debian.tar.xz hurd-doc_0.9.git20210811-5_all.deb Greetings, Your Debian queue daemon (running on host usper.debian.org)
Re: Installing on extended partition
O 28/08/21 ás 15:02, Samuel Thibault escribiu: Parodper, le sam. 28 août 2021 14:35:16 +0200, a ecrit: A quick calculation shows none of those are multiples of 4096. Then that's most probably why. I don't know if we could just drop the checks. You said that it was installing fine with the MAKEDEV-created entries? Possibly the checks are overzealous. Samuel The thing is parted does not recognize the partition table (and shows the drive as if it has 134.7GB), so I can't install. What I can do with MAKEDEV is mount, but parted still does not work. Now that I think about it, it might be caused by the drive size (150GB), because the 80GB slave driver appears fine, and it also has a logical partition. Maybe having the 4th entry refer to sizes outside the 120GB range makes the partition table invalid?
Re: Installing on extended partition
Parodper, le sam. 28 août 2021 14:35:16 +0200, a ecrit: > A quick calculation shows none of those are multiples of 4096. Then that's most probably why. I don't know if we could just drop the checks. You said that it was installing fine with the MAKEDEV-created entries? Possibly the checks are overzealous. Samuel
Re: Installing on extended partition
O 28/08/21 ás 11:33, Samuel Thibault escribiu: Parodper, le sam. 28 août 2021 10:56:07 +0200, a ecrit: I still get the unknown partition table, and doing head /dev/hd0s1 fails with a «Input/Output error». head /dev/hd0 works fine. Tried doing settrans -a /dev/hd0s1 /hurd/storeio -T typed part:1:device:hd0; head /dev/hd0s1 and still getting IO error. The command also ends and does not output any error. Looking at hurd/libstore/part.c, I see if (run.start % source->block_size != 0) err = EIO; if (run.length % source->block_size != 0) err = EIO; could it be that your partitions are not aligned on 4096 bytes? Probably. The partitions on the drive have been created by their respective installers, from FreeDOS to Haiku to OpenBSD. If I understand correctly those variable names, the partition's start and length must be multiples of 4096? In that case I think I do not have any partition like that. Annotated sfdisk -d output: label: dos label-id: 0x20ac7dda device: /dev/sda unit: sectors /dev/sda1 : start= 63, size= 4208967, type=b, bootable #FreeDOS partition /dev/sda2 : start= 4209030, size=71682030, type=a6 #OpenBSD partition /dev/sda3 : start=75891060, size=30716280, type=81 #Minix3 partition /dev/sda4 : start= 106607401, size= 205967877, type=f #Extended partition /dev/sda5 : start= 106607403, size=40965687, type=6 #HaikuOS A quick calculation shows none of those are multiples of 4096. Is there any way to skip that calc (how hard would it be to patch it out from Debian Linux?). Side note, ls /dev is very slow (after a while I just cancel it), while echo /dev/* is instantaneous. That is not surprising: ls uses stat, and thus triggers the start of each and every translator in /dev. It should be able to terminate, though, it could be useful to try for i in /dev/* ; do echo $i ; ls $i ; done to see which one apparently hangs. Samuel It starts to lag on some of hd0s* (p. e. hd0s10 does, but hd0s16 does not). With hd1 starts to pick up speed, and everywhere else it works fine. Something that I just noticed on this test was that, on boot, the kernel (I guess?) showed the hd0 disk and all the partitions. I attach the syslog file after all the tests. Aug 28 12:06:40 syslogd started: BusyBox v1.22.1 Aug 28 12:06:40 kernel: /proc/sys/kernel/printk: No such file or directory Aug 28 12:06:40 kernel: klogd started: BusyBox v1.22.1 (Debian 1:1.22.0-12) Aug 28 12:06:40 kernel: GNU Mach 1.8+git20210827-486 Aug 28 12:06:40 kernel: biosmem: physical memory map: Aug 28 12:06:40 kernel: biosmem: 00:09fc00, available Aug 28 12:06:40 kernel: biosmem: 09fc00:0a, reserved Aug 28 12:06:40 kernel: biosmem: 0f:10, reserved Aug 28 12:06:40 kernel: biosmem: 10:006fff, available Aug 28 12:06:40 kernel: biosmem: 006fff:006fff3000, ACPI NVS Aug 28 12:06:40 kernel: biosmem: 006fff3000:007000, ACPI Aug 28 12:06:40 kernel: biosmem: 00fec0:00fec01000, reserved Aug 28 12:06:40 kernel: biosmem: 00fee0:00fee01000, reserved Aug 28 12:06:40 kernel: biosmem: 00:01, reserved Aug 28 12:06:40 kernel: vm_page: page table size: 458720 entries (25088k) Aug 28 12:06:40 kernel: vm_page: DMA: pages: 4080 (15M), free: 0 (0M) Aug 28 12:06:40 kernel: vm_page: DMA: min:500 low:600 high:1000 Aug 28 12:06:40 kernel: vm_page: DIRECTMAP: pages: 219136 (856M), free: 205471 (802M) Aug 28 12:06:40 kernel: vm_page: DIRECTMAP: min:10956 low:13148 high:21913 Aug 28 12:06:40 kernel: vm_page: HIGHMEM: pages: 235504 (919M), free: 0 (0M) Aug 28 12:06:40 kernel: vm_page: HIGHMEM: min:11775 low:14130 high:23550 Aug 28 12:06:40 kernel: GNU Mach 1.8+git20210827-486 Aug 28 12:06:40 kernel: biosmem: physical memory map: Aug 28 12:06:40 kernel: biosmem: 00:09fc00, available Aug 28 12:06:40 kernel: biosmem: 09fc00:0a, reserved Aug 28 12:06:40 kernel: biosmem: 0f:10, reserved Aug 28 12:06:40 kernel: biosmem: 10:006fff, available Aug 28 12:06:40 kernel: biosmem: 006fff:006fff3000, ACPI NVS Aug 28 12:06:40 kernel: biosmem: 006fff3000:007000, ACPI Aug 28 12:06:40 kernel: biosmem: 00fec0:00fec01000, reserved Aug 28 12:06:40 kernel: biosmem: 00fee0:00fee01000, reserved Aug 28 12:06:40 kernel: biosmem: 00:01, reserved Aug 28 12:06:40 kernel: vm_page: page table size: 458720 entries (25088k) Aug 28 12:06:40 kernel: vm_page: DMA: pages: 4080 (15M), free: 0 (0M) Aug 28 12:06:40 kernel: vm_page: DMA: min:500 low:600 high:1000 Aug 28 12:06:40 kernel: vm_page: DIRECTMAP: pages: 219136 (856M), free: 205471 (802M) Aug 28 12:06:40 kernel: vm_page:
gnumach_1.8+git20210828-1_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 28 Aug 2021 11:32:55 + Source: gnumach Binary: gnumach-common gnumach-dev gnumach-image-1-486 gnumach-image-1.8-486 gnumach-image-1.8-486-dbg kernel-image-1.8-486-di Built-For-Profiles: noudeb pkg.gnumach.noxen Architecture: source Version: 2:1.8+git20210828-1 Distribution: unstable Urgency: medium Maintainer: GNU Hurd Maintainers Changed-By: Samuel Thibault Description: gnumach-common - GNU version of the Mach microkernel, common files. gnumach-dev - GNU version of the Mach microkernel gnumach-image-1-486 - GNU version of the Mach microkernel gnumach-image-1.8-486 - GNU version of the Mach microkernel gnumach-image-1.8-486-dbg - GNU version of the Mach microkernel for debugging kernel-image-1.8-486-di - GNU version of the Mach microkernel for the Debian installer (udeb) Changes: gnumach (2:1.8+git20210828-1) unstable; urgency=medium . * New upstream snapshot. Checksums-Sha1: 1fdb5856d07b1533b374ee9b978c94e25e0b5432 3153 gnumach_1.8+git20210828-1.dsc 3e149653043f532e6b8ab5fca89144cbd3844a42 2831952 gnumach_1.8+git20210828.orig.tar.xz b45a83432892532e5125da34ba05bd696678a0d4 26440 gnumach_1.8+git20210828-1.debian.tar.xz Checksums-Sha256: c68ef348996c158f668e7d033302a7df92cba704828d574fc9127b9cd51d03b4 3153 gnumach_1.8+git20210828-1.dsc e579518bff38075a5d924c891f6b2776a734a34259f6425c9f82255ae76255fc 2831952 gnumach_1.8+git20210828.orig.tar.xz 233c4870c1e5397c9263c9d7e4ecfe4234830bf2656118881487218f37404484 26440 gnumach_1.8+git20210828-1.debian.tar.xz Files: 72846f925ea3f6312bab4ab33c38a6e1 3153 kernel optional gnumach_1.8+git20210828-1.dsc 70c491f2ed5c1f67cc22d26e5befed81 2831952 kernel optional gnumach_1.8+git20210828.orig.tar.xz a754fa07b43dff828c900b22d777dc12 26440 kernel optional gnumach_1.8+git20210828-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE59DSENomQIYa2nfqRdTszGSEm3kFAmEqIBcACgkQRdTszGSE m3m3QA//fsPYV2GrQhXZS6fQkxIxedRk/p2dmtYnccwh3kmPrtfoMPhR00zWT4Ka dMgc5bYST+kt+98GQEsHy7sNtGBEtCRAQs+48BJZgTGyL+W5UAUN0OW+yWgF9l2F xmriURfU5JJCnIpiqIx/BAsjNU+d5OCVPr7QDNOaGXa1dmZ+02PTZDomZOxerE7Y uLpPDW50VNfEZ8DT2my4faXEjWUD1YjhfxTP53QCazo+YZRODIgt3MA+GE2flUoB GO4ZEjH3Rf1Lxj1DT++1DDpICycG0uWh1W2FXsnXnBkP+xvPVHNiqPsleBoeoF41 kWCwgNH0hbI0TwM7xcbSBE4GLmrQZ7W9GJgts7ruYeZ+R5+QES4xlL4uKPMEO8vx 32yVKgUKl5UwXW8WgwQRQxvnBNY2eMlWRkqH2+UdXEBVIWdpoWHhTsXonH7vakhF 8qSc8PU4Kk2IW3XqYWoMb6rPirPgn35jTrKWyytV/DGG2tv8kV/ZtASwD0vVlYvg YWfcQeCUBg4t1x4RVIP+aoRlsO5B8CPDvkpKv6KuhQ5ZEkIXVoOiKDsR0wQmQlZg k2dydJx6v7Mm1zs1x/asqAzqOK85m+2I2ZY/WPE7I+Gc7i84GQgPLrLEyjoinLox BfITGV/uK/9IRxwtsMQ3G+VzrSOs+zle2XBvVE8gtelIq7yEnV0= =gVIG -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of gnumach_1.8+git20210828-1_source.changes
gnumach_1.8+git20210828-1_source.changes uploaded successfully to localhost along with the files: gnumach_1.8+git20210828-1.dsc gnumach_1.8+git20210828.orig.tar.xz gnumach_1.8+git20210828-1.debian.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
Re: Installing on extended partition
Parodper, le sam. 28 août 2021 10:56:07 +0200, a ecrit: > I still get the unknown partition table, and doing head /dev/hd0s1 fails > with a «Input/Output error». head /dev/hd0 works fine. > > Tried doing settrans -a /dev/hd0s1 /hurd/storeio -T typed part:1:device:hd0; > head /dev/hd0s1 and still getting IO error. The command also ends and does > not output any error. Looking at hurd/libstore/part.c, I see if (run.start % source->block_size != 0) err = EIO; if (run.length % source->block_size != 0) err = EIO; could it be that your partitions are not aligned on 4096 bytes? > Side note, ls /dev is very slow (after a while I just cancel it), while echo > /dev/* is instantaneous. That is not surprising: ls uses stat, and thus triggers the start of each and every translator in /dev. It should be able to terminate, though, it could be useful to try for i in /dev/* ; do echo $i ; ls $i ; done to see which one apparently hangs. Samuel
Re: Installing on extended partition
O 25/08/21 ás 22:18, Samuel Thibault escribiu: Parodper, le lun. 23 août 2021 08:40:17 +0200, a ecrit: O 19/08/21 ás 20:34, Samuel Thibault escribiu: Tried using «dd bs=512 skip=1 seek=1 conv=notrunc if=debian-hurd.iso of=/dev/sda8». It still needs MAKEDEV to mount it, and does not recognize the partition table. I cannot reproduce the issue. In my test I could was able to just provide the /dev/hd0s5 path and it'd just work. Yeah, it is going to be hard to reproduce. After I discovered that the netboot installer (from https://d-i.debian.org/daily-images/hurd-i386/daily/netboot/mini.iso, it was the only ISO in the daily folder) did not need to load from the disk I tried it. I still get the unknown partition table, and doing head /dev/hd0s1 fails with a «Input/Output error». head /dev/hd0 works fine. * Installer asks for drivers, choose to manually select the drive. * Then I change to TTY2, cd /dev and ./MAKEDEV hd0s6 This last step was not necessary in QEMU, that is why I was asking. That shouldn't be necessary at all, /dev is getting filled with device translator entries during the boot process, see attached snapshot. I do get the same things on boot (see https://i.imgur.com/XGImhqK.jpg), but when I try to do «mount -t iso9660 /dev/hd08 /mnt», or even just «head /dev/hd0», I get a Input/Output error. Ah, you mean that there really are some existing entries but they don't work, and the entries created by MAKEDEV happen to seem to work? About /dev/hd0 itself it's very surprising that it'd get Input/Output errors since the entry that MAKEDEV create is strictly the same as the existing one. As for /dev/hd0s8, d-i indeed uses the parted layer to access the partition, while MAKEDEV creates an entry that uses the kernel-level driver for partitions. It is very surprising that the latter would work better than the former, since only the former is maintained. When you open your disk with parted from a Linux system, does it complain somehow? It does not, but something interesting is that in GParted sda6 (I had sda6 [ext2 Hurd root], sda7 [swap] and sda8 [iso] in case parted was not able to create partitions) appeared with the same label as sda8. However, after the test above I deleted those partitions and the rror persists. PD: Is there any way to tell the translators to be more verbose? Something like 'echo OPTIONS=--verbose >> /etc/translator.conf'? There is no such global thing since translators are allowed to be implemented whatever the way they prefer. But you can start translators by hand to make sure to get their output: settrans -a /dev/hd0s8 /hurd/storeio -T typed part:8:device:hd0 Samuel Tried doing settrans -a /dev/hd0s1 /hurd/storeio -T typed part:1:device:hd0; head /dev/hd0s1 and still getting IO error. The command also ends and does not output any error. Side note, ls /dev is very slow (after a while I just cancel it), while echo /dev/* is instantaneous.
