| tuxd3v | usb port on bananapi m2 zero was tested and its working ok :) | 00:39 |
|---|---|---|
| tuxd3v | zmoment, sorry only now am I reading the logs :) | 00:41 |
| tuxd3v | yeah QEMU_EFI, is correct its the one I used to make the instalation.. | 00:42 |
| tuxd3v | Fylesystem should use around 1Gb or 1.1GB for a base install, its the Idea I have , also | 00:42 |
| tuxd3v | 320MB should be now the minimum to start the installation process, fetch installer, tools, and install stuff.. | 00:43 |
| tuxd3v | 320Mb is the base minimum, I tested with 256MB Ram first, and after 7 hours it broke down, so I pushed for 320MB, and even so there are some moments in the process, like kernel updates initramfs, and such, and slow down a lot but it succeeds.. | 00:44 |
| tuxd3v | So I take 320Mb as the minimum for the mini.iso :) | 00:45 |
| tuxd3v | the EFI shell asks about that file 'startup.nsh' | 00:46 |
| tuxd3v | indeed.. | 00:46 |
| tuxd3v | you created the file with: | 00:49 |
| tuxd3v | '\EFI\debian\grubx64.efi' | 00:49 |
| tuxd3v | content? | 00:49 |
| tuxd3v | guess in my case would be different, but around the same way.. | 00:50 |
| tuxd3v | I tested 32 bits version because you were already testing 64 bits version :) | 00:50 |
| tuxd3v | the Idea, get both tested ;) | 00:51 |
| zmoment | tuxd3v: yes, created the startup.nsh with \EFI\debian\grubaa64.efi, note the aa | 00:52 |
| zmoment | but does your boot fine? mine stops at the grub prompt. Can't get the menu from grub | 00:53 |
| tuxd3v | mine shows me that error:https://paste.debian.net/hidden/b86263f1/ | 00:55 |
| tuxd3v | then is retires to booot from diferent devices, later it enters EFI shell, but at beguining indeed it laks about that 'startup.nsh' script file.. | 00:56 |
| tuxd3v | for what I understand the EFI partition should be mounted on /boot/efi, right? | 00:56 |
| tuxd3v | I have this in fs0: | 00:59 |
| tuxd3v | EFI\devuan\grubarm.efi | 00:59 |
| zmoment | yours is different from mine, since your system is 32 bit and mine 64 | 01:00 |
| tuxd3v | indeed | 01:00 |
| tuxd3v | but mine has a 'devuan' folder intead of debian , yours also? | 01:01 |
| zmoment | yes it has. Sorry, I copied it from a similar debina installation that I made to see if the boot process was fine, and it isn't. Suffers from the same problem. | 01:03 |
| zmoment | /dev/vda1 on /boot/efi type vfat | 01:04 |
| tuxd3v | after the creation of that script file, everything went smooth: | 01:37 |
| tuxd3v | https://paste.debian.net/hidden/711ce410/ | 01:37 |
| tuxd3v | grub was ok for me | 01:37 |
| tuxd3v | it just creates the fstab entries with UUID :D | 01:37 |
| tuxd3v | when I try to start the vm, I need to wit the system trying pxe ipv4, then pxe ipv6, and only then EFI, around 1 minute or a bit more.. | 01:42 |
| tuxd3v | you also have this problem? | 01:42 |
| zmoment | but have you rebooted to check if it boots to the grub menu without stops? | 01:43 |
| tuxd3v | wit-> wait | 01:43 |
| zmoment | mine takes maybe a minute yes | 01:43 |
| tuxd3v | yes, I shutdown and started again, and when in EFI it goes strait to grub menu to choose what to do.. | 01:44 |
| zmoment | did you place those uuid entries in /etc/fstab yourself? | 01:45 |
| tuxd3v | So initially it always do that stop about a minute trying pxe boot.. | 01:45 |
| tuxd3v | no, the system created the UUIDS, I then replaced then with the classic locations :) | 01:46 |
| tuxd3v | after the pxe trying to boot, it goes to EFI, and its were it runs the script, then immediately it shows grub menu | 01:47 |
| zmoment | ok, tomorrow I'll try again. Now it's late, have to sleep. Thank you tuxd3v | 01:48 |
| tuxd3v | zmoment, what is the behaviour you are geting after the PXE try? | 01:48 |
| tuxd3v | you welcome, I also wanted to test the mini.iso :) | 01:49 |
| tuxd3v | in the script I put there: | 01:50 |
| tuxd3v | EFI\devuan\grubarm.efi | 01:50 |
| zmoment | At the efi it asks whether I want to continue or something else, I dont' recall | 01:50 |
| tuxd3v | saved, and retried.. | 01:50 |
| tuxd3v | but it showld show you a countdown to run the script | 01:50 |
| tuxd3v | after that countdown expires, it should jump on grub | 01:51 |
| zmoment | to grub yes, but to a prompt, not to the menu | 01:51 |
| tuxd3v | ho.. | 01:51 |
| zmoment | Tomorrow I keep you informed. Bye | 01:52 |
| tuxd3v | Cya tomorrow | 01:53 |
| tuxd3v | Bye | 01:53 |
| tuxd3v | tomorrow will try the mini.iso aarch64 on qemu :) | 05:35 |
| tuxd3v | c0rnelius, you are olaying now for Denmark.. | 19:27 |
| tuxd3v | playing.. | 19:27 |
| zmoment | hi tuxd3v. I did some more installation tries. The last one for debian9, the system could boot automatically. I did a manual partitioning as always, but this time, the disk was set as /dev/vdb. Is yours vda or vdb? | 19:36 |
| tuxd3v | when you are in the installer, vda is the ramfs with the installer and stuff, vdb is your install target | 19:38 |
| tuxd3v | Ĩ am also trying to do a install for aarch64, but I believe my mini.iso is not ok, I will download it again and retry after.. | 19:39 |
| tuxd3v | I set 1 Partiton as EFI, with 256MB, and a second one with the rest of 2GB disk(second partition), for / | 19:40 |
| tuxd3v | the grub install process is one of the last things that ocurr in the installer.. | 19:40 |
| zmoment | tuxd3v: maybe this is the culprit of my problem. I am (was) doing debian and devuan installations side by side. For Debian, this time, the disk is vdb. For Devuan, it's vda. See https://ibb.co/MVgm9Yq | 19:45 |
| zmoment | I'll check the init script to spot any difference that can justify that | 19:45 |
| tuxd3v | usually the ramfs disk( which is the one run by the installer), would be vda, because its the first disk, before even it advance to disk partitioning.. | 19:56 |
| tuxd3v | in any case, we should always check, the disk size | 19:57 |
| tuxd3v | the disk with the size we created we should install in it.. | 19:57 |
| tuxd3v | but yeah vdb should be the instaling disk.. | 19:57 |
| zmoment | Tried again, with the same script, except for the name of the disk file name and my devuan detects the disk as vda and the ram disk as vdb. I'll finish the installation but I suspect It won't boot. | 20:03 |
| Tenkawa | zmoment: if your disk is showing up as vd* its because you defined it as a virtio disk and not a specific disk format | 20:18 |
| Tenkawa | the backing may be many different formats but the os sees it as a virtio disk | 20:19 |
| tuxd3v | Tenkawa, I beliebe its the order that he is talking about.. | 20:21 |
| tuxd3v | all of them are vd* disks | 20:22 |
| tuxd3v | but vda should be assigned to the ramdisk, of the instalkler.. | 20:22 |
| tuxd3v | and vdb as the target | 20:22 |
| zmoment | In the devuan there's -device virtio-blk-device,drive=drive0,bootindex=0 \ while in my script for debian there's -device virtio-blk,drive=drive0,bootindex=0 \ So, virtio-blk-device vs virtio-blk. | 20:22 |
| Tenkawa | tuxd3v: he still needs to fix the mapping.. and are you sure the drivers are in his kernel? | 20:23 |
| Tenkawa | otherwise it wont see that to mount it in the guest | 20:23 |
| Tenkawa | especially CONFIG_VIRTIO_BLK | 20:25 |
| Tenkawa | but if the installer saw it it should be fine | 20:26 |
| Tenkawa | the mapping methods for them are horrid | 20:27 |
| tuxd3v | I am even with a bigger problem, my 'qemu-system-aarch64' doesn't even launch the cdrom :/ | 20:30 |
| tuxd3v | I am stuck there.. | 20:30 |
| tuxd3v | on 32 bits all was smoth | 20:30 |
| Tenkawa | tuxd3v: you did set the cdrom device as a sata device right? | 20:32 |
| Tenkawa | or ide cdrom | 20:32 |
| tuxd3v | Tenkawa, I believe by default its ide | 20:32 |
| Tenkawa | not if you change controllers | 20:33 |
| Tenkawa | you have to set it explicitly | 20:33 |
| zmoment | changed the virtio-blk-device to virtio-blk, but still get the big disk as /dev/vda | 20:33 |
| Tenkawa | zmoment: it will until you remap it | 20:34 |
| Tenkawa | vda is always virtio device 1 | 20:34 |
| tuxd3v | in my previous 32 bits install vda was the ramdisk.. | 20:35 |
| zmoment | How to remap it in qemu? | 20:35 |
| Tenkawa | tuxd3v: what architectures/partitions/drives? | 20:36 |
| Tenkawa | tuxd3v: they all factor in together | 20:36 |
| Tenkawa | zmoment: can you pastebin/post your startup command for your vm | 20:37 |
| Tenkawa | and be patient with my slow movement… currently healing with injuries to both arms (including main typing hand) | 20:38 |
| tuxd3v | qemu-system-aarch64 is not starting for me :( | 20:57 |
| Tenkawa | any errors? | 21:00 |
| tuxd3v | nope.. | 21:07 |
| tuxd3v | it just doesn't start the cdrom.. | 21:07 |
| tuxd3v | but on 32 bits he does | 21:08 |
| tuxd3v | maybe the mini.iso was corrupted.. | 21:08 |
| tuxd3v | downloading again.. | 21:08 |
| tuxd3v | I suspect of a problem with the bios :/ | 21:15 |
| tuxd3v | zmoment, does your bios work nicely? | 21:15 |
| tuxd3v | I am trying with 512M also tried with 1024M and still the cdrom doesn't boot :/ | 21:16 |
| tuxd3v | this is what I am trying: | 21:32 |
| tuxd3v | https://paste.debian.net/hidden/302ffdb0/ | 21:32 |
| tuxd3v | for 32 bits work | 21:32 |
| tuxd3v | for aarch64 nope | 21:32 |
| Tenkawa | I've never seen a "real" 64 bit arm machine boot from cd much less virtual | 21:37 |
| Tenkawa | only 32 bit | 21:37 |
| Tenkawa | it might not even be possible | 21:38 |
| tuxd3v | but zmoment succeeded :) | 21:38 |
| Tenkawa | yeah.. i just found a document… just a sec | 21:39 |
| Tenkawa | ahh haa | 21:39 |
| Tenkawa | try this syntax: | 21:41 |
| Tenkawa | er syntax : | 21:41 |
| Tenkawa | file=mini.iso,if=none,id=drive1,cache=writeback -device virtio-blk,drive=drive1,bootindex=1 | 21:41 |
| Tenkawa | you will need to create efi firmware too with this:" | 21:42 |
| Tenkawa | dd if=/dev/zero of=flash1.img bs=1M count=64 | 21:42 |
| Tenkawa | dd if=/dev/zero of=flash0.img bs=1M count=64 | 21:42 |
| Tenkawa | dd if=/usr/share/qemu-efi-aarch64/QEMU_EFI.fd of=flash0.img conv=notrunc | 21:42 |
| Tenkawa | and add this on your boot line | 21:43 |
| Tenkawa | -drive file=flash0.img,format=raw,if=pflash -drive file=flash1.img,format=raw,if=pflash | 21:43 |
| Tenkawa | got that from here: | 21:44 |
| Tenkawa | https://futurewei-cloud.github.io/ARM-Datacenter/qemu/how-to-launch-aarch64-vm/ | 21:44 |
| tuxd3v | I don't have /usr/share/qemu-efi-aarch64/QEMU_EFI.fd | 21:45 |
| zmoment | tuxd3v: I also posted a init script yesterday or two days ago | 21:45 |
| tuxd3v | zmoment, startup.nsh ? | 21:45 |
| zmoment | I'm using this https://termbin.com/732r | 21:46 |
| Tenkawa | tuxd3v: you dont have to think so literal: /home/tuxd3v/Desktop/QEMU_EFI_arm.fd | 21:47 |
| Tenkawa | its experimenting time :) | 21:48 |
| Tenkawa | yeah and zmoment's setup is much more what I expect to see | 21:50 |
| Tenkawa | just needs a few tweaks | 21:50 |
| Tenkawa | I would highly recommend building the config with the virt-manager tool.. very useful tool | 21:51 |
| Tenkawa | uses libvirt and can run multiple virtualization technologies… | 21:52 |
| tuxd3v | no way it simply refuses to load the mini.iso :( | 21:58 |
| tuxd3v | I don't know why | 21:58 |
| tuxd3v | in my system only 32 bits works out of the box :( | 21:59 |
| tuxd3v | It will require a deep revision.. | 22:00 |
| tuxd3v | ho.-. for what I discovered if you add a cpu to it, it advances a bit | 22:06 |
| tuxd3v | but not much..still interesting.. | 22:06 |
| c0rnelius | tuxd3v: what? | 23:36 |
| tuxd3v | Denmark team had a c0rnelius player :) | 23:37 |
| c0rnelius | Oh... :) | 23:38 |
| zmoment | Tenkawa: I prefer to use qemu instead of virt-manager, as the scripts can be used in other operating systems non-linux. | 23:44 |
| Tenkawa | it can export the qemu cmds for you btw | 23:45 |
| zmoment | didn't know that | 23:49 |
| Tenkawa | yeah its very nice | 23:52 |
| Tenkawa | it just builds a qemu cmdline with the xml it stores | 23:52 |
| Tenkawa | so it can export it out to text | 23:52 |
| Tenkawa | I need to test it since I havent used that functionality in a long time | 23:53 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!