FS doesn't work after install
Closed this issue · 12 comments
Hi, thanks for a good project!
Everything works fine but after I use an 'install' command in diskless mode, and restart my qemu - I got the looped boot.sh with errors.
screenshot - https://drive.google.com/file/d/1iuLKhwqLN3CppegeGOa6RbSPfITV8kdl/view?usp=sharing
So I have a solution but that's not good.
My solution:
- make image output=video keyboard=qwerty
- make qemu output=video nic=rtl8139
- disk format /dev/ata/0/0
- goto /
- write ini/
- edit boot.sh (wrote user login /n shell)
- write usr/
- user create admin
- then "install" command and change again boot.sh file for theme and banner ;/
Hello, thank you very much for reporting the issue!
Looks like a bug I had recently when the kernel became larger than 2MB so it'd spill over the rest of the FS where the files are installed. I optimized a few things in #430 to move it below the limit instead of increasing it to 4MB and breaking existing file systems.
Can you copy here the first and last lines of make image output=video keyboard=qwerty
please?
Here's what I get:
> make image output=video keyboard=qwerty
qemu-img create disk.img 32M
Formatting 'disk.img', fmt=raw size=33554432
touch src/lib.rs
env | grep MOROS
MOROS_MEMORY=32
MOROS_VERSION=0.9.0
MOROS_KEYBOARD=qwerty
cargo bootimage --no-default-features --features video --bin moros --release
WARNING: `CARGO_MANIFEST_DIR` env variable not set
Building kernel
...
Finished release [optimized + debuginfo] target(s) in 18.01s
Created bootimage for `moros` at `/home/v/src/vinc/moros/target/x86_64-moros/release/bootimage-moros.bin`
dd conv=notrunc if=target/x86_64-moros/release/bootimage-moros.bin of=disk.img
3896+0 records in
3896+0 records out
1994752 bytes (2.0 MB, 1.9 MiB) copied, 0.00673524 s, 296 MB/s
And:
> ls -l target/x86_64-moros/release/bootimage-moros.bin
-rwxr-xr-x 1 v v 1994752 Nov 22 09:33 target/x86_64-moros/release/bootimage-moros.bin
So for me it's a bit under the limit, but maybe not for you? I'm using Arch Linux and tested the build on MacOS.
You can also try to comment out a few files in src/usr/install.rs
, for example /bin/hello
and /var/www/moros.png
, before rebuilding the image as a temporary fix.
> make image output=video keyboard=qwerty
qemu-img create disk.img 32M
Formatting 'disk.img', fmt=raw size=33554432
touch src/lib.rs
env | grep MOROS
CURDIR=/mnt/c/Users/DogAdmin/Desktop/moros/moros
bin=target/x86_64-moros/release/bootimage-moros.bin
moros_KEYBOARD=qwerty
PWD=/mnt/c/Users/DogAdmin/Desktop/moros/moros
cargo bootimage --no-default-features --features video --bin moros --release
WARNING: `CARGO_MANIFEST_DIR` env variable not set
Building kernel
....
Finished release [optimized] target(s) in 22.23s
Building bootloader
Compiling bootloader v0.9.23 (/home/denver/.cargo/registry/src/github.com-1ecc6299db9ec823/bootloader-0.9.23)
Finished release [optimized + debuginfo] target(s) in 6.13s
Created bootimage for `moros` at `/mnt/c/Users/DogAdmin/Desktop/moros/moros/target/x86_64-moros/release/bootimage-moros.bin`
dd conv=notrunc if=target/x86_64-moros/release/bootimage-moros.bin of=disk.img3886+0 records in
3886+0 records out
1989632 bytes (2.0 MB, 1.9 MiB) copied, 2.66359 s, 747 kB/s
And:
>ls -l target/x86_64-moros/release/bootimage-moros.bin
-rwxrwxrwx 1 denver denver 1989632 Nov 21 23:22 target/x86_64-moros/release/bootimage-moros.bin
Looks pretty same, but size looks exactly 2MB
I'm using windows11 with ubuntu wsl2, also tried on Manjaro Linux and macOS Monterey
Thanks! It's strange because the kernel binary is just under the 2MB limit, not by much, but still below it so it should work. I'm going to try to reproduce the issue on a fresh install of Ubuntu.
Cheers mate, cos I have no idea why this can be like that
My disk.img has a size of 32MB exactly after "install" process, and kernel binary is under 2MB
I also tried making some fixes and reducing size but the problem still same, I wanna try to do some checks after clear installation but not sure then I will find an issue
And an interesting feature - after installing you are able to use all features of os, in this list are "user login", "shell" and others.
so what I did few minutes ago -
> make image output=video keyboard=qwerty
> make qemu output=video nic=rtl8139
But image has a 128MB size, kernel 1.9MB cos I commented image in www and hello+sleep binary.
Then I did:
>install
Create a user and files an also has been copied
then I used "user login" and checked what in my /ini/boot.sh script (I leave only one line "shell")
and finally reboot
Now its works after reboot! but still strange haha
I couldn't reproduce the issue from a fresh install of Ubuntu, and I even tried your fork without success.
I'm not sure anymore that the problem is the kernel size, but you can increase KERNEL_SIZE
in src/lib.rs
to 4 MB and see if that change something for you?
It's also strange that calling user login
print the usage. Interesting bug!
Oh my gosh looks like I fixed it haha
That's strange and funny but the solution was by adding a space after commands in boot.sh
Im tried a few times and can say that's exact solution to my issue, but I think that doesn't have to work like that
I have no idea why they work like that yet but wanna debug a shell
command and create a final solution for this bug
Ah, that would explain the usage output. Are you editing the file outside of the OS? Could it be a line ending char issue?
for me the space only solves the first boot after a clean install, so I edited dsk/ini/boot.sh
.
However, if the space is removed or added later (after the first successful login), the problem disappears completely regardless of the presence of spaces in the file, even if it is downloaded again
If your line ending are \r\n
instead of \n
it means that the command user login
for example will be user login\r
and it won't be recognized. That'd explain why usage is printed instead. The spaces that you need to add at the end of the commands in the script seems to indicate that.
I'm already working on an issue with commands containing only spaces so I added a trim
to exec_with_config
in src/usr/shell.rs
in #442. Does that solve your issue?