cpu '0' panicked at 'How's this possible?"

[ghost]

I just cloned the repository, installed the dependencies, realized that I didn't have pip installed so I installed that and then pip installed requests and xbstrap, ran it and realized meson is not installed so i installed that, then it finally compiled and ran. However, it is giving me this error.

Here is the full log:

info: qemu-system-x86_64 -cdrom build/aero.iso -m 9800M -smp 1 -serial stdio -drive file=build/disk.img,if=none,id=NVME1,format=raw -device nvme,drive=NVME1,serial=nvme --boot d -s -enable-kvm -cpu host
[0] arch/x86_64/mod.rs:141 info loaded paging
[0] arch/x86_64/mod.rs:144 info loaded heap
[0] arch/x86_64/mod.rs:161 info loaded bootstrap GDT
[0] arch/x86_64/mod.rs:177 info loaded IDT
[0] arch/x86_64/apic.rs:450 debug apic: detected APIC (addr=PhysAddr(0xfee00000), type=X2apic)
[0] arch/x86_64/interrupts/mod.rs:210 debug Disabled PIC
[0] arch/x86_64/mod.rs:180 info loaded APIC
[0] acpi/mod.rs:67 debug found RSDT at 0xffff8000bffe1550
[0] acpi/madt.rs:124 warn unknown MADT entry with id: 4
[0] arch/x86_64/mod.rs:185 info loaded ACPI
[0] arch/x86_64/mod.rs:188 info loaded TLS
[0] arch/x86_64/mod.rs:193 info loaded GDT
[0] main.rs:119 info loaded filesystem
[0] arch/x86_64/apic.rs:413 info registered redirect (vec=33, gsi=2)
[0] main.rs:122 info loaded timer
[0] main.rs:125 info loaded scheduler
[0] main.rs:130 info initialized kernel
[1] modules.rs:93 (tid=4, pid=4) debug Module { init: 0xffffffff80019320, ty: Block } false
[1] modules.rs:93 (tid=4, pid=4) debug Module { init: 0xffffffff8001b5c0, ty: Block } false
[1] modules.rs:93 (tid=4, pid=4) debug Module { init: 0xffffffff8002c930, ty: Block } false
[1] /home/mins/.cargo/git/checkouts/lai-rs-cfbd9520fedc57ae/b183090/src/host.rs:80 (tid=4, pid=4) debug loaded AML table 'DSDT', total 5060 bytes of AML code.
[1] /home/mins/.cargo/git/checkouts/lai-rs-cfbd9520fedc57ae/b183090/src/host.rs:80 (tid=4, pid=4) debug ACPI namespace created, total of 283 predefined objects.
[1] acpi/aml.rs:36 (tid=4, pid=4) debug aml: subsystem initialized
[1] modules.rs:93 (tid=4, pid=4) debug Module { init: 0xffffffff8005f0a0, ty: Block } false
[1] fs/devfs.rs:90 (tid=4, pid=4) debug installed device `card0`
[1] modules.rs:93 (tid=4, pid=4) debug Module { init: 0xffffffff80070be0, ty: Block } false
[1] modules.rs:93 (tid=4, pid=4) debug Module { init: 0xffffffff80097d30, ty: Block } false
[1] modules.rs:93 (tid=4, pid=4) debug Module { init: 0xffffffff800265a0, ty: Other } false
[1] drivers/pci.rs:863 (tid=4, pid=4) debug PCI device (device=HostBridge, vendor=Intel)
[1] drivers/pci.rs:863 (tid=4, pid=4) debug PCI device (device=IsaBridge, vendor=Intel)
[1] drivers/pci.rs:863 (tid=4, pid=4) debug PCI device (device=IdeController, vendor=Intel)
[1] drivers/block/ide/mod.rs:115 (tid=4, pid=4) trace ide: starting ide
[1] drivers/block/ide/mod.rs:120 (tid=4, pid=4) warn ide: dma not supported
[1] drivers/pci.rs:863 (tid=4, pid=4) debug PCI device (device=OtherBridgeDevice, vendor=Intel)
[1] drivers/pci.rs:863 (tid=4, pid=4) debug PCI device (device=VgaCompatibleController, vendor=Qemu)
[1] drivers/pci.rs:863 (tid=4, pid=4) debug PCI device (device=EthernetController, vendor=Intel)
[1] drivers/e1000.rs:300 (tid=4, pid=4) trace e1000: MAC address 52:54:0:12:34:56
[1] arch/x86_64/apic.rs:413 (tid=4, pid=4) info registered redirect (vec=35, gsi=11)
[1] drivers/e1000.rs:359 (tid=4, pid=4) trace e1000: successfully initialized
[1] drivers/pci.rs:863 (tid=4, pid=4) debug PCI device (device=NvmeController, vendor=Unknown(6966))
[1] drivers/block/nvme/mod.rs:276 (tid=4, pid=4) trace nvme: setting up NVMe controller
[1] drivers/block/nvme/mod.rs:294 (tid=4, pid=4) trace nvme: version (major=1, minor=3, tertiary=0)
[1] drivers/block/nvme/mod.rs:206 (tid=4, pid=4) trace nvme: resetting the controller to enabled=false state
[1] drivers/block/nvme/mod.rs:206 (tid=4, pid=4) trace nvme: resetting the controller to enabled=true state
[1] drivers/block/nvme/mod.rs:350 (tid=4, pid=4) trace nvme: identifed controller (vendor=6966, subsystem_vendor=6900)
[1] drivers/block/nvme/mod.rs:447 (tid=4, pid=4) trace nvme: identified namespace (blocks=1073741824, block_size=512, size=549755813888)
[1] drivers/block/nvme/mod.rs:459 (tid=4, pid=4) trace nvme: successfully initialized NVMe controller
[1] fs/devfs.rs:90 (tid=4, pid=4) debug installed device `nvme0n1`
[1] fs/block/mod.rs:268 (tid=4, pid=4) debug block: installed block device nvme0n1
[1] modules.rs:101 (tid=4, pid=4) info loaded PCI driver
[1] unwind.rs:180 (tid=4, pid=4) error cpu '0' panicked at 'How's this possible?'
[1] unwind.rs:184 (tid=4, pid=4) error aero_kernel/src/fs/mod.rs:306:20
[1] unwind.rs:188 (tid=4, pid=4) error 
[1] unwind.rs:113 (tid=4, pid=4) trace ---------------------------------- BACKTRACE -----------------------------------
[1] unwind.rs:150 (tid=4, pid=4) trace  0: 0xffffffff8001e122 - rust_begin_unwind
[1] unwind.rs:150 (tid=4, pid=4) trace  1: 0xffffffff800ce943 - core::panicking::panic_fmt::h069cad845d58975a
[1] unwind.rs:150 (tid=4, pid=4) trace  2: 0xffffffff800ccaea - core::option::expect_failed::h3131d62826b2db33
[1] unwind.rs:150 (tid=4, pid=4) trace  3: 0xffffffff8009cfad - aero_kernel::fs::lookup_path::hb12bef3f79c9b7f0
[1] unwind.rs:150 (tid=4, pid=4) trace  4: 0xffffffff80060c16 - aero_kernel::fs::block::launch::hcf95d05344e0485a
[1] unwind.rs:150 (tid=4, pid=4) trace  5: 0xffffffff8003df0b - aero_kernel::modules::init::hb44a459acd17bbfd
[1] unwind.rs:150 (tid=4, pid=4) trace  6: 0xffffffff8002eefe - aero_kernel::kernel_main_thread::hb44ea367342a5748
[1] unwind.rs:150 (tid=4, pid=4) trace  7: 0xffffffff8012bf98 - aero_kernel::AERO_SYSTEM_ALLOCATOR::ha4b070cde23b1144
[1] unwind.rs:121 (tid=4, pid=4) trace  8: <guard page>

Not sure if it's related or not, but another issue I am seeing is this

mins@debian:~/Sources/aero$ ./aero.py
error: host-rust not built as a part of the sysroot, skipping compilation of `userland/`
   Compiling compiler_builtins v0.1.91
   Compiling core v0.0.0 (/home/mins/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   Compiling ahash v0.7.6
   Compiling num-traits v0.2.15
   Compiling memoffset v0.5.6
   Compiling log v0.4.17
   Compiling serde v1.0.149
   Compiling serde_json v1.0.89
   Compiling lai v0.1.0 (https://github.com/aero-os/lai-rs#b1830903)
   Compiling aero_kernel v0.1.0 (/home/mins/Sources/aero/src/aero_kernel)
   ....

[jwpjrdev]

the second thing is known, it was in the works of being resolved in another PR but i can't work on it thanks to a lack of computer to effectively do it on

[Andy-Python-Programmer]

This is the result of the disk image not being built. Can you please post the output of ./tools/mkimage.sh? Also did you install the dependencies via ./tools/deps.sh?

[ghost]

It looks like there is something wrong with the deps.sh script. I managed to make it work by editing it.

ANOTHER BIG PROBLEM: WHY IS DISK.IMG OVER 500GB IN SIZE?

[ghost]

OK, so, the problem has to do with the script attempting to use parted. parted (on my system at least) requires sudo to run, however the script did not attempt to use sudo to run it.

also, please do not create in excess of 500gb files on someone's computer without them knowing. That is half of my SSD's space. Your operating system is like 7kb it should not require that much space. FIX THAT.

[jwpjrdev]

bro built the entire sysroot 💀

[ghost]

um, I'm sorry? But, it doesn't seem like somehow changing what you build into it changes the size.
https://github.com/Andy-Python-Programmer/aero/blob/master/tools/mkimage.sh#L21
The size is hardcoded into this dd command.

[man0lis]

The command in this line creates a sparse file (if your file system supports that). The file looks like it uses 512GB but it does not. Only data written to the file later uses disk space. du -h file shows you the actual size of the file.

[Andy-Python-Programmer]

It looks like there is something wrong with the deps.sh script. I managed to make it work by editing it.

Can you explain what was wrong?

ANOTHER BIG PROBLEM: WHY IS DISK.IMG OVER 500GB IN SIZE?

#101 (comment)

[ghost]

it still doesn't really need to be 500GB but sure.

I'm not sure exactly what the problem with deps.sh is. All I know is that it didn't work properly as is. I removed the if else around the deps_linux file and kept just the Debian code and it worked fine after that. Probably because Debian has ID and not ID_LIKE.

mins@debian:~$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

[Azure-stars]

hey, I met the same question with you. But my system is ubuntu22.04.
How did you solve your problem? I delete the ID LIKE in the /etc/os-release but it doesn't work.
Whether do I need to build the entire sysroot(it's so big that I not really want to install it)?
@minneelyyyy

[MolassesLover]

Literally why is it 500GB in size?

This entire build pipeline is sending me. First deps.sh is wholly problematic because it doesn't check your distribution, then a 500GB image is created without consent, and there is no way to use the QEMU command generated by aero.py without building, so you must have the dependencies installed.

Edit: Apparently there is an --only-run flag, but then you still run into the issue of needing the dependencies installed, since the mkimage.sh script is not designed to run in a container, whatsoever. Which after running, of course, builds a 500GB image.

[MolassesLover]

The command in this line creates a sparse file (if your file system supports that). The file looks like it uses 512GB but it does not. Only data written to the file later uses disk space. du -h file shows you the actual size of the file.

What confuses me is why the sparse file is so big. Is there a practical reason I'm missing?