Re: Installing Debian GNU/Hurd in qemu/kvm using the Debian Installer (first draft)

[Svante Signell]

On Tue, 2011-03-29 at 18:17 +0200, olafBuddenhagen@gmx.net wrote:
> Hi,
> 
> On Wed, Mar 23, 2011 at 10:27:31AM +0100, Svante Signell wrote:
> 
> > Attached is the first draft on how to install and run Debian GNU/Hurd
> > using the Debian Installer.
> 
> Great, thanks! :-)
> 
> Will have to be turned into markdown though to add it to the wiki...
> 
> > Enable VTx and VTd
> 
> Actually, VTd doesn't seem relevant to what you are doing... It's only
> necessary if you give the guest system direct access to certain hardware
> devices.

OK, I'll make a comment on the VTd part.

> > If qemu is installed:
> > qemu-img create hurd-install.qemu 4G
> > 
> > If qemu-kvm is installed:
> > kvm-img create hurd-install.kvm 4G
> 
> Does KVM really use different images than plain QEMU? Or is it the same
> utility, but uses a different name depending on which package you
> installed?...

No I just used different notations to show if qemu or qemu-kvm was used.
Renamed to *.img

> > QEMU VLAN     <------>  Firewall/DHCP server <-----> Internet
>                           ^^^^^^^^^^^^^^^^^^^^
> 
> That's generally called "gateway router", or often just "gateway" or
> just "router", depending on context. (The last is what most people are
> likely to understand nowadays.)
> 
> I must say though that I'm not familiar with qemu networking; so maybe
> my remark is not relevant here...
> 
> (BTW, "firewall" is not relevant here anyways -- the decisive bit is
> NAT; which is done by the same iptables infrastructure in Linux, but
> conceptually not really the same thing...)

This picture was found somewhere on the Web (I don't remember where
now). Changed to Gateway/DHCP server.

> > deb http://ftp.debian-ports.org/debian unstable main
>                                          ^^^^^^^^
> 
> That should be "unreleased".

Fixed!

> BTW, doesn't the installer set this up correctly?...

Obviously not.

> > A few words about the Mach console:
> > ===================================
> > This console is very primitive and does not have any scrolling facilities.
> > Use the mach console only for basic work.
> 
> Note that the Hurd console also has a number of drawbacks. (One of which
> you actually mention later on: not seeing kernel messages. But there are
> other issues too.) So the preference is not at all clear. There is a
> reason why it's not enabled by default...

I agree, neither of them are perfect. I prefer to use a terminal window
with ssh (and where your local keyboard mapping works...)

> Also note that using the "screen" program on Mach console is also a
> pretty good choice.

Don't know anything about screen, what to write here?

> > 2) Hurd console after boot: Log in to the Mach console and run the
> > executable script: hurd-console
> > 
> > a) As user: sudo ./hurd-console (add yourself to the sudoers with visudo)
> > b) As root ./hurd-console
> > 
> > hurd.-console:
> > console -d vga -d pc_mouse --repeat=mouse -d pc_kbd --repeat=kbd -d 
> > generic_speaker -c /dev/vcs
> 
> I don't see much point in creating a script for this -- once used, the
> command can be easily fetched from shell history...

Yes, but in the Mach console you cannot do editing easily (and you have
to write this on your local keyboard with the US keyboard hidden below.
easy if wou have a US keyboard, error prone otherwise (ask me)).

> Either way, I don't think it's useful to describe it as a script in the
> install guide -- just makes it more confusing. If someone likes a script
> or alias, it's up to them to create one :-)
> 
> > Create .xinitrc:
> > xrandr -s 1024x768 &
> 
> Can't that be specified in xorg.conf instead?

Maybe, I don't currently remember the syntax.

> > As user: sudo startx
> > As root: startx (not recommended)
> 
> Why root? It works fine as normal user here... It's generally not
> recommended to run a whole X session as root.

We still have the bug when exiting X as user, see Samuels reply.

> > Note: Make sure you are starting X from the Hurd console otherwise X
> > will not work.
> 
> Note that it's not actually necessary to run it *from* the Hurd console.
> The console must be running; but you can issue startx from an ssh
> session too...

Yes you are right, it can be started from an ssh session too, but you
need to use the Hurd console, since X will come up in the qemu window.