Re: report on debian-9.0-sparc64-NETINST-1.iso with qemu

2017-01-27 Thread Bruno Haible 
I wrote:
> 2) The installed system now boots, either by entering
>  1/vmlinuz initrd=/initrd.img root=/dev/sda2
> at the SILO prompt, or by letting this prompt timeout. However, the boot 
> process
> hangs after one minute, after this output:
> 
>  Starting udev Kernel Device Manager...
> [  OK  ] Started udev Kernel Device Manager.
> [  OK  ] Found device /dev/ttyS0.
> [   66.121368] sd 0:0:0:0: Attached scsi generic sg0 type 0
> [   66.137222] sr 1:0:0:0: Attached scsi generic sg1 type 5
> [   66.384970] [drm] Initialized drm 1.1.0 20060810
> [   66.726958] [drm] Found bochs VGA, ID 0xb0c5.
> [   66.727424] [drm] Framebuffer size 16384 kB @ 0x1ff0100, mmio @ 
> 0x1ff0200.
> [   66.773438] [TTM] Zone  kernel: Available graphics memory: 248620 kiB
> [   66.774061] [TTM] Initializing pool allocator

The fix for this is to add
  -vga none
to the qemu command line.

I first tried variations of kernel parameters (with and without -nographic):
1/vmlinuz initrd=/initrd.img root=/dev/sda2 video=atyfb:1024x768@60
1/vmlinuz initrd=/initrd.img root=/dev/sda2 video=sbus:off
1/vmlinuz initrd=/initrd.img root=/dev/sda2 video=atyfb:off
but this had no effect: I could not convince Linux not to use the VGA graphics
card for a frame buffer. So I finally "removed" the graphics card from the
emulated computer.

I think '-nographic' cannot have an effect in such a situation because it
affects only the _presentation_ in the host system of the emulated hardware.
And the guest OS running in the emulated hardware behaves independently of how
it's displayed in the host.

Adrian Glaubitz wrote:
> Did you try -nographic? This should create an emulated serial console device.

The emulated serial console device also exists when I use '-display gtk' instead
of '-nographic'. There's a menu item in the window that allows me to see its
contents.

  Bruno

Re: failing debootstrap

2017-01-27 Thread Yaroslav Halchenko 

On Mon, 23 Jan 2017, John Paul Adrian Glaubitz wrote:
> > So installation was completed ok and the beast rebooted but doesn't boot 
> > (see
> > below the transcript from the screen).  May be the reason is my obnoxious (I
> > guess I like that word that much to use twice) partitioning

> > 2 drives partitioned (RAID part + swap part) -> MD RAID1 -> LVM -> / (ext3)

> > So may be SILO just can't find/boot from such an abomination and I should 
> > have
> > created a small boot partition for it first?

> Exactly. As long as you're using SILO, your boot partition should be on a 
> plain
> and simple ext3 partition to avoid any issues.

> You can try to install grub2 from the "unreleased" repository manually during
> the installation by opening a shell from the debian-installer, chrooting into
> /target, running "apt update && apt install grub2". But I haven't tested this
> _at all_, so I can't tell if this works or not.

> However, any tests with the +sparc64 grub2 version from "unreleased" are 
> highly
> appreciated and welcome on the list.

I was weak -- having seen some discussions on the list with grub2 issues I just
went first old SILO way.  It was quite a bit painful to have drive
repartitioned since changes to the partitioning were not picked up by the
kernel unless I rebooted it and I was trying to split swap partition into boot
and swap two partitions.

And after installation succeeded and boot went on, the problem is as I
have reported on IRC:

  I am enjoying partial success with installing sparc64 on ultrasparc T5140. 
used installer cd from last may. interesting
  glitch is that system when booted doesn't see any partitioning of the drives 
-- only LVM volume for the / is available
  this precludes enabling swaps and mounting /boot
  here is how it looks:

root@sparky:/tmp# fdisk -l /dev/sd[ab]
Disk /dev/sda: 136.7 GiB, 146810536448 bytes, 286739329 sectors
Geometry: 255 heads, 63 sectors/track, 17848 cylinders
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: sun

Device Start   End   Sectors   Size Id Type  Flags
/dev/sda1  0 267193079 267193080 127.4G fd Linux raid autodetect  
/dev/sda2  267193080 269153009   1959930   957M  1 Boot   
/dev/sda3  0 286728119 286728120 136.7G  5 Whole disk 
/dev/sda4  269153010 286728119  17575110   8.4G 82 Linux swap 


Disk /dev/sdb: 136.7 GiB, 146810536448 bytes, 286739329 sectors
Geometry: 255 heads, 63 sectors/track, 17848 cylinders
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: sun

Device Start   End   Sectors   Size Id Type  Flags
/dev/sdb1  0 267193079 267193080 127.4G fd Linux raid autodetect  
/dev/sdb2  267193080 286728119  19535040   9.3G 82 Linux swap 
/dev/sdb3  0 286728119 286728120 136.7G  5 Whole disk 
root@sparky:/tmp# ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root  9 Jan 26 09:36 2016-05-04-14-13-13-00 -> ../../sr0
lrwxrwxrwx 1 root root 10 Jan 26 09:28 70cd7f29-78c4-4907-9101-ffdc2a7c8582 -> 
../../dm-0
root@sparky:/tmp# ls -l /dev/disk/by-id/
total 0
lrwxrwxrwx 1 root root 10 Jan 26 09:28 dm-name-disks-debian -> ../../dm-0
lrwxrwxrwx 1 root root 10 Jan 26 09:28 
dm-uuid-LVM-SHQBSSnkYpgqZEVBwqjrJHNngR3xnryCTemrrQ6v4auqKYt71XZcNsFm1YDGoP4b -> 
../../dm-0
lrwxrwxrwx 1 root root  9 Jan 26 09:28 
lvm-pv-uuid-kk1bpa-GzIa-J2dr-Rg3s-goiP-67p6-BoOzAV -> ../../md0
lrwxrwxrwx 1 root root  9 Jan 26 09:28 md-name-megaspark:0 -> ../../md0
lrwxrwxrwx 1 root root  9 Jan 26 09:28 
md-uuid-72005f8f:6bb79fc7:44b4d997:897c735a -> ../../md0
lrwxrwxrwx 1 root root  9 Jan 26 09:28 scsi-35000c5000f3e0453 -> ../../sda
lrwxrwxrwx 1 root root  9 Jan 26 09:28 scsi-35000c5000f3e9697 -> ../../sdb
lrwxrwxrwx 1 root root  9 Jan 26 09:36 
usb-TSSTcorp_CD_DVDW_TS-T632A_B030B0D6311A-0:0 -> ../../sr0
lrwxrwxrwx 1 root root  9 Jan 26 09:28 wwn-0x5000c5000f3e0453 -> ../../sda
lrwxrwxrwx 1 root root  9 Jan 26 09:28 wwn-0x5000c5000f3e9697 -> ../../sdb
root@sparky:/tmp# ls -ld /dev/sd*
brw-rw 1 root disk 8,  0 Jan 26 09:28 /dev/sda
brw-rw 1 root disk 8, 16 Jan 26 09:28 /dev/sdb


kernel: 4.5.0-2-sparc64-smp

any clues how to mitigate or what is possibly wrong?

PS please CC me in replies

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Re: report on debian-9.0-sparc64-NETINST-1.iso with qemu [SOLVED]

2017-01-27 Thread Mark Cave-Ayland 
On 27/01/17 18:52, Bruno Haible wrote:

> Yeah! This works! The machine now can connect to the internet.
> The ifconfig output now is:
> 
> # /target/sbin/ifconfig
> enp0s5: flags=4163  mtu 1500
> inet 10.0.2.15  netmask 255.255.255.0  broadcast 0.0.0.0
> inet6 fec0::5054:ff:fe12:3456  prefixlen 64  scopeid 0x40
> inet6 fe80::5054:ff:fe12:3456  prefixlen 64  scopeid 0x20
> ether 52:54:00:12:34:56  txqueuelen 1000  (Ethernet)
> RX packets 291  bytes 263098 (256.9 KiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 174  bytes 15608 (15.2 KiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
> lo: flags=73  mtu 65536
> inet 127.0.0.1  netmask 255.0.0.0
> inet6 ::1  prefixlen 128  scopeid 0x10
> loop  txqueuelen 1  (Local Loopback)
> RX packets 0  bytes 0 (0.0 B)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 0  bytes 0 (0.0 B)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
> # lsmod | grep virt
> virtio_net 24168  0
> virtio_pci 14583  0
> virtio_ring12099  2 virtio_net,virtio_pci
> virtio  6188  2 virtio_net,virtio_pci
> 
> (qemu) info network
> virtio-net-pci.0: 
> index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
>  \ hostnet0: index=0,type=user,net=10.0.2.0,restrict=off
> 
> Thanks a lot!

Excellent! I should add that qemu-system-sparc64 should support virtio
1.0 at some point when I get some time to figure out why it hangs - all
that's happened is that the default flipped from legacy to modern with
the last QEMU release which is why this is now suddenly visible.


ATB,

Mark.

Transporte de Carga desde los 4 puertos principales del pais

2017-01-27 Thread Departamento de Gestion Comercial 
[1] web

[2] nuestros servicios

 forum

[3] contacto

servicios ofrecidos
transmaquina
transporte de carga y alquiler de maquinaria

estimados srs.


quedamos a sus ordenes como proveedores serios y motivados a prestarles un 
excelente servicio en toda venezuela.

en caso de necesitar servicios de:

transporte de carga
alquiler de maquinaria de construcción
alquiler de grúas telescopicas
tansporte de carga extradimensionada
transporte de cemento a granel

reciban un cordial saludo,

luis arriaga
gerente comercial
[4] ven...@transmaquina.com.ve
0424-1362899

[5] www.transmaquina.com.ve

[6] visitar página web

información adicional

cobertura geográfica
prestamos servicios en toda venezuela , ya que trabajamos como aliados en las 
principales ciudades del país.

venta de equipos
prestamos el servicio de venta de equipos. nos encargamos de publicidad de 
venta de camiones, gandolas, maquinaria, grúas y montacargas.
este mensaje fue enviado a t...@test.com por gerencia comercial - luis arriaga
caracas, miranda, venezuela, caracas, miranda  1070, venezuela

cancelar suscripción| administre su suscripción| remitir email| reportar abuso


 References:

1. u=5f04de7
2. u=5f04de7
3. u=5f04de9
4. mailto:ven...@transmaquina.com.ve
5. u=5f04dea
6. u=5f04deb

This message was sent to debian-sparc@lists.debian.org by 
vent...@transmaquina.com.ve

You can modify/update your subscription via the link below.

Unsubscribe from all mailings
http://lt.benchmarkurl.com/c/su?e=AA1B43=717D3=F60F052=Kka4Ai3k4gTPGjr4B%2BVXHvldOwIQaPD7WzlRiT%2FO9%2Fk%3D=A0B1119


Caracas, Miranda, Venezuela, Caracas, Miranda  1070, Venezuela

Email Marketing
BenchmarkEmail.com
 [http://lt.benchmarkurl.com]

Re: report on debian-9.0-sparc64-NETINST-1.iso with qemu [SOLVED]

2017-01-27 Thread Bruno Haible 
Artyom Tarasenko wrote on 27.01.2017:
> On Thu, Jan 26, 2017 at 10:16 PM, Bruno Haible  wrote:
> > Mark Cave-Ayland wrote:
> >> >> The hardware emulated by QEMU on this platform is
> >> >>   hub 0
> >> >>\ hub0port1: user.0: index=0,type=user,net=10.0.2.0,restrict=off
> >> >>\ hub0port0: ne2k_pci.0: 
> >> >> index=0,type=nic,model=ne2k_pci,macaddr=52:54:00:12:34:56
> >> >> Does anyone happen to know?
> >> >
> >> > You should ask Mark Cave-Ayland or Artyom Tarasenko who are the 
> >> > maintainers for
> >> > the SPARC target in qemu.
> >>
> >> I can confirm that virtio does work in QEMU, but only in legacy (0.9)
> >> mode - for some reason if 1.0 mode is used then we seem to hang because
> >> we're missing an interrupt. I've managed to recreate this locally but
> >> not had the time to dig into the details yet - any help always
> >> appreciated :)
> >>
> >> The command line you need for virtio on QEMU looks something like this:
> >>
> >> ./qemu-system-sparc64 -drive
> >> file=debian-9.0-sparc64-NETINST-1.iso,if=none,index=0,id=cd,media=cdrom
> >> -device virtio-blk-pci,disable-modern=on,drive=cd -nographic
> >
> > Thanks for the attempt to help. But I don't have a need for virtio for
> > the disk or cdrom - the default works perfectly fine there. The problem I
> > have is with the network card: the default doesn't work, and virtio
> > (as recommended by Artyom) crashes qemu.
> 
> To be more specific, it's not crashing qemu. It just brings the
> emulated system in a condition in which it won't function (trap after
> the maximal trap level is reached). So it's not necessarily a qemu
> bug. Can be a virtio/kernel bug as well.
> 
> But there is a point in Marks reply: maybe nowadays virtio-net also
> has to be switched into the legacy mode.
> Instead of "-net nic,model=virtio -net user" can you please try:
> 
> -netdev user,id=hostnet0  -device
> virtio-net-pci,disable-modern=off,disable-legacy=off,disable-modern=on,netdev=hostnet0

Yeah! This works! The machine now can connect to the internet.
The ifconfig output now is:

# /target/sbin/ifconfig
enp0s5: flags=4163  mtu 1500
inet 10.0.2.15  netmask 255.255.255.0  broadcast 0.0.0.0
inet6 fec0::5054:ff:fe12:3456  prefixlen 64  scopeid 0x40
inet6 fe80::5054:ff:fe12:3456  prefixlen 64  scopeid 0x20
ether 52:54:00:12:34:56  txqueuelen 1000  (Ethernet)
RX packets 291  bytes 263098 (256.9 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 174  bytes 15608 (15.2 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1  (Local Loopback)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# lsmod | grep virt
virtio_net 24168  0
virtio_pci 14583  0
virtio_ring12099  2 virtio_net,virtio_pci
virtio  6188  2 virtio_net,virtio_pci

(qemu) info network
virtio-net-pci.0: 
index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
 \ hostnet0: index=0,type=user,net=10.0.2.0,restrict=off

Thanks a lot!

Bruno

Re: report on debian-9.0-sparc64-NETINST-1.iso with qemu [SOLVED]

2017-01-27 Thread John Paul Adrian Glaubitz 
Can someone sitting in front of their computer please put that information up 
on the Debian Wiki in the sparc64 section. I'd appreciate that a lot :).

Adrian
(currently on mobile)

> On Jan 27, 2017, at 7:52 PM, Bruno Haible  wrote:
> 
> Artyom Tarasenko wrote on 27.01.2017:
>>> On Thu, Jan 26, 2017 at 10:16 PM, Bruno Haible  wrote:
>>> Mark Cave-Ayland wrote:
>> The hardware emulated by QEMU on this platform is
>>  hub 0
>>   \ hub0port1: user.0: index=0,type=user,net=10.0.2.0,restrict=off
>>   \ hub0port0: ne2k_pci.0: 
>> index=0,type=nic,model=ne2k_pci,macaddr=52:54:00:12:34:56
>> Does anyone happen to know?
> 
> You should ask Mark Cave-Ayland or Artyom Tarasenko who are the 
> maintainers for
> the SPARC target in qemu.
 
 I can confirm that virtio does work in QEMU, but only in legacy (0.9)
 mode - for some reason if 1.0 mode is used then we seem to hang because
 we're missing an interrupt. I've managed to recreate this locally but
 not had the time to dig into the details yet - any help always
 appreciated :)
 
 The command line you need for virtio on QEMU looks something like this:
 
 ./qemu-system-sparc64 -drive
 file=debian-9.0-sparc64-NETINST-1.iso,if=none,index=0,id=cd,media=cdrom
 -device virtio-blk-pci,disable-modern=on,drive=cd -nographic
>>> 
>>> Thanks for the attempt to help. But I don't have a need for virtio for
>>> the disk or cdrom - the default works perfectly fine there. The problem I
>>> have is with the network card: the default doesn't work, and virtio
>>> (as recommended by Artyom) crashes qemu.
>> 
>> To be more specific, it's not crashing qemu. It just brings the
>> emulated system in a condition in which it won't function (trap after
>> the maximal trap level is reached). So it's not necessarily a qemu
>> bug. Can be a virtio/kernel bug as well.
>> 
>> But there is a point in Marks reply: maybe nowadays virtio-net also
>> has to be switched into the legacy mode.
>> Instead of "-net nic,model=virtio -net user" can you please try:
>> 
>> -netdev user,id=hostnet0  -device
>> virtio-net-pci,disable-modern=off,disable-legacy=off,disable-modern=on,netdev=hostnet0
> 
> Yeah! This works! The machine now can connect to the internet.
> The ifconfig output now is:
> 
> # /target/sbin/ifconfig
> enp0s5: flags=4163  mtu 1500
>inet 10.0.2.15  netmask 255.255.255.0  broadcast 0.0.0.0
>inet6 fec0::5054:ff:fe12:3456  prefixlen 64  scopeid 0x40
>inet6 fe80::5054:ff:fe12:3456  prefixlen 64  scopeid 0x20
>ether 52:54:00:12:34:56  txqueuelen 1000  (Ethernet)
>RX packets 291  bytes 263098 (256.9 KiB)
>RX errors 0  dropped 0  overruns 0  frame 0
>TX packets 174  bytes 15608 (15.2 KiB)
>TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
> lo: flags=73  mtu 65536
>inet 127.0.0.1  netmask 255.0.0.0
>inet6 ::1  prefixlen 128  scopeid 0x10
>loop  txqueuelen 1  (Local Loopback)
>RX packets 0  bytes 0 (0.0 B)
>RX errors 0  dropped 0  overruns 0  frame 0
>TX packets 0  bytes 0 (0.0 B)
>TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
> # lsmod | grep virt
> virtio_net 24168  0
> virtio_pci 14583  0
> virtio_ring12099  2 virtio_net,virtio_pci
> virtio  6188  2 virtio_net,virtio_pci
> 
> (qemu) info network
> virtio-net-pci.0: 
> index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
> \ hostnet0: index=0,type=user,net=10.0.2.0,restrict=off
> 
> Thanks a lot!
> 
> Bruno

Re: report on debian-9.0-sparc64-NETINST-1.iso with qemu

2017-01-27 Thread Artyom Tarasenko 
On Thu, Jan 26, 2017 at 10:16 PM, Bruno Haible  wrote:
> Mark Cave-Ayland wrote:
>> >> The hardware emulated by QEMU on this platform is
>> >>   hub 0
>> >>\ hub0port1: user.0: index=0,type=user,net=10.0.2.0,restrict=off
>> >>\ hub0port0: ne2k_pci.0: 
>> >> index=0,type=nic,model=ne2k_pci,macaddr=52:54:00:12:34:56
>> >> Does anyone happen to know?
>> >
>> > You should ask Mark Cave-Ayland or Artyom Tarasenko who are the 
>> > maintainers for
>> > the SPARC target in qemu.
>>
>> I can confirm that virtio does work in QEMU, but only in legacy (0.9)
>> mode - for some reason if 1.0 mode is used then we seem to hang because
>> we're missing an interrupt. I've managed to recreate this locally but
>> not had the time to dig into the details yet - any help always
>> appreciated :)
>>
>> The command line you need for virtio on QEMU looks something like this:
>>
>> ./qemu-system-sparc64 -drive
>> file=debian-9.0-sparc64-NETINST-1.iso,if=none,index=0,id=cd,media=cdrom
>> -device virtio-blk-pci,disable-modern=on,drive=cd -nographic
>
> Thanks for the attempt to help. But I don't have a need for virtio for
> the disk or cdrom - the default works perfectly fine there. The problem I
> have is with the network card: the default doesn't work, and virtio
> (as recommended by Artyom) crashes qemu.

To be more specific, it's not crashing qemu. It just brings the
emulated system in a condition in which it won't function (trap after
the maximal trap level is reached). So it's not necessarily a qemu
bug. Can be a virtio/kernel bug as well.

But there is a point in Marks reply: maybe nowadays virtio-net also
has to be switched into the legacy mode.
Instead of "-net nic,model=virtio -net user" can you please try:

-netdev user,id=hostnet0  -device
virtio-net-pci,disable-modern=off,disable-legacy=off,disable-modern=on,netdev=hostnet0

-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu