WiteWulf
-
Posts
423 -
Joined
-
Last visited
-
Days Won
25
Posts posted by WiteWulf
-
-
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.
-
1
-
-
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.
-
If you're extracting using the built in archive tools in Finder it will always extract to a new folder with the name of the archive file.
-
I've tried and tried to get the most recent redpill version for bromolow 7.0.1-RC1 to build with @haydibe's 0.7.2 and 0.7.3 docker scripts on macOS 11.5.2 and it kept failing with Docker Desktop for macOS. I installed docker from home-brew instead and still got the same failure when building the image at the end. I gave up and created a Debian 10 VM in VMware Fusion and built it on there (using haydibe's docker script again) and it worked first time.. I know others have reported this working on a similar Mac setup, but I just couldn't make it work for some reason.
If you're having similar issues and don't have access to VMware fusion you could give virtualbox a go instead.
I've not tried booting my Gen8 off the new image yet, I'll give that a go tomorrow
-
6 minutes ago, ghtester said:
The almost exactly the same issue here, I just get a slightly different output but in general it also fails with: *** Please tell me who you are.
Well my later posts show that I got further than that. I deleted all my docker images and the redpill toolchain builder folder with the cached data in it and started from scratch (it only takes a few minutes to download it all, just make sure you hang on to the relevant json config file for your platform). Checking out the git repos works after I do that, but it fails at creating the image, needing a '-f' switch on a copy command. I can get into the running docker container and edit the file.sh as suggested by jumpy, but then I don't know how to call the build properly from within the running container. If I save file.sh and exit the container the script reverts back to it's previous state, missing the '-f' switch. Hopefully haydibe will update their docker scripts at some point to support this new redpill release. I'm in no hurry, though as I have a (mostly) working system at present and there are bigger things to address.
-
6 minutes ago, WiteWulf said:
I'm sure I recall this sort of behaviour from waaaaaay back when....lemme have a grep though my posting history and see if I can find it. It's a graceful shutdown/restart, yeah, not a kernel panic/crash sort of reboot?
Yup, here it is from a couple of years ago. Server boots up and operates just fine until you try to login to the web interface, and which point it initiates a reboot:
-
1
-
-
I'm sure I recall this sort of behaviour from waaaaaay back when....lemme have a grep though my posting history and see if I can find it. It's a graceful shutdown/restart, yeah, not a kernel panic/crash sort of reboot?
-
Getting a bit further now after doing a 'docker system prune -a' and 'redpill_tool_chain.sh clean all' and modifying the entrypoint.sh as per jumkey's suggestion:
[#] Generating GRUB config... [OK] [#] Creating loader image at /opt/redpill-load/images/redpill-DS3615xs_7.0.1-42214_b1631532886.img... [ERR] [!] Failed to copy /opt/redpill-load/config/_common/EFI/. to /opt/redpill-load/build/1631532886/img-mnt/part-1/EFI /bin/cp: cannot create directory '/opt/redpill-load/build/1631532886/img-mnt/part-1/EFI/./boot': File exists *** Process will exit *** Makefile:29: recipe for target 'build_redpill_load' failed make: *** [build_redpill_load] Error 1*edit* I completely deleted everything: all docker images and the redpill directory structure, starting with a fresh extract of 'redpill-tool-chain_x86_64_v0.7.2.zip'. So everything was downloaded/fetched fresh, and I'm still getting the same error.
-
1 hour ago, jumkey said:
😂sorry rebase and git push -f
can fix pull with
git fetch --all && git reset --hard origin/develop && git pull
I'm having the same issue as @scoobdriver, using @haydibe's docker build environment. My docker-fu is lacking
First I did a './redpill_tool_chain.sh clean all ', followed by './redpill_tool_chain.sh build bromolow-7.0.1-42214' which completes successfully, but './redpill_tool_chain.sh auto bromolow-7.0.1-42214' fails as per scoobdriver's report.
I did './redpill_tool_chain.sh run bromolow-7.0.1-42214' to get an interactive shell, then cd'd into '/opt/redpill-load' and ran the command above:
root@redpill-tool-chain:/opt/redpill-load# git fetch --all && git reset --hard origin/develop && git pull Fetching origin remote: Enumerating objects: 89, done. remote: Counting objects: 100% (89/89), done. remote: Compressing objects: 100% (45/45), done. remote: Total 69 (delta 31), reused 62 (delta 24), pack-reused 0 Unpacking objects: 100% (69/69), done. From https://github.com/jumkey/redpill-load + dcd6217...5b69d3f develop -> origin/develop (forced update) + 4951ed8...61c5e3d master -> origin/master (forced update) HEAD is now at 5b69d3f 7.0.1 RC Already up-to-date.
but it still fails with the same error as previously reported when running './redpill_tool_chain.sh auto bromolow-7.0.1-42214':
redpill-tool-chain_x86_64_v0.7.2 % ./redpill_tool_chain.sh auto bromolow-7.0.1-42214 remote: Enumerating objects: 325, done. remote: Counting objects: 100% (325/325), done. remote: Compressing objects: 100% (79/79), done. remote: Total 277 (delta 195), reused 276 (delta 195), pack-reused 0 Receiving objects: 100% (277/277), 111.68 KiB | 0 bytes/s, done. Resolving deltas: 100% (195/195), completed with 38 local objects. From https://github.com/RedPill-TTG/redpill-lkm 23578eb..061b3e6 master -> origin/master remote: Enumerating objects: 89, done. remote: Counting objects: 100% (89/89), done. remote: Compressing objects: 100% (45/45), done. remote: Total 69 (delta 31), reused 62 (delta 24), pack-reused 0 Unpacking objects: 100% (69/69), done. From https://github.com/jumkey/redpill-load + dcd6217...5b69d3f develop -> origin/develop (forced update) + 4951ed8...61c5e3d master -> origin/master (forced update) Checking if redpill-lkm sources require pull. Updating 23578eb..061b3e6 Fast-forward CMakeLists.txt | 19 +- Makefile | 57 ++++- common.h | 77 +++++- compat/toolkit/drivers/usb/storage/usb.h | 135 +++++++++++ config/cmdline_delegate.c | 100 ++++---- config/cmdline_delegate.h | 36 +-- config/cmdline_opts.h | 45 ++++ config/runtime_config.c | 99 +++++--- config/runtime_config.h | 13 +- debug/debug_execve.c | 38 ++- internal/call_protected.c | 13 +- internal/call_protected.h | 28 ++- internal/helper/memory_helper.c | 44 ++++ internal/helper/memory_helper.h | 37 +++ internal/helper/symbol_helper.c | 13 + internal/helper/symbol_helper.h | 15 ++ internal/intercept_driver_register.c | 27 +-- internal/intercept_execve.c | 11 +- internal/notifier_base.h | 13 + internal/override_symbol.c | 229 +++++++----------- internal/override_symbol.h | 67 +----- internal/scsi/hdparam.h | 350 +++++++++++++++++++++++++++ internal/scsi/scsi_notifier.c | 239 +++++++++++++++++++ internal/scsi/scsi_notifier.h | 29 +++ internal/scsi/scsi_notifier_list.c | 4 + internal/scsi/scsi_notifier_list.h | 27 +++ internal/scsi/scsi_toolbox.c | 245 +++++++++++++++++++ internal/scsi/scsi_toolbox.h | 100 ++++++++ internal/scsi/scsiparam.h | 24 ++ internal/stealth.c | 4 +- internal/stealth.h | 3 +- internal/stealth/sanitize_cmdline.c | 32 +-- internal/uart/uart_swapper.c | 23 +- internal/uart/virtual_uart.c | 32 +-- internal/uart/vuart_virtual_irq.c | 4 +- internal/virtual_pci.c | 18 +- redpill_main.c | 40 +++- shim/bios/bios_shims_collection.c | 90 +++---- shim/bios/bios_shims_collection.h | 6 +- shim/bios/rtc_proxy.c | 61 +++-- shim/bios/rtc_proxy.h | 3 + shim/bios_shim.c | 35 +-- shim/block_fw_update_shim.c | 16 +- shim/boot_dev/boot_shim_base.c | 70 ++++++ shim/boot_dev/boot_shim_base.h | 57 +++++ shim/boot_dev/fake_sata_boot_shim.c | 317 +++++++++++++++++++++++++ shim/boot_dev/fake_sata_boot_shim.h | 8 + shim/boot_dev/native_sata_boot_shim.c | 283 ++++++++++++++++++++++ shim/boot_dev/native_sata_boot_shim.h | 8 + shim/boot_dev/sata_boot_shim.c | 595 ---------------------------------------------- shim/boot_dev/sata_boot_shim.h | 8 - shim/boot_dev/usb_boot_shim.c | 59 +++-- shim/boot_device_shim.c | 31 ++- shim/disable_exectutables.c | 16 +- shim/disable_exectutables.h | 5 +- shim/pci_shim.c | 22 +- shim/pmu_shim.c | 42 ++-- shim/shim_base.h | 9 + shim/storage/smart_shim.c | 1056 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ shim/storage/smart_shim.h | 7 + shim/storage/virtio_storage_shim.c | 147 ++++++++++++ shim/storage/virtio_storage_shim.h | 7 + shim/uart_fixer.c | 15 +- tools/make_all.sh | 13 +- 64 files changed, 4011 insertions(+), 1265 deletions(-) create mode 100644 compat/toolkit/drivers/usb/storage/usb.h create mode 100644 config/cmdline_opts.h create mode 100644 internal/helper/memory_helper.c create mode 100644 internal/helper/memory_helper.h create mode 100644 internal/helper/symbol_helper.c create mode 100644 internal/helper/symbol_helper.h create mode 100644 internal/notifier_base.h create mode 100644 internal/scsi/hdparam.h create mode 100644 internal/scsi/scsi_notifier.c create mode 100644 internal/scsi/scsi_notifier.h create mode 100644 internal/scsi/scsi_notifier_list.c create mode 100644 internal/scsi/scsi_notifier_list.h create mode 100644 internal/scsi/scsi_toolbox.c create mode 100644 internal/scsi/scsi_toolbox.h create mode 100644 internal/scsi/scsiparam.h create mode 100644 shim/boot_dev/boot_shim_base.c create mode 100644 shim/boot_dev/boot_shim_base.h create mode 100644 shim/boot_dev/fake_sata_boot_shim.c create mode 100644 shim/boot_dev/fake_sata_boot_shim.h create mode 100644 shim/boot_dev/native_sata_boot_shim.c create mode 100644 shim/boot_dev/native_sata_boot_shim.h delete mode 100644 shim/boot_dev/sata_boot_shim.c delete mode 100644 shim/boot_dev/sata_boot_shim.h create mode 100644 shim/shim_base.h create mode 100644 shim/storage/smart_shim.c create mode 100644 shim/storage/smart_shim.h create mode 100644 shim/storage/virtio_storage_shim.c create mode 100644 shim/storage/virtio_storage_shim.h Pulled latest commits. Check if redpill-load sources require pull. *** Please tell me who you are. Run git config --global user.email "you@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: unable to auto-detect email address (got 'root@redpill-tool-chain.(none)')Do I need to be in a different directory in the docker container to run the git fetch?
-
3 minutes ago, shibby said:
if you tell me how can i do this from bare-metal i can try
You either need to be running on a server with a remote console, like an HP with iLO, Dell with DRAC, etc., or else a physical serial port with another machine connected to it to see what's being output to the console. Can you do either of those?
-
1 minute ago, shibby said:
ok, something is wrong with new driver (or maybe i something thing screw up).
I have 7.0.1 DS918+ installed. Today i compile new redpill and "burn" on new flashdrive. Everything seems to launch correct, ping to NAS working, Synology Assistant found NAS with status "ready". But when i try go to IP:5000 then NAS goes to hard reboot. Does anyone has the same issue?
I've not had that issue (not using the new image yet), but can you get the output from the serial console to see what's causing the crash?
-
8 hours ago, ThorGroup said:On 9/7/2021 at 10:46 AM, WiteWulf said:
Question: I have an HP NC360T PCIe NIC card in my system. I'm only using one interface, so have only declared one of them in my user_config.json. Is this a problem?
I notice in Control Panel in DSM that two interfaces are detected, and both have the same MAC address (the one I declared for the interface that I'm actually using). Likewise, running 'ifconfig' from the cli reports two interfaces with the same MAC address. I know that an OSI 7-layer network stack shouldn't have an issue with multiple interfaces on a system having the same MAC address (it's standard on Sun machines, for example), but will DSM complain about this?
You should define both. DSM is... hacky... in terms of ethernet interfaces. All of them should be accounted for with different MAC addresses.
Okay, I figured out why DSM was showing two adapters with the same MAC address: I was declaring/assigning the MAC addresses in the wrong order in user_config.json
I originally had:
{ "extra_cmdline": { "pid": "0x1000", "vid": "0x090c", "sn": "xxxxLWNxxxxxx", "mac1": "xxxxxxxxxx75", "mac2": "xxxxxxxxxx74" }, "synoinfo": {}, "ramdisk_copy": {} }Which manifested as "mac2=xxxxxxxxxx74 mac1=xxxxxxxxxx75" in my grub.cfg. This resulted in DSM seeing two adapters with the same MAC address of xxxxxxxxxx75
Swapping them around to:
{ "extra_cmdline": { "pid": "0x1000", "vid": "0x090c", "sn": "xxxxLWNxxxxxx", "mac1": "xxxxxxxxxx74", "mac2": "xxxxxxxxxx75" }, "synoinfo": {}, "ramdisk_copy": {} }Gives me a grub.cfg with "mac2=xxxxxxxxxx75 mac1=xxxxxxxxxx74" and two NICs with the correct, different, MAC addresses in DSM. This is obviously to do with the order in which the kernel enumerates the NIC interfaces, and the MAC addresses have to be declared in a way that matches that order or linux/DSM gets confused.
-
7 hours ago, ThorGroup said:On 9/7/2021 at 4:06 PM, WiteWulf said:
Oh, that's cool, didn't realise that! That opens up the possibility of getting a better/additional HBA to go in there at some point...
Yes, the built-in card was broken only for a short while. 6.2.3 restored the driver. We didn't test if v7 removed it again (hopefully not).
I just re-enabled the internal NIC on my Gen8 and rebooted into 7.0.1-RC1 and confirm the internal NIC is not seen, either in DSM or running 'ifconfig' from the command line. I guess that confirms the drivers are not included; others' experience suggested this earlier in the thread.
-
6 hours ago, ThorGroup said:
1 - If you dd the raw image (dd if=file.img of=/dev/rdiskX => make sure you sure rdisk and not disk) you don't need to manually modify the partition. Before you do that you should check the disk with diskutil list to get the number and unmount all existing partitions using diskutil unmount (not eject from the Finder).
2 - That smells like an ancient docker version in the DSM itself... we saw this before and they fixed the issue after like 6-7 months. It may be the case again.
1 - I'm writing with dd to /dev/rdiskX and absolutely do have to mark it as active afterwards. I've created loads of images now and every time there is no partition marked as active. This isn't a problem for most hardware, but the Gen8 (which as you've pointed out elsewhere is quite picky) *needs* to have the first partition marked as active to boot from it
2 - DSM 7.0.1-RC1 is running docker 20.10.3. This appears to be from February 2021, and only five patch levels behind current (20.10.8). To be clear: this problem only ever manifested with docker containers running influxdb, but across numerous versions of influxdb tried. Lots of Googling suggests no one else is experiencing problems like this, but I'm curious to know if anyone else here sees it.
-
What are the gains in emulating 920 over 918?
-
52 minutes ago, altas said:
only Free License for iLO
the NIC is active but no IP/DHCP Lease
I’m sure I asked you this already in DM, but:
- are you using the internal NIC or a confirmed compatible PCIe NIC? Internal NIC doesn’t have the necessary driver included in redpill
- did you edit the grub.cfg of the image to include your own SN, VID/PID and the MAC address(es) of your NIC(s)?
-
5 hours ago, altas said:
Baremetal DSM7 for a HP GEN8
i have got one from WiteWulf but it stops somewhereI'm not convinced it's "stopping". The last logs you see appear to be it configuring a serial port. This is very early on in the boot sequence, I think it may be switching console output to that new serial port, rather than the one you're looking at (the virtual one on your iLO).
Do you have an advanced license for your iLO?
Is it bringing up a NIC and DHCP'ing?
-
FWIW, I've got all four drive bays in my Gen8 populated, plus an SSD on the ODD SATA port (configured as read cache, so not included in the system or data volumes, it's RAID0 on /dev/md4) and mdadm reports the following for md0 and md1 (Raid devices = 12, clean/degraded):
bash-4.4# mdadm --detail /dev/md1 /dev/md1: Version : 0.90 Creation Time : Wed Jan 23 18:53:26 2019 Raid Level : raid1 Array Size : 2097088 (2047.94 MiB 2147.42 MB) Used Dev Size : 2097088 (2047.94 MiB 2147.42 MB) Raid Devices : 12 Total Devices : 4 Preferred Minor : 1 Persistence : Superblock is persistent Update Time : Thu Sep 9 12:23:55 2021 State : clean, degraded Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0...and this for md2 and md3:
bash-4.4# mdadm --detail /dev/md2 /dev/md2: Version : 1.2 Creation Time : Sat Apr 4 16:26:16 2015 Raid Level : raid5 Array Size : 5846338944 (5575.50 GiB 5986.65 GB) Used Dev Size : 1948779648 (1858.50 GiB 1995.55 GB) Raid Devices : 4 Total Devices : 4 Persistence : Superblock is persistent Update Time : Fri Sep 10 08:42:38 2021 State : clean Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0
Is it "normal" for the system partition to be in a degraded state (never looked at this before when I was on Jun's bootloader or xpenoboot, or is this something that needs to be fixed with the maxdisks parameter? A real DS3615XS has 12 drive bays, obviously, so that would be why it's expecting to find up to 12 devices...
-
4 minutes ago, ct85msi said:
yes. I know...but I can`t find where to insert the parameters on the mounted image. I generated a new image with those synoinfo parameters inserted but grub.cfg hasn`t changed.
As per jhoughton’s post, synoinfo parameters are patched into the running system, whereas extra_cmdline parameters are added to grub.cfg
synoinfo doesn’t change grub, they’re two separate parts of the redpill process.
-
2 hours ago, MastaG said:
other then that I noticed that 7.0-41222 is actually a beta firmware for the ds3615xs and it's pretty outdated.
I see there were newer builds, even a RC, but they didnt release it for this specific model?
Yeah, that's why I skipped 7.0 for my Gen8 and went straight to the RC for 7.0.1. Other than the kernel panics with my influxdb docker container it's been very stable and fast.
-
Well, I've set up a new influxdb container (2.0.8), migrated the 1.7.7 data to it and it's not crashed so far! Just got to get Grafana talking to it again now. I'm not going to update this thread any more as I don't think it's relevant to xpenology from this point.
*edit*
Spoiler alert: it kernel panic'd again 🙄
I give up...
*edit2*
I forgot to mention that I also upgraded the DSM to 7.0.1-RC1 redpill while I was working on this, and it obviously didn't fix the problem.
-
4 hours ago, Franks4fingers said:
The final thing I have done with this is to mark the first partition on the USB key as active as I read others had done something similar and it resolved whatever the issue was that they were having.....didn't make a difference for me so far.
That was only for people who's hardware (notably HP Gen8 Microserver) wouldn't boot off the USB stick.
-
I've definitely tied this down to the influxdb container. Everything else runs quite happily now when set to auto-start on boot. Guess I need to do the database migration properly and see how that turns out.
-
1 hour ago, abesus said:
My my fault. I was trying to set conservative same as @WiteWulf but my system is not supporting such parameter - powersave works ok.
Thanks for all
Since migrating my system to 7.0.1-RC1 today I've found that conservative also no longer works. I think it's a change in the kernel or drivers.
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
The above command will show you what frequency scaling governors are available. On my system (Xeon E3-1265L V2 on a bromolow ds3615xs image), I only have the following options available:powersave performance userspaceAnd this will show you what governor is currently in use:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governorHave a poke around in /sys/devices/system/cpu/cpu0/cpufreq/, there's all sorts of useful info in there.
On my system, 'powersave' seems to lock the core at 1600MHz, 'performance' at 2500MHz and 'userspace' allows processes to set the frequency manually. There do not appear to be governors that dynamically scale CPU frequency with load. In the past these included 'on demand' and 'conservative'.
RedPill - the new loader for 6.2.4 - Discussion
in Developer Discussion Room
Posted
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