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

init-eMMC-flasher does not copy multiple kernel modules #116

Open
JoseGoncalves opened this issue May 6, 2020 · 6 comments
Open

init-eMMC-flasher does not copy multiple kernel modules #116

JoseGoncalves opened this issue May 6, 2020 · 6 comments

Comments

@JoseGoncalves
Copy link
Contributor

JoseGoncalves commented May 6, 2020

The flasher scripts are only flashing the running kernel modules. In the scenario when a user is experimenting with more that one kernel build, it does not copy the extra modules folder(s) in /lib/modules.

An easy fix is, in the _copy_rootfs() function, to remove /lib/modules/* from the first rsync exclusions and remove the whole ==> Copying: Kernel modules section.

@RobertCNelson
Copy link
Owner

@JoseGoncalves correct, this was a design choice to minimize final disk space, when supporting "fat" images:

For a long time, (pre Debian Images for BeagleBoard.org), I've shipped my own fat images:

https://elinux.org/BeagleBoardDebian#Demo_Image

2020-03-12
BeagleBoard xM: v5.4.24-armv7-x20 kernel
All BeagleBone Variants and PocketBeagle: v4.19.94-ti-r36 kernel
BeagleBoard-X15 (and BeagleBone AI): v4.19.94-ti-r36 kernel

This image has 2 kernel's installed by default.

Regards,

@JoseGoncalves
Copy link
Contributor Author

@RobertCNelson don't quite understand what you called a design choice.

From my point of view, when a user has a rootfs in an SD card and runs a script whose purpose is to flash it into eMMC, he would expect to have in the eMMC an exact copy of what was in the memory card.

If, for some reason, a user wants to trim that image he should remove the unwanted bits before script execution.

@JoseGoncalves
Copy link
Contributor Author

JoseGoncalves commented May 6, 2020

In a second look I understood your point. You had previously images that supported multiple boards, i.e., with kernels for different boards, that would not make sense to burn on a board's flash were it would be useless.

@RobertCNelson
Copy link
Owner

RobertCNelson commented May 6, 2020

We could add a flag to /boot/SOC.sh as we've done this before for ssh regeneration..

6f03ba9#diff-c483633eab46489e55e2e391823018ad

I'd expect the current default state to be the same, but with a new flag it could do your requirement.. Something like:

flasher_copy_all_kernel=enable

Regards,

@JoseGoncalves
Copy link
Contributor Author

@RobertCNelson Thanks, that will work for me.

A better option, without using extra flags, but which involves more changes/work in your build process, would be to add some board specific suffix in all your kernel image names, that would identify kernels for specific boards. In the flasher script you would use that suffix to only burn images built for the board were you are running it.

@RobertCNelson
Copy link
Owner

We do that today...

"Board Specific Suffix" = aka the kernel it's actually running. ;)

What you really meant get's a little messy..

https://github.com/RobertCNelson/omap-image-builder/blob/master/tools/setup_sdcard.sh#L936-L1035

But user are free to install what ever they want or build what they want, so any automatic detection can fail.. Best to just use the kernel that it booted..

Regards,

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

No branches or pull requests

2 participants