On Wednesday, 23 March 2022 10:30:59 EDT andy pugh wrote: > On Wed, 23 Mar 2022 at 13:50, Mark Wendt <[email protected]> wrote: > > ./configure --help should give you all the options for that > > particular > > version of configure. > > andypugh@buster:~/linuxcnc-dev$ ./debian/configure --help > configure: Set up debian/ files to build for a particular kernel > > Usage: > configure uspace [noauto | rtai | rtai=packagename | xenomai] ... > Build for a userspace realtime systems or simulator > > configure sim > Deprecated synonym for 'configure uspace' > > configure [kernel-version] > Build for the installed RTAI realtime kernel specified by > [kernel-version], for example "3.4.9-rtai-686-pae" > > configure -r > Build for the currently running kernel for RTAI realtime only > > configure -a > If the currently running kernel has realtime extensions, use > it. Otherwise use any available realtime kernel it can find. > > I have a feeling that this is mentioning RTAI in rather more places > than it should.
So do I Andy. but don't know enough to point a finger at it. But I have a different problem this morning that a google search hasn't hit. History: dd installed an early 2019 buster image to a 64G u-sd card. put it in my pi, edited /etc/avahi.conf to get rid of any mention of 169.254 addresses in order to make networking work by gettiing rid of a 1st route to that address so mine could take effect. ran apt uptdate;apt upgrade to update about 255 pkgs to todays buster status. I had previously tried to install my 4.19.71-rt24 kernel I'd built a couple years ago but that locked the boot on the square rainbow, several times. So I dd'd my working /boot directory from a live system to a file, brought that file to this machine and dd'd it back to the boot partition overwriting everything there with the same stuff from a running system. checked both partitions with dosfsck for the 253 meg /boot fixed its backup and boot flags, looked good to an ls -l when mounted. fsck.ext4 is happy with the second partition so no damage there... unmount card, take to my running system, pull the plug and change to the card I just spent a day yesterday prepareing and failing to boot. boots to the 4 raspberries in the upper left corner, and green activity led goes dark and ceases its flickering. Its stuck forever. And google knows zip about this failure. Ditto the raspi-forum, which I can read, but because they don't like realtime kernels, my posts are dropped into /dev/null. Has anybody here ever encountered this boot failure on a pi4? Is there a way using /boot/cmdline.txt to generate a boot log that will stay on the card for later failure snooping via a card reader? I can get you anything you want to see. If the group has a deb that will install that rt kernel, or of a later one known to work, plz give me a link to your version as a deb. After about a week trying to make another card like I'm running my Sheldon from, I'm out of ideas. Thanks all. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
