Call for (bare metal) testing!

[fosslinux]

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:

[eduardosm]

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]

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]

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]

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

[endgame]

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]

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]

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

[fosslinux]

Yes - that is true.

[ajherchenroder]

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]

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]

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]

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]

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?.

[endgame]

Reporting another 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 for a different reason:

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   764k      0  0:00:01  0:00:01 --:--:--  765k
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0   190    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0
curl: (22) The requested URL returned error: 429
Warning: Problem : HTTP error. Will retry in 1 seconds. 5 retries left.
  0   190    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 429
Warning: Problem : HTTP error. Will retry in 2 seconds. 4 retries left.
  0   190    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 429
Warning: Problem : HTTP error. Will retry in 4 seconds. 3 retries left.
  0   190    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 429
Warning: Problem : HTTP error. Will retry in 8 seconds. 2 retries left.
  0   190    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 429
Warning: Problem : HTTP error. Will retry in 16 seconds. 1 retries left.
  0   190    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 429
curl: (1) Protocol "https" not supported or disabled in libcurl
libtool-2.4.7.tar.xz: OK

Do we need special handling for 429s when building on a fast machine?