Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Call for (bare metal) testing! #477

Open
fosslinux opened this issue Jul 10, 2024 · 13 comments
Open

Call for (bare metal) testing! #477

fosslinux opened this issue Jul 10, 2024 · 13 comments

Comments

@fosslinux
Copy link
Owner

Testing would be appreciated for the 1.0 branch - of all kinds is great, but particularly;

  • chroot or bwrap mode on a variety of Linux systems
  • bare metal tests.

Please post a report below for any bare metal tests at all, any interesting other tests, or tests that fail.

An associated bug report for failures would be appreciated, as long as you can tell where it failed and what the error was.

A good report format follows:

Kind of bootstrap: (chroot/bwrap/qemu/bare metal)
Success or Failure: ...
Machine/OS Information: (for bare metal, hardware information, including laptop model or motherboard model, CPU, amount of RAM, boot device; for others, Linux distribution, etc)
Failure information: (if relevant)
Additional Information:

@fosslinux fosslinux pinned this issue Jul 10, 2024
@eduardosm
Copy link
Contributor

I have been able to successfully run the build on chroot, bwrap and qemu modes.

  • For chroot and bwrap, I used --build-kernels --external-sources.
  • For qemu, I used kernel bootstrapping with --external-sources.

Done on Fedora 40.

However, I have not been able to complete the build on bare metal. I used kernel bootstrapping with --external-sources.

The laptop I used is a PackardBell Easynote ML65, which is quite old (~16 years).

  • Intel Core 2 Duo T5800
  • 4 GB RAM
  • SATA DVD burner without any disk in it
  • Two 2.5" empty SATA slots
  • 4 USB 2.0 ports, with a USB stick on two of them (with init.img and external.img)

The builds goes through the builder-hex0 and Fiwix stages, but it freezes while booting the Linux kernel.

Here is a recording of the moment it freezes.

linux-boot.webm

@mid-kid
Copy link
Contributor

mid-kid commented Aug 9, 2024

Can we get some better instructions on how to do this? In particular, I'd like to know:

  • What are the system requirements for the full bootstrap?
  • In case my system isn't fully supported, can I bootstrap using a prebuilt linux kernel?
    • Is there a kernel you'd recommend? I think e.g. slackware's might contain enough modules. Alternatively, do you recommend a livecd to grab a config and lsmod from to do make localyesconfig?
  • What bootstrap.py commands would I use for any of this? I'm a bit confused wrt those, as I haven't managed to use a linux kernel for bootstrapping, but I find the "full" bootstrap equally confusing.

@fosslinux
Copy link
Owner Author

fosslinux commented Aug 12, 2024

Sure!

What are the system requirements for the full bootstrap?

  • x86 system
  • for the kernel bootstrap, ability to boot in CSM (BIOS) mode
  • 4GB+ of RAM
  • some kind of mass storage device (USB, SDD, HDD, etc)
  • Ethernet connection (optional)

In case my system isn't fully supported, can I bootstrap using a prebuilt linux kernel?

Yes, but we would love to know about any cases where the full kernel bootstrap doesn't work!

The way to do this is by using the (I have only just noticed, poorly named) -qk argument to rootfs.py, which will instruct rootfs.py to NOT use the kernel bootstrap and rather generate an initramfs.

Regarding the kernel, I haven't tried to figure out a minimal Linux kernel requirement recently - been focusing more on the full kernel bootstrap. I know the requirements are fairly minimal though, so I'd recommend just giving it a go with a kernel you have around.
An important point: you should build in any modules that are needed! Modules are not supported for the bootstrap kernel.

What bootstrap.py commands would I use for any of this? I'm a bit confused wrt those, as I haven't managed to use a linux kernel for bootstrapping, but I find the "full" bootstrap equally confusing.

At a minimum, you want the -b option (bare metal), so at minimum, you'd need ./rootfs.py -b. This will then give you a path to a disk image after a little bit, that you can write to some mass storage device and attempt to boot off.

Thank you for pointing out some deficiencies in documentation :)

@Googulator
Copy link
Collaborator

3GB RAM is sufficient, if you use swap (-qs 4G option), or limit parallelism to 1 core (-c 1 option).

@endgame
Copy link

endgame commented Aug 31, 2024

Reporting in with a possibly invalid build failure:

Item Detail
Motherboard ASUS P5QL-CM
CPU Intel Pentium Dual-Core E5200
Architecture x86
RAM /!\ 2G /!\
rootfs.py command ./rootfs.py -s 8G -b -a x86 --cores 1
live-bootstrap commit 71ff0a0

This is the only 32-bit BIOS machine I have kicking around, so despite insufficient RAM, I figured I'd give it a go anyway. It managed to build all the way to Fiwix, but failed to kexec from the builder-hex0 environment into Fiwix itself, hanging (at least overnight) at the jump. I needed to reclaim desk space in the morning, so I turned the machine off after that. If there are specific debugging steps you'd like me to try, please let me know.

@fosslinux
Copy link
Owner Author

Thank you! There is a good chance that this is caused by a lack of RAM space, I believe (but do not know for sure)

By the way, 64-bit x86_64 BIOS machines should also be able to run live-bootstrap, as they are just an extension of 32-bit x86 :)

@mid-kid
Copy link
Contributor

mid-kid commented Aug 31, 2024

I wonder if --external-sources can build with less RAM. It stores more of the bootstrap on disk rather than RAM.

@fosslinux
Copy link
Owner Author

Yes - that is true.

@ajherchenroder
Copy link
Contributor

I have successfully completed a full bootstrap on bare metal. It was completed on a NUC style mini-pc running a J4105 celeron. The machine has 12 gigs of ram. The box is UEFI only so I created a mini boot environment using buildroot with just enough in it to clone the repository and download the files. The bootstrap was run in chroot mode and completed successfully. From the live bootstrap environment I was able to build a Gentoo live cd and a stage 3 tarball. (Thanks mid-kid, your bootstrap repository was instrumental in getting that to work). I was able to install Gentoo from the output with no issues.

@sempiternal-aurora
Copy link

sempiternal-aurora commented Nov 12, 2024

I just tried to do some bare metal bootstraps on the 1.0 Branch, as well as the master branch, on a few different systems, my results are below:

Item HP Laptop Lenovo Yogabook
Kind of bootstrap bare-metal bare-metal
Success or Failure Failure Failure
Machine/OS Information HP Pavilion - 13-an1076tu w/ i3 1005G1 processor, 8GB ram, 128GB Kingston USB boot drive, legacy bios mode Lenovo Yoga 300-11IBR w/ Pentium N3060 processor, 4GB ram, 128GB Kingston USB boot drive, BIOS in legacy boot mode
Failure information Hung on trying to run kaem.x86 script trying to run kaem.x86 script caused flashing blue + symbols to cover the screen
Additional Information Tried only on master tried on both master & 1.0, both failed

If you need me to do anything else, let me know. I'm happy to play around with these, just need a few directions to look into to try and fix this.

edit: fix the table

@ajherchenroder
Copy link
Contributor

ajherchenroder commented Nov 12, 2024

It’s been a while since I’ve had a modern machine with legacy boot but I seem to remember limitations when booting from USB sticks. Check your bios settings for something like “legacy usb support”. I would also try with a smaller USB stick.

@Googulator
Copy link
Collaborator

Can you boot a regular Linux kernel on those machines, and quote the "e820" lines from dmesg? I suspect you might have a discontiguous memory map, sometimes seen on UEFI machines.

@endgame
Copy link

endgame commented Dec 22, 2024

Reporting a failure with ./rootfs.py -q bootstrapping x86. The bootstrap proceeds all the way into Linux and starts building Linux versions of some utilities before failing to get libtool-2.4.7 sources:

libtool-2.4.7: beginning build using script pass1.sh
libtool-2.4.7: getting sources.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  992k  100  992k    0     0   522k      0  0:00:01  0:00:01 --:--:--  522k
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0
curl: (22) The requested URL returned error: 400
curl: (1) Protocol "https" not supported or disabled in libcurl
libtool-2.4.7.tar.xz: OK
(and then the kernel panics)

Has http://mirrors.kernel.org started redirecting all traffic to HTTPS?.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants