Page 71 of 73
Posted: Sat 09 Nov 2019, 17:48
by rufwoof
sc0ttman wrote:A simple "main menu" or "welcome menu" ncurses script, which offers easy ways to run various system tools (puppy-config stuff I mentioned above), or recovery scripts (fsck, etc) would make the CLI/terminal experience in Puppy about as easy as any other distro.
.. Kind of separately..
It would be great to have ncurses working as early in the boot process as possible, although I've no idea if it can work in the initrd.
I am biased but if nrcurses does work in the initrd, I'd like to see Pkg (and ncurses) work even from inside the initrd, so that Pkg (and Pkgdialog) can be used even before mounting the main filesystem (rootfs)...
Just recompiled the kernel config I'm using with that ncurses menu included as a dynamically linked (i.e. copied over the bin as-is and also copied over the libs) and that booted/ran ok. That was within initrd, i.e. was run within a setsid cttyhack child process within init, that when exited out of resumes pid 1 (normal init/console). The reason I use the setsid cttyhack for tty/pseudo terminal is to enable job control (screen/background tasks etc.) that otherwise (console) isn't available. I originally coded that ncurses menu to just show the menu, and exit with a exit string of whatever option was selected, and I have a wrapper script that loops around showing the menu, trapping the selected return text (requested action string) in a case statement, and launching the associated action for that, before re-showing the menu again. As-is that menu is fixed (as compiled into the C program), but relatively easy to change and recompile. With the ncurses program and libs added it expanded the vmlinuz to 12MB (around 360KB larger compared to without the ncurses program/libs).
That is without mouse point/click functionality. You have to (the way it is coded i.e. mirrors mc type controls) press F9 to activate the menu and then the first letter of whatever highlighted choice you want to run, or use the arrow keys to navigate/enter to select.
Fatdog has slapt-get cli based package manager alongside gslapt (gui based package manager), so along with wifi net connected I guess that could also be run within init. However I haven't actually tried that.
My vmlinuz is compiled to be very machine specific, but no reason why that couldn't be bloated out by including modules/firmware for a wide range of hardware. Doing so however would expand the size considerably and in that case it would perhaps be best to have initramfs_data.cpio (initrd) outside of vmlinuz. I suspect however that you'd be looking at something like a 80MB system. At that sort of size you might as well just use a bare-bone type puppy as a early stage init boot (something like a xvesa type puppy), do whatever configuration/action you desired within that before exiting to resume init/pid 1 and boot the main/full puppy.
Posted: Sat 16 Nov 2019, 13:15
by mistfire
Some woof-ce accomplishements this 2019
* Improved package management and sfs loading
* Improved PTP and MTP support
* Improved puppy core apps gui
* Improved disk image file mounting
* XDG Desktop compliance
* Improved touchpad support
* Added non-acpi support
Posted: Mon 25 Nov 2019, 15:38
by rockedge
At the moment using the kernel-kit to produce a 5.2.21 SMP PREEMPT RT kernel and I am running into this error immediately
Code: Select all
./funcs.sh: line 7: vercmp: command not found
I am running Bionic64-v8 with a kernel 4.19.25-rt16 #1 SMP PREEMPT RT
and I do not have the command
vercmp on board. Nor do I see a way to get it...so please let me know how to include this command or can I bypass the function?
Posted: Mon 25 Nov 2019, 18:26
by mikeslr
vercmp is not in the Ubuntu repos. Per Arch, it is a version comparison utility.
https://www.archlinux.org/pacman/vercmp.8.html, Distros employing it seem to be few and far between.
https://pkgs.org/download/vercmp;
https://pkgs.org/download/filevercmp. See also,
https://github.com/diorahman/vercmp. They do not appear to be either arch or kernel specific.
And perhaps the idea for a work-around,
https://unix.stackexchange.com/question ... en-version
As always, the information I transmit may be entirely misleading.
Posted: Mon 25 Nov 2019, 18:53
by rockedge
hello mikeslr,
I think I know what is happening and why vercmp did not work on one Bionic64 and does on another. Some thing in the save folder is eliminating or while listing it. I was able to compile a kernel 5.2.21 just now successfully and am now looking into the patches needed to build this as a true real time kernel.
The goal is to create a Puppy Linux that can run LinuxCNC in it's full capacity and direct CNC machines. Although so far there are errors still during compiling LinuxCNC, it is getting closer. I am using for that kernel 4.19.27-rt16 SMP PREEMPT RT right now but if successful in building a newer version 5 real time kernel I will use it.
Posted: Mon 13 Jan 2020, 08:45
by BarryK
I was very surprised today. Those of you who have been developing with Puppy for many years will probably know about "PuppyHardwareProfile" for /etc/X11/xorg.conf, which, in a nutshell, handles booting a usb-stick on different PCs, with different video chips and monitors.
Yesterday I have enhanced this a bit in woofQ, my fork of Woof2, and then I looked at woof-CE on github, and it seems that PuppyHardwareProfile was removed in 2016.
See my blog post:
https://bkhome.org/news/202001/improved ... -xorg.html
Has hardware-profiling for Xorg been moved or implemented in some other way in woof-CE, or is it really gone?
Posted: Mon 13 Jan 2020, 11:49
by peebee
BarryK wrote:I was very surprised today.
Has hardware-profiling for Xorg been moved or implemented in some other way in woof-CE, or is it really gone?
https://github.com/puppylinux-woof-CE/w ... a6e297a152 of 20-Jun-2016
says:
xwin: logic to replace xorg hardware profiles
This attemps to replace the hardware profiles stuff
based on ddcprobe.
The xorg.conf-auto-pc template is good enough..
it's pretty generic and very specific to puppy,
so it can work with a variety of
hardware from a 1997 video card to a 2016 one.
This new logic will attemp to run X a second time
if it fails the first time
(falling back to a generic template..)
If the system does not crash after that
then there's a chance to run xorgwizard...
Posted: Mon 13 Jan 2020, 14:49
by BarryK
peebee wrote:BarryK wrote:I was very surprised today.
Has hardware-profiling for Xorg been moved or implemented in some other way in woof-CE, or is it really gone?
https://github.com/puppylinux-woof-CE/w ... a6e297a152 of 20-Jun-2016
says:
xwin: logic to replace xorg hardware profiles
This attemps to replace the hardware profiles stuff
based on ddcprobe.
The xorg.conf-auto-pc template is good enough..
it's pretty generic and very specific to puppy,
so it can work with a variety of
hardware from a 1997 video card to a 2016 one.
This new logic will attemp to run X a second time
if it fails the first time
(falling back to a generic template..)
If the system does not crash after that
then there's a chance to run xorgwizard...
Yes, but falling back to a "generic template" is not hardware-profiling -- it is what we had prior to 2007 before hardware-profiling was introduced.
If someone modifies xorg.conf and the files in xorg.conf.d, for booting on a particular PC, that is likely to be inappropriate when boot on another PC.
If you then go to the trouble of configuring xorg.conf and xorg.conf.d on the second PC, then it won't work on the first.
As far as I can see, looking around on woof-CE, Xorg effectively no longer has hardware profiling.
Posted: Mon 13 Jan 2020, 15:37
by s243a
BarryK wrote:I was very surprised today.
Has hardware-profiling for Xorg been moved or implemented in some other way in woof-CE, or is it really gone?
https://github.com/puppylinux-woof-CE/w ... a6e297a152 of 20-Jun-2016
says:
xwin: logic to replace xorg hardware profiles
This attemps to replace the hardware profiles stuff
based on ddcprobe.
The xorg.conf-auto-pc template is good enough..
it's pretty generic and very specific to puppy,
so it can work with a variety of
hardware from a 1997 video card to a 2016 one.
This new logic will attemp to run X a second time
if it fails the first time
(falling back to a generic template..)
If the system does not crash after that
then there's a chance to run xorgwizard...
Yes, but falling back to a "generic template" is not hardware-profiling -- it is what we had prior to 2007 before hardware-profiling was introduced.
If someone modifies xorg.conf and the files in xorg.conf.d, for booting on a particular PC, that is likely to be inappropriate when boot on another PC.
If you then go to the trouble of configuring xorg.conf and xorg.conf.d on the second PC, then it won't work on the first.
As far as I can see, looking around on woof-CE, Xorg effectively no longer has hardware profiling.
I like knowledge on this issue but I do wonder if there is anything useful here:
mistfire wrote:@thinkpadfreak I implemented autoconfig because of my experiences of using puppy across different computers with save file loaded. It will only trigger when tazpuppy detects changes on hardware setup such as changing video cards or display monitors when the computer booting up. This makes TazPuppy a truly portable OS.
[url]
http://murga-linux.com/puppy/viewtopic. ... 73#1009440[\url]
or perhaps the old puppy way of doing it was better than whatever mistfire implemented in tazpup? I don't know so I'll let the experts discuss
Posted: Mon 13 Jan 2020, 17:00
by jamesbond
s243a - you had a wrong closing url tag.
Here is your post, when the closing tag has been fixed.
s243a wrote:BarryK wrote:I was very surprised today.
Has hardware-profiling for Xorg been moved or implemented in some other way in woof-CE, or is it really gone?
https://github.com/puppylinux-woof-CE/w ... a6e297a152 of 20-Jun-2016
says:
xwin: logic to replace xorg hardware profiles
This attemps to replace the hardware profiles stuff
based on ddcprobe.
The xorg.conf-auto-pc template is good enough..
it's pretty generic and very specific to puppy,
so it can work with a variety of
hardware from a 1997 video card to a 2016 one.
This new logic will attemp to run X a second time
if it fails the first time
(falling back to a generic template..)
If the system does not crash after that
then there's a chance to run xorgwizard...
Yes, but falling back to a "generic template" is not hardware-profiling -- it is what we had prior to 2007 before hardware-profiling was introduced.
If someone modifies xorg.conf and the files in xorg.conf.d, for booting on a particular PC, that is likely to be inappropriate when boot on another PC.
If you then go to the trouble of configuring xorg.conf and xorg.conf.d on the second PC, then it won't work on the first.
As far as I can see, looking around on woof-CE, Xorg effectively no longer has hardware profiling.
I like knowledge on this issue but I do wonder if there is anything useful here:
mistfire wrote:@thinkpadfreak I implemented autoconfig because of my experiences of using puppy across different computers with save file loaded. It will only trigger when tazpuppy detects changes on hardware setup such as changing video cards or display monitors when the computer booting up. This makes TazPuppy a truly portable OS.
http://murga-linux.com/puppy/viewtopic. ... 73#1009440
or perhaps the old puppy way of doing it was better than whatever mistfire implemented in tazpup? I don't know so I'll let the experts discuss
Posted: Mon 13 Jan 2020, 17:12
by jamesbond
BarryK wrote:Yes, but falling back to a "generic template" is not hardware-profiling -- it is what we had prior to 2007 before hardware-profiling was introduced.
If someone modifies xorg.conf and the files in xorg.conf.d, for booting on a particular PC, that is likely to be inappropriate when boot on another PC.
If you then go to the trouble of configuring xorg.conf and xorg.conf.d on the second PC, then it won't work on the first.
As far as I can see, looking around on woof-CE, Xorg effectively no longer has hardware profiling.
Correct, but the counter-point is:
a) these days autoconfig works reliably, there is very little need to manually edit xorg.conf
b) sometimes different machines have GPU with the same name (as detected by hardware-profiler) but requires different configuration, so in that case the hardware profile is a hindrance rather than help (as mistfire said).
If you still want to hardware profile, the it is probably better to profile based on machine-id (machine serial number and/or UUID) as returned by dmi-decode, rather than using GPU names. Of course, this still not foolproof and has its own set of problems: what if the owner changes the GPU card, etc; plus it doesn't work on ARM boards that don't have "dmi-decode", etc.
Posted: Mon 13 Jan 2020, 23:13
by BarryK
jamesbond wrote:BarryK wrote:Yes, but falling back to a "generic template" is not hardware-profiling -- it is what we had prior to 2007 before hardware-profiling was introduced.
If someone modifies xorg.conf and the files in xorg.conf.d, for booting on a particular PC, that is likely to be inappropriate when boot on another PC.
If you then go to the trouble of configuring xorg.conf and xorg.conf.d on the second PC, then it won't work on the first.
As far as I can see, looking around on woof-CE, Xorg effectively no longer has hardware profiling.
Correct, but the counter-point is:
a) these days autoconfig works reliably, there is very little need to manually edit xorg.conf
b) sometimes different machines have GPU with the same name (as detected by hardware-profiler) but requires different configuration, so in that case the hardware profile is a hindrance rather than help (as mistfire said).
If you still want to hardware profile, the it is probably better to profile based on machine-id (machine serial number and/or UUID) as returned by dmi-decode, rather than using GPU names. Of course, this still not foolproof and has its own set of problems: what if the owner changes the GPU card, etc; plus it doesn't work on ARM boards that don't have "dmi-decode", etc.
Many people run the xorgwizard, because video either misbehaves or even not work at all.
An example of misbehaving, is that Xorg may automatically choose 'sna' video acceleration, but that may be very flakey, even causing hanging. The xorgwizard in EasyOS allows to switch between 'sna' and the older 'uxa' video acceleration.
So, the person then boots up on another PC, and xorgwizard has hard-coded the intel driver to use 'uxa', and that might not even work. So they run the xorgwizard and change it to 'sna'.
Another example is screen resolution. This may be hard-coded, as often the automatic choice is wrong. Same problem when boot on another PC.
I agree that the hardware-profile string could be improved. I have some thoughts on that. For example, obtain the IDs of the GPU:
Code: Select all
# lspci -d ::0300 -n | cut -f 3 -d ' '
8086:5a85
...would that work on arm boards?
Posted: Tue 14 Jan 2020, 03:56
by ozsouth
Having had the video issue BK describes on 2 very different pcs, I set modesetting driver as default on generic isos. Can still have occasional issues.
Posted: Tue 14 Jan 2020, 07:32
by jamesbond
BarryK wrote:I agree that the hardware-profile string could be improved. I have some thoughts on that. For example, obtain the IDs of the GPU:
Code: Select all
# lspci -d ::0300 -n | cut -f 3 -d ' '
8086:5a85
...would that work on arm boards?
Unfortunately, no. Most ARM boards don't have PCI bus, so using lspci won't work. But it has been a while since I work with ARM boards, so things may have changed.
Posted: Tue 14 Jan 2020, 10:22
by BarryK
jamesbond wrote:BarryK wrote:I agree that the hardware-profile string could be improved. I have some thoughts on that. For example, obtain the IDs of the GPU:
Code: Select all
# lspci -d ::0300 -n | cut -f 3 -d ' '
8086:5a85
...would that work on arm boards?
Unfortunately, no. Most ARM boards don't have PCI bus, so using lspci won't work. But it has been a while since I work with ARM boards, so things may have changed.
Ditto. I vaguely thought they didn't have pci bus, but can't really remember. I will have to fire up my RPi3.
But hardware profiling doesn't really matter on an arm board, as you would usually have a build of Puppy that only works on a particular type of board. Different monitors though.
Or a family of boards, such 01micko's RasPup, works on all the RiPis.
Posted: Tue 14 Jan 2020, 10:31
by BarryK
ozsouth wrote:Having had the video issue BK describes on 2 very different pcs, I set modesetting driver as default on generic isos. Can still have occasional issues.
Yeah, that's another example. I have three desktop PCs and three laptops, all of them have Intel GPUs, and Xorg chooses the 'intel' driver on some, the 'modesetting' driver on the others.
This automatic choice is not always what you want, hence you run the xorgwizard.
Once you have run the xorgwizard, or selected a video resolution other than the default, you have locked-in to that video hardware.
Then you boot your usb-stick on another computer, and your video has a good likelihood of being broken.
Hence, the dropping of PuppyHardwareProfile in 2016, was a bad move.
EDIT:
Keyboard layout is another example. People who work in international environments might use PCs with different keyboards. Choosing a particular keyboard layout is another thing that locks you in to that hardware, and your keyboard will be wrong when you boot on another PC. PuppyHardwareProfile fixed that.
Posted: Tue 14 Jan 2020, 13:52
by Smithy
There are definitely some issues with the new video methods on intel (GMA 3000 I think).
I am getting a streak on the monitor and a lot of the time the puppy starts but then the monitor goes blank, makes an attempt to come on again, then goes off again at the final boot stage.
I can hear the monitor giving a little squeal as it turns on and off.
Eventually after resets, it seems to tune to the new puppy (no saves, just straight ram boot).
That is on 64 bit Dpup Buster, but I noticed problems on Bionic 64, but also newer 32 bitters.
I replaced the bios battery, thinking it was that, but the issue seems to affecting the bios and auto monitor?
Also that dialogue comes up sometimes that offers choices like "Do nothin, carry on" 2. set video etc.
Well I would rather it just carries on without that dialogue, like it used to!
Not sure if this is all related to the developments in WoofCE, and it is an older dual core board, but I don't want
the intel chip to potentially suffer damage.
This bios doesn't have UEFI (or I have turned CMS off) and is
Vendor : Intel Open Source Technology Center
Renderer: Mesa DRI Intel(R) Sandybridge Desktop x86/MMX/SSE2
Version : 3.0 Mesa 17.2.2
Direct Rendering: Yes
Note: The above renderer has worked extremely well for a long time.
Will have to check what the renderer says in Buster and Bionic.
I don't want to create any red herrings here, just an experience with this type of computer.
Posted: Tue 14 Jan 2020, 18:40
by rockedge
what kernel are you using ?
Posted: Tue 14 Jan 2020, 19:42
by Smithy
Hi rockedge, I was using the provided kernel in Joseph DPup Buster 4.19, then I flipped it to 4.4.52-rt63 (fatdog jamesbond).
Changed it to see if the newer kernel and drivers could be causing the problem.
I'll reset the bios at some point to see if I can get rid of the streak.
I think that did work a while ago when I was messing with various puppies.
Posted: Fri 17 Jan 2020, 11:35
by Smithy
Following up on this:
I removed bios battery, reset the jumper, reseated the ram.
CSM Compatibility Support Module permits the loading of a traditional operation system.
Enable to support Non-UEFI operation system
Disable to support Win8 64 bit and later UEFI aware operation system.
So I disabled the CSM, upshot is the pixellated video streak across the monitor has gone now.
The Intel renderer is 3.0 Mesa 18.3.6 64 bit. Will test Jose Dpup Buster 64 bit for a while, but so far so good.
Pulse Audio is interesting in that you can whack the volume up to 11db increase and no distortion, (vlc 3.08)
maybe it has a brickwall limiter in it.
Just in case this is a woof ce issue, running the firewall setup has a couple of rule append errors- invalid argument.
Tray button just seems to overwrite taskbar menu fixes in jwm (duplicated menu button) but not sure how that thing works (xdg?)
Openbox right click menu bjorked (as an alternative to jwm) again xdg refresh problem or something?