Re: PCIe NVME drives not detected on Dell R6515
Scott Long wrote on 04/17/2020 17:38: Can you send me the output of ‘pciconf -llv’, either in 12-STABLE or 13-CURRENT? Also, can you send me the output of ‘dmesg’? I have only iDRAC access to this machine, I cannot copy or export text. Can I send you printscreen images? Thank you! Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
Can you send me the output of ‘pciconf -llv’, either in 12-STABLE or 13-CURRENT? Also, can you send me the output of ‘dmesg’? Thanks, Scott > On Apr 17, 2020, at 5:23 AM, Miroslav Lachman <000.f...@quip.cz> wrote: > > I already asked on stable@ but as I tried it on 13-CURRENT with the same > result I am trying to ask for help here. > > I have rented dedicated server Dell PowerEdge R6515 with iDRAC access only. > There are 2 NVME drives which I wanted to use as ZFS root pool. > > They are shown in iDRAC > > Device Description: PCIe SSD in Slot 1 in Bay 1 > Device Protocol: NVMe-MI1.0 > Model:Dell Express Flash NVMe P4510 1TB SFF > Bus: 130 > Manufacturer: INTEL > Product ID: a54 > Revision: VDV1DP23 > Enclosure:PCIe SSD Backplane 1 > > > pciconf -l show many things, some of them are named "noneN@pci..." but none > "nvme" > > The is printscreen (12.1 but 13-CURRENT is the same) > > https://ibb.co/tPnymL7 > > But I booted Linux SystemRescueCd and nvme devices are there visible in /dev/ > https://ibb.co/sj22Nwg > > There is verbose output of Linux lspci https://ibb.co/dPZTwV1 > > Linux dmesg contains: > nvme nvme0: pci function :81:00.0 > nvme nvme1: pci function :82:00.0 > nvme nvme0: 32/0/0 default/read/poll queues > nvme nvme1: 32/0/0 default/read/poll queues > > > The machine is Dell PowerEdge R6515 with AMD EPYC 7302P > > > More details extracted from iDRAC web interface > > I found this informations > > PCIe SSD in Slot 1 in Bay 1 > Bus: 82 > BusProtocol: PCIE > Device: 0 > DeviceDescription: PCIe SSD in Slot 1 in Bay 1 > DeviceProtocol: NVMe-MI1.0 > DeviceType: PCIeSSD > DriveFormFactor: 2.5 inch > FailurePredicted: NO > FQDD: Disk.Bay.1:Enclosure.Internal.0-1 > FreeSizeInBytes: Information Not Available > Function: 0 > HotSpareStatus: Information Not Available > InstanceID: Disk.Bay.1:Enclosure.Internal.0-1 > Manufacturer: INTEL > MaximumCapableSpeed: 8 GT/s > MediaType: Solid State Drive > Model: Dell Express Flash NVMe P4510 1TB SFF > NegotiatedSpeed: 8 GT/s > PCIeCapableLinkWidth: x4 > PCIeNegotiatedLinkWidth: x4 > PrimaryStatus: Ok > ProductID: a54 > RaidStatus: Information Not Available > RAIDType: Unknown > RemainingRatedWriteEndurance: 100 % > Revision: VDV1DP23 > SerialNumber: PHLJxxWF1PN > SizeInBytes: 1000204886016 > Slot: 1 > State: Ready > SystemEraseCapability: CryptographicErasePD > > PCIe SSD in Slot 1 in Bay 1 - PCI Device > BusNumber: 130 > DataBusWidth: 4x or x4 > Description: Express Flash NVMe 1.0 TB 2.5" U.2 (P4510) > DeviceDescription: PCIe SSD in Slot 1 in Bay 1 > DeviceNumber: 0 > DeviceType: PCIDevice > FQDD: Disk.Bay.1:Enclosure.Internal.0-1 > FunctionNumber: 0 > InstanceID: Disk.Bay.1:Enclosure.Internal.0-1 > LastSystemInventoryTime: 2020-04-17T03:21:39 > LastUpdateTime: 2020-03-31T13:55:06 > Manufacturer: Intel Corporation > PCIDeviceID: 0A54 > PCISubDeviceID: 2003 > PCISubVendorID: 1028 > PCIVendorID: 8086 > SlotLength: 2.5 Inch Drive Form Factor > SlotType: PCI Express Gen 3 SFF-8639 > > > Can anybody shed some light what the real problem is? > > Is the hardware not properly detected or is the driver completely missing? > > NVME PCIe architecture is out of my knowledge. > > I really appreciate any help. > > Kind regards > Miroslav Lachman > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
Would that be the Intel VMD/VROC stuff? If so, there’s a driver for FreeBSD, but it’s not well tested yet. Will have to dig in further. Scott > On Apr 17, 2020, at 9:50 AM, Warner Losh wrote: > > > > On Fri, Apr 17, 2020 at 9:39 AM Scott Long wrote: > Can you send me the output of ‘pciconf -llv’, either in 12-STABLE or > 13-CURRENT? Also, can you send me the output of ‘dmesg’? > > There was another thread that said there was a raid card in the way... It > would be cool to find a way to get it out of the way... :) > > Warner > > Thanks, > Scott > > > > On Apr 17, 2020, at 5:23 AM, Miroslav Lachman <000.f...@quip.cz> wrote: > > > > I already asked on stable@ but as I tried it on 13-CURRENT with the same > > result I am trying to ask for help here. > > > > I have rented dedicated server Dell PowerEdge R6515 with iDRAC access only. > > There are 2 NVME drives which I wanted to use as ZFS root pool. > > > > They are shown in iDRAC > > > > Device Description: PCIe SSD in Slot 1 in Bay 1 > > Device Protocol: NVMe-MI1.0 > > Model:Dell Express Flash NVMe P4510 1TB SFF > > Bus: 130 > > Manufacturer: INTEL > > Product ID: a54 > > Revision: VDV1DP23 > > Enclosure:PCIe SSD Backplane 1 > > > > > > pciconf -l show many things, some of them are named "noneN@pci..." but none > > "nvme" > > > > The is printscreen (12.1 but 13-CURRENT is the same) > > > > https://ibb.co/tPnymL7 > > > > But I booted Linux SystemRescueCd and nvme devices are there visible in > > /dev/ > > https://ibb.co/sj22Nwg > > > > There is verbose output of Linux lspci https://ibb.co/dPZTwV1 > > > > Linux dmesg contains: > > nvme nvme0: pci function :81:00.0 > > nvme nvme1: pci function :82:00.0 > > nvme nvme0: 32/0/0 default/read/poll queues > > nvme nvme1: 32/0/0 default/read/poll queues > > > > > > The machine is Dell PowerEdge R6515 with AMD EPYC 7302P > > > > > > More details extracted from iDRAC web interface > > > > I found this informations > > > > PCIe SSD in Slot 1 in Bay 1 > > Bus: 82 > > BusProtocol: PCIE > > Device: 0 > > DeviceDescription: PCIe SSD in Slot 1 in Bay 1 > > DeviceProtocol: NVMe-MI1.0 > > DeviceType: PCIeSSD > > DriveFormFactor: 2.5 inch > > FailurePredicted: NO > > FQDD: Disk.Bay.1:Enclosure.Internal.0-1 > > FreeSizeInBytes: Information Not Available > > Function: 0 > > HotSpareStatus: Information Not Available > > InstanceID: Disk.Bay.1:Enclosure.Internal.0-1 > > Manufacturer: INTEL > > MaximumCapableSpeed: 8 GT/s > > MediaType: Solid State Drive > > Model: Dell Express Flash NVMe P4510 1TB SFF > > NegotiatedSpeed: 8 GT/s > > PCIeCapableLinkWidth: x4 > > PCIeNegotiatedLinkWidth: x4 > > PrimaryStatus: Ok > > ProductID: a54 > > RaidStatus: Information Not Available > > RAIDType: Unknown > > RemainingRatedWriteEndurance: 100 % > > Revision: VDV1DP23 > > SerialNumber: PHLJxxWF1PN > > SizeInBytes: 1000204886016 > > Slot: 1 > > State: Ready > > SystemEraseCapability: CryptographicErasePD > > > > PCIe SSD in Slot 1 in Bay 1 - PCI Device > > BusNumber: 130 > > DataBusWidth: 4x or x4 > > Description: Express Flash NVMe 1.0 TB 2.5" U.2 (P4510) > > DeviceDescription: PCIe SSD in Slot 1 in Bay 1 > > DeviceNumber: 0 > > DeviceType: PCIDevice > > FQDD: Disk.Bay.1:Enclosure.Internal.0-1 > > FunctionNumber: 0 > > InstanceID: Disk.Bay.1:Enclosure.Internal.0-1 > > LastSystemInventoryTime: 2020-04-17T03:21:39 > > LastUpdateTime: 2020-03-31T13:55:06 > > Manufacturer: Intel Corporation > > PCIDeviceID: 0A54 > > PCISubDeviceID: 2003 > > PCISubVendorID: 1028 > > PCIVendorID: 8086 > > SlotLength: 2.5 Inch Drive Form Factor > > SlotType: PCI Express Gen 3 SFF-8639 > > > > > > Can anybody shed some light what the real problem is? > > > > Is the hardware not properly detected or is the driver completely missing? > > > > NVME PCIe architecture is out of my knowledge. > > > > I really appreciate any help. > > > > Kind regards > > Miroslav Lachman > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
Warner Losh wrote on 04/17/2020 18:15: No. It was some kind of extra card (Perteq?) managing things in a Dell server. It may be the VMD/VROC stuff, and that driver may be worth a shot, but I'm thinking not. It looks like Doug's code for that is in the tree, though https://reviews.freebsd.org/rS353380. Or are other changes needed? I've been blessed with either being able to turn this off, or not having to deal... vmd is in the kernel of 13-CURRENT installer I tried but I don't see any vmd device. Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
You are correct about Intel vs AMD. Comparing the full output of pciconf from FreeBSD with the fragment of lspci from Linux suggests that there’s at least one set of a PCIe switch and child devices that is not being enumerated by FreeBSD. Can you send the full output of `lspci -tvv` from linux? Thanks, Scott > On Apr 17, 2020, at 9:54 AM, Scott Long wrote: > > Would that be the Intel VMD/VROC stuff? If so, there’s a driver for FreeBSD, > but it’s not well tested yet. Will have to dig in further. > > Scott > > >> On Apr 17, 2020, at 9:50 AM, Warner Losh wrote: >> >> >> >> On Fri, Apr 17, 2020 at 9:39 AM Scott Long wrote: >> Can you send me the output of ‘pciconf -llv’, either in 12-STABLE or >> 13-CURRENT? Also, can you send me the output of ‘dmesg’? >> >> There was another thread that said there was a raid card in the way... It >> would be cool to find a way to get it out of the way... :) >> >> Warner >> >> Thanks, >> Scott >> >> >>> On Apr 17, 2020, at 5:23 AM, Miroslav Lachman <000.f...@quip.cz> wrote: >>> >>> I already asked on stable@ but as I tried it on 13-CURRENT with the same >>> result I am trying to ask for help here. >>> >>> I have rented dedicated server Dell PowerEdge R6515 with iDRAC access only. >>> There are 2 NVME drives which I wanted to use as ZFS root pool. >>> >>> They are shown in iDRAC >>> >>> Device Description: PCIe SSD in Slot 1 in Bay 1 >>> Device Protocol: NVMe-MI1.0 >>> Model:Dell Express Flash NVMe P4510 1TB SFF >>> Bus: 130 >>> Manufacturer: INTEL >>> Product ID: a54 >>> Revision: VDV1DP23 >>> Enclosure:PCIe SSD Backplane 1 >>> >>> >>> pciconf -l show many things, some of them are named "noneN@pci..." but none >>> "nvme" >>> >>> The is printscreen (12.1 but 13-CURRENT is the same) >>> >>> https://ibb.co/tPnymL7 >>> >>> But I booted Linux SystemRescueCd and nvme devices are there visible in >>> /dev/ >>> https://ibb.co/sj22Nwg >>> >>> There is verbose output of Linux lspci https://ibb.co/dPZTwV1 >>> >>> Linux dmesg contains: >>> nvme nvme0: pci function :81:00.0 >>> nvme nvme1: pci function :82:00.0 >>> nvme nvme0: 32/0/0 default/read/poll queues >>> nvme nvme1: 32/0/0 default/read/poll queues >>> >>> >>> The machine is Dell PowerEdge R6515 with AMD EPYC 7302P >>> >>> >>> More details extracted from iDRAC web interface >>> >>> I found this informations >>> >>> PCIe SSD in Slot 1 in Bay 1 >>> Bus: 82 >>> BusProtocol: PCIE >>> Device: 0 >>> DeviceDescription: PCIe SSD in Slot 1 in Bay 1 >>> DeviceProtocol: NVMe-MI1.0 >>> DeviceType: PCIeSSD >>> DriveFormFactor: 2.5 inch >>> FailurePredicted: NO >>> FQDD: Disk.Bay.1:Enclosure.Internal.0-1 >>> FreeSizeInBytes: Information Not Available >>> Function: 0 >>> HotSpareStatus: Information Not Available >>> InstanceID: Disk.Bay.1:Enclosure.Internal.0-1 >>> Manufacturer: INTEL >>> MaximumCapableSpeed: 8 GT/s >>> MediaType: Solid State Drive >>> Model: Dell Express Flash NVMe P4510 1TB SFF >>> NegotiatedSpeed: 8 GT/s >>> PCIeCapableLinkWidth: x4 >>> PCIeNegotiatedLinkWidth: x4 >>> PrimaryStatus: Ok >>> ProductID: a54 >>> RaidStatus: Information Not Available >>> RAIDType: Unknown >>> RemainingRatedWriteEndurance: 100 % >>> Revision: VDV1DP23 >>> SerialNumber: PHLJxxWF1PN >>> SizeInBytes: 1000204886016 >>> Slot: 1 >>> State: Ready >>> SystemEraseCapability: CryptographicErasePD >>> >>> PCIe SSD in Slot 1 in Bay 1 - PCI Device >>> BusNumber: 130 >>> DataBusWidth: 4x or x4 >>> Description: Express Flash NVMe 1.0 TB 2.5" U.2 (P4510) >>> DeviceDescription: PCIe SSD in Slot 1 in Bay 1 >>> DeviceNumber: 0 >>> DeviceType: PCIDevice >>> FQDD: Disk.Bay.1:Enclosure.Internal.0-1 >>> FunctionNumber: 0 >>> InstanceID: Disk.Bay.1:Enclosure.Internal.0-1 >>> LastSystemInventoryTime: 2020-04-17T03:21:39 >>> LastUpdateTime: 2020-03-31T13:55:06 >>> Manufacturer: Intel Corporation >>> PCIDeviceID: 0A54 >>> PCISubDeviceID: 2003 >>> PCISubVendorID: 1028 >>> PCIVendorID: 8086 >>> SlotLength: 2.5 Inch Drive Form Factor >>> SlotType: PCI Express Gen 3 SFF-8639 >>> >>> >>> Can anybody shed some light what the real problem is? >>> >>> Is the hardware not properly detected or is the driver completely missing? >>> >>> NVME PCIe architecture is out of my knowledge. >>> >>> I really appreciate any help. >>> >>> Kind regards >>> Miroslav Lachman >>> ___ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >> >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > ___ >
Re: PCIe NVME drives not detected on Dell R6515
On Fri, Apr 17, 2020 at 05:40:55PM +0200, Miroslav Lachman wrote: > Scott Long wrote on 04/17/2020 17:38: > > Can you send me the output of ???pciconf -llv???, either in 12-STABLE or > > 13-CURRENT? Also, can you send me the output of ???dmesg > > I have only iDRAC access to this machine, I cannot copy or export text. Can > I send you printscreen images? You used to be able to ssh to the iDRAC IP and there was a magic command that let you get to the serial console via SSH. I don't have access to Dell hardware any more to dig out the magic command, sorry Regards, Gary ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
On Fri, Apr 17, 2020 at 9:39 AM Scott Long wrote: > Can you send me the output of ‘pciconf -llv’, either in 12-STABLE or > 13-CURRENT? Also, can you send me the output of ‘dmesg’? > There was another thread that said there was a raid card in the way... It would be cool to find a way to get it out of the way... :) Warner > Thanks, > Scott > > > > On Apr 17, 2020, at 5:23 AM, Miroslav Lachman <000.f...@quip.cz> wrote: > > > > I already asked on stable@ but as I tried it on 13-CURRENT with the > same result I am trying to ask for help here. > > > > I have rented dedicated server Dell PowerEdge R6515 with iDRAC access > only. > > There are 2 NVME drives which I wanted to use as ZFS root pool. > > > > They are shown in iDRAC > > > > Device Description: PCIe SSD in Slot 1 in Bay 1 > > Device Protocol: NVMe-MI1.0 > > Model:Dell Express Flash NVMe P4510 1TB SFF > > Bus: 130 > > Manufacturer: INTEL > > Product ID: a54 > > Revision: VDV1DP23 > > Enclosure:PCIe SSD Backplane 1 > > > > > > pciconf -l show many things, some of them are named "noneN@pci..." but > none "nvme" > > > > The is printscreen (12.1 but 13-CURRENT is the same) > > > > https://ibb.co/tPnymL7 > > > > But I booted Linux SystemRescueCd and nvme devices are there visible in > /dev/ > > https://ibb.co/sj22Nwg > > > > There is verbose output of Linux lspci https://ibb.co/dPZTwV1 > > > > Linux dmesg contains: > > nvme nvme0: pci function :81:00.0 > > nvme nvme1: pci function :82:00.0 > > nvme nvme0: 32/0/0 default/read/poll queues > > nvme nvme1: 32/0/0 default/read/poll queues > > > > > > The machine is Dell PowerEdge R6515 with AMD EPYC 7302P > > > > > > More details extracted from iDRAC web interface > > > > I found this informations > > > > PCIe SSD in Slot 1 in Bay 1 > > Bus: 82 > > BusProtocol: PCIE > > Device: 0 > > DeviceDescription: PCIe SSD in Slot 1 in Bay 1 > > DeviceProtocol: NVMe-MI1.0 > > DeviceType: PCIeSSD > > DriveFormFactor: 2.5 inch > > FailurePredicted: NO > > FQDD: Disk.Bay.1:Enclosure.Internal.0-1 > > FreeSizeInBytes: Information Not Available > > Function: 0 > > HotSpareStatus: Information Not Available > > InstanceID: Disk.Bay.1:Enclosure.Internal.0-1 > > Manufacturer: INTEL > > MaximumCapableSpeed: 8 GT/s > > MediaType: Solid State Drive > > Model: Dell Express Flash NVMe P4510 1TB SFF > > NegotiatedSpeed: 8 GT/s > > PCIeCapableLinkWidth: x4 > > PCIeNegotiatedLinkWidth: x4 > > PrimaryStatus: Ok > > ProductID: a54 > > RaidStatus: Information Not Available > > RAIDType: Unknown > > RemainingRatedWriteEndurance: 100 % > > Revision: VDV1DP23 > > SerialNumber: PHLJxxWF1PN > > SizeInBytes: 1000204886016 > > Slot: 1 > > State: Ready > > SystemEraseCapability: CryptographicErasePD > > > > PCIe SSD in Slot 1 in Bay 1 - PCI Device > > BusNumber: 130 > > DataBusWidth: 4x or x4 > > Description: Express Flash NVMe 1.0 TB 2.5" U.2 (P4510) > > DeviceDescription: PCIe SSD in Slot 1 in Bay 1 > > DeviceNumber: 0 > > DeviceType: PCIDevice > > FQDD: Disk.Bay.1:Enclosure.Internal.0-1 > > FunctionNumber: 0 > > InstanceID: Disk.Bay.1:Enclosure.Internal.0-1 > > LastSystemInventoryTime: 2020-04-17T03:21:39 > > LastUpdateTime: 2020-03-31T13:55:06 > > Manufacturer: Intel Corporation > > PCIDeviceID: 0A54 > > PCISubDeviceID: 2003 > > PCISubVendorID: 1028 > > PCIVendorID: 8086 > > SlotLength: 2.5 Inch Drive Form Factor > > SlotType: PCI Express Gen 3 SFF-8639 > > > > > > Can anybody shed some light what the real problem is? > > > > Is the hardware not properly detected or is the driver completely > missing? > > > > NVME PCIe architecture is out of my knowledge. > > > > I really appreciate any help. > > > > Kind regards > > Miroslav Lachman > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
OpenZFS port updated
FreeBSD support has been merged into the master branch of the openzfs/zfs
repository, and the FreeBSD ports have been switched to this branch.
OpenZFS brings many exciting features to FreeBSD, including:
* native encryption
* improved TRIM implementation
* most recently, persistent L2ARC
Of course, avoid upgrading your pools if you want to keep the option to go back
to the base ZFS.
OpenZFS can be installed alongside the base ZFS. Change your loader.conf entry
to openzfs_load=“YES” to load the OpenZFS module at boot, and set PATH to find
the tools in /usr/local/sbin before /sbin. The base zfs tools are still
basically functional with the OpenZFS module, so changing PATH in rc is not
strictly necessary.
The FreeBSD loader can boot from pools with the encryption feature enabled, but
the root/bootenv datasets must not be encrypted themselves.
The FreeBSD platform support in OpenZFS does not yet include all features
present in FreeBSD’s ZFS. Some notable changes/missing features include:
* many sysctl names have changed (legacy compat sysctls should be added at
some point)
* zfs send progress reporting in process title via setproctitle
* extended 'zfs holds -r'
(https://svnweb.freebsd.org/base?view=revision=290015)
* vdev ashift optimizations
(https://svnweb.freebsd.org/base?view=revision=254591)
* pre-mountroot zpool.cache loading (for automatic pool imports)
To the last point, this mainly effects the case where / is on ZFS and /boot is
not or is on a different pool. OpenZFS cannot handle this case yet, but work is
in progress to cover that use case. Booting directly from ZFS does work.
If there are pools that need to be imported at boot other than the boot pool,
OpenZFS does not automatically import yet, and it uses /etc/zfs/zpool.cache
rather than /boot/zfs/zpool.cache to keep track of imported pools. To ensure
all pool imports occur automatically, a simple edit to /etc/rc.d/zfs will
suffice:
diff --git a/libexec/rc/rc.d/zfs b/libexec/rc/rc.d/zfs
index 2d35f9b5464..8e4aef0b1b3 100755
--- a/libexec/rc/rc.d/zfs
+++ b/libexec/rc/rc.d/zfs
@@ -25,6 +25,13 @@ zfs_start_jail()
zfs_start_main()
{
+ local cachefile
+
+ for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do
+ if [ -f $cachefile ]; then
+ zpool import -c $cachefile -a
+ fi
+ done
zfs mount -va
zfs share -a
if [ ! -r /etc/zfs/exports ]; then
This will probably not be needed long-term. It is not necessary if the boot
pool is the only pool.
Happy testing :)
- Ryan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
No. It was some kind of extra card (Perteq?) managing things in a Dell server. It may be the VMD/VROC stuff, and that driver may be worth a shot, but I'm thinking not. It looks like Doug's code for that is in the tree, though https://reviews.freebsd.org/rS353380. Or are other changes needed? I've been blessed with either being able to turn this off, or not having to deal... Warner On Fri, Apr 17, 2020 at 9:54 AM Scott Long wrote: > Would that be the Intel VMD/VROC stuff? If so, there’s a driver for > FreeBSD, but it’s not well tested yet. Will have to dig in further. > > Scott > > > > On Apr 17, 2020, at 9:50 AM, Warner Losh wrote: > > > > > > > > On Fri, Apr 17, 2020 at 9:39 AM Scott Long wrote: > > Can you send me the output of ‘pciconf -llv’, either in 12-STABLE or > 13-CURRENT? Also, can you send me the output of ‘dmesg’? > > > > There was another thread that said there was a raid card in the way... > It would be cool to find a way to get it out of the way... :) > > > > Warner > > > > Thanks, > > Scott > > > > > > > On Apr 17, 2020, at 5:23 AM, Miroslav Lachman <000.f...@quip.cz> > wrote: > > > > > > I already asked on stable@ but as I tried it on 13-CURRENT with the > same result I am trying to ask for help here. > > > > > > I have rented dedicated server Dell PowerEdge R6515 with iDRAC access > only. > > > There are 2 NVME drives which I wanted to use as ZFS root pool. > > > > > > They are shown in iDRAC > > > > > > Device Description: PCIe SSD in Slot 1 in Bay 1 > > > Device Protocol: NVMe-MI1.0 > > > Model:Dell Express Flash NVMe P4510 1TB SFF > > > Bus: 130 > > > Manufacturer: INTEL > > > Product ID: a54 > > > Revision: VDV1DP23 > > > Enclosure:PCIe SSD Backplane 1 > > > > > > > > > pciconf -l show many things, some of them are named "noneN@pci..." > but none "nvme" > > > > > > The is printscreen (12.1 but 13-CURRENT is the same) > > > > > > https://ibb.co/tPnymL7 > > > > > > But I booted Linux SystemRescueCd and nvme devices are there visible > in /dev/ > > > https://ibb.co/sj22Nwg > > > > > > There is verbose output of Linux lspci https://ibb.co/dPZTwV1 > > > > > > Linux dmesg contains: > > > nvme nvme0: pci function :81:00.0 > > > nvme nvme1: pci function :82:00.0 > > > nvme nvme0: 32/0/0 default/read/poll queues > > > nvme nvme1: 32/0/0 default/read/poll queues > > > > > > > > > The machine is Dell PowerEdge R6515 with AMD EPYC 7302P > > > > > > > > > More details extracted from iDRAC web interface > > > > > > I found this informations > > > > > > PCIe SSD in Slot 1 in Bay 1 > > > Bus: 82 > > > BusProtocol: PCIE > > > Device: 0 > > > DeviceDescription: PCIe SSD in Slot 1 in Bay 1 > > > DeviceProtocol: NVMe-MI1.0 > > > DeviceType: PCIeSSD > > > DriveFormFactor: 2.5 inch > > > FailurePredicted: NO > > > FQDD: Disk.Bay.1:Enclosure.Internal.0-1 > > > FreeSizeInBytes: Information Not Available > > > Function: 0 > > > HotSpareStatus: Information Not Available > > > InstanceID: Disk.Bay.1:Enclosure.Internal.0-1 > > > Manufacturer: INTEL > > > MaximumCapableSpeed: 8 GT/s > > > MediaType: Solid State Drive > > > Model: Dell Express Flash NVMe P4510 1TB SFF > > > NegotiatedSpeed: 8 GT/s > > > PCIeCapableLinkWidth: x4 > > > PCIeNegotiatedLinkWidth: x4 > > > PrimaryStatus: Ok > > > ProductID: a54 > > > RaidStatus: Information Not Available > > > RAIDType: Unknown > > > RemainingRatedWriteEndurance: 100 % > > > Revision: VDV1DP23 > > > SerialNumber: PHLJxxWF1PN > > > SizeInBytes: 1000204886016 > > > Slot: 1 > > > State: Ready > > > SystemEraseCapability: CryptographicErasePD > > > > > > PCIe SSD in Slot 1 in Bay 1 - PCI Device > > > BusNumber: 130 > > > DataBusWidth: 4x or x4 > > > Description: Express Flash NVMe 1.0 TB 2.5" U.2 (P4510) > > > DeviceDescription: PCIe SSD in Slot 1 in Bay 1 > > > DeviceNumber: 0 > > > DeviceType: PCIDevice > > > FQDD: Disk.Bay.1:Enclosure.Internal.0-1 > > > FunctionNumber: 0 > > > InstanceID: Disk.Bay.1:Enclosure.Internal.0-1 > > > LastSystemInventoryTime: 2020-04-17T03:21:39 > > > LastUpdateTime: 2020-03-31T13:55:06 > > > Manufacturer: Intel Corporation > > > PCIDeviceID: 0A54 > > > PCISubDeviceID: 2003 > > > PCISubVendorID: 1028 > > > PCIVendorID: 8086 > > > SlotLength: 2.5 Inch Drive Form Factor > > > SlotType: PCI Express Gen 3 SFF-8639 > > > > > > > > > Can anybody shed some light what the real problem is? > > > > > > Is the hardware not properly detected or is the driver completely > missing? > > > > > > NVME PCIe architecture is out of my knowledge. > > > > > > I really appreciate any help. > > > > > > Kind regards > > > Miroslav Lachman > > > ___ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > > >
Re: PCIe NVME drives not detected on Dell R6515
Scott Long wrote on 04/17/2020 17:54: Would that be the Intel VMD/VROC stuff? If so, there’s a driver for FreeBSD, but it’s not well tested yet. Will have to dig in further. This is AMD EPYC machine. Isn't VROC Intel only thing? On Apr 17, 2020, at 9:50 AM, Warner Losh wrote: On Fri, Apr 17, 2020 at 9:39 AM Scott Long wrote: Can you send me the output of ‘pciconf -llv’, either in 12-STABLE or 13-CURRENT? Also, can you send me the output of ‘dmesg’? There was another thread that said there was a raid card in the way... It would be cool to find a way to get it out of the way... :) I didn't find any evidence of RAID card but maybe I cannot look for it. Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenZFS port updated
On Fri, Apr 17, 2020 at 3:14 PM Mel Pilgrim wrote: > > On 2020-04-17 11:35, Ryan Moeller wrote: > > The FreeBSD platform support in OpenZFS does not yet include all > > features present in FreeBSD’s ZFS. Some notable changes/missing > > features include: > [...] > > * pre-mountroot zpool.cache loading (for automatic pool imports) > > > > To the last point, this mainly effects the case where / is on ZFS and > > /boot is not or is on a different pool. OpenZFS cannot handle this > > case yet, but work is in progress to cover that use case. Booting > > directly from ZFS does work. > > To be clear, this means OpenZFS currently does not support / on > GELI-encrypted disks, correct? If you have a legacy setup with a bootpool, that is correct. Since 12.0+ the bootpool is almost completely redundant except for some odd setup that I can never remember. For legacy setups, the bootpool can/should be merged into your root pool if it's feasible. Thanks, Kyle Evans ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
> On Apr 17, 2020, at 3:07 PM, Miroslav Lachman <000.f...@quip.cz> wrote: > > Scott Long wrote on 04/17/2020 23:04: >>> On Apr 17, 2020, at 2:45 PM, Miroslav Lachman <000.f...@quip.cz> wrote: >>> >>> Scott Long wrote on 04/17/2020 22:17: > On Apr 17, 2020, at 1:47 PM, Miroslav Lachman <000.f...@quip.cz> wrote: > > Kurt Jaeger wrote on 04/17/2020 21:44: >> Hi! pciconf -lBc pcib12 pciconf -lBc pcib13 >>> >>> Printscreen attached. >> Attachments are stripped from the list -- can you put them somewhere >> online ? > > Here it is https://ibb.co/c1dZrTf > > Miroslav Lachman > Ok, the bridges know about their downstream bus numbers, but I see nothing that suggests that they’re being probed. The next step would be bootverbose, but that’s going to be a lot of output to collect in screen captures. >>> >>> Over 3000 lines long but I finally managed to make SOL work so I have it as >>> text! >>> >>> https://pastebin.pl/view/90fdaafb >>> >> This helped a lot, thanks. It looks like these PCIe buses are marked as >> being hotplug, and for some reason we’re not probing them. At this point, >> I’d need to feed you some kernel patches that will dump out more info, but >> you’d have to compile them and get them onto your boot media. Is that a >> possibility? > > Currently I have all machines on 11.3 (where I can rebuild kernel without > problem) > If CURRENT is required I would need to setup some CURRENT VM in VirtualBox. > > Can you send me some link to documentation who should I create new ISO after > rebuild? > I don’t know of any docs for doing custom releases, and it looks like it’s harder than it used to be to insert custom patches. That said, I recommend doing the following on your 11.x build system: 1. Do a clean `make buildworld` with an up-to-date tree 2. change into the `release` directory that you just did the buildworld from 3. `sudo make release NOPORTS= NODOC= CHROOTDIR=/usr/tmp/release SRCBRANCH="base/stable/11@rHEAD”` You can set CHROOTDIR to whatever you want that has a few GB of space, but remember where you’ve set it for later steps. This will build a release with stock sources. Let it complete, both to prepare for the next step and to ensure that it works. It’ll take an hour or two depending on your machine speed 4. Take the patch that I’ll send you shortly and apply it to $CHROOTDIR/usr/src 5. `sudo make memstick NOPORTS= NODOC= SRC_UPDATE_SKIP= CHROOTDIR=/usr/tmp/release` Scott ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
Kurt Jaeger wrote on 04/17/2020 21:44: Hi! pciconf -lBc pcib12 pciconf -lBc pcib13 Printscreen attached. Attachments are stripped from the list -- can you put them somewhere online ? Here it is https://ibb.co/c1dZrTf Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
> On Apr 17, 2020, at 2:45 PM, Miroslav Lachman <000.f...@quip.cz> wrote: > > Scott Long wrote on 04/17/2020 22:17: >>> On Apr 17, 2020, at 1:47 PM, Miroslav Lachman <000.f...@quip.cz> wrote: >>> >>> Kurt Jaeger wrote on 04/17/2020 21:44: Hi! >> pciconf -lBc pcib12 >> pciconf -lBc pcib13 > > Printscreen attached. Attachments are stripped from the list -- can you put them somewhere online ? >>> >>> Here it is https://ibb.co/c1dZrTf >>> >>> Miroslav Lachman >>> >> Ok, the bridges know about their downstream bus numbers, but I see nothing >> that suggests that they’re being probed. The next step would be >> bootverbose, but that’s going to be a lot of output to collect in screen >> captures. > > Over 3000 lines long but I finally managed to make SOL work so I have it as > text! > > https://pastebin.pl/view/90fdaafb > This helped a lot, thanks. It looks like these PCIe buses are marked as being hotplug, and for some reason we’re not probing them. At this point, I’d need to feed you some kernel patches that will dump out more info, but you’d have to compile them and get them onto your boot media. Is that a possibility? Thanks, Scott ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
On 2020-04-17 8:50, Warner Losh wrote: On Fri, Apr 17, 2020 at 9:39 AM Scott Long wrote: Can you send me the output of ‘pciconf -llv’, either in 12-STABLE or 13-CURRENT? Also, can you send me the output of ‘dmesg’? There was another thread that said there was a raid card in the way... It would be cool to find a way to get it out of the way... :) On the R6515, NVME drives are supported through a PERC S150 mini card. There's no m.2 slots or U.2 ports on the mainboard itself. The S150 supports non-RAID mode, but that still leaves supporting a software-based PERC card as a PCIe switch for the 8 or 10 NVME bays behind it. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
Hi! > > pciconf -lBc pcib12 > > pciconf -lBc pcib13 > > Printscreen attached. Attachments are stripped from the list -- can you put them somewhere online ? -- p...@opsec.eu+49 171 3101372Now what ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenZFS port updated
Is the intention to eventually replace the zfs code in src/ ? What will be the
long-term relationship between src/ and ports/ for this?
Scott
> On Apr 17, 2020, at 12:35 PM, Ryan Moeller wrote:
>
> FreeBSD support has been merged into the master branch of the openzfs/zfs
> repository, and the FreeBSD ports have been switched to this branch.
>
> OpenZFS brings many exciting features to FreeBSD, including:
> * native encryption
> * improved TRIM implementation
> * most recently, persistent L2ARC
>
> Of course, avoid upgrading your pools if you want to keep the option to go
> back to the base ZFS.
>
> OpenZFS can be installed alongside the base ZFS. Change your loader.conf
> entry to openzfs_load=“YES” to load the OpenZFS module at boot, and set PATH
> to find the tools in /usr/local/sbin before /sbin. The base zfs tools are
> still basically functional with the OpenZFS module, so changing PATH in rc is
> not strictly necessary.
>
> The FreeBSD loader can boot from pools with the encryption feature enabled,
> but the root/bootenv datasets must not be encrypted themselves.
>
> The FreeBSD platform support in OpenZFS does not yet include all features
> present in FreeBSD’s ZFS. Some notable changes/missing features include:
> * many sysctl names have changed (legacy compat sysctls should be added at
> some point)
> * zfs send progress reporting in process title via setproctitle
> * extended 'zfs holds -r'
> (https://svnweb.freebsd.org/base?view=revision=290015)
> * vdev ashift optimizations
> (https://svnweb.freebsd.org/base?view=revision=254591)
> * pre-mountroot zpool.cache loading (for automatic pool imports)
>
> To the last point, this mainly effects the case where / is on ZFS and /boot
> is not or is on a different pool. OpenZFS cannot handle this case yet, but
> work is in progress to cover that use case. Booting directly from ZFS does
> work.
>
> If there are pools that need to be imported at boot other than the boot pool,
> OpenZFS does not automatically import yet, and it uses /etc/zfs/zpool.cache
> rather than /boot/zfs/zpool.cache to keep track of imported pools. To ensure
> all pool imports occur automatically, a simple edit to /etc/rc.d/zfs will
> suffice:
>
> diff --git a/libexec/rc/rc.d/zfs b/libexec/rc/rc.d/zfs
> index 2d35f9b5464..8e4aef0b1b3 100755
> --- a/libexec/rc/rc.d/zfs
> +++ b/libexec/rc/rc.d/zfs
> @@ -25,6 +25,13 @@ zfs_start_jail()
>
> zfs_start_main()
> {
> + local cachefile
> +
> + for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do
> + if [ -f $cachefile ]; then
> + zpool import -c $cachefile -a
> + fi
> + done
> zfs mount -va
> zfs share -a
> if [ ! -r /etc/zfs/exports ]; then
>
> This will probably not be needed long-term. It is not necessary if the boot
> pool is the only pool.
>
> Happy testing :)
>
> - Ryan
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
Scott Long wrote: On Apr 17, 2020, at 3:07 PM, Miroslav Lachman <000.f...@quip.cz> wrote: Scott Long wrote on 04/17/2020 23:04: On Apr 17, 2020, at 2:45 PM, Miroslav Lachman <000.f...@quip.cz> wrote: Scott Long wrote on 04/17/2020 22:17: On Apr 17, 2020, at 1:47 PM, Miroslav Lachman <000.f...@quip.cz> wrote: Kurt Jaeger wrote on 04/17/2020 21:44: Hi! pciconf -lBc pcib12 pciconf -lBc pcib13 Printscreen attached. Attachments are stripped from the list -- can you put them somewhere online ? Here it is https://ibb.co/c1dZrTf Miroslav Lachman Ok, the bridges know about their downstream bus numbers, but I see nothing that suggests that they’re being probed. The next step would be bootverbose, but that’s going to be a lot of output to collect in screen captures. Over 3000 lines long but I finally managed to make SOL work so I have it as text! https://pastebin.pl/view/90fdaafb This helped a lot, thanks. It looks like these PCIe buses are marked as being hotplug, and for some reason we’re not probing them. At this point, I’d need to feed you some kernel patches that will dump out more info, but you’d have to compile them and get them onto your boot media. Is that a possibility? Currently I have all machines on 11.3 (where I can rebuild kernel without problem) If CURRENT is required I would need to setup some CURRENT VM in VirtualBox. Can you send me some link to documentation who should I create new ISO after rebuild? I don’t know of any docs for doing custom releases, and it looks like it’s harder than it used to be to insert custom patches. That said, I recommend doing the following on your 11.x build system: 1. Do a clean `make buildworld` with an up-to-date tree 2. change into the `release` directory that you just did the buildworld from 3. `sudo make release NOPORTS= NODOC= CHROOTDIR=/usr/tmp/release SRCBRANCH="base/stable/11@rHEAD”` You can set CHROOTDIR to whatever you want that has a few GB of space, but remember where you’ve set it for later steps. This will build a release with stock sources. Let it complete, both to prepare for the next step and to ensure that it works. It’ll take an hour or two depending on your machine speed 4. Take the patch that I’ll send you shortly and apply it to $CHROOTDIR/usr/src 5. `sudo make memstick NOPORTS= NODOC= SRC_UPDATE_SKIP= CHROOTDIR=/usr/tmp/release` Just a thought - it could possibly be easier to build just the patched kernel and try booting it (11.3 userland should work with CURRENT kernel, right?), doing the kernel-toolchaing target first, and using INSTKERNNAME with the installkernel target to temporary select it from loader menu. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenZFS port updated
On 2020-04-17 13:31, Kyle Evans wrote: On Fri, Apr 17, 2020 at 3:14 PM Mel Pilgrim wrote: On 2020-04-17 11:35, Ryan Moeller wrote: The FreeBSD platform support in OpenZFS does not yet include all features present in FreeBSD’s ZFS. Some notable changes/missing features include: [...] * pre-mountroot zpool.cache loading (for automatic pool imports) To the last point, this mainly effects the case where / is on ZFS and /boot is not or is on a different pool. OpenZFS cannot handle this case yet, but work is in progress to cover that use case. Booting directly from ZFS does work. To be clear, this means OpenZFS currently does not support / on GELI-encrypted disks, correct? If you have a legacy setup with a bootpool, that is correct. Since 12.0+ the bootpool is almost completely redundant except for some odd setup that I can never remember. For legacy setups, the bootpool can/should be merged into your root pool if it's feasible. Yes, these are the "legacy" configuration with a small, unecrypted pool containing /boot and the keys to attach the encrypted root pool. Could the case you're thinking of be avoiding manual entry of a password at boot? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenZFS port updated
On Fri, Apr 17, 2020 at 1:16 PM Scott Long wrote:
>
> Is the intention to eventually replace the zfs code in src/ ?
Yes. Once the feature gap is filled in and most of the potential POLA
violations are fixed.
> What will be the long-term relationship between src/ and ports/ for this?
OpenZFS users on 12 will use the port indefinitely. HEAD will
presumably be updated whenever a point release is created upstream.
Ultimately I can see two versions of the port, one that tracks master
for HEAD and 12 and one that tracks only the latest release for 12
users.
-M
>
> Scott
>
>
> > On Apr 17, 2020, at 12:35 PM, Ryan Moeller wrote:
> >
> > FreeBSD support has been merged into the master branch of the openzfs/zfs
> > repository, and the FreeBSD ports have been switched to this branch.
> >
> > OpenZFS brings many exciting features to FreeBSD, including:
> > * native encryption
> > * improved TRIM implementation
> > * most recently, persistent L2ARC
> >
> > Of course, avoid upgrading your pools if you want to keep the option to go
> > back to the base ZFS.
> >
> > OpenZFS can be installed alongside the base ZFS. Change your loader.conf
> > entry to openzfs_load=“YES” to load the OpenZFS module at boot, and set
> > PATH to find the tools in /usr/local/sbin before /sbin. The base zfs tools
> > are still basically functional with the OpenZFS module, so changing PATH in
> > rc is not strictly necessary.
> >
> > The FreeBSD loader can boot from pools with the encryption feature enabled,
> > but the root/bootenv datasets must not be encrypted themselves.
> >
> > The FreeBSD platform support in OpenZFS does not yet include all features
> > present in FreeBSD’s ZFS. Some notable changes/missing features include:
> > * many sysctl names have changed (legacy compat sysctls should be added at
> > some point)
> > * zfs send progress reporting in process title via setproctitle
> > * extended 'zfs holds -r'
> > (https://svnweb.freebsd.org/base?view=revision=290015)
> > * vdev ashift optimizations
> > (https://svnweb.freebsd.org/base?view=revision=254591)
> > * pre-mountroot zpool.cache loading (for automatic pool imports)
> >
> > To the last point, this mainly effects the case where / is on ZFS and /boot
> > is not or is on a different pool. OpenZFS cannot handle this case yet, but
> > work is in progress to cover that use case. Booting directly from ZFS does
> > work.
> >
> > If there are pools that need to be imported at boot other than the boot
> > pool, OpenZFS does not automatically import yet, and it uses
> > /etc/zfs/zpool.cache rather than /boot/zfs/zpool.cache to keep track of
> > imported pools. To ensure all pool imports occur automatically, a simple
> > edit to /etc/rc.d/zfs will suffice:
> >
> > diff --git a/libexec/rc/rc.d/zfs b/libexec/rc/rc.d/zfs
> > index 2d35f9b5464..8e4aef0b1b3 100755
> > --- a/libexec/rc/rc.d/zfs
> > +++ b/libexec/rc/rc.d/zfs
> > @@ -25,6 +25,13 @@ zfs_start_jail()
> >
> > zfs_start_main()
> > {
> > + local cachefile
> > +
> > + for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do
> > + if [ -f $cachefile ]; then
> > + zpool import -c $cachefile -a
> > + fi
> > + done
> > zfs mount -va
> > zfs share -a
> > if [ ! -r /etc/zfs/exports ]; then
> >
> > This will probably not be needed long-term. It is not necessary if the boot
> > pool is the only pool.
> >
> > Happy testing :)
> >
> > - Ryan
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
Scott Long wrote on 04/17/2020 21:18: On Apr 17, 2020, at 11:46 AM, Miroslav Lachman <000.f...@quip.cz> wrote: Scott Long wrote on 04/17/2020 18:17: You are correct about Intel vs AMD. Comparing the full output of pciconf from FreeBSD with the fragment of lspci from Linux suggests that there’s at least one set of a PCIe switch and child devices that is not being enumerated by FreeBSD. Can you send the full output of `lspci -tvv` from linux? Sorry for my late reply. Booting the Linux SystemRescueCd is too slow. lspci -tvv output is attached I tried to connect to SOL by SSH but it shows black screen only. lspci shows drives: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller] Kind regards Miroslav Lachman It looks like pcib12 and pcib13 in FreeBSD should be the bridges that have the NVMe devices behind them, but those devices aren’t showing up. I don’t see any obvious code in linux to handle those bridges, so there must be something subtle that we’re missing in FreeBSD. Maybe we’re having trouble enumerating above PCI bus 128? I think that was a problem a few years ago but I also thought it was fixed. Can you do the following in FreeBSD: pciconf -lBc pcib12 pciconf -lBc pcib13 Printscreen attached. Anything else I can provide? Thank you Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenZFS port updated
On 2020-04-17 11:35, Ryan Moeller wrote: The FreeBSD platform support in OpenZFS does not yet include all features present in FreeBSD’s ZFS. Some notable changes/missing features include: [...] * pre-mountroot zpool.cache loading (for automatic pool imports) To the last point, this mainly effects the case where / is on ZFS and /boot is not or is on a different pool. OpenZFS cannot handle this case yet, but work is in progress to cover that use case. Booting directly from ZFS does work. To be clear, this means OpenZFS currently does not support / on GELI-encrypted disks, correct? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenZFS port updated
Hi, > On 17 Apr 2020, at 19:35, Ryan Moeller wrote: > > FreeBSD support has been merged into the master branch of the openzfs/zfs > repository, and the FreeBSD ports have been switched to this branch. > > OpenZFS brings many exciting features to FreeBSD, including: > * native encryption > * improved TRIM implementation [etc] Note that unlike native ZFS, OpenZFS doesn’t (last time I looked) support autotrim by default - you have to enable it explicitly. -- Bob Bishop r...@gid.co.uk ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
> On Apr 17, 2020, at 3:13 PM, Mel Pilgrim > wrote: > > On 2020-04-17 8:50, Warner Losh wrote: >> On Fri, Apr 17, 2020 at 9:39 AM Scott Long wrote: >>> Can you send me the output of ‘pciconf -llv’, either in 12-STABLE or >>> 13-CURRENT? Also, can you send me the output of ‘dmesg’? >>> >> There was another thread that said there was a raid card in the way... It >> would be cool to find a way to get it out of the way... :) > On the R6515, NVME drives are supported through a PERC S150 mini card. > There's no m.2 slots or U.2 ports on the mainboard itself. The S150 supports > non-RAID mode, but that still leaves supporting a software-based PERC card as > a PCIe switch for the 8 or 10 NVME bays behind it. This doesn’t seem to be the case for Miroslav’s system. There’s no special handling of the PCIe bridge/switch in linux where it does work, and there’s growing evidence that this is a case of FreeBSD not handling hotplug ports correctly. Scott ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenZFS port updated
> On Apr 17, 2020, at 4:56 PM, Pete Wright wrote: > > On 4/17/20 11:35 AM, Ryan Moeller wrote: >> FreeBSD support has been merged into the master branch of the openzfs/zfs >> repository, and the FreeBSD ports have been switched to this branch. > Congratulations on this effort - big milestone! >> OpenZFS brings many exciting features to FreeBSD, including: >> * native encryption > Is there a good doc reference on available for using this? I believe this is > zfs filesystem level encryption and not a replacement for our existing > full-disk-encryption scheme that currently works? I’m not aware of a good current doc for this. If anyone finds/writes something, please post it! There are some old resources you can find with a quick search that do a pretty good job of covering the basic ideas, but I think the exact syntax of commands may be slightly changed in the final implementation. The encryption is performed at a filesystem level (per-dataset). > thanks again! > -pete > > -- > Pete Wright > p...@nomadlogic.org > @nomadlogicLA > > ___ > freebsd-sta...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
> On Apr 17, 2020, at 11:46 AM, Miroslav Lachman <000.f...@quip.cz> wrote: > > Scott Long wrote on 04/17/2020 18:17: >> You are correct about Intel vs AMD. Comparing the full output of pciconf >> from FreeBSD with the fragment of lspci from Linux suggests that there’s at >> least one set of a PCIe switch and child devices that is not being >> enumerated by FreeBSD. Can you send the full output of `lspci -tvv` from >> linux? > > Sorry for my late reply. Booting the Linux SystemRescueCd is too slow. > > lspci -tvv output is attached > > I tried to connect to SOL by SSH but it shows black screen only. > > lspci shows drives: > > Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller] > > Kind regards > Miroslav Lachman > It looks like pcib12 and pcib13 in FreeBSD should be the bridges that have the NVMe devices behind them, but those devices aren’t showing up. I don’t see any obvious code in linux to handle those bridges, so there must be something subtle that we’re missing in FreeBSD. Maybe we’re having trouble enumerating above PCI bus 128? I think that was a problem a few years ago but I also thought it was fixed. Can you do the following in FreeBSD: pciconf -lBc pcib12 pciconf -lBc pcib13 Thanks, Scott ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
Scott Long wrote on 04/17/2020 22:17: On Apr 17, 2020, at 1:47 PM, Miroslav Lachman <000.f...@quip.cz> wrote: Kurt Jaeger wrote on 04/17/2020 21:44: Hi! pciconf -lBc pcib12 pciconf -lBc pcib13 Printscreen attached. Attachments are stripped from the list -- can you put them somewhere online ? Here it is https://ibb.co/c1dZrTf Miroslav Lachman Ok, the bridges know about their downstream bus numbers, but I see nothing that suggests that they’re being probed. The next step would be bootverbose, but that’s going to be a lot of output to collect in screen captures. Over 3000 lines long but I finally managed to make SOL work so I have it as text! https://pastebin.pl/view/90fdaafb Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenZFS port updated
On 4/17/20 11:35 AM, Ryan Moeller wrote: FreeBSD support has been merged into the master branch of the openzfs/zfs repository, and the FreeBSD ports have been switched to this branch. Congratulations on this effort - big milestone! OpenZFS brings many exciting features to FreeBSD, including: * native encryption Is there a good doc reference on available for using this? I believe this is zfs filesystem level encryption and not a replacement for our existing full-disk-encryption scheme that currently works? thanks again! -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
Scott Long wrote on 04/17/2020 23:04: On Apr 17, 2020, at 2:45 PM, Miroslav Lachman <000.f...@quip.cz> wrote: Scott Long wrote on 04/17/2020 22:17: On Apr 17, 2020, at 1:47 PM, Miroslav Lachman <000.f...@quip.cz> wrote: Kurt Jaeger wrote on 04/17/2020 21:44: Hi! pciconf -lBc pcib12 pciconf -lBc pcib13 Printscreen attached. Attachments are stripped from the list -- can you put them somewhere online ? Here it is https://ibb.co/c1dZrTf Miroslav Lachman Ok, the bridges know about their downstream bus numbers, but I see nothing that suggests that they’re being probed. The next step would be bootverbose, but that’s going to be a lot of output to collect in screen captures. Over 3000 lines long but I finally managed to make SOL work so I have it as text! https://pastebin.pl/view/90fdaafb This helped a lot, thanks. It looks like these PCIe buses are marked as being hotplug, and for some reason we’re not probing them. At this point, I’d need to feed you some kernel patches that will dump out more info, but you’d have to compile them and get them onto your boot media. Is that a possibility? Currently I have all machines on 11.3 (where I can rebuild kernel without problem) If CURRENT is required I would need to setup some CURRENT VM in VirtualBox. Can you send me some link to documentation who should I create new ISO after rebuild? Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
> On Apr 17, 2020, at 1:47 PM, Miroslav Lachman <000.f...@quip.cz> wrote: > > Kurt Jaeger wrote on 04/17/2020 21:44: >> Hi! pciconf -lBc pcib12 pciconf -lBc pcib13 >>> >>> Printscreen attached. >> Attachments are stripped from the list -- can you put them somewhere >> online ? > > Here it is https://ibb.co/c1dZrTf > > Miroslav Lachman > Ok, the bridges know about their downstream bus numbers, but I see nothing that suggests that they’re being probed. The next step would be bootverbose, but that’s going to be a lot of output to collect in screen captures. Scott ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Patch to add recent bluetooth features to hccontrol
apologies if this is the wrong list. I have created a patch to add more recent bluetooth features to hccontrol. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245354 Is this a reasonable approach? Best regards, Marc Veldman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenZFS port updated
On 4/17/20 2:54 PM, Ryan Moeller wrote: On Apr 17, 2020, at 4:56 PM, Pete Wright wrote: On 4/17/20 11:35 AM, Ryan Moeller wrote: FreeBSD support has been merged into the master branch of the openzfs/zfs repository, and the FreeBSD ports have been switched to this branch. Congratulations on this effort - big milestone! OpenZFS brings many exciting features to FreeBSD, including: * native encryption Is there a good doc reference on available for using this? I believe this is zfs filesystem level encryption and not a replacement for our existing full-disk-encryption scheme that currently works? I’m not aware of a good current doc for this. If anyone finds/writes something, please post it! There are some old resources you can find with a quick search that do a pretty good job of covering the basic ideas, but I think the exact syntax of commands may be slightly changed in the final implementation. The encryption is performed at a filesystem level (per-dataset). thanks for the clarification Ryan. I may try to test this out in the near future and will try to record my findings in a wiki or somewhere. being able to do filesystem level encryption is something i have several immediate use cases for. thanks! -p -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PCIe NVME drives not detected on Dell R6515
On Fri, 17 Apr 2020 23:07:38 +0200 Miroslav Lachman 000.f...@quip.cz said Scott Long wrote on 04/17/2020 23:04: > > >> On Apr 17, 2020, at 2:45 PM, Miroslav Lachman <000.f...@quip.cz> wrote: >> >> Scott Long wrote on 04/17/2020 22:17: On Apr 17, 2020, at 1:47 PM, Miroslav Lachman <000.f...@quip.cz> wrote: Kurt Jaeger wrote on 04/17/2020 21:44: > Hi! >>> pciconf -lBc pcib12 >>> pciconf -lBc pcib13 >> >> Printscreen attached. > Attachments are stripped from the list -- can you put them somewhere > online ? Here it is https://ibb.co/c1dZrTf Miroslav Lachman >>> Ok, the bridges know about their downstream bus numbers, but I see nothing > that suggests that they’re being probed. The next step would be bootverbose, > but that’s going to be a lot of output to collect in screen captures. >> >> Over 3000 lines long but I finally managed to make SOL work so I have it as > text! >> >> https://pastebin.pl/view/90fdaafb >> > > This helped a lot, thanks. It looks like these PCIe buses are marked as > being hotplug, and for some reason we’re not probing them. At this point, > I’d need to feed you some kernel patches that will dump out more info, but > you’d have to compile them and get them onto your boot media. Is that a > possibility? Currently I have all machines on 11.3 (where I can rebuild kernel without problem) If CURRENT is required I would need to setup some CURRENT VM in VirtualBox. Can you send me some link to documentation who should I create new ISO after rebuild? Here's what I do After building world && kernel: # cd /usr/src/ # make installworld DESTDIR=/to/path/with-2Gig-space # make distribution DESTDIR=/to/path/with-2Gig-space (you need a slice with ~2G space available) Then: # mkisofs -b boot/cdboot -no-emul-boot -r -J -V "FreeBSD__Install" -publisher "" -o /path/to/put/NEW_INSTALL.iso /to/path/with-2Gig-space Hope it makes sense to you. :) --Chris Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sort.core error doing installworld on Current.
Op 17-04-2020 om 03:31 schreef Rodney W. Grimes: On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman wrote: So you some how had a sort core dump sitting in /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how did get there? I'd take a look at the date on the file and, it it is older than the buildworld, just assume that it was left-over garbage. In either case, you can delete it and do another installworld. That should most likely fix things, but, if the buildworld or installworld had a crash of sort(1) that left the file, further investigation might be needed. Re-making the zoneinfo would help track it down should this be a re al bug, but it's my uneducated guess that it's not. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 Please forgive that awful post! I missed a part of your message by laziness. It's odd that the error of sort(1) crashing was not caught by the script. Yes, that is a Makefile flaw someplace. Further there must be a wildcard being used to decide which files to install, that is a further Makefile flaw. Wildcards should NOT be used in the source of an install list, exactly because of this type of cruft that can be dropped in an obj dir. Clearly, sort should NOT crash! Again, a re-build of zoneinfo might catch something. Looking at the core might tell you which "sort" was involved... the one you just built or the one in the base system. This could be just a FOTU, but I would not bet on it. I suspect a recent zoneinfo commit as the root cause. I have no idea how to bypass this issue. I have used sort from the latest snapshot and placed that file on the system and in the build dir, but i keep getting the core How can i test an build and install part for zoneinfo If i go into the dir /usr/src/share/zoneinfo and do make install it does not work, do i need to add something? Thank you both for your time -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks wrote: I have a machine running FreeBSD head. rev 13.0-CURRENT #11 r360008 This is a quite powerful machine, so i thought it was a good idea to let that server do the build and for my virtualbox machine i can use the powerful machine to do a installword over NFS. But when i did the make installworld step the client so to say gives an error. install -o root -g wheel -m 444 /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu /usr/share/zoneinfo/Zulu install -o root -g wheel -m 444 /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules /usr/share/zoneinfo/posixrules install -o root -g wheel -m 444 /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core /usr/share/zoneinfo/sort.core install: /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core: Permission denied *** Error code 71 Stop. bmake[5]: stopped in /usr/src/share/zoneinfo *** Error code 1 Stop. bmake[4]: stopped in /usr/src/share *** Error code 1 Stop. bmake[3]: stopped in /usr/src *** Error code 1 Stop. bmake[2]: stopped in /usr/src *** Error code 1 Stop. bmake[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src .ERROR_TARGET='installworld' .ERROR_META_FILE='' .MAKE.LEVEL='0' MAKEFILE='' .MAKE.MODE='normal' _ERROR_CMD='.PHONY' .CURDIR='/usr/src' .MAKE='make' .OBJDIR='/usr/obj/usr/src/amd64.amd64' .TARGETS='installworld' DESTDIR='' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MAKEOBJDIRPREFIX='/usr/obj' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20181221' PATH='/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/usr/obj/usr/src/amd64.amd64' It looks likes sort coredumps in the usr/share/zoneinfo part of the base. As it has no permission on the NFS share it errors out. On the server itself, the installworld goes well, but it leaves a sort.core file behind in /usr/share/zoneinfo cd /usr/share/zoneinfo ls -al ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sort.core error doing installworld on Current.
> > Op 17-04-2020 om 03:31 schreef Rodney W. Grimes: > >> On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman wrote: > >> > >>> So you some how had a sort core dump sitting in > >>> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how > >>> did get there? I'd take a look at the date on the file and, it it is older > >>> than the buildworld, just assume that it was left-over garbage. In either > >>> case, you can delete it and do another installworld. > >>> > >>> That should most likely fix things, but, if the buildworld or installworld > >>> had a crash of sort(1) that left the file, further investigation might be > >>> needed. Re-making the zoneinfo would help track it down should this be a > >>> re > >>> al bug, but it's my uneducated guess that it's not. > >>> -- > >>> Kevin Oberman, Part time kid herder and retired Network Engineer > >>> E-mail: rkober...@gmail.com > >>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > >>> > >> Please forgive that awful post! I missed a part of your message by > >> laziness. > >> > >> It's odd that the error of sort(1) crashing was not caught by the script. > > Yes, that is a Makefile flaw someplace. > > Further there must be a wildcard being used to decide which files to > > install, that is a further Makefile flaw. Wildcards should NOT be used > > in the source of an install list, exactly because of this type of cruft > > that can be dropped in an obj dir. > > > >> Clearly, sort should NOT crash! Again, a re-build of zoneinfo might catch > >> something. Looking at the core might tell you which "sort" was involved... > >> the one you just built or the one in the base system. This could be just a > >> FOTU, but I would not bet on it. > > I suspect a recent zoneinfo commit as the root cause. > > > I have no idea how to bypass this issue. > I have used sort from the latest snapshot and placed that file on the > system and in the build dir, but i keep getting the core > > How can i test an build and install part for zoneinfo > > If i go into the dir /usr/src/share/zoneinfo and do make install it does > not work, do i need to add something? Can you show us the output from cd /usr/src/share/zoneinfo make clean && make depend && make all && make install Someplace in that we should get to see sort crashing... > > Thank you both for your time > > >> -- > >> Kevin Oberman, Part time kid herder and retired Network Engineer > >> E-mail: rkober...@gmail.com > >> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > >> > >> > >>> > >>> On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks > >>> wrote: > >>> > I have a machine running FreeBSD head. > rev 13.0-CURRENT #11 r360008 > > This is a quite powerful machine, so i thought it was a good idea to let > that server do the build and for my virtualbox machine i can use the > powerful machine to do a installword over NFS. > > But when i did the make installworld step the client so to say gives an > error. > > install -o root -g wheel -m 444 > /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu > /usr/share/zoneinfo/Zulu > install -o root -g wheel -m 444 > /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules > /usr/share/zoneinfo/posixrules > install -o root -g wheel -m 444 > /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core > /usr/share/zoneinfo/sort.core > install: /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core: > Permission denied > *** Error code 71 > > Stop. > bmake[5]: stopped in /usr/src/share/zoneinfo > *** Error code 1 > > Stop. > bmake[4]: stopped in /usr/src/share > *** Error code 1 > > Stop. > bmake[3]: stopped in /usr/src > *** Error code 1 > > Stop. > bmake[2]: stopped in /usr/src > *** Error code 1 > > Stop. > bmake[1]: stopped in /usr/src > *** Error code 1 > > Stop. > make: stopped in /usr/src > .ERROR_TARGET='installworld' > .ERROR_META_FILE='' > .MAKE.LEVEL='0' > MAKEFILE='' > .MAKE.MODE='normal' > _ERROR_CMD='.PHONY' > .CURDIR='/usr/src' > .MAKE='make' > .OBJDIR='/usr/obj/usr/src/amd64.amd64' > .TARGETS='installworld' > DESTDIR='' > LD_LIBRARY_PATH='' > MACHINE='amd64' > MACHINE_ARCH='amd64' > MAKEOBJDIRPREFIX='/usr/obj' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20181221' > PATH='/sbin:/bin:/usr/sbin:/usr/bin' > SRCTOP='/usr/src' > OBJTOP='/usr/obj/usr/src/amd64.amd64' > > It looks likes sort coredumps in the usr/share/zoneinfo part of the base. > As it has no permission on the NFS share it errors out. > On the server itself, the installworld goes well, but it leaves a > sort.core file behind in /usr/share/zoneinfo > > cd /usr/share/zoneinfo > ls -al >
Re: sort.core error doing installworld on Current.
On Fri, Apr 17, 2020 at 12:24:41PM +0200, Johan Hendriks wrote: > > Op 17-04-2020 om 03:31 schreef Rodney W. Grimes: > > I have no idea how to bypass this issue. > Sorry; I was busy with work stuff when your original post came by. IIRC, you had several system components excluded from building (on your build machine); do you also have them excluded on the target machine(s)? That is, /etc/src.conf on each target machines needs to specify (the installation of) no more than what was built on the build machine. I have been doing this (bild on a more pawerful machine; mount on less-powerful machine via NFS; install) routinely (every Sunday) for the last several years; it's when I have managed to neglect to ensure the above property that I have encountered such "weirdness." Ref. http://www.catwhisker.org/~david/FreeBSD/upgrade.html Peace and good health, david -- David H. Wolfskill da...@catwhisker.org Please read https://www.speaker.gov/newsroom/41420-0 See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: sort.core error doing installworld on Current.
> >
> > Op 17-04-2020 om 03:31 schreef Rodney W. Grimes:
> > >> On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman
> > >> wrote:
> > >>
> > >>> So you some how had a sort core dump sitting in
> > >>> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how
> > >>> did get there? I'd take a look at the date on the file and, it it is
> > >>> older
> > >>> than the buildworld, just assume that it was left-over garbage. In
> > >>> either
> > >>> case, you can delete it and do another installworld.
> > >>>
> > >>> That should most likely fix things, but, if the buildworld or
> > >>> installworld
> > >>> had a crash of sort(1) that left the file, further investigation might
> > >>> be
> > >>> needed. Re-making the zoneinfo would help track it down should this be
> > >>> a re
> > >>> al bug, but it's my uneducated guess that it's not.
> > >>> --
> > >>> Kevin Oberman, Part time kid herder and retired Network Engineer
> > >>> E-mail: rkober...@gmail.com
> > >>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> > >>>
> > >> Please forgive that awful post! I missed a part of your message by
> > >> laziness.
> > >>
> > >> It's odd that the error of sort(1) crashing was not caught by the script.
> > > Yes, that is a Makefile flaw someplace.
> > > Further there must be a wildcard being used to decide which files to
> > > install, that is a further Makefile flaw. Wildcards should NOT be used
> > > in the source of an install list, exactly because of this type of cruft
> > > that can be dropped in an obj dir.
>From src/share/zoneinfo/Makefile at about line 93:
92 if make(*install*)
93 TZS!= cd ${TZBUILDDIR} && find * -type f | LC_ALL=C sort
this is a very bad thing to do in a
Makefile.
94 .endif
Now I still don't know why sort cored, but I am sure this is the line that did
it.
> > >
> > >> Clearly, sort should NOT crash! Again, a re-build of zoneinfo might catch
> > >> something. Looking at the core might tell you which "sort" was
> > >> involved...
> > >> the one you just built or the one in the base system. This could be just
> > >> a
> > >> FOTU, but I would not bet on it.
> > > I suspect a recent zoneinfo commit as the root cause.
> > >
> > I have no idea how to bypass this issue.
> > I have used sort from the latest snapshot and placed that file on the
> > system and in the build dir, but i keep getting the core
> >
> > How can i test an build and install part for zoneinfo
> >
> > If i go into the dir /usr/src/share/zoneinfo and do make install it does
> > not work, do i need to add something?
>
> Can you show us the output from
> cd /usr/src/share/zoneinfo
> make clean && make depend && make all && make install
> Someplace in that we should get to see sort crashing...
>
> >
> > Thank you both for your time
> >
> > >> --
> > >> Kevin Oberman, Part time kid herder and retired Network Engineer
> > >> E-mail: rkober...@gmail.com
> > >> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> > >>
> > >>
> > >>>
> > >>> On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks
> > >>> wrote:
> > >>>
> > I have a machine running FreeBSD head.
> > rev 13.0-CURRENT #11 r360008
> >
> > This is a quite powerful machine, so i thought it was a good idea to
> > let
> > that server do the build and for my virtualbox machine i can use the
> > powerful machine to do a installword over NFS.
> >
> > But when i did the make installworld step the client so to say gives an
> > error.
> >
> > install -o root -g wheel -m 444
> > /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu
> > /usr/share/zoneinfo/Zulu
> > install -o root -g wheel -m 444
> > /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules
> > /usr/share/zoneinfo/posixrules
> > install -o root -g wheel -m 444
> > /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core
> > /usr/share/zoneinfo/sort.core
> > install:
> > /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core:
> > Permission denied
> > *** Error code 71
> >
> > Stop.
> > bmake[5]: stopped in /usr/src/share/zoneinfo
> > *** Error code 1
> >
> > Stop.
> > bmake[4]: stopped in /usr/src/share
> > *** Error code 1
> >
> > Stop.
> > bmake[3]: stopped in /usr/src
> > *** Error code 1
> >
> > Stop.
> > bmake[2]: stopped in /usr/src
> > *** Error code 1
> >
> > Stop.
> > bmake[1]: stopped in /usr/src
> > *** Error code 1
> >
> > Stop.
> > make: stopped in /usr/src
> > .ERROR_TARGET='installworld'
> > .ERROR_META_FILE=''
> > .MAKE.LEVEL='0'
> > MAKEFILE=''
> > .MAKE.MODE='normal'
> > _ERROR_CMD='.PHONY'
> > .CURDIR='/usr/src'
> > .MAKE='make'
> > .OBJDIR='/usr/obj/usr/src/amd64.amd64'
> > .TARGETS='installworld'
> >
Re: sort.core error doing installworld on Current.
Op 17-04-2020 om 12:47 schreef Rodney W. Grimes:
Op 17-04-2020 om 03:31 schreef Rodney W. Grimes:
On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman wrote:
So you some how had a sort core dump sitting in
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how
did get there? I'd take a look at the date on the file and, it it is older
than the buildworld, just assume that it was left-over garbage. In either
case, you can delete it and do another installworld.
That should most likely fix things, but, if the buildworld or installworld
had a crash of sort(1) that left the file, further investigation might be
needed. Re-making the zoneinfo would help track it down should this be a re
al bug, but it's my uneducated guess that it's not.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Please forgive that awful post! I missed a part of your message by laziness.
It's odd that the error of sort(1) crashing was not caught by the script.
Yes, that is a Makefile flaw someplace.
Further there must be a wildcard being used to decide which files to
install, that is a further Makefile flaw. Wildcards should NOT be used
in the source of an install list, exactly because of this type of cruft
that can be dropped in an obj dir.
From src/share/zoneinfo/Makefile at about line 93:
92 if make(*install*)
93 TZS!= cd ${TZBUILDDIR} && find * -type f | LC_ALL=C sort
this is a very bad thing to do in a
Makefile.
94 .endif
Now I still don't know why sort cored, but I am sure this is the line that did
it.
Clearly, sort should NOT crash! Again, a re-build of zoneinfo might catch
something. Looking at the core might tell you which "sort" was involved...
the one you just built or the one in the base system. This could be just a
FOTU, but I would not bet on it.
I suspect a recent zoneinfo commit as the root cause.
I have no idea how to bypass this issue.
I have used sort from the latest snapshot and placed that file on the
system and in the build dir, but i keep getting the core
How can i test an build and install part for zoneinfo
If i go into the dir /usr/src/share/zoneinfo and do make install it does
not work, do i need to add something?
Can you show us the output from
cd /usr/src/share/zoneinfo
make clean && make depend && make all && make install
Someplace in that we should get to see sort crashing...
On both machines my src.conf file is the same.
I will start over from a clean world by doing a make cleanworld and see
if it then still gives the errors
Maybe some old artifacts are hanging around.
Thank you both for your time
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks
wrote:
I have a machine running FreeBSD head.
rev 13.0-CURRENT #11 r360008
This is a quite powerful machine, so i thought it was a good idea to let
that server do the build and for my virtualbox machine i can use the
powerful machine to do a installword over NFS.
But when i did the make installworld step the client so to say gives an
error.
install -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu
/usr/share/zoneinfo/Zulu
install -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules
/usr/share/zoneinfo/posixrules
install -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core
/usr/share/zoneinfo/sort.core
install: /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core:
Permission denied
*** Error code 71
Stop.
bmake[5]: stopped in /usr/src/share/zoneinfo
*** Error code 1
Stop.
bmake[4]: stopped in /usr/src/share
*** Error code 1
Stop.
bmake[3]: stopped in /usr/src
*** Error code 1
Stop.
bmake[2]: stopped in /usr/src
*** Error code 1
Stop.
bmake[1]: stopped in /usr/src
*** Error code 1
Stop.
make: stopped in /usr/src
.ERROR_TARGET='installworld'
.ERROR_META_FILE=''
.MAKE.LEVEL='0'
MAKEFILE=''
.MAKE.MODE='normal'
_ERROR_CMD='.PHONY'
.CURDIR='/usr/src'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/amd64.amd64'
.TARGETS='installworld'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20181221'
PATH='/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src/amd64.amd64'
It looks likes sort coredumps in the usr/share/zoneinfo part of the base.
As it has no permission on the NFS share it errors out.
On the server itself, the installworld goes well, but it leaves a
sort.core file behind in /usr/share/zoneinfo
cd /usr/share/zoneinfo
ls -al
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe,
PCIe NVME drives not detected on Dell R6515
I already asked on stable@ but as I tried it on 13-CURRENT with the same result I am trying to ask for help here. I have rented dedicated server Dell PowerEdge R6515 with iDRAC access only. There are 2 NVME drives which I wanted to use as ZFS root pool. They are shown in iDRAC Device Description: PCIe SSD in Slot 1 in Bay 1 Device Protocol: NVMe-MI1.0 Model:Dell Express Flash NVMe P4510 1TB SFF Bus: 130 Manufacturer: INTEL Product ID: a54 Revision: VDV1DP23 Enclosure:PCIe SSD Backplane 1 pciconf -l show many things, some of them are named "noneN@pci..." but none "nvme" The is printscreen (12.1 but 13-CURRENT is the same) https://ibb.co/tPnymL7 But I booted Linux SystemRescueCd and nvme devices are there visible in /dev/ https://ibb.co/sj22Nwg There is verbose output of Linux lspci https://ibb.co/dPZTwV1 Linux dmesg contains: nvme nvme0: pci function :81:00.0 nvme nvme1: pci function :82:00.0 nvme nvme0: 32/0/0 default/read/poll queues nvme nvme1: 32/0/0 default/read/poll queues The machine is Dell PowerEdge R6515 with AMD EPYC 7302P More details extracted from iDRAC web interface I found this informations PCIe SSD in Slot 1 in Bay 1 Bus: 82 BusProtocol: PCIE Device: 0 DeviceDescription: PCIe SSD in Slot 1 in Bay 1 DeviceProtocol: NVMe-MI1.0 DeviceType: PCIeSSD DriveFormFactor: 2.5 inch FailurePredicted: NO FQDD: Disk.Bay.1:Enclosure.Internal.0-1 FreeSizeInBytes: Information Not Available Function: 0 HotSpareStatus: Information Not Available InstanceID: Disk.Bay.1:Enclosure.Internal.0-1 Manufacturer: INTEL MaximumCapableSpeed: 8 GT/s MediaType: Solid State Drive Model: Dell Express Flash NVMe P4510 1TB SFF NegotiatedSpeed: 8 GT/s PCIeCapableLinkWidth: x4 PCIeNegotiatedLinkWidth: x4 PrimaryStatus: Ok ProductID: a54 RaidStatus: Information Not Available RAIDType: Unknown RemainingRatedWriteEndurance: 100 % Revision: VDV1DP23 SerialNumber: PHLJxxWF1PN SizeInBytes: 1000204886016 Slot: 1 State: Ready SystemEraseCapability: CryptographicErasePD PCIe SSD in Slot 1 in Bay 1 - PCI Device BusNumber: 130 DataBusWidth: 4x or x4 Description: Express Flash NVMe 1.0 TB 2.5" U.2 (P4510) DeviceDescription: PCIe SSD in Slot 1 in Bay 1 DeviceNumber: 0 DeviceType: PCIDevice FQDD: Disk.Bay.1:Enclosure.Internal.0-1 FunctionNumber: 0 InstanceID: Disk.Bay.1:Enclosure.Internal.0-1 LastSystemInventoryTime: 2020-04-17T03:21:39 LastUpdateTime: 2020-03-31T13:55:06 Manufacturer: Intel Corporation PCIDeviceID: 0A54 PCISubDeviceID: 2003 PCISubVendorID: 1028 PCIVendorID: 8086 SlotLength: 2.5 Inch Drive Form Factor SlotType: PCI Express Gen 3 SFF-8639 Can anybody shed some light what the real problem is? Is the hardware not properly detected or is the driver completely missing? NVME PCIe architecture is out of my knowledge. I really appreciate any help. Kind regards Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sort.core error doing installworld on Current.
Op 17-04-2020 om 13:30 schreef Johan Hendriks:
Op 17-04-2020 om 12:47 schreef Rodney W. Grimes:
Op 17-04-2020 om 03:31 schreef Rodney W. Grimes:
On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman
wrote:
So you some how had a sort core dump sitting in
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The
questions, how
did get there? I'd take a look at the date on the file and, it
it is older
than the buildworld, just assume that it was left-over garbage.
In either
case, you can delete it and do another installworld.
That should most likely fix things, but, if the buildworld or
installworld
had a crash of sort(1) that left the file, further investigation
might be
needed. Re-making the zoneinfo would help track it down should
this be a re
al bug, but it's my uneducated guess that it's not.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Please forgive that awful post! I missed a part of your message
by laziness.
It's odd that the error of sort(1) crashing was not caught by the
script.
Yes, that is a Makefile flaw someplace.
Further there must be a wildcard being used to decide which files to
install, that is a further Makefile flaw. Wildcards should NOT be
used
in the source of an install list, exactly because of this type of
cruft
that can be dropped in an obj dir.
From src/share/zoneinfo/Makefile at about line 93:
92 if make(*install*)
93 TZS!= cd ${TZBUILDDIR} && find * -type f | LC_ALL=C sort
this is a very bad thing to do
in a Makefile.
94 .endif
Now I still don't know why sort cored, but I am sure this is the line
that did it.
Clearly, sort should NOT crash! Again, a re-build of zoneinfo
might catch
something. Looking at the core might tell you which "sort" was
involved...
the one you just built or the one in the base system. This could
be just a
FOTU, but I would not bet on it.
I suspect a recent zoneinfo commit as the root cause.
I have no idea how to bypass this issue.
I have used sort from the latest snapshot and placed that file on the
system and in the build dir, but i keep getting the core
How can i test an build and install part for zoneinfo
If i go into the dir /usr/src/share/zoneinfo and do make install it
does
not work, do i need to add something?
Can you show us the output from
cd /usr/src/share/zoneinfo
make clean && make depend && make all && make install
Someplace in that we should get to see sort crashing...
On both machines my src.conf file is the same.
I will start over from a clean world by doing a make cleanworld and
see if it then still gives the errors
Maybe some old artifacts are hanging around.
Thank you both for your time
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks
wrote:
I have a machine running FreeBSD head.
rev 13.0-CURRENT #11 r360008
This is a quite powerful machine, so i thought it was a good
idea to let
that server do the build and for my virtualbox machine i can
use the
powerful machine to do a installword over NFS.
But when i did the make installworld step the client so to say
gives an
error.
install -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu
/usr/share/zoneinfo/Zulu
install -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules
/usr/share/zoneinfo/posixrules
install -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core
/usr/share/zoneinfo/sort.core
install:
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core:
Permission denied
*** Error code 71
Stop.
bmake[5]: stopped in /usr/src/share/zoneinfo
*** Error code 1
Stop.
bmake[4]: stopped in /usr/src/share
*** Error code 1
Stop.
bmake[3]: stopped in /usr/src
*** Error code 1
Stop.
bmake[2]: stopped in /usr/src
*** Error code 1
Stop.
bmake[1]: stopped in /usr/src
*** Error code 1
Stop.
make: stopped in /usr/src
.ERROR_TARGET='installworld'
.ERROR_META_FILE=''
.MAKE.LEVEL='0'
MAKEFILE=''
.MAKE.MODE='normal'
_ERROR_CMD='.PHONY'
.CURDIR='/usr/src'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/amd64.amd64'
.TARGETS='installworld'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20181221'
PATH='/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src/amd64.amd64'
It looks likes sort coredumps in the usr/share/zoneinfo part of
the base.
As it has no permission on the NFS share it errors out.
On the server itself, the installworld goes well, but it leaves a
sort.core file behind in /usr/share/zoneinfo
cd /usr/share/zoneinfo
ls -al
___
freebsd-current@freebsd.org mailing list
