Posted: Mon 09 Jun 2014, 01:58
No Wonder! duh!
READ-ONLY Archive
https://oldforum.puppylinux.com/
Actually (James) with all different kernels per puppy and multiple puppies, using the generic vmlinuz and modules.sfs can be a problem. Symlinks would be a solution but we install in (V)FAT too...Just make sure you rename your kernel image to vmlinuz and the module sfs to kernel-modules.sfs
No, no cooked machine unless your machine's thermal protection is faulty.Well, I don't think jobs are the same as threads.. I should have commented it however I have been using -j6 forever on my athlon X2. Cooked machine is a possibility but more likely is the thermal cut out protection.
Agreed. Just to note that build-iso.sh is a quick and dirty scriptActually (James) with all different kernels per puppy and multiple puppies, using the generic vmlinuz and modules.sfs can be a problem. Symlinks would be a solution but we install in (V)FAT too...
I think you mean "put modules.sfs" in initrd. Yes, this is an option, this is what I actually do for Fatdog64/FatdogArm/XOpup. But note: putting it in initrd means it will stay in RAM. This may or may not be a good thing:put the kernel in the initrd (as in FD_ARM/XOpup
If there enough RAM, yesjamesbond wrote: One thing I didn't check when I put the modules.sfs into ZDRV - does ZDRV gets copied to RAM too at boot time? If not, that means when you use CD to boot it, the CD can't be taken out.
Depends where you lookNG does mean "Next Generation" - as you can see from "samba-tng", "util-linux-ng", and many other examples
Ah, that's because xorg hotplugging is *NOT ENABLED* in puppy. The ones built with deb-build does work (if you also apply the pinstall.sh patches from rootfs). For others, what stemsee says is quite interesting, here's what Arch has to say about it: https://wiki.archlinux.org/index.php/Multi-pointer_X.xinput installed on puppy results in # xinput list commmand showing one mouse0 and keyboard0, the same command on L64 and all other linux distros results in a list of input devices as seen in hardinfo - input . a 'Master' is the head to which are attached the first keyboard and mouse and all other input devices. By creating a second master xinput allows you to attach to it a second keyboard and mouse which gives another pointer that acts indepedently of the first as in multi-touch. You can of course create several masters with several pointers and keyboards etc. It may be possible still to 'bind' a master to a display/screen/desktop. Which is useful for me and my family to share one pc with extra displays keyboard and mice = pseudo multi-seat without nested servers = accelerated graphics and much better performance. Not for most people's usage I know.
LOL--if suffix is -nfg then you absolutely know it's no good
No. What we usually do when we build the modules.sfs is something like thisPS @jamesbond. re kernel-kit. Do you have a script for getting kernel firmware and cutting out inappropriate bloat?
Code: Select all
# in kernel source, after completion of make oldconfig
make -j6 bzImage modules
make modules_install INSTALL_MOD_PATH=./modules
cp -a /lib/firmware modules
mksquashfs modules kernel-modules.sfs -comp xz -Xbcj x86
Code: Select all
# in kernel source, after completion of make oldconfig
make -j6 bzImage modules
make modules_install INSTALL_MOD_PATH=./modules
cp -a /lib/firmware modules
mksquashfs modules kernel-modules.sfs -comp xz -Xbcj x86
Sorry, can you please clarify your question? Also, if this is Fatdog-related question, that should go to Fatdog thread (use the one you see is still active).stemsee wrote:@Jamesbond
How to manage savefile booting with FD initrd???
It is specified in DISTRO_SPECS that got included in initrd by build-iso.sh. You can't simply change them by specifying them from boot parameter (Mick, please correct me if I'm wrong). Fatdog's initrd (the real one, not the one in woof-next --- the one in woof-next's is still Puppy original initrd) does allow you to specify what basesfs you want to load through a boot parameter.stemsee wrote:Not fatdog proper but the initrd in woof-ng. Does the initrd require a kernel argument to load a puppy.2/3/4sf file and where does it mount it? pupsave=ram:/path/to/savefile still valid?
I don't know. I don't think you can specify arbitrary names for Puppy savefile, though. Fatdog's initrd, on the other hand, does.Is And can initrd parse a line DISTRO_PUPSAVE=puppy-save.2/3/4sf