Re: report on debian-9.0-sparc64-NETINST-1.iso with qemu
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
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]
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=4163mtu 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
[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]
Artyom Tarasenko wrote on 27.01.2017: > On Thu, Jan 26, 2017 at 10:16 PM, Bruno Haiblewrote: > > 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]
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 Haiblewrote: > > 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
On Thu, Jan 26, 2017 at 10:16 PM, Bruno Haiblewrote: > 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