On Wednesday, March 6, 2019 at 10:59:08 AM UTC-5, Nadav Har'El wrote: > > > On Tue, Mar 5, 2019 at 5:37 PM Waldek Kozaczuk <[email protected] > <javascript:>> wrote: > >> >> 2019-03-05T14:47:40.839064594 [anonymous-instance:WARN:vmm/src/ >>> lib.rs:1080] Guest-boot-time = 62091 us 62 ms, 69244 CPU us 69 CPU ms >>> *root=/dev/vda: No such file or directory* >>> program exited with status 1 >>> VFS: unmounting /dev >>> VFS: unmounting /proc >>> VFS: unmounting / >>> Powering off. >>> 2019-03-05T14:47:40.848183837 [anonymous-instance:ERROR:vmm/src/ >>> lib.rs:1320] Failed to log metrics while stopping: Logger was not >>> initialized. >>> 2019-03-05T14:47:40.862006: End >>> >>> >>> I don't where this message comes from, I am guessing that something got >>> broken in the command line and OSv tried to run the string "root=/dev/vda" >>> as the command line instead of the desired command line (/usr/games/rogue)? >>> Using build fs=ramfs does not help, so it seems the new virtio stuff is >>> working, just something in the command line got broken? >>> >> Indeed the issue is with the command line and I am actually not >> surprised. I very rarely use rogue as I am not really familiar with this >> game ;-) Never came across it in the 80ties. >> > > I wholeheartedly recommend this game. Dennis Ritchie once called it "the > biggest waste of CPU cycles in history". I guess this was a few decades > before Fortnight ;-) > > Anyway, I never actually played a full game of rogue on OSv. It just has a > short name, and runs something non-obvious, so I tend to use it as an > example when I need to run something without thinking too much what to > run... > > > >> I any case firecracker appends some Linux-specific parameters to the >> command line >> > > You're right. It's very strange, I was assuming it prepends, but it indeed > appends. And when rogue is given a parameter it indeed tries to use it as a > file - apparently a file for a previously saved game (you can stop a game > in the middle and save it to a file, and later restore it). > > Anyway, thanks for fixing it. > > >> (see here for command line example - >> https://github.com/firecracker-microvm/firecracker/releases - default >> "reboot=k >> panic=1 pci=off nomodules 8250.nr_uarts=0 i8042.noaux i8042.nomux >> i8042.nopnp i8042.dumbkbd") that we do not care for except for >> virtio-mmio stuff which we parse and remove from command line before we >> pass it on the downstream logic. The applications that I have used to test >> OSv on firecracker (*-hello, *-httpserver ones for example) do not care >> about extra parameters but in the rogue case it somehow cares. The >> particular one (*root=/dev/vda*) I think comes from the fact that adding >> block device makes it add this parameter to command line. I think the rouge >> would boot properly with previous version of firecracker.py where it did >> not add block device to firecracker instance. BTW it would be nice to >> change OSv to show received command line in verbose mode. I would find it >> very handy. >> > >> Long story short in order to address these command line woes, we need to >> come up with some sort of 'OSv command line marker' scheme. For example we >> could add logic to look for some special end of command line sequence of >> characters or add new boot option called '--cmdline_end_marker' which would >> explicitly state what to look for end of the command line. Do you have >> other ideas? >> > > I don't know, your choice :-) > >> >> Relatedly you may have noticed that new firecracker.py automatically >> converts usr.img to usr.raw as firecracker cannot deal with qcow :-( >> > > I noticed, but also saw a few people on the Internet giving firecracker > examples with a qcow2 image, so how sure are you that it doesn't deal with > qcow2? > I tried it again but same effect. You may easily test it yourself by changing one line in firecracker.py and make it pass qcow_path instead of disk_path. I looked at both firecracker and firectl code to see if any has any trace of dealing with qcow2. And could not find it. I think that the author of the article you found misleads readers to think firecracker supports qcow2. Maybe for additional disks but even that I doubt. I even tested it by converting raw ext4 linux image to qcow2 and trying to boot linux to no avail.
I will ask it on firecracker slack channel or other forums to be 100% sure I am not doing something wrong. > >> This is not a problem with rofs images (which btw I typically use with >> firecracker as it boots much faster) but leads to 10G usr.raw file when we >> use zfs. Obviously one can pass fs_size_mb parameter to build script but I >> wonder if there is a better way to handle it. Change default 10G to >> something smaller? >> > > Perhaps. This 10G was completely arbitrary. Maybe the default should be > smaller and make it clearer in the README or Makefile how to change it. > > -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
