RedPill - the new loader for 6.2.4 - Discussion


Recommended Posts

47 minutes ago, SpiRe said:

Can we please create a separate thread for this tool chain?

Thought about it... but this is rather an addition to redpill, than XPE development, isn't it? 

 

47 minutes ago, SpiRe said:

Also it would be great if we were provided link to the github repository (if it's not already here or even created).

I understand that you volunteer to push it to github? Be my guest :)

Everyone is free to modify the sources, publish modifications here or push them to github.

 

I claim no ownership of the toolchain builder - as such I would appreciate if my name is not mentioned in the github repo.  I prefer to not leave my marks on Github with it... 

 

Update: I forget to mention that I uploaded the fix for 0.7.4 in the original post pointing to the development branch for apollolake-7.0.1-42214.

 

Edited by haydibe
  • Like 1
  • Thanks 1
Link to post
Share on other sites
20 минут назад, haydibe сказал:

 

Update: I forget to mention that I uploaded the fix for 0.7.4 in the original post pointing to the development branch for apollolake-7.0.1-42214.

 

 

With the last update toolchain 

[#] Checking runtime for required tools... [OK]
[#] PAT file /opt/redpill-load/cache/ds918+_42214.pat not found - downloading from https://global.download.synology.com/download/DSM/release/7.0.1/42214/DSM_DS918%2B_42214.pat
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  339M  100  339M    0     0  16.3M      0  0:00:20  0:00:20 --:--:-- 17.7M
[#] Verifying /opt/redpill-load/cache/ds918+_42214.pat file... [OK]
[#] Unpacking /opt/redpill-load/cache/ds918+_42214.pat file to /opt/redpill-load/build/1631652312/pat-ds918+_42214-unpacked... [OK]
[#] Verifying /opt/redpill-load/build/1631652312/pat-ds918+_42214-unpacked/zImage file... [OK]
[#] Patching /opt/redpill-load/build/1631652312/pat-ds918+_42214-unpacked/zImage to /opt/redpill-load/build/1631652312/zImage-patched... [OK]
[#] Verifying /opt/redpill-load/build/1631652312/pat-ds918+_42214-unpacked/rd.gz file... [OK]
[#] Unpacking /opt/redpill-load/build/1631652312/pat-ds918+_42214-unpacked/rd.gz file to /opt/redpill-load/build/1631652312/rd-ds918+_42214-unpacked... [OK]
[#] Apply patches to /opt/redpill-load/build/1631652312/rd-ds918+_42214-unpacked... [OK]
[#] Patching config files in ramdisk... [OK]
[#] Adding OS config patching... [OK]
[#] Repacking ramdisk to /opt/redpill-load/build/1631652312/rd-patched-ds918+_42214.gz... [OK]
[#] Generating GRUB config... [OK]
[#] Creating loader image at /opt/redpill-load/images/redpill-DS918+_7.0.1-42214_b1631652312.img... [ERR]
[!] Failed to copy /opt/redpill-load/config/_common/EFI/. to /opt/redpill-load/build/1631652312/img-mnt/part-1/EFI

/bin/cp: cannot create directory '/opt/redpill-load/build/1631652312/img-mnt/part-1/EFI/./boot': File exists

*** Process will exit ***
make: *** [Makefile:33: build_redpill_load] Error 1

 

Edited by Amoureux
Link to post
Share on other sites

... this kind of makes me wonder if I should release the toolchain loader with just the ttg repos in the global_settings.json, and let everyone add their own repos for everything custom. Afterall the global_settings.json is designed to support that szenario.   

  • Like 1
Link to post
Share on other sites
28 минут назад, haydibe сказал:

... this kind of makes me wonder if I should release the toolchain loader with just the ttg repos in the global_settings.json, and let everyone add their own repos for everything custom. Afterall the global_settings.json is designed to support that szenario.   

why not? But set default scheme with main repo.

 

P.S.

Wery interesting... building RedPill image with the last toolchain on my NAS  was successful. macOS specific behavior?

Edited by Amoureux
Link to post
Share on other sites

I removed all platform versions from the global_config.json that did not point to the @ThorGroupredpill-load repository. Thus, there is no build-in <platform_version> for DSM7.0.1 anymore and you will have to add according settings to the global_config.json yourself. It proved to be impossible to keep track of all changes that happen arround redpill-load, and after all not everyone wants to have an optioniated configuration that uses a specific fork.

 

changes:redpill-tool-chain_x86_64_v0.8.zip

removed all platform versions that use redpill-load repostories other then the offical TTG repo -> all 7.0.1 versions

 

Edited by haydibe
  • Like 4
  • Thanks 2
Link to post
Share on other sites

@ThorGroup Is there any way to get S.M.A.R.T data when you hdd passthrough as scsi i passed through hdd which connected on LSI SaS it worked like expected but showing qemu drive and wrong temp because adding LSI sas driver will might work but idk i failed many times

a4d703fd007c2f28194c43f5e2aef21a.jpg

recently switched my main nas to this yes i have backup don’t worry trying what we can archive if we don’t have working drivers in future
dsm 7.0.1

edit :- we can have smart data on proxmox webui ok that is other side

edit :- serial is spamming “generating fake smart”


[  269.267949]  sd_ioctl(HDIO_DRIVE_CMD ; ATA_CMD_ID_ATA) failed with error=-22, attempting to emulate something[  269.269528]  Generating completely fake ATA IDENTITY[  269.271472]  Handling ioctl(0x30d) for /dev/sdl[  269.272409]  sd_ioctl(0x30d) - not a hooked ioctl, noop[  269.273462]  Handling ioctl(0x31f) for /dev/sdl[  269.274459]  sd_ioctl(HDIO_DRIVE_CMD ; ATA_CMD_ID_ATA) failed with error=-22, attempting to emulate something[  269.276229]  Generating completely fake ATA IDENTITY[  273.120359]  Handling ioctl(0x31f) for /dev/sdh[  273.121174]  Got SMART *command* - looking for feature=0xd0[  273.122451]  Generating fake SMART values[  275.790673]  Handling ioctl(0x30d) for /dev/sdh[  275.791803]  sd_ioctl(0x30d) - not a hooked ioctl, noop[  275.792771]  Handling ioctl(0x31f) for /dev/sdh[  275.793646]  sd_ioctl(HDIO_DRIVE_CMD ; ATA_CMD_ID_ATA) failed with error=-22, attempting to emulate something[  275.795185]  Generating completely fake ATA IDENTITY[  275.797133]  Handling ioctl(0x30d) for /dev/sdi[  275.797975]  sd_ioctl(0x30d) - not a hooked ioctl, noop[  275.798938]  Handling ioctl(0x31f) for /dev/sdi



Sent from my iPhone using Tapatalk

Link to post
Share on other sites
6 hours ago, haydibe said:

"clean all" removed all images (last build + orphaned), but did only remove the build cache of orhaned images, but not the latest.

Now "clean all" will clean the build cache for the last build image as well.

 

re-uploaded with yumkey fix

 

 

redpill-tool-chain_x86_64_v0.7.4_fix.zip 8.07 kB · 30 downloads

 

i can't find the image file

 

 

rtc-074.jpg

Edited by snowfox
Link to post
Share on other sites

I compiled my network driver (e1000) using sources 25426branch apollolake but all incomming connections (exempt ping) stuck in SYN_RECV state. If I try "curl http://127.0.0.1:5000" or using the IP over serial console I got HTML response. The "route" command takes ~20 seconds to complete but everything's fine.

 

Someone could help me, for now I'm out of ideas to fix this ?

 

I'm running under VirtualBox with Intel PRO/1000 MT (82540EM).

 

version:        7.3.21-k8-NAPI
license:        GPL
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     E8EA0212E46FF2123F995C4
depends:        
retpoline:      Y
intree:         Y
vermagic:       4.4.180+ SMP mod_unload 
parm:           TxDescriptors:Number of transmit descriptors (array of int)
parm:           RxDescriptors:Number of receive descriptors (array of int)
parm:           Speed:Speed setting (array of int)
parm:           Duplex:Duplex setting (array of int)
parm:           AutoNeg:Advertised auto-negotiation setting (array of int)
parm:           FlowControl:Flow Control setting (array of int)
parm:           XsumRX:Disable or enable Receive Checksum offload (array of int)
parm:           TxIntDelay:Transmit Interrupt Delay (array of int)
parm:           TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm:           RxIntDelay:Receive Interrupt Delay (array of int)
parm:           RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm:           debug:Debug level (0=none,...,16=all) (int)
 

Thanks !

 

 

2021-09-14_23-37.png.a5c6f9bdfc12205b7ce1a419f986a910.png

Link to post
Share on other sites
4 hours ago, snowfox said:

i can't find the image file

 

I assume you mean that the toolchain docker image you wanted to build failed to be created? At least that's what you screenshot indicates.

 

Though, the error message does not help to pinpoint the cause. It might be thrown by apt or curl itself. I just checked the jq download url in a browser -> still valid. 

 

The" I have no idea" attempt to fix it, would be: "clean all" and a restart of the docker service or the docker host itself. 

 

 

Link to post
Share on other sites
8 hours ago, haydibe said:

I removed all platform versions from the global_config.json that did not point to the @ThorGroupredpill-load repository

that was good move. We have too many forks of origin repository. Too many individual changes. All commits made by others users should be pulled to @ThorGroup repo and aproved by they.

 

  • Like 2
Link to post
Share on other sites
7 minutes ago, shibby said:

that was good move. We have too many forks of origin repository. Too many individual changes. All commits made by others users should be pulled to @ThorGroup repo and aproved by they.

 

agree. I use fork to submit pull request and realize some of my own ideas, which will change at any time, and lack of testing

  • Like 1
Link to post
Share on other sites

Thank you @jumkey, I will test your development branch on baremetal DS918+, 7.0.1 RC. Until now I had chchia`s master branch.

 

I want to know if someone else with this combo (baremetal, ds918+, 7.0.1 RC) has the error where the usb boot drive is mounted.

 

After TTG introduced sata boot support, this error appeared, but I don`t see anyone complaining about this, only me and  @FiberInternetUser.

Link to post
Share on other sites
43 minutes ago, ct85msi said:

I want to know if someone else with this combo (baremetal, ds918+, 7.0.1 RC) has the error where the usb boot drive is mounted.

Lenovo M93p, ds918+, 7.0.1rc, redpill compiled yesterday from jumkey`s develop branch... all works fine.

  • Like 1
Link to post
Share on other sites
11 hours ago, Amoureux said:

 

With the last update toolchain 


[#] Creating loader image at /opt/redpill-load/images/redpill-DS918+_7.0.1-42214_b1631652312.img... [ERR]
[!] Failed to copy /opt/redpill-load/config/_common/EFI/. to /opt/redpill-load/build/1631652312/img-mnt/part-1/EFI

/bin/cp: cannot create directory '/opt/redpill-load/build/1631652312/img-mnt/part-1/EFI/./boot': File exists

*** Process will exit ***
make: *** [Makefile:33: build_redpill_load] Error 1

 

I was having exactly the same issues trying to build on macOS with Docker Desktop. See my posts from a few pages back (plus suggestions for fixes from haydibe and jumkey). Eventually got it "working" by creating a debian VM in VMware fusion, installing docker and building it in there instead. It's some weirdness with macOS's posix stuff I think.

Link to post
Share on other sites
10 hours ago, haydibe said:

I removed all platform versions from the global_config.json that did not point to the @ThorGroupredpill-load repository. Thus, there is no build-in <platform_version> for DSM7.0.1 anymore and you will have to add according settings to the global_config.json yourself. It proved to be impossible to keep track of all changes that happen arround redpill-load, and after all not everyone wants to have an optioniated configuration that uses a specific fork.

 

changes:redpill-tool-chain_x86_64_v0.8.zip

removed all platform versions that use redpill-load repostories other then the offical TTG repo -> all 7.0.1 versions

 

This got building working again on macOS with Docker Desktop for me. I added the 'bromolow-7.0.1-42214' stanza back in to global_config.json and built successfully.

  • Like 1
Link to post
Share on other sites
11 hours ago, plarkass said:

I would like to know if there is a documentation about how to start with this amazing loader.

In the past, I used jun loader on my actual xpenology but I want to install a new one on dsm7.

 

If someone have a link are few explanation, I really appreciate.

Everything you need is in this thread, but it's not for beginners and is not considered beta quality yet. If you can't follow the instructions present here it's not for you yet. Be patient :D

Link to post
Share on other sites

I just booted my baremetal Gen8 off an image created with @ThorGroup's latest redpill code (as of this release), and haydibe's 0.8 toolchain. This is using bromolow 7.0.1-RC1 (42214) It booted successfully, all disks and NICs in my configuration are online, but I'm seeing the following on the serial console every 10-60 seconds (it is not occurring on a regular pattern):

Quote

[  446.593174] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sda

[  446.626781] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop

[  446.666090] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdb

[  446.700210] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop

[  446.740036] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdc

[  446.773960] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop

[  446.812469] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdd

[  446.846153] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop

[  446.884977] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sde

[  446.918111] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop

[  446.965213] <redpill/smart_shim.c:794> Handling ioctl(0x31f) for /dev/sde

 

The messages appear in clumps for each SATA device in my system (four HDDs and SSD used for read cache). It's as if something is trying to query the disks at a low level and failing as the redpill smart_shim doesn't handle it (hence the 'noop').

 

0x31f appears to be "HDIO_DRIVE_CMD execute a special drive command"

0x2285 is SG_IO, which appears to be used for sending SCSI commands to a device

 

The system appears to be fully functional other than the logging described above. NB these messages were not present in the console output on ThorGroup's previous release.

 

*edit*

 

My guess is it's to do with this:
 

SCSI drives monitoring subsystem
This is more of a dev-only functionality, but lies in the core of all the features described above. In short, Linux kernel contains a mechanism for publishing and subscribing to events. Unfortunately it's a rather new and niche subsystem. The SCSI driver, as one of the oldest parts of the Linux kernel, doesn't support the notifications. In order to react to new drives being connected to the system we developed an extension for the SCSI driver adding that functionality. We will probably pursue upstreaming of these changes, so one day they can land in the kernel natively.
 
For details see the following commits:
https://github.com/RedPill-TTG/redpill-lkm/commit/098bae23fe21ccd495e57b846539704899fda639 (add the notification subsystem)
https://github.com/RedPill-TTG/redpill-lkm/commit/ccc58c0883c3f0cc8a8599918cc0d5cd9491f678 (extract common SCSI functionality to a submodule)

 

EDIT: see my follow up post on the next page, I think this is just a case of excessive debug logging, and nothing's actually wrong here.

Edited by WiteWulf
Link to post
Share on other sites
4 minutes ago, ct85msi said:

@WiteWulfthis is the error I was talking about. It mounts the usb boot stick and dmesg gives me this error.

 

I opened a ticket https://github.com/RedPill-TTG/redpill-load/issues/30

I'm not convinced. I'm not seeing any errors on my system regarding the USB stick (it's not visible once booted, as it should be), and the messages are all regarding the storage devices on my system (sda, sdb, sdc and sdd are the SATA HDDs, while sde is the SSD).

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.