El 4/8/24 a las 12:24, Roland Clobus escribió:
Hello Adrian,
Thanks so far for the MRs, I barely have found the time to look at
them properly.
On 12/07/2024 23:46, adrian15sgd wrote:
Hi Debian Live,
I wanted you to know that I am resuming Rescatux development.
1) Rescatux is a Debian-based live distribution featuring a graphical
wizard for rescuing broken GNU/Linux and Windows installations and
boot loaders. ( https://www.supergrubdisk.org/rescatux/ ).
Rescatux is built thanks to live-build onto a CDROM that supports:
- 686 kernel
686 is getting less support for trixie, at least the d-i will not be
made available any more; I'm unsure how long a 686 kernel will be in
Debian.
For live-build I'm providing support for bullseye, bookworm, trixie
and sid, but not older versions.
That's useful to know so that I can unblock the SELinux MR.
- amd64 kernel
- IA32 UEFI
- x64 UEFI
- Media with SELinux Filesystem so that the Live Media can be boot in
SELinux Permissive mode.
- Automatic Arch Detection for Syslinux
- Automatic Arch Detection for Grub2 (This is already in upstream
live-build)
- LiveID so that two different isos can be differentiated.
.
2) As such I will be adding either new features to live-build or
recycling old features that only were found on the Rescatux's
live-build ( https://github.com/rescatux/live-build ) and live-boot (
https://github.com/rescatux/live-boot ) forks.
My main approach will be to send draft merge-requests onto Salsa and
just discuss them there.
That's what I was advised to do back in the day, probably around
2021. If you think it's much better to discuss them in a thread here
in the mailing list just let me know.
Having smaller bits to review will be easier to have it integrated in
the main branch.
Yeah, well, I try to make the MRs to cover only one feature. If an MR
has too many changes please complain and I will try to split it on
several MRs.
3) As a summary of what I will be working on (which might be converted
onto a Merge Request or not) is:
- Add SELinux support to live-build (
https://github.com/rescatux/live-build/commit/d93a98634bb915c4c943a7b53dc9f44e8c5a5e4b
)
- Add LiveID support
* Live-boot (
https://github.com/rescatux/live-boot/commits/liveid-001/ )
* Live-build (
https://github.com/rescatux/live-build/commits/1a895c14216fe4f3a241b456fa19d1c603558fd2/
)
* About LiveID ( https://github.com/rescatux/liveid ) > - IA32
UEFI shim not provided when 686 and amd64 are installed
*
https://github.com/rescatux/live-build/commit/c8738fb101859f23b3e74623e9696f5c3940a9b3
*
https://github.com/rescatux/live-build/commit/0713b0c409714e1214ccbff5a5daa67f0e95164f
I managed to peek at this already, while writing this mail.
Nice.
- Arch Detection for Syslinux
*
https://github.com/rescatux/live-build/commit/99ddc7bb9510ee4810b55a391e35060dd68cf9ee
* https://salsa.debian.org/live-team/live-build/-/merge_requests/25
- Non-free firmware by default in Live-Build
* https://lists.debian.org/debian-live/2022/12/msg00002.html
non-free-firmware is properly supported in live-build nowadays and is
enabled when `--archive-areas "main non-free-firmware"` is used
(bullseye needs 'main non-free contrib').
Well, if I have to add `--archive-areas "main non-free-firmware"` when
building the iso... it's not properly supported in my own eyes.
I expect something similar to non-free firmware being included and
turned on by default and then having a boot option (in both grub.cfg and
syslinux cfgs) so those non-free-firmware modules can be blacklisted and
not used at all.
Also an option to enable or disable this behaviour when building the
image if one wants to.
Be aware that the links above are branches or tags related to 2021's
code so that's not what I'm going to Merge Request. I will have to
rework some code and probably some of it will be written from
scratch. I have added the links just in case anyone was curious about
knowing more about these features.
4) So if you see that I begin to post here or in the salsa merge
requests more frequently than before that's why.
Your MRs are welcomed, but (as you well know) time is the limiting
factor.
Yeah, I know.
Now that I have received an answer from you I'm a bit more relieved.
With kind regards,
Roland Clobus
