ideasman69

Hi guys, Just curious if the kernel, bootloader etc output that I see out of COM1 during boot is recorded to a file somewhere? I've had a couple of unexpected shutdowns of my synology VM and trying to track down what might be causing it. Cheers

From both a performance and reliability standpoint. I'd always opt for both over having a disk appear as disk 1 instead of disk 2 or 3 - but that's just me. performance/reliability vs appearance 🤷‍♂️

Thanks for all your testing and results @flyride. From previous experience with proxmox, I'm going to stick with the q35 option and just deal with the drive numbering offset. q35 should be picked when passing through PCIe devices, but each to their own of course

...but it doesn't with the SAS controller. i've got an identical setup in my homelab. proxmox VM but instead of passing through an 8 port HBA, i'm passing through 2 x standard AHCI controllers. The satamap options do work on that.

you can't get rid of them though. If i switch to the USB loader, it gets rid of one of them - but the first one always remains. @phone guy is using the virtual USB loader and his disks start at disk 2. because I'm using the loader via a SATA port, my disks start at disk 3. i prefer this method as the bootloader image gets backed up along with the VM.

I'd love to, but like @phone guy says - it doesn't seem to work on proxmox. When i run rploader satamap, it finds the three controllers: - intel sata (no disks attached) - intel sata (redpill image attached) - sas hba (8 disks attached) I set the two intel controllers to 1 disk each which generates this: "SataPortMap": "118", "DiskIdxMap": "000102" In the past i'd use this to map the sas controller to start at 00, the second intel controller to start at disk 9 and the first controller to start at disk 10: "SataPortMap": "118", "DiskIdxMap": "090800" But the sas controller seems to totally ignore this mapping

Ah ok. I’m currently using the 3622 build which seems to support the expansion. Although adding the sasidxmap setting to the user_config makes no difference. My sas connected disks start at disk 3 as I’m using the bootloader in SATA0 (rather than the virtual usb stick). KVM/proxmox makes one sata controller when there are no disks and then another for when there are disks. I’ve just set my satamap to 11 as trying to set the unused controller to 0 causes a panic.

i came to post the same question but it looks like you guys are all over it! I've been playing around with it for hours without any luck. Should the SasIdxMap=0 option still work in redpill? This old post by @jun says:

awesome, thanks mate ill give this a shot! Will you add that to your proxmox guide?? also - why does everyone seem to go down the virtual usb route with proxmox? I've found the following very easy: - upload any of the images from the github (bios img, uefi img or vmdk) and upload to local -> iso images - run qm importdisk {vmid} /var/lib/vz/template/iso/tinycore-redpill-uefi.v0.4.6.img local-lvm via shell - assign it to SATA0 in the VM hardware settings Does the virtual USB method have any advantages over using the bootloader in the virtual SATA controller?

would this be a better package to use for virtio? https://github.com/pocopico/redpill-load/raw/develop/redpill-virtio/rpext-index.json Then again, looking through the v9fs files, it does mention the same modules and more: "kmods": { "virtio.ko": "", "virtio_ring.ko": "", "virtio_mmio.ko": "", "virtio_pci.ko": "", "virtio_blk.ko": "", "virtio_net.ko": "", "virtio_scsi.ko": "", "9pnet.ko": "", "9pnet_virtio.ko": "", "9p.ko": "" },

oh cool, thanks. i dont know if the acpid module is working for me as my proxmox "shutdown" button doesnt do anything

Can anyone explain why most of the guide I see have 2 seperate build commands? Like this one quoted above... a build command for 7.0.1 and then another for 7.1.0? Is there any reason why we couldn't just do the following? ./rploader.sh update now ./rploader.sh fullupgrade now ./rploader.sh serialgen DS3622xs+ ./rploader.sh identifyusb now ./rploader.sh satamap now ./rploader.sh ext broadwellnk-7.1.0-42661 add https://github.com/pocopico/redpill-load/raw/develop/redpill-virtio/rpext-index.json ./rploader.sh ext broadwellnk-7.1.0-42661 add https://github.com/pocopico/redpill-load/raw/develop/redpill-acpid/rpext-index.json ./rploader.sh backup now ./rploader.sh build broadwellnk-7.1.0-42661

thanks mate. I used his guide which produced a VM identical to mine... it ended up being my satamap. I had it 0 for the VM's sata controller that had no drives attached. once I set it to 6, it booted 😕 i spent hours on that!

the time/date isn't set in your tinycore instance

Hi guys, I'm having NO luck with redpill on proxmox. I've tried a number of methods: - qm importdisk the vmdk and assigning it to SATA0 - both the bios and uefi IMG files as virtual usb devices like in this post - with and without the virtio modules - different versions and models (ie 918+, DS3622xs+, 7.0.1, 7.1 etc) The TinyCore Image Builder loads up fine. I can go through the update/generate process. Once I reboot out of TinyCore and attempt to load the appropriate RedPill option from the boot menu - it always panics in the exact same spot when loading ahci: [ 2.117175] ahci 0000:00:1f.2: version 3.0 [ 2.118230] ahci 0000:00:1f.2: AHCI 0001.0000 32 slots 6 ports 1.5 Gbps 0x3f impl SATA mode [ 2.119318] ahci 0000:00:1f.2: flags: 64bit ncq only [ 2.119953] BUG: unable to handle kernel NULL pointer dereference at 0000000000000120 [ 2.120301] IP: [<ffffffff813ffefe>] ata_host_start.part.37+0x18e/0x1b0 [ 2.121399] PGD 0 [ 2.121399] Oops: 0000 [#1] SMP [ 2.121399] Modules linked in: redpill(OE) [ 2.121399] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G OE 4.4.180+ #42661 [ 2.121399] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 2.125182] task: ffff88007b108000 ti: ffff88007b110000 task.ti: ffff88007b110000 [ 2.125182] RIP: 0010:[<ffffffff813ffefe>] [<ffffffff813ffefe>] ata_host_start.part.37+0x18e/0x1b0 [ 2.125182] RSP: 0018:ffff88007b113be8 EFLAGS: 00010246 [ 2.125182] RAX: 0000000000000000 RBX: ffff8800351d23d8 RCX: 0000000000000080 [ 2.125182] RDX: 0000000000000000 RSI: 000000000000001c RDI: 0000000000000000 [ 2.125182] RBP: ffff88007b113c10 R08: ffffffff818a9c60 R09: 0000000000000040 [ 2.125182] R10: 00000000000000fa R11: ffffffff81a056ad R12: ffff8800351d23d8 [ 2.131324] R13: 000000000000001c R14: ffffffff81428cf0 R15: ffffffff818a9c60 [ 2.131324] FS: 0000000000000000(0000) GS:ffff88007dd00000(0000) knlGS:0000000000000000 [ 2.131324] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2.131324] CR2: 0000000000000120 CR3: 00000000357c0000 CR4: 00000000001606f0 [ 2.131324] Stack: [ 2.131324] ffff8800351d23d8 ffff8800351d23d8 000000000000001c ffffffff81428cf0 [ 2.131324] ffffffff818a9c60 ffff88007b113c58 ffffffff81406176 0000000000000202 [ 2.131324] 0000000000000080 ffff8800351d23d8 ffff8800351d23d8 000000000000001c [ 2.131324] Call Trace: [ 2.131324] [<ffffffff81428cf0>] ? ahci_handle_port_intr+0x90/0x90 [ 2.131324] [<ffffffff81406176>] ata_host_activate+0xb6/0x110 [ 2.131324] [<ffffffff81428dfd>] ahci_host_activate+0x4d/0x180 [ 2.131324] [<ffffffff81313a5a>] ? pcibios_set_master+0x5a/0x80 [ 2.131324] [<ffffffff81425ef9>] ahci_init_one+0x9a9/0xdf0 [ 2.131324] [<ffffffff81315d50>] pci_device_probe+0x90/0x100 [ 2.131324] [<ffffffff8139d50a>] driver_probe_device+0xba/0x260 [ 2.131324] [<ffffffff8139d729>] __driver_attach+0x79/0x80 [ 2.131324] [<ffffffff8139d6b0>] ? driver_probe_device+0x260/0x260 [ 2.131324] [<ffffffff8139b7e9>] bus_for_each_dev+0x69/0xa0 [ 2.131324] [<ffffffff8139cf59>] driver_attach+0x19/0x20 [ 2.131324] [<ffffffff8139cbac>] bus_add_driver+0x19c/0x1e0 [ 2.131324] [<ffffffff81932b91>] ? ata_sff_init+0x31/0x31 [ 2.131324] [<ffffffff8139decb>] driver_register+0x6b/0xc0 [ 2.131324] [<ffffffff813147f1>] __pci_register_driver+0x41/0x50 [ 2.131324] [<ffffffff81932baa>] ahci_pci_driver_init+0x19/0x1b [ 2.131324] [<ffffffff81000340>] do_one_initcall+0x80/0x130 [ 2.131324] [<ffffffff818f56e7>] ? do_early_param+0x90/0x90 [ 2.131324] [<ffffffff818f5faf>] kernel_init_freeable+0x14d/0x1de [ 2.131324] [<ffffffff8155e50d>] ? rest_init+0x74/0x74 [ 2.131324] [<ffffffff8155e516>] kernel_init+0x9/0xd3 [ 2.131324] [<ffffffff81563baf>] ret_from_fork+0x3f/0x80 [ 2.131324] [<ffffffff8155e50d>] ? rest_init+0x74/0x74 [ 2.131324] Code: 39 80 16 00 48 83 eb 08 41 83 ec 01 45 85 e4 79 db 4c 89 f7 e8 c4 10 fa ff 44 89 f8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 8b 43 28 <48> 83 b8 20 01 00 00 00 0f 85 f4 fe ff ff e9 67 ff ff ff 41 bf [ 2.131324] RIP [<ffffffff813ffefe>] ata_host_start.part.37+0x18e/0x1b0 [ 2.131324] RSP <ffff88007b113be8> [ 2.131324] CR2: 0000000000000120 [ 2.131324] ---[ end trace b4d1009b2d916780 ]--- [ 2.160499] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 [ 2.160499] [ 2.161484] Kernel Offset: disabled [ 2.161484] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 [ 2.161484] I believe the ahci controller at 0000:00:1f.2 is the default KVM sata controller which doesn't have an option to remove. I've tried attaching the loader to SATA0. Tried passing through 2 different types of physical AHCI controllers but it always panics here. I had no troubles going through the process on ESXi on this exact same hardware, as well as baremetal on this same hardware. Does anyone have any ideas what I might be missing?