Debian/Hurd: Console Timeout Error

[Charlie Sale]

Hello Hurd.

I believe that I commented on this in another thread, but I figured
I should put this into a new thread because it is its own topic and
it might apply to someone else.

I am trying to run Debian/Hurd on qemu, specifically qemu-system-i386.
The command that I am running it with is:
| qemu-system-i386 \
| -net user,hostfwd=tcp:127.0.0.1:8888-:22 -net nic \
| -drive file=debian-hurd-20171101.img,cache=writeback -m 1G

I get two major issues. The foremost being that he console times
out. I get the error:
| /bin/console: Could not recieve return value from daemon process:
| Connection Timeout
whenever the console begins to boot up. This is a big issue because I
cannot interact with the system. I have tried connecting via ssh (I
start the system with port forwarding), but the system is not configured
to allow connection without a password (the root user does not have a
password, so trying to login with a blank password does not work).

The other major issues is that fsck fails during the boot. I don't know
if this is as important as the console failure, but I thought I would
point it out.

I hope that someone has a remedy.

Cheers!
Charlie
--
-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBFpKrgwBCADaPosQdy9rTpDmGp7y+m7QCW3w3AGtPgoBRJVwuXyOnRp/Q8Xg
jMaQF17GmRgy54+eZJJV5vQNrXAvTo7hX5lAjNTu0EawPE53zQZ7CFGT8YEjlJ8j
PYh5Tp02ckQxZQOZqyIQS2w2CqCZYhSeq2l50pNA2Rutxd2an1DBzdH/1zBnY5qo
r+8N5MgNBcvjgaWiT8kAefHHlD+ssWygg1yVUzxHbOoLWRi24o0mKn6a24fP5EHr
uZXfsoC1Vrhb8RjyftXw0DPFavx6Zi7VIHv68MB/aBVEtMHisCyHlfnqFTMcgKWh
hV5ZC5OR7ELNhNZ82+BoTVH5oA5bD5Hi9tklABEBAAG0J0NoYXJsaWUgU2FsZSA8
c29mdHdhcmVzYWxlMDFAZ21haWwuY29tPokBOAQTAQIAIgUCWkquDAIbAwYLCQgH
AwIGFQgCCQoLBBYCAwECHgECF4AACgkQjFElWoJ7azJvjgf/TtI2/F7xPRUzPaTi
opGbkPXgZMDrRCXK58NQMmUHXmLAwMx2MbfKOhu0hXvZw5ITlkN++bZyXZTiHLwf
fGU5BvtXFKoO8YcZtfbzsUSs3O31hNAuaEm3jwUR1LnoBYJk0Rv1/fnJKdwsUKO9
EvVRSv7CbQh3TLN1aH4RhUAf6NSvDiqv0AwKxceIZsRBf8AbsodlNpxZPay82M2X
YRMyv4sqbeLycXXqOxZMS8BGvzG1O0MobnJ7r/AsqAUUBQrHMEVhpaQgdJ4DMLDl
8KgaynN9vw6/hzl6HkeGHjk2BeUhQZ5Uae++Ot20q1+1b9SHv8YNmnC3PixXGz1G
nFyZ0bkBDQRaSq4MAQgAxWdDdccMwoKmaT6icAJGeFg3sNlgqJ8pF9sK6/QtObUl
fq/MQl2PLP5GjoH1rx8ptms7w3QeTEMJJZweSKD6Fot3R1mQ5mxkxIpR/t/5hS+n
WfqFM+Ri8Va51vBZetTge21ynKac1O1ZGIA2ySKPGexW/ouAWnpZIasmQ0LWnryh
aFNEB9ND0Eork6xjptXRGcBb98trCeiQAc4bffgHpC945f483dScdIcu192QAcY+
J9PAw8eY824s4stx8+Mvu3aaFb7SZEgAPN3WXgjMBY0jysxstAqfxxv78tHCt7uU
AOMRE2pS5nzbEcKakB2VuB4eRFVNb9Qk5Ogw+0wOGQARAQABiQEfBBgBAgAJBQJa
Sq4MAhsMAAoJEIxRJVqCe2sy/r4IAJl96tBtsk2y90J7oT1Z4KIW9zL/2lj//4FY
OU5MbGBMocmzSaosNIZDOQphzvJZGHtxpfp4WkZEU+5wi4n6OqAXoE9Uc8qKImfY
L7FXhRnnXpVuFZOpau/fSijKa5xpoGStBUE3rBm7l+U/FQqsXmmErij1EMcEu8fl
Qu2iFb1elkbticZMcczdAHPpNOwSffnhwx/sOsSqGmw0L+FgMkrnuOIpzMHhjKEC
6n63wBQG3IMNzMyUbsL35p7sz6pn8yk+WUB+NFFrIUbxlDMzRJg73ZZoivELBZik
KWTQS9fP5aQBXz5eNM7KE8v/+BIaNw4dG1i7pZKiFz5qGOkR8M0=
=0Ueh
-----END PGP PUBLIC KEY BLOCK-----

[Svante Signell]

Post by Charlie Sale
The other major issues is that fsck fails during the boot. I don't
know if this is as important as the console failure, but I thought I
would point it out.

Hi Charlie,

You should check your image from your Linux host:
NOTE: Check the offset for your / partition
fdisk -l debian-hurd-20171101.img
2048*512 = 1048576
su
/sbin/losetup -o 1048576 /dev/loop0 debian-hurd-20171101.img
e2fsck -y /dev/loop0
losetup -d /dev/loop0
exit

After that I think your image will boot fine.

[Charlie Sale]

I tried doing that, but I got some errors during the process. Here is what
I did:

1. $ fdisk -l debian-hurd*.img
*output*:
Device Boot Start End Sectors Size Id Type
debian-hurd-20171101.img1 2048 1953791 1951744 953M 82 Linux swap
/ Solaris
debian-hurd-20171101.img2 1955838 10239999 8284162 4G 5 Extended
debian-hurd-20171101.img5 1955840 10239999 8284160 4G 83 Linux

2. # losetup -o 1955838 /dev/loop0 debian-hurd-20171101.img
Which worked fine.

3. e2fsck -y /dev/loop0

*output*:
e2fsck 1.43.5 (04-Aug-2017)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/loop0

The superblock could not be read or does not describe a valid
ext2/ext3/ext4
filesystem. If the device is valid and it really contains an
ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>

I tried doing both of the suggested remedy commands, but neither worked.
They just
returned the same output.

Because these commands failed, nothing changed in booting my Debian.

Thanks for trying to help. Any more suggestions?

Thanks!
Charlie

Post by Svante Signell

Post by Charlie Sale
The other major issues is that fsck fails during the boot. I don't
know if this is as important as the console failure, but I thought I
would point it out.

Hi Charlie,
NOTE: Check the offset for your / partition
fdisk -l debian-hurd-20171101.img
2048*512 = 1048576
su
/sbin/losetup -o 1048576 /dev/loop0 debian-hurd-20171101.img
e2fsck -y /dev/loop0
losetup -d /dev/loop0
exit
After that I think your image will boot fine.

[Joshua Branson]

Maybe try downloading a new qemu image? Sometimes this happens to me,
and I just give up and try using a new qemu image...

Post by Charlie Sale
1. $ fdisk -l debian-hurd*.img
Device Boot Start End Sectors Size Id Type
debian-hurd-20171101.img1 2048 1953791 1951744 953M 82 Linux swap / Solaris
debian-hurd-20171101.img2 1955838 10239999 8284162 4G 5 Extended
debian-hurd-20171101.img5 1955840 10239999 8284160 4G 83 Linux
2. # losetup -o 1955838 /dev/loop0 debian-hurd-20171101.img
Which worked fine.
3. e2fsck -y /dev/loop0
e2fsck 1.43.5 (04-Aug-2017)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/loop0
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
I tried doing both of the suggested remedy commands, but neither worked. They just
returned the same output.
Because these commands failed, nothing changed in booting my Debian.
Thanks for trying to help. Any more suggestions?
Thanks!
Charlie

Post by Charlie Sale
The other major issues is that fsck fails during the boot. I don't
know if this is as important as the console failure, but I thought I
would point it out.

Hi Charlie,
NOTE: Check the offset for your / partition
fdisk -l debian-hurd-20171101.img
2048*512 = 1048576
su
/sbin/losetup -o 1048576 /dev/loop0 debian-hurd-20171101.img
e2fsck -y /dev/loop0
losetup -d /dev/loop0
exit
After that I think your image will boot fine.

[Svante Signell]

Post by Charlie Sale
I tried doing that, but I got some errors during the process. Here is
1. $ fdisk -l debian-hurd*.img
Device                    Boot   Start      End Sectors  Size Id
Type 
debian-hurd-20171101.img1         2048  1953791 1951744  953M 82
Linux swap / Solaris 
debian-hurd-20171101.img2      1955838 10239999 8284162    4G  5
Extended 
debian-hurd-20171101.img5      1955840 10239999 8284160    4G 83
Linux
2. # losetup -o 1955838 /dev/loop0 debian-hurd-20171101.img
Which worked fine.

I think you need to use -o 1955838*512 as offset. However, take a look
at kpartx. With that tool you get better control. And you really need
to find out where / is mounted. Why do you have Solaris and Linux
partitions in that image?

[Samuel Thibault]

Post by Svante Signell

Post by Charlie Sale
Device                    Boot   Start      End Sectors  Size Id
debian-hurd-20171101.img2      1955838 10239999 8284162    4G  5
Extended 
debian-hurd-20171101.img5      1955840 10239999 8284160    4G 83
Linux
2. # losetup -o 1955838 /dev/loop0 debian-hurd-20171101.img
Which worked fine.

I think you need to use -o 1955838*512 as offset.

Actually, rather 1955840*512 since it's the ext2fs volume you want to
mount, not the extended partition.

Samuel

[Samuel Thibault]

Hello,

Post by Charlie Sale
I am trying to run Debian/Hurd on qemu, specifically qemu-system-i386.

Which version of qemu is this exactly?

Samuel

[Charlie Sale]

Alright. A quick update:

So I created a disk from scratch. I use that, and the console works fine. I
can type on it and everything. Yay.

However, I cannot login. It says that the root password is empty. So ill do
something like this:

User: root
Password: \n
login: Invalid password

Or I'll use a space
User: root
Password: _\n
login: Invalid Password

Or, I'll type in "empty"
User: root
Password: empty\n
login Invalid Password

And also, to answer your question, I am running qemu version 2.10.1

Any ideas on how to fix? Thanks!

Charlie

Post by Samuel Thibault
Hello,

Post by Charlie Sale
I am trying to run Debian/Hurd on qemu, specifically qemu-system-i386.

Which version of qemu is this exactly?
Samuel

[Samuel Thibault]

So I created a disk from scratch. I use that, and the console works fine. I can
type on it and everything. Yay.
However, I cannot login. It says that the root password is empty.

How did you create the disk exactly?

Samuel

[Charlie Sale]

I followed the directions from the qemu images sections. Basically, I
created a new image with qemu-img. Then, I ran qemu with that as the disk,
and I used a net installer in the CD-ROM. I then followed installation
instructions. I installed onto the right disk.

Does this answer your question.

Charlie

Post by Charlie Sale
So I created a disk from scratch. I use that, and the console works

fine. I can

Post by Charlie Sale
type on it and everything. Yay.
However, I cannot login. It says that the root password is empty.

How did you create the disk exactly?
Samuel

[Samuel Thibault]

I followed the directions from the qemu images sections. Basically, I created a
new image with qemu-img. Then, I ran qemu with that as the disk, and I used a
net installer in the CD-ROM. I then followed installation instructions. I
installed onto the right disk.

Ok, but then you did type a root password during the installation
process, didn't you?
(if not, then as described on the question screen root won't be allowed
to log in directly, only the normal user will, and sudo is needed to
become root)

Samuel

[Joshua Branson]

Maybe I'll being really silly here, but isn't root password empty mean
you just press RET?

User: root
Password: <RET>

So I created a disk from scratch. I use that, and the console works fine. I can type on it and everything. Yay.
User: root
Password: \n
login: Invalid password
Or I'll use a space
User: root
Password: _\n
login: Invalid Password
Or, I'll type in "empty"
User: root
Password: empty\n
login Invalid Password
And also, to answer your question, I am running qemu version 2.10.1
Any ideas on how to fix? Thanks!
Charlie
Hello,

Post by Charlie Sale
I am trying to run Debian/Hurd on qemu, specifically qemu-system-i386.

Which version of qemu is this exactly?
Samuel

[Samuel Thibault]

Post by Joshua Branson
Maybe I'll being really silly here, but isn't root password empty mean
you just press RET?

Actually no, it happens that an empty password leads to no password
prompt.

Nothing silly, just something to know :)

Samuel

[Joshua Branson]

Oh, good to know! haha!