Jump to content
XPEnology Community

RedPill - the new loader for 6.2.4 - Discussion

ThorGroup

By ThorGroup
in Developer Discussion Room

 Share

Recommended Posts

dohun0310 Newbie

dohun0310

Posted
Posted

Hello, I'm using xpenology, which is a 4G RAM for the Intel Celeron J1900. I'm looking at your incredible project and trying to apply it to this xpenology. But this xpenology has been installed on msata ssd with built-in dsm. At that time, both vid and pid were empty and used, but your project stopped at the grub because vid and pid were empty. Help me, please. (I've tried vid 0x46f4 and pid 0x0001, but it's the same)

  • Thanks 1
Link to comment
Share on other sites
Piteball Junior Member

Piteball

Posted
Posted (edited)
4 hours ago, dohun0310 said:

Hello, I'm using xpenology, which is a 4G RAM for the Intel Celeron J1900. I'm looking at your incredible project and trying to apply it to this xpenology. But this xpenology has been installed on msata ssd with built-in dsm. At that time, both vid and pid were empty and used, but your project stopped at the grub because vid and pid were empty. Help me, please. (I've tried vid 0x46f4 and pid 0x0001, but it's the same)

 

As has been noted many times over in the last posts, there's no SATA DOM support implemented yet, which means you can only boot using USB storage. It's also why you can't boot this loader on ESXi yet.

Edited by Piteball
Link to comment
Share on other sites
ThorGroup Junior Member

ThorGroup

Posted
  • Author
Posted (edited)

Good new & bad news - but an update is ready! ;)

 

SATA boot is here

In the recent days we were working hard to provide SATA boot support for those who cannot use USB (e.g. ESXi users). We stepped into an uncharted territory here as Jun's loader used a completely different method (which isn't feasible for v7). As of a trivia fact it seems like he did try to plug into SCSI subsystem but he never finish it.

The idea behind that is simple. In short we had to intercept the kernel probe events for any new disks and change their vendor name and model name on-the-fly. However, it's easier said than done as there are three core obstacles to consider:

  • SCSI driver has no hooks to plug to
  • how to distinguish which drive should be altered?
  • what if the drive was processed before the module loaded?

 

Hooking unkhokable

We decided to approach this in a non-hacky way to make sure it's stable over the time. We plugged directly to the Linux drivers subsystem and designated our own method for SCSI devices probing. Doing it this way allows us to filter incoming drives without stepping into race condition territory like with the USB.

 

Which drive to alter?

Unlike USB drives, SATA doesn't use vid/pid or anything like that. In the pure SCSI world (SATA uses SCSI as its underlying protocol) devices are expected to have a type and simply respond to commands without any additional drivers (making vid/pid useless). There are three ways to match the devices:

  • vendor/model names: syno uses them, but they're not unique (in fact hypervisors use hardcoded pairs for all drives - forwarded, virtual, USB etc)
  • serial number: as above, they're not unique
  • host/port location: can possibly change from boot to boot in virtualized environments, they're not guaranteed to be the same between kernels (i.e. you cannot boot ubuntu to check and then assume DSM has the same one). Additionally, they're not easily controllable by the user as normally nobody cares which virtual port a drive is attached to

The only stable and user-controllable factor is the capacity. Filtering by that isn't trivial as the SCSI metadata doesn't contain it - we need to execute commands to the drive to query for it. However, it's the most stable and robust approach of all and we went with it. By default we consider the first drive which is less or equal to 1GiB to be the synoboot drive. The default image generated by redpill-load is ~300MiB so we are well under that. This value can be changed (see below).

 

 

What if SCSI was faster than RedPill?

We were happy to release SATA support much earlier until we hit the wall. Normally during testing we simply "plugged" the drive after the module was already loaded and debugged all the code. However, the full boot process is much more dynamic. In around half of the attempts we did the SATA drive was processed before RedPill LKM was able to load. Well, *******.

Due to how syno assigns synoboot it's nearly impossible to change the designation after it was done. Because of this we added a system where the module will check all existing drives if they match the capacity criteria. If any of them matches it will be disconnected and a force rescan of the controller will be triggered. This is perfectly safe as long as the drive is not mounted. This is why we take care to only touch disks which are already confirmed to be shimmable. Also, this functionality shouldn't break in the future as we're using the official SCSI API provided by the SCSI driver ;)

 

If you want to read more about the technical details of how USB and/or SATA shimming works see:

 

SATA boot has limitations

And here comes the bad news: the USB boot is universal but SATA is not. Syno kernel contains a hardcoded check for three things:

  • SATA DoM supported (compilation parameter)
  • SATA DoM enabled (boot parameter)
  • SATA DoM vendor/model criteria (compilation parameter)

 

We can obviously control the enabled parameter and if needed change vendor/model hardcoded in the kernel during compilation (but we don't need to). However, there's nothing we can realistically do for the SATA DoM supported flag (CONFIG_SYNO_BOOT_SATA_DOM). When that option isn't set during compilation of the kernel the code supporting SATA DoM is not even present in the final kernel and thus changing the vendor/model names will not make the drive appear as synoboot. Due to the factors we discussed above we cannot simply change it post-factum.

This means, as of today, SATA boot is not supported on 918+ as apollolake is compiled without SATA DoM support.

 

There used to be a hacky workaround which Jun's loader used relying on altering /dev/ nodes in userland. However this approach has many problems (described in synoboot docs). It is not feasible to use it anymore. We will try to explore other avenues to fool the kernel the SATA DoM is really not a SATA DoM but maybe something else, but unfortunately no hard promises there. The main difficulty here is that the SCSI driver is littered with "MY_ABC_HERE" which (especially there) was used to replace multiple different constants making the code impossible to read and understand without experimenting what part is ACTUALLY compiled in the real kernel.

 

Something also worth mentioning is that SATA DoM does not have a way to trigger "force reinstall" like USB does. This isn't something a normal person should worry about thou. Just leaving it here as SATA DoM kernel param (see below) cannot be used along with "mfg". While technically it could boot, such state would be nonsensical as syno code doesn't support such a scenario (so we've added a check for that and error-out instead of silently failing like syno code does).

 

When using SATA boot you don't need vid/pid at all, they're ignored completely.

 

SATA boot usage is simple but be careful migrating

Using SATA boot is pretty much transparent to the non-kernel people. We check for the "synoboot_satadom=1" boot option, which is a native syno option for enabling SATA DoM support. If that option is set we switch shimming from USB (default) to SATA and run the whole logic.

In addition the 1GiB criterion to tell whether the drive is a synoboot or not is configurable using a custom "dom_szmax=" option. It accepts any value from zero upwards. It should be specified in MiB (e.g. the default is dom_szmax=1024). This is really only needed if you have more than one SATA drive which are <1GiB..... so yeah, pretty unlikely.

 

If you previously used Jun's loader and specified internalportcfg=/esataportcfg=/usbportcfg=/DiskIdxMap to hide boot drive from the UI (especially while using ESXi) you must reevaluate these options. This is because disk hiding is no longer needed as we utilize the official SATA DoM and thus DSM will not count that disk while doing DiskIdxMap shifts. If you leave it as-is your first data disk will be invisible.

The forum has a great post about what these values mean and how they play together:

 

--------------------------------------------------------------------------------------------------------------------------------------------

 

GRUB saves boot options

Along with that we also updated RedPill Load to support multiple boot options and actually save which one was booted last. So when you first run a new image make sure to select the SATA boot option if you so choose. After every reboot GRUB will remember your choice. All images supporting SATA DoM now contain two boot options by default - USB or SATA. At this stage we can say if you're using a platform which allows both (e.g. Proxmox) there's no preference what you should use, both of them should be equally stable.

 

Crash-by-default

We decided to enable "bug-on-load-error" option in the default build of RP LKM. This means you will get a kernel panic right away if the module detected that something couldn't be done instead of allowing the system to boot (and potentially display error 13). This will make bug reporting and debugging much easier for everybody.

 

Documentation updates

We've added the documentation for the following things:

 

Automatic kernel patching

...some probably see where it goes ;) We forgot to mention that during our previous update but we were able to find a way to automatically patch not only the ramdisk check but also the boot_params chain of trust flags. This means that as long as the kernel doesn't change that much reacting to a new version should be pretty quick.

 

--------------------------------------------------------------------------------------------------------------------------------------------

 

Now, continuing the tradition, let us reply to all the outstanding commens :)

On 8/12/2021 at 4:46 AM, NooL said:

The error 13 - No idea if its the same issue/related, but I remember that selecting the "reinstall" option in Jun's loader and then attempting to install will throw the error 13 after uploading the image as well (while the normal option wont) 

 

Maybe worth looking into, but no idea, just a random thought :) 

See the error 13 docs mentioned above. The reinstall option will not help. The only thing which "reinstall" / "mfg" option does in Jun's loader (and in RedPill as well) is to shim USB to different vid/pid values which signals to DSM "hey, ignore existing OS and boot to the installer no matter what".

 

 

On 8/12/2021 at 4:52 AM, loomes said:

Edit the patch file and replace the line with:

"$UniqueRD" = "kvmcloud" ] || [ -e "/lib/modules/virtio.ko" ]; then

 

So you are sure that the virtio drivers gets loading when they exist.

We're not so convinced to loading VirtIO drivers everywhere, we try to target the systems which truly can use them ;)

Did we miss something? Is there any reason you want to load VirtIO on all platforms blindly?

 

 

On 8/13/2021 at 12:17 AM, havast said:

Hi All!

 

First of all, thank you devs for the hard work, you are keeping this project alive, nice!

 

Second: I would like to test DSM7 on my ESXI host. Anyone can build a 3615xs or 3617xs loader for me, if i give SN and MAC for it? Sure i would donate a few beer for the help :)

 

Thanks for the help!

You can do so now using freshly bakes SATA boot. However, we don't recommend using the loader just yet if you aren't able to compile it. It's usage will be significantly simpler when we have a beta version - for now we try to make it as such that develoeprs who know what they're doing can play with it, saving regular hobbysts from a possible data loss.

 

 

On 8/13/2021 at 4:34 PM, nemesis122 said:

Hi all

Thank you for all your hardwork.

Maybe im stupid :-) im not a developer.

Could you help me how can i create/use this loader/with the docker file from haydibe ?

Import in docker (How) ?? install Linux and then with ssh ?? 

thank you for a small guide for a noob.

thanks

 

The loader is not at the point of being "noob friendly" (and it's like that on purpose to save you from a possible data loss).

 

 

On 8/14/2021 at 12:25 AM, cwiggs said:

Do you have any plans to upload this to github?  It'd be nice to track changes, compile issues, and eventually merge back to a official redpill repo.

We're currently working on incorporating @haydibe's docker into RedPill Load repo :)  As we were working on the SATA boot feature we didn't want to introduce another layer of complexity as the SATA boot involved changes across all three repos.

 

 

5 hours ago, dohun0310 said:

Hello, I'm using xpenology, which is a 4G RAM for the Intel Celeron J1900. I'm looking at your incredible project and trying to apply it to this xpenology. But this xpenology has been installed on msata ssd with built-in dsm. At that time, both vid and pid were empty and used, but your project stopped at the grub because vid and pid were empty. Help me, please. (I've tried vid 0x46f4 and pid 0x0001, but it's the same)

The SATA support is only present in the newest release. if you wish to test it pull the new version.

 

 

Edited by ThorGroup
  • Like 2
  • Thanks 4
Link to comment
Share on other sites
dohun0310 Newbie

dohun0310

Posted
Posted
2 minutes ago, ThorGroup said:

좋은 새 소식과 나쁜 소식 - 하지만 업데이트가 준비되었습니다! ;)

 

SATA 부팅은 여기

최근에는 USB를 사용할 수 없는 사용자(예: ESXi 사용자)를 위해 SATA 부팅 지원을 제공하기 위해 열심히 노력했습니다. Jun의 로더가 완전히 다른 방법(v7에서는 가능하지 않음)을 사용했기 때문에 우리는 여기에서 미지의 영역에 들어섰습니다.

그 뒤에 숨겨진 아이디어는 간단합니다. 간단히 말해서 우리는 새 디스크에 대한 커널 프로브 이벤트를 가로채서 공급업체 이름과 모델 이름을 즉석에서 변경해야 했습니다. 그러나 다음과 같은 세 가지 핵심 장애물을 고려해야 하기 때문에 말처럼 쉽지 않습니다.

  • SCSI 드라이버에는 연결할 후크가 없습니다.
  • 변경해야 할 드라이브를 구별하는 방법은 무엇입니까?
  • 모듈이 로드되기 전에 드라이브가 처리되면 어떻게 됩니까?

훅킹 불가

우리는 시간이 지남에 따라 안정적인지 확인하기 위해 해킹이 아닌 방식으로 접근하기로 결정했습니다. 우리는 Linux 드라이버 하위 시스템에 직접 연결하고 SCSI 장치 프로빙을 위한 자체 방법을 지정했습니다. 이 방법을 사용하면 USB와 같은 경쟁 조건 영역에 들어가지 않고 들어오는 드라이브를 필터링할 수 있습니다.

 

어떤 드라이브를 변경할 것인가?

USB 드라이브와 달리 SATA는 vid/pid 또는 이와 유사한 것을 사용하지 않습니다. 순수한 SCSI 세계(SATA는 SCSI를 기본 프로토콜로 사용)에서 장치는 유형이 있고 추가 드라이버 없이 명령에 간단히 응답할 것으로 예상됩니다(vid/pid를 쓸모 없게 만듭니다). 장치를 일치시키는 세 가지 방법이 있습니다.

  • 공급업체/모델 이름 : syno가 사용하지만 고유하지 않습니다(사실 하이퍼바이저는 모든 드라이브에 대해 하드코딩된 쌍을 사용합니다(전달, 가상, USB 등)).
  • 일련 번호: 위와 같이 고유하지 않습니다.
  • 호스트/포트 위치: 가상화된 환경에서 부팅할 때마다 변경할 수 있지만 커널 간에 동일하다는 보장은 없습니다(즉, 우분투를 부팅하여 확인하고 DSM이 동일한 것으로 가정할 수 없음). 또한 일반적으로 아무도 드라이브가 연결된 가상 포트에 신경 쓰지 않기 때문에 사용자가 쉽게 제어할 수 없습니다.

안정적이고 사용자가 제어할 수 있는 유일한 요소는 용량입니다. SCSI 메타데이터에 포함되어 있지 않기 때문에 이를 기준으로 필터링하는 것은 간단하지 않습니다. 드라이브에 대한 명령을 실행하여 쿼리해야 합니다. 그러나 그것은 가장 안정적이고 강력한 접근 방식이며 우리는 그것을 사용했습니다. 기본적으로 1GiB보다 작거나 같은 첫 번째 드라이브를 synoboot 드라이브로 간주합니다. redpill-load에 의해 생성된 기본 이미지는 ~300MiB이므로 그 이하입니다. 이 값은 변경할 수 있습니다(아래 참조).

 

 

SCSI가 RedPill보다 빨랐다면?

우리는 벽에 부딪힐 때까지 SATA 지원을 훨씬 더 일찍 출시하게 되어 기뻤습니다. 일반적으로 테스트하는 동안 모듈이 이미 로드되고 모든 코드를 디버그한 후 드라이브를 "플러그"했습니다. 그러나 전체 부팅 프로세스는 훨씬 더 동적입니다. 우리가 수행한 시도의 약 절반에서 RedPill LKM이 로드될 수 있기 전에 SATA 드라이브가 처리되었습니다. 잘, *******.

syno가 synoboot를 할당하는 방식으로 인해 완료 후 지정을 변경하는 것은 거의 불가능합니다. 이 때문에 모듈이 용량 기준과 일치하는 경우 모든 기존 드라이브를 확인하는 시스템을 추가했습니다. 그들 중 하나라도 일치하면 연결이 끊어지고 컨트롤러의 강제 재검색이 트리거됩니다. 이것은 드라이브가 장착되지 않는 한 완벽하게 안전합니다. 이것이 이미 shimmable로 확인된 터치 디스크에만 주의를 기울이는 이유입니다. 또한 이 기능은 SCSI 드라이버에서 제공하는 공식 SCSI API를 사용하고 있으므로 앞으로 중단되지 않아야 합니다.;)

 

USB 및/또는 SATA shimming 작동 방식에 대한 기술적인 세부 사항에 대해 자세히 알아보려면 다음을 참조하십시오.

 

SATA 부팅에는 제한이 있습니다.

그리고 여기에 나쁜 소식이 있습니다. USB 부팅은 보편적이지만 SATA는 그렇지 않습니다. Syno 커널에는 세 가지에 대한 하드코딩된 검사가 포함되어 있습니다.

  • SATA DoM 지원(컴파일 매개변수)
  • SATA DoM 활성화(부팅 매개변수)
  • SATA DoM 공급업체/모델 기준(컴파일 매개변수)

활성화된 매개변수를 분명히 제어할 수 있고 필요한 경우 컴파일 중에 커널에 하드코딩된 공급업체/모델을 변경할 수 있습니다(그러나 우리는 그렇지 않습니다). 그러나 SATA DoM 지원 플래그(CONFIG_SYNO_BOOT_SATA_DOM)에 대해 현실적으로 할 수 있는 일은 없습니다. 커널을 컴파일하는 동안 해당 옵션이 설정되지 않으면 SATA DoM을 지원하는 코드가 최종 커널에도 없으므로 공급업체/모델 이름을 변경해도 드라이브가 synoboot로 표시되지 않습니다. 위에서 논의한 요인으로 인해 사후에 간단히 변경할 수 없습니다.

즉, 현재 SATA DoM 지원 없이 apollolake 가 컴파일 되므로 SATA 부팅은 918+ 에서 지원되지 않습니다 .

 

Jun의 로더가 userland의 /dev/ 노드를 변경하는 데 사용하는 해킹 해결 방법이 있었습니다. 그러나 이 접근 방식에는 많은 문제가 있습니다(synoboot 문서에 설명됨). 더 이상 사용할 수 없습니다. 우리는 커널을 속이는 다른 방법을 모색하려고 노력할 것입니다. SATA DoM은 실제로 SATA 운명이 아니지만 아마도 다른 것일 수 있지만 불행히도 거기에는 확실한 약속이 없습니다. 여기서 가장 큰 어려움은 SCSI 드라이버에 "MY_ABC_HERE"가 흩어져 있다는 것입니다. 이것은 (특히 거기에) 실제 커널에서 실제로 컴파일된 부분을 실험하지 않고는 코드를 읽고 이해할 수 없도록 만드는 여러 다른 상수를 대체하는 데 사용되었습니다.

 

언급할 가치가 있는 것은 SATA DoM에는 USB처럼 "강제 재설치"를 트리거하는 방법이 없다는 것입니다. 이것은 보통 사람이 당신에 대해 걱정할 일이 아닙니다. SATA DoM 커널 매개변수(아래 참조)로 여기에 그대로 두기만 하면 "mfg"와 함께 사용할 수 없습니다. 기술적으로 부팅할 수는 있지만 syno 코드가 이러한 시나리오를 지원하지 않기 때문에 그러한 상태는 무의미합니다(그래서 우리는 syno 코드처럼 자동으로 실패하는 대신 이를 확인하고 오류를 제거하도록 추가했습니다).

 

SATA 부팅을 사용할 때 vid/pid가 전혀 필요하지 않으며 완전히 무시됩니다.

 

SATA 부팅 사용법은 간단하지만 신중하게 마이그레이션

SATA 부팅을 사용하는 것은 커널이 아닌 사람들에게 거의 투명합니다. SATA DoM 지원을 활성화하기 위한 기본 syno 옵션인 "synoboot_satadom=1" 부팅 옵션을 확인합니다. 해당 옵션이 설정되면 시밍을 USB(기본값)에서 SATA로 전환하고 전체 로직을 실행합니다.

또한 드라이브가 synoboot인지 여부를 알려주는 1GiB 기준은 사용자 지정 "dom_szmax=" 옵션을 사용하여 구성할 수 있습니다. 0부터 모든 값을 허용합니다. MiB로 지정해야 합니다(예: 기본값은 dom_szmax=1024). 이것은 <1GiB.....인 SATA 드라이브가 두 개 이상인 경우에만 필요합니다. 예, 가능성은 거의 없습니다.

 

이전에 Jun의 로더를 사용하고 UI에서 부팅 드라이브를 숨기기 위해 internalportcfg=/esataportcfg=/usbportcfg=/DiskIdxMap을 지정한 경우(특히 ESXi를 사용하는 동안) 이러한 옵션을 다시 평가해야 합니다 . 공식 SATA DoM을 사용하므로 디스크 숨김이 더 이상 필요하지 않으므로 DSM이 DiskIdxMap 이동을 수행하는 동안 해당 디스크를 계산하지 않기 때문입니다. 그대로 두면 첫 번째 데이터 디스크가 표시되지 않습니다.

포럼에는 이러한 가치가 무엇을 의미하고 어떻게 함께 작동하는지에 대한 훌륭한 게시물이 있습니다.

 

-------------------------------------------------- -------------------------------------------------- ----------------------------------------

 

GRUB는 부팅 옵션을 저장합니다.

이와 함께 여러 부팅 옵션을 지원하고 실제로 마지막으로 부팅된 옵션을 저장하도록 RedPill Load를 업데이트했습니다. 따라서 새 이미지를 처음 실행할 때 SATA 부팅 옵션을 선택해야 합니다. 재부팅할 때마다 GRUB은 사용자의 선택을 기억합니다. 이제 SATA DoM을 지원하는 모든 이미지에는 기본적으로 USB 또는 SATA의 두 가지 부팅 옵션이 포함됩니다. 이 단계에서 우리는 둘 다 허용하는 플랫폼(예: Proxmox)을 사용하는 경우 사용해야 하는 기본 설정이 없으며 둘 다 똑같이 안정적이어야 한다고 말할 수 있습니다.

 

기본적으로 충돌

RP LKM의 기본 빌드에서 "bug-on-load-error" 옵션을 활성화하기로 결정했습니다. 이는 모듈이 시스템 부팅을 허용하지 않고(및 잠재적으로 오류 13을 표시함) 수행할 수 없는 작업을 감지한 경우 즉시 커널 패닉이 발생함을 의미합니다. 이렇게 하면 모든 사람이 버그 보고 및 디버깅을 훨씬 쉽게 수행할 수 있습니다.

 

문서 업데이트

다음 사항에 대한 문서를 추가했습니다.

자동 커널 패치

...일부는 어디로 가는지 ;)알 수 있습니다. 이전 업데이트에서 언급하는 것을 잊었지만 ramdisk 검사 뿐만 아니라 boot_params 신뢰 플래그 체인 도 자동으로 패치하는 방법을 찾을 수 있었습니다 . 이는 커널이 그렇게 많이 변경되지 않는 한 새 버전에 대한 반응이 상당히 빨라야 함을 의미합니다.

 

-------------------------------------------------- -------------------------------------------------- ----------------------------------------

 

이제 전통을 이어가는 모든 뛰어난 댓글에 답장을 보내드리겠습니다. :)

위에서 언급한 오류 13 문서를 참조하십시오. 재설치 옵션은 도움이 되지 않습니다. Jun의 로더(및 RedPill에서도)에서 "재설치" / "mfg" 옵션이 수행하는 유일한 작업은 USB를 DSM에 "이봐, 기존 OS를 무시하고 설치 프로그램으로 부팅" 신호를 보내는 다른 vid/pid 값으로 shim하는 것입니다. 뭐라고 요".

 

 

우리는 VirtIO 드라이버를 모든 곳에 로드하는 것에 대해 확신을 갖고 있지 않으며, 이를 진정으로 사용할 수 있는 시스템을 대상으로 하려고 합니다. ;)

우리가 뭔가를 놓쳤나요? 모든 플랫폼에 VirtIO를 맹목적으로 로드하려는 이유가 있습니까?

 

 

이제 새로 구워진 SATA 부팅을 사용하여 그렇게 할 수 있습니다. 그러나 컴파일할 수 없다면 아직 로더를 사용하지 않는 것이 좋습니다. 베타 버전이 있으면 사용법이 훨씬 더 간단해질 것입니다. 지금은 자신이 하는 일을 알고 있는 개발자가 이 버전으로 게임을 할 수 있도록 하여 일반 취미 사용자가 데이터 손실을 방지할 수 있도록 하려고 합니다.

 

 

로더는 "멍청한 놈 친화적"이지는 않습니다 (그리고 그것은 가능한 데이터 손실로부터 당신을 구하기 위해 의도적으로 비슷합니다).

 

 

현재 통합 작업을 진행 중입니다. @haydibe의 도커를 RedPill 로드 리포지토리 :)  에 삽입 SATA 부팅 기능에 대해 작업할 때 SATA 부팅이 세 리포지토리 모두에 걸쳐 변경 사항을 포함하므로 다른 복잡성 계층을 도입하고 싶지 않았습니다.

 

 

SATA 지원은 최신 릴리스에만 있습니다. 테스트하려면 새 버전을 가져오세요.

 

 

But it doesn't work on 918+, which means you can't use 7.0-41890?

Link to comment
Share on other sites
ThorGroup Junior Member

ThorGroup

Posted
  • Author
Posted
11 minutes ago, dohun0310 said:

But it doesn't work on 918+, which means you can't use 7.0-41890?

You are correct, you cannot use 7.0-41890 with SATA boot. We can expect 41890 to be available soon for 3615xs. As of now if you want to play with 7.0 and along with SATA you need to use 7.0-41222 on 3615xs.

Link to comment
Share on other sites
loomes Regular Member

loomes

Posted
Posted
1 hour ago, ThorGroup said:

We're not so convinced to loading VirtIO drivers everywhere, we try to target the systems which truly can use them ;)

Did we miss something? Is there any reason you want to load VirtIO on all platforms blindly?

 

Thats only a thing im using for myself. After a commit in the past, i mean it was https://github.com/RedPill-TTG/redpill-lkm/commit/76c36a43483562c3438dd491a58208bc92e04416 (but im not sure) the detection dont work anymore in my proxmox machine so i changed the file.

Link to comment
Share on other sites
ilovepancakes Advanced Member

ilovepancakes

Posted
Posted
1 hour ago, ThorGroup said:

SATA boot is here

 

Nicely done!! I built a fresh lkm and loader and can successfully install DSM 7 on ESXi now! A couple of things I noticed from a first run...

 

1.) The Grub boot menu doesn't seem to remember the "SATA" boot option as the last chosen option. When I reboot the VM, it defaults back to USB.

 

2.) Within DSM, if I go to Info Center under Control Panel, the "General" tab doesn't load, it just is white and shows no info about DSM.

 

3.) The only way I got the install to work was to have the loader VMDK and the data VMDK on the same SATA controller. If loader is on a SCSI controller for the VM, it boots but gets error 13 again. If I move loader to SATA controller along with a data VMDK, it installs, BUT I cannot create a storage pool/volume in DSM. Storage Manager shows the Vmware SATA drive but DSM says it cannot detect the drives status as "Healthy" so it won't let that drive be used to create a volume. I know SMART doesn't work with Xpenology and ESXi, but in Jun's loader the virtual drives at least showed "Healthy" which meant DSM could use them.

 

Any insight or testing you have done on your end to make it work?  Here are some photos.

 

 

Screen Shot 2021-08-14 at 4.08.10 PM.png

Screen Shot 2021-08-14 at 4.08.18 PM.png

Screen Shot 2021-08-14 at 4.08.51 PM.png

Link to comment
Share on other sites
haydibe Guru

haydibe

Posted
Posted (edited)

... and the toolchain builder is updated to v0.5.2.  

Highlights: ´auto` action and the deactivated Docker build cache 

 

# Inofficial redpill toolchain image builder

- Creates a OCI Container (~= Docker) image based tool chain.

- Takes care of downloading (and caching) the required sources to compile redpill.ko and the required os packages that the build process depends on.

- Caches .pat downloads inside the container on the host.

- Configuration is done in the JSON file `global_config.json`; custom <platform_version> entries can be added underneath the `building_configs` block. Make sure the id is unique per block!

 

## Changes

- Added an entrypoint script that updates the redill sources in the container, executes the build and exits the container once finished.

- Added action "auto", which starts the entypoint script. If you are not activily developing on redpill, then this is the action you wil want to use.

- The action "run" retained the old behavior: it skips the entrypoint script and drops you in a  bash shell. This action is ment for devs.

- Deaktivated Docker build cache, to prevent changes in the redpill repos stay undetected when building a new image.

- Refactored the in-contaienr Makefile inside to detect the kernel version for redpill-load/ext/rp-lkm/redpill-linux-${KERNELVERSION}.ko from compiled redpill.ko

 

## Usage

 

1. Create `user_config.json` according https://github.com/RedPill-TTG/redpill-load

2. Build the image for the platform and version you want:

   `./redpill_tool_chain.sh build <platform_version>`

3. Run the image for the platform and version you want:

   `./redpill_tool_chain.sh auto <platform_version>`

 

The "old way" with `./redpill_tool_chain.sh run <platform_version>` and executing `make build_all` is still available.

 

Note: run `./redpill_tool_chain.sh` to get the list of supported ids for the <platform_version> parameter.

 

After step 3. the redpill load image should be build and can be found in the host folder "images".

 

Examples:

### See Help text

 

```

./redpill_tool_chain.sh

Usage: ./redpill_tool_chain.sh <action> <platform version>

 

Actions: build, auto, run

 

- build:    Build the toolchain image for the specified platform version.

 

- auto:     Starts the toolchain container using the previosuly build toolchain image for the specified platform.

            Updates redpill sources and builds the bootloader image automaticaly. Will end the container once done.

 

- run:      Starts the toolchain container using the previously built toolchain image for the specified platform.

            Interactive Bash terminal.

 

Available platform versions:

---------------------

bromolow-6.2.4-25556

bromolow-7.0-41222

apollolake-6.2.4-25556

apollolake-7.0-41890

```

 

### Build toolchain image

 

For Bromolow 6.2.4   : ./redpill_tool_chain.sh build bromolow-6.2.4-25556

For Bromolow 7.0     : ./redpill_tool_chain.sh build bromolow-7.0-41222

For Apollolake 6.2.4 : ./redpill_tool_chain.sh build apollolake-6.2.4-25556

For Apollolake 7.0   : ./redpill_tool_chain.sh build apollolake-7.0-41890

 

### Create redpill bootloader image

 

For Bromolow 6.2.4   : ./redpill_tool_chain.sh auto bromolow-6.2.4-25556

For Bromolow 7.0     : ./redpill_tool_chain.sh auto bromolow-7.0-41222

For Apollolake 6.2.4 : ./redpill_tool_chain.sh auto apollolake-6.2.4-25556

For Apollolake 7.0   : ./redpill_tool_chain.sh auto apollolake-7.0-41890

 

redpill-tool-chain_x86_64_v0.5.2.zip

Edited by haydibe
  • Like 3
  • Thanks 6
Link to comment
Share on other sites
cwiggs Junior Member

cwiggs

Posted
Posted
4 hours ago, ilovepancakes said:

 

2.) Within DSM, if I go to Info Center under Control Panel, the "General" tab doesn't load, it just is white and shows no info about DSM.

 

 

Screen Shot 2021-08-14 at 4.08.51 PM.png

 I have the same problem running bromolow-7.0-41222 on Proxmox 6.

Link to comment
Share on other sites
flyride Guru Master

flyride

Posted
Posted
19 hours ago, ThorGroup said:

You are correct, you cannot use 7.0-41890 with SATA boot. We can expect 41890 to be available soon for 3615xs. As of now if you want to play with 7.0 and along with SATA you need to use 7.0-41222 on 3615xs.

 

Just out of curiosity, why the continued development on 3615xs versus Broadwell?  The advantage of 3617xs is that 16 threads are accessible instead of 8.

Link to comment
Share on other sites
pocopico Guru Master

pocopico

Posted
Posted
1 hour ago, p3t3 said:

changed network e1000e, but still not working

Since you have a quite new generation CPU,  can you try the following ?

 

1. You set the VMware OS to Other  Linux 64 3.x for bromolow 

2. Capture all serial consoles output 

3. Apollo lake loader VMware OS to Other Linux 4.x

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...