Q) Sudo never gives me a chance to enter a password using PAM, it just
says 'Sorry, try again.' three times and exits.
A) You didn't setup PAM to work with sudo. On RedHat Linux or Fedora
Core this generally means installing the sample pam.conf file as /etc/pam.d/sudo. See the example pam.conf file for hints on what to use
for other Linux systems.
The issue with debootstrap, part 1
==================================
To check if the previous issue is my system being in a messed up state, I've tried to bootstrap a subhurd, to check if everything would work cleanly there. Again, I've successfully used debootstrap to create subhurds on
this same system before.
The Hurd wiki page on subhurds [2] suggests the following command:
debootstrap sid mnt/ http://httpredir.debian.org/debian
[2]: https://www.gnu.org/software/hurd/hurd/subhurd.html
W: Retrying failed download of http://snapshot.debian.org/archive/debian-ports/20210812T100000Z/pool-hurd-i386/main/g/gcc-10/libgcc-s1_10.2.1-6_hurd-i386.deb
W: http://snapshot.debian.org/archive/debian-ports/20210812T100000Z/pool-hurd-i386/main/g/gcc-10/libgcc-s1_10.2.1-6_hurd-i386.deb
was corrupt
W: Couldn't download package libgcc-s1 (ver 10.2.1-6 arch hurd-i386)
at http://snapshot.debian.org/archive/debian-ports/20210812T100000Z/pool-hurd-i386/main/g/gcc-10/libgcc-s1_10.2.1-6_hurd-i386.deb
then later the same thing for libstdc++6; the rest of the packages get downloaded successfully and pass the validation.
That surely looks like something's broken about the repos, and not in my system!
The log contains the following:
Processing triggers for libc-bin (2.32-4) ...
Errors were encountered while processing:
rsyslog
dpkg: dependency problems prevent configuration of rsyslog:
rsyslog depends on libjson-c3 (>= 0.10); however:
Package libjson-c3 is not installed.
$ su
su: Authentication failure
$ sudo echo hi
Sorry, try again.
Sorry, try again.
sudo: 3 incorrect password attempts
I've verified that I see the same behavior on darnassus,
Hello,
Answering separately since they are completely separate issues.
Sergey Bugaev, le jeu. 30 sept. 2021 15:35:41 +0300, a ecrit:
- Filesize:77531148 [weak]
- SHA512:c8108d738ef08afa9556ec395e0b8097e54f66347cce924303b6294dcfa32a4a3853b29597902372562542c7b73ca364be44234d3c0b709e992ad19fa6b566a2
- SHA256:06de0c824e0ff3e683a5698ebd63892c34f264eff7d311a7e3a225dd894f8457
- SHA1:4b881bd3628a18f0917b55349563fe6a95f25887 [weak]
- MD5Sum:65d941cde7d7279bbecfe22c67ff40fa [weak]
Hashes of received file:
- SHA512:9fae8af5d37a72f3410c9c0c70d75c4677b9ee8933bd3a05c8cb20e59430f7b56fb060b6d0cba41a20ac0e7d878cd447a6936b740ffc3536b74afe0fd31d90bb
- SHA256:06de0c824e0ff3e683a5698ebd63892c34f264eff7d311a7e3a225dd894f8457
- SHA1:4b881bd3628a18f0917b55349563fe6a95f25887 [weak]
- MD5Sum:65d941cde7d7279bbecfe22c67ff40fa [weak]
- Filesize:77531148 [weak]
I'm primarily concerned about the hashsum check failures. In all of the cases, filesize, md5, sha1, and sha256 seem to match, but sha512 differs between expected and received. I can't really imagine how this could be possible unless sha512 was just computed incorrectly either remotely or locally.
That's odd indeed. Which gnumach kernel were you using? I noticed an FPU context switch bug in gnumach, possibly that was affecting only the
sha512 implementation. It is fixed in version 2:1.8+git20210923-1.
On Fri, Oct 8, 2021 at 12:33 AM Samuel Thibault <sthibault@debian.org> wrote:
Hello,
Answering separately since they are completely separate issues.
Thanks a lot for taking a look!
That's odd indeed. Which gnumach kernel were you using? I noticed an FPU context switch bug in gnumach, possibly that was affecting only the
sha512 implementation. It is fixed in version 2:1.8+git20210923-1.
2:1.8+git20210828-1, according to 'apt policy'. I cannot install a
different (newer) one for obvious reasons; though I should be able to
build one from source, boot it, and if that fixes the issue, update
properly.
Hello,
Answering separately since they are completely separate issues.
That's odd indeed. Which gnumach kernel were you using? I noticed an FPU context switch bug in gnumach, possibly that was affecting only the
sha512 implementation. It is fixed in version 2:1.8+git20210923-1.
I've verified that I see the same behavior on darnassus,
I don't see it happen on darnassus.
Please always check the latest version of the wiki pages on darnassus,
there it was fixed:
debootstrap --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg --extra-suites=unreleased sid chroot http://deb.debian.org/debian-ports/
The log contains the following:
Processing triggers for libc-bin (2.32-4) ...
Errors were encountered while processing:
rsyslog
dpkg: dependency problems prevent configuration of rsyslog:
rsyslog depends on libjson-c3 (>= 0.10); however:
Package libjson-c3 is not installed.
Yes, that's why you need the unreleased part.
Or perhaps you happen to know of an apt flag/option to
ignore sha512 and temporarily rely on other hashes?
Was the FPU context bug introduced recently (as in, several months
ago)? If it wasn't, the checksum issues must be caused by something
else.
That's because vim is currently failing to build, and thus we get
trapped again by the version difference between vim and vim-common.
"Unstable" has its name for a reason :)
On Fri, Oct 8, 2021 at 2:20 PM Samuel Thibault <sthibault@debian.org> wrote:
That's because vim is currently failing to build, and thus we get
trapped again by the version difference between vim and vim-common.
"Unstable" has its name for a reason :)
Even ignoring vim for a second (I could/should attempt to exclude it
'cause I don't use it anyways), the "syslog depends on {libjson-c3,liblogging-stdlog0,liblognorm2}" still happens with
unreleased. That is, adding unreleased only increased the number of
issues (adding vim).
On Fri, Oct 8, 2021 at 2:20 PM Samuel Thibault <sthibault@debian.org> wrote:
That's because vim is currently failing to build, and thus we get
trapped again by the version difference between vim and vim-common.
"Unstable" has its name for a reason :)
Even ignoring vim for a second (I could/should attempt to exclude it
'cause I don't use it anyways), the "syslog depends on {libjson-c3,liblogging-stdlog0,liblognorm2}" still happens with
unreleased. That is, adding unreleased only increased the number of
issues (adding vim).
Sergey
On Fri, Oct 8, 2021 at 12:42 AM Samuel Thibault <sthibault@debian.org> wrote:
I've verified that I see the same behavior on darnassus,
I don't see it happen on darnassus.
Interesting: I've just checked and I no longer see it on darnassus
either! But I'm 100% positive I saw it there. Could it be that
darnassus has been updated in the meantime (between Sep 30 and today)?
(By the way, there seems to be some issue with /home again.)
To create a file my.image of size 2 gigabytes, do
$ dd if=/dev/zero of=my.image bs=1M count=1 seek=2000
(Note that it is currently problematic to create files larger than 2 gigabytes this way.)
A proper fix would be to extend
device_get_status () to support sizes that don't fit into a single
32-bit int; perhaps by using a third int and a new "flavor".
On Fri, Oct 8, 2021 at 8:49 PM Samuel Thibault <sthibault@debian.org> wrote:
That's the "Extend `device_read`/`device_write` into supporting > 2TiB
disk sizes." item in the "small hack entries" list. There's indeed the device_get_status() call that needs fixing, but device_read/write as
well, they need to be extended to 64bit record numbers.
Right. But 2 GB for a subhurd is a much more severe limitation than 2 TB.
I wonder if it'd be possible to change device_{read,write} to use a
64-bit integer without introducing separate new RPCs,
That's the "Extend `device_read`/`device_write` into supporting > 2TiB
disk sizes." item in the "small hack entries" list. There's indeed the device_get_status() call that needs fixing, but device_read/write as
well, they need to be extended to 64bit record numbers.
On Fri, Oct 8, 2021 at 9:03 PM Samuel Thibault <sthibault@debian.org>
wrote:
Sergey Bugaev, le ven. 08 oct. 2021 21:01:09 +0300, a ecrit:
I wonder if it'd be possible to change device_{read,write} to use a 64-bit integer without introducing separate new RPCs,
No: RPC interfaces have fixed typing, expressed in the mig files.
RPC interfaces are whatever we want them to be :) — as long as we keep things compatible with old clients. Specifically, we could say,
type recnum_t = uint64_t | array[*:2] of uint32_t;
and voila, (new) clients send 64-bit numbers, but the servers can accept either.
I'm more concerned that it would change glibc ABI, as clients would
now be expected to pass 64-bit numbers.
Trying to magically extent is asking for much more trouble than just
adding the new RPCs.
I'm not saying that I'm convinced that it's worth it — perhaps adding
new RPCs and switching all users to them would be easier. But it's an interesting possibility.
Sergey
type recnum_t = uint64_t | array[*:2] of uint32_t;
Sergey Bugaev, le ven. 08 oct. 2021 21:01:09 +0300, a ecrit:
I wonder if it'd be possible to change device_{read,write} to use a
64-bit integer without introducing separate new RPCs,
No: RPC interfaces have fixed typing, expressed in the mig files.
Trying to magically extent is asking for much more trouble than just
adding the new RPCs.
On Fri, Oct 08, 2021 at 01:09:38PM +0300, Sergey Bugaev wrote:
On Fri, Oct 8, 2021 at 12:42 AM Samuel Thibault <sthibault@debian.org> wrote:
I've verified that I see the same behavior on darnassus,
I don't see it happen on darnassus.
Interesting: I've just checked and I no longer see it on darnassus
either! But I'm 100% positive I saw it there. Could it be that
darnassus has been updated in the meantime (between Sep 30 and today)?
It most likely has, yes.
(By the way, there seems to be some issue with /home again.)
Ugh. I'm not available to fix them right now, but I'll check next week.
$ nm -D /usr/lib/i386-gnu/libkrb5.so.3 | grep krb5int_c_combine_keys
U krb5int_c_combine_keys@k5crypto_3_MIT
$ file /usr/lib/i386-gnu/libkrb5.so.3
/usr/lib/i386-gnu/libkrb5.so.3: symbolic link to libkrb5.so.3.3~0
$ dpkg -S /usr/lib/i386-gnu/libkrb5.so.3.3~0
dpkg-query: no path found matching pattern /usr/lib/i386-gnu/libkrb5.so.3.3~0
I don't know what to make of that.
Which version do you have?
Perhaps just
apt install --reinstall libkrb5-3
so that it reinstalls the libkrb5.so.3 symlink (which in version
1.18.3-7 is supposed to point to libkrb5.so.3.3).
Diversions show up in /var/lib/dpkg/diversions.
$ file /usr/lib/i386-gnu/libkrb5.so.3
/usr/lib/i386-gnu/libkrb5.so.3: symbolic link to libkrb5.so.3.3~0
Could this be an effect of some "diversion"? How do I check?
On Mon, Oct 11, 2021 at 6:41 PM Samuel Thibault <sthibault@debian.org> wrote:
Diversions show up in /var/lib/dpkg/diversions.
There's nothing about libkrb5 in there :|
Are there any other tools left to investigate why dpkg is fine with
this, and where libkrb5.so.3.3~0 comes from? Should I just forcefully
delete libkrb5.so.3.3~0 along with the symlink, and reinstall the
package again?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (3 / 13) |
Uptime: | 86:24:01 |
Calls: | 6,496 |
Calls today: | 7 |
Files: | 12,099 |
Messages: | 5,277,030 |