Re: Removing extsrc: (was Re: Proposal: Deprecate (or rename) extsrc/)
lukem@ wrote: > | (Also, if I recall correctly, "extsrc/" without much consultation). There was a proposal on tech-toolchain: https://mail-index.netbsd.org/tech-toolchain/2009/11/29/msg000790.html but I could not imagine a typical usecase at that time. > I only received support for removing extsrc. > There were no comments to retain as-is or to retain with a different > directory name. I agree name-complete conflicts are always annoying and I'd also favor your proposal. Thanks, --- Izumi Tsutsui
Removing extsrc: (was Re: Proposal: Deprecate (or rename) extsrc/)
On 22-01-07 12:47, Luke Mewburn wrote: | I propose that we deprecate or remove the "extsrc/" tree, | as the name name-complete conflicts with "external/". | | The "external/" tree was added in mid 2008. | A lot of the in-tree third-party source is now in this tree, | and developers need to traverse this tree a lot. | | The "extsrc/" tree was added in late 2009. | Nothing in tree uses "extsrc/"; it's a placeholder for third-party | vendors to hook into the build for their own extensions. | There's no reason a vendor can't just integrate into the build | with local changes - that's what Wasabi Systems did in the early 2000s. | | (Also, if I recall correctly, "extsrc/" without much consultation). | | If some people require the "extsrc/" functionality in tree, then I propose: | 1) A good case to retain the functionality should be made by them. | 2) A better name than "extsrc/" should be chosen, that's not |going to cause completion rage. Maybe "3rdparty"? I only received support for removing extsrc. There were no comments to retain as-is or to retain with a different directory name. As such, I propose to completely excise extsrc from the build. This includes: 1. Makefile: remove do-extsrc target. 2. build.sh: remove options -y and -Y extsrcdir . 3. distrib/sets: remove support for extsrc in various tools including the options -L ext and -y, and the extsrc sets. 4. bsd.own.mk, (etc.): remove support for extsrc/, EXTSRCSRCDIR, MKEXTSRC. 5. BUILDING: remove docs for extsrc/, EXTSRCSRCDIR, MKEXTSRC, ... 6. extsrc/: remove the directory. I'll do this in the next few days. Luke. signature.asc Description: PGP signature
Re: [SUCCESS] Debugging/fixing a kernel stalled not crashing
A final point: Context: I rent a baremetal server (OVH) that has an Intel Xeon quadcore, IvyBridge, with 16Gb of RAM, 3 2TB disks, an Intel PRO 1000 ethernet card (but the bandwith is limited to 100Mib). It is an entry level offer, that I wanted only for an IPv4 address (there is an IPv6 address too). The images to install include no BSD but only Linux/Debian variants. Following instructions from an helpful wiki page, I try to install using a Linux rescue disk (provided by OVH), running all in memory, and having qemu-system-x86_64 allowing to use a CDROM install image. Nothing booted. Since it was unclear from the web interface if the boot process was depending or not on the information about an image being installed (to allow booting from the disk), I then installed a Linux/Debian on only one disk (one can select, 1, 2 or 3 disks, but if multiple disks this is software RAID). Using the rescue system, I then resized the Debian partition and installed NetBSD on another partition (dual booting) and, to bypass a possible limitation in the booting process (only booting GRUB and accessing directly GRUB), I chainloaded the NetBSD stage1 from the GRUB2 menu, and verified, under qemu, this will boot, using GRUB2 boot once feature so that if the NetBSD crashed and reboots, I can go back to Debian to try something else. Still no success. It was almost certain there was a problem with the kernel. So I wrote a special /boot.cfg to test various things, custom compiling a kernel (since the GENERIC installation one was not running), and tried to validate step by step the booting procedure in order to try, after to insert a cpu_reboot() instruction in the kernel to see where the problem occurred (since when rebooting, I will be able to connect to Debian, I would have known that before the instruction, it was OK). In order to limit the work, I used once more qemu but to install NetBSD on another disk (so that I can in fact use qemu not with the rescue system, but directly under Debian without trashing the very disk Debian runs from). The first test was to see if, indeed, NetBSD stage2 was loaded. The menu in /boot.cfg was simple: the instruction "quit". => First lesson: this does not work, because the rebooting is not a total one, and mapping the drives (in GRUB2) to ensure that the booting succeeds, the stage2 reboots but finally back to itself, so the machine was unendlessly rebooting and I had no connection. It took me various modifications before realizing it was the case (under qemu) so I abandonned the idea and tried to boot a custom kernel, without SMP and without framebuffer (i915drmkms). This succeeded. I then get back to test letting the framebuffer. It didn't work. I then disable the framebuffer for everything, and tried with SMP. It worked. Then, I tried 9.2 GENERIC and 9.3 GENERIC without framebuffer. Both work. So the final lesson: NetBSD can be installed on such machine but the framebuffer is a problem. And NetBSD is not far behind Linux, because the Debian distribution is a recent one, and the main clue was in the Linux dmesg: Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-14-amd64 root=UUID=eea6d0a4-03b6-44e6-8588-ff6c4eba2095 ro nomodeset iommu=pt The: nomodeset. Linux doesn't work with the embedded graphics (HD 4000) either. So it is partly a kernel problem (kernel stalling with framebuffer initializations) but mainly an install problem (framebuffer in such cases should be disabled). If someone thinks there can be interest in how I set dual booting, chainloading NetBSD from GRUB2, and configuring the boot procedure, I can write a mini-page about it. For the rest: problem solved. NetBSD can install on an OVH baremetal (at least this kind of machine). -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[PARTIAL SUCCESS] Debugging/fixing a kernel stalled not crashing
Le Thu, Aug 18, 2022 at 04:33:04PM +0200, tlaro...@polynum.com a écrit : > Context: I rent a baremetal server and try to install NetBSD on it. I > finally installed a Linux (Debian) and installed NetBSD as a dual boot. > But NetBSD doesn't come up (in case there was a > network misconfiguration, I verified that no log, no dmesg was written) > and neither does it crashes and reboots (because I use GRUB2 boot once > feature and, if it was the case, the server will go back to Debian, and > it doesn't). > So: - I have installed a Linux/Debian and I'm using GRUB2 to chainload the stage1 block in order to load the NetBSD kernel, using the booting once feature of GRUB2 so that if something goes wrong, I can go back to the Linux/Debian; - I have set (since I can see nothing of the boot process) a /boot.cfg with several choices, and set the default in order from the chainloading done by GRUB2 to try various things (since I haven't found the possibility to mount ffs rw under Linux, I use qemu-system-x86_64, under Debian, to write and modify the NetBSD partitions); - The machine is an Intel Xeon, quadcore, IvyBridge. Since the GENERIC kernel does not boot, I have compiled a custom 9.3, stripping all unneeded, and adding this feature (commented out in the GENERIC config): acpismbus* at acpi?# ACPI SMBus CMI (experimental) since from x86/pci/imcsmb/imc.c, there are some pecularities about the (Sandy,Ivy)bridge with the Xeon. Disabling the framebuffer (i915drmkms) via userconf, and disabling the SMP, NetBSD boots on the machine. The dmesg is here: http://downloads.kergis.com/misc/rpt_netbsd9.3_monocore_no-fb.dmesg Since I fought quite a lot with Debian, GRUB2 and so on for the installation and the boot process, I have to verify if an SMP version of the same does boot or not. If an SMP does not boot, I will go back to the list to have tips about how I can best gain informations about what's going wrong in order to try to fix or help to fix it. -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
