Conversation
|
I just published a |
Docs.rs has no network access, so we can't `cargo install` the binary dependencies. This is not required for doc generation, so we trick our way around that issue by providing a dummy build script just for docs.rs.
|
In the README.md there is a broken link to the migration guides. |
|
@asensio-project Thanks! Fixed in 4e2b8d7 |
|
Looks like the size of the generated first stage code increased on the latest nightly: https://github.com/rust-osdev/bootloader/actions/runs/3511818449/jobs/5882914661 . So we need to reduce the first stage size even more before merging this. As a workaround, we could ship a precompiled version built with a pinned nightly version, but we should try find a proper fix first. |
|
When I tried to compile with the new version of this crate I have the following error: Looks like a dependency error. |
|
Funty 1.2 has been yanked. Cargo ignores yanked versions unless Cargo.lock already mentions them. |
|
I know. But how can be fixed? |
|
The dependency on mbrman will need to be updated to 0.5, which uses bitvec 1.0, which in turn uses the non-yanked funty 2.0. |
|
|
|
@asensio-project In the meantime, the following workaround can be used: It must be in the top-level Cargo.toml |
Fixes the build on the latest Rust nightlies, which apparently generate slightly bigger code than older nightlies.
|
What about adding an option for avoiding the bootloader to don't write into screen until loading the kernel? This way, we don't have to clear screen. |
phil-opp
changed the title
|
Since I don't know when the The new |
We could add a |
|
Looks like there is some kind of test failure on If someone has access to a macOS machine, it would be great if you could try these steps:
|
|
The test seems successful on my macOS M1 device. If I add Might be a problem solely with the speed of GitHub actions? Log |
|
@micfong-z Thanks for testing!
I don't think that speed is the problem. The test runs for almost 20 minutes before it gets canceled by out timeout:
This typically happens on a panic. Unfortunately, we don't have serial output of the bootloader panic message, so we don't see it in the logs... |
|
fyi, I just ran a GitHub Actions on my fork, testing
I would doubt this is a technical glitch from GitHub, but I'm not quite sure about how Actions works, and I just edited on the existing testing yml file. I might have missed some steps to replicate the problem. |
|
Interesting.. I just restarted the failed CI jobs manually, let's see if the problem is reproducible. |
|
"All checks have passed" now :D |
|
I just updated mbrman to 0.5.1 which uses bitvec 1.0.1. Sorry for the long delay |
Thanks a lot!
Well, I guess we can merge then :D. We have a scheduled CI build in place for the |
6 participants
Prepares the new
v0.11merged in #232 for publishing.TODO:
Fixes #291
Fixes #286