Page 15 of 16

Posted: Mon 07 May 2007, 16:32
by Nathan F
The issue with the missing icons has to do with the fact that the icons have to be cached to a directory in /tmp. Interesting problem here, lxpanel does not have an icon search path, so when the menu is created the full path to each icon must be specified. What I did is to have lxpanel go through a series of directories and copy the icons to /tmp/icons, and then the menu generator prepends that path to all the icon names. It works but what is happening is that it isn't getting finished by the time lxpanel has started, so not all the icons are present yet.

Anyway it's a bug I've known about for a couple weeks now, but the solution may not be totally straightforward. I suppose I could move it from /tmp/icons to somewhere persistent and that would be one solution, but then you have an extra copy of all those icons in the savefile. Or I could just have the menu generator prepend /usr/share/pixmaps to every icon path, since most icons are located there anyway. That solution works but with a couple problems, because then there will definately be some applications missed, but it would also improve the overall startup time. Whatever I decide you can trust it will be fixed for the final.

I also spotted the "chown" errors. This is once again something in the "snapmergepuppy" script, which flushes the files into the savefile. If it is erroring there the files should definately have still gotten saved, but it's possible the ownership might change to root:root. There was a big problem with this not long ago in Puppy and I submitted a patch to Barry to fix it, which was at the time working. It's possible something external might have caused it to ail though. I will do some experiments with it to see what is going on.

Assumin you added sshd to /etc/rc.d/services as you mentioned then that explains it all, because the correct file is /etc/rc.d/rc.services. Of course you could have just mistyped on the forum here in which case there reaqlly is a problem for us to track down.

Nathan

Posted: Mon 07 May 2007, 19:09
by SimonW
The issue with the missing icons has to do with the fact that the icons have to be cached to a directory in /tmp.
...
Anyway it's a bug I've known about for a couple weeks now, but the solution may not be totally straightforward.
No problem. I can live with it - after all it will be a mostly unattended machine in the end. Access by vnc and ssh normally.

Assumin you added sshd to /etc/rc.d/services as you mentioned then that explains it all, because the correct file is /etc/rc.d/rc.services. Of course you could have just mistyped on the forum here in which case there reaqlly is a problem for us to track down.
Yep, I added sshd in a new file called /etc/rc.d/rc.services and it worked like a dream. Now I'm working on samba setup....

If it's not a long answer, could someone explain (even if it's just a link to another part of the Puppy forums) regarding how to remaster? After I've customised, I'd like to burn it all to a master CD so I can then create CF cards without doing all the configuration again. My remaster will include the application 'motion' which is a cctv and webcam motion detection program (open-source).

Thanks,
Simon.

Posted: Mon 07 May 2007, 19:52
by Dougal
I've writtten a script to replace test-scsi.

Posted: Mon 07 May 2007, 21:29
by SimonW
Dougal,

Should I look for changed behaviour in Pmount with test-scsi changed for your version?

Or perhaps it's changed for another reason!

Posted: Mon 07 May 2007, 22:58
by Dougal
SimonW wrote:Should I look for changed behaviour in Pmount with test-scsi changed for your version?
No, I think Pmount only uses probedisk and probepart.

Posted: Mon 07 May 2007, 23:12
by msumner
SimonW wrote:
If it's not a long answer, could someone explain (even if it's just a link to another part of the Puppy forums) regarding how to remaster?
Hi Simon, I guess that you could not find remaster in the menu. Me neither. There are two remastering programs in /usr/sbin/, They are pupremaster.sh which appears to be an adaptation of dougals enhanced remaster, and remasterpup2 which looks like a Nathan experiment, as it invites anyone to give it a try. Both come with instructions, so take a look. I have not tried them yet, but I should as I am looking into putting a remastering section in the help files.
Cheers, Mike

Posted: Tue 08 May 2007, 20:02
by Dougal
I've updated the installer to (hopefully) fix the problem with vfat being regognized as ext3. It's up to Nathan now to update his version... (it's really trivial and shouldn't require any Grafpup-specific coding, so the new code can just be added to the old installer)


While I'm here: anyone (especially those with SATA drives) feel like running my hardware test dotpup? It shouldn't take more than a few seconds...

Posted: Tue 08 May 2007, 21:32
by SimonW
Here you are Dougal.

Posted: Tue 08 May 2007, 21:56
by SimonW
I've found a couple more things (sorry Nathan!):

When I first boot up my VIA EPIA machine with Sata drive and CF boot media, Grafpup always comes up in (what looks like) 640x480 mode. It might be 800x600 but is a shock compared to the expected 1024x768.

Looking round for clues I spotted an error message, it might not be related, but:
In /var/log/bootsysinit.log ... savepuppyd: Line 16: -eq : Unary operator expected.
At line 16 of /usr/sbin/savepuppyd we have a [ test checking the variable $PUPMODE to be 2.
I could be wrong, but should this be testing GRAFMODE now?

A menu-initiated reboot comes up in the expected 1024x768. But the strangest thing is that a menu-power-off and then a manual turn-on is then in 1024x768 again. Wow!
I noted a message flying by after the echo "This script will run X windows for you" but am not quick enough to read it. I do not know if X uses a log file to see the error later. It's not in /var/log/messages.


The second thing is that the beta iso's ffmpeg installation might have a problem?
Trying to compile my motion application resulted in a missing libdts.so.0 error - my app could not link.

Typing 'ffmpeg' on its own also resulted in this same error. What should happen is a long 'usage' message. The full text of the error was:
ffmpeg: error while loading shared libraries: libdts.so.0: Cannot open shared object file: No such file or directory.
And a 'find' does not show any files in the entire filesystem by that name.

EDIT: Found this earlier in this thread....
Posted: Sat Apr 28, 2007 2:12 pm Post subject:
Just go to a command line, cd to the directory that has your libdts-0.0.2.tar.gz and as root type:

pkgtool -install libdts-0.0.2

Will try this tonight.

Second Edit:
The libdts package in the repository didn't seem to install correctly, so I downloaded another - which had to be compiled from source - from here:
http://debian.unnet.nl/pub/videolan/libdts/0.0.2/

did './configure' then 'make' then 'make install' and my application, motion, which uses ffmpeg, then linked correctly. Brilliant.

Note that under grafpup if you want to repeat my steps, you'll need the 'devx_005.sfs' package.

Posted: Tue 08 May 2007, 22:11
by msumner
Dougal, test results on dell 6400 using sata 100gb HDD and 1gb usb flash. Will this look for my built in cardreader?
Mike

Posted: Wed 09 May 2007, 10:33
by SimonW
Report on Remastering using pupremaster.sh

It seemed to work well, I have created an iso and burnt it to CD. I had to use a roundabout method to remaster so I thought I'd explain the steps necessary if you don't have a CD drive on your Puppy machine!

Grafpup System: VIA EPIA motherboard, Grafpup beta iso booted from CF card in ide adapter. Local Sata hard drive, currently with lots of space.

I needed all the Grafpup files: isolinux.bin vmlinuz initrd.gz etc, which although 'on' my CF card, since it booted, didn't seem to be all there when I accessed it through /initrd/mnt/....

So I used my other machine (Athlon, Windoze, with a CD burner) to break apart the original Grafpup beta iso into the separate files, then used WinSCP to transfer them over an SSH connection onto the Sata drive on the VIA machine. (Remember, the Sata drive has lots of space).

Then I used the /usr/sbin/pupremaster.sh script to generate a new ISO file. You can't start it from the menu system. The ISO was 277Mb but this includes all the drivers (it's not hardware specific to me), and the 'devx' sfs, and samba & motion applications. It took about 10 minutes to create it on the VIA machine.

Finally a transfer by WinSCP back again to the CD-burning machine to burn it as an ISO image. The burnt CD looks good, I can see the isolinux.bin etc files. Haven't booted from it yet, and will update this message when I have.

EDIT - Results of trying to boot with the remastered CD:

Bad news I'm afraid. On 2 different machines with CD drives, got the following message:

(retyped from what appears on-screen)
Boot from ATAPI CD-ROM:
No Emulation
ISOLINUX 3.11 2005-09-02
isolinux: Disk Error 80, AX=42CE, drive 9F
Boot failed: press a key to retry...
The CD 'appears' bootable, Isobuster under Windoze shows the Grafpup installation files, and the 'floppy image' is also there. Looks identical to the Beta 1 iso CD I made.

On both machines I tried the disc on, the error message was exactly the same.

Posted: Wed 09 May 2007, 13:10
by Dougal
Thanks for the files, Mike and Simon.

Simon: the low-resolution is something that usually happens as a result of xwin setting that as a default Xvesa mode (I assume you're using Xvesa?).
I must admit, though, that I cannot think of why it would behave differently when rebooting or shutting down...


Mike: I'll find out later if it saw your card-reader... It looks for all devices and checks various files in /proc, so should see it if the kernel recognized it.

Nathan: I just updated the xorgwizard, video-wizard and my Xvesawizard, in case you want to use them.

Posted: Wed 09 May 2007, 16:02
by msumner
Dougal, I think I was running in puppy 2.15 CE when I did ran last hardware test. This one was done while running in grafpup beta:
Mike

Posted: Wed 09 May 2007, 16:17
by Nathan F
Dougal - I've been following your progress on the Xorgwizard and might just sneak it in there. Thanks.

Nathan

Posted: Thu 10 May 2007, 12:02
by SimonW
Just to say I've updated the message above regarding libdts - the repo packages didn't work for me. I downloaded a new copy including source and compiled it locally, that worked.


Also updated the message above with the results of my remastered Grafpup CD. Bad news I'm afraid, not quite sure why - but this is the first time I've remastered any Puppy.

Posted: Thu 10 May 2007, 16:32
by plinej
Nathan, I upadted a couple of apps. Mostly bug fixes and will post them below.

SimonW, I tweaked dougal's remaster script a bit to work better in grafpup and have successfully remastered a few times. I also had to modify the last part of /etc/profile I sent my revisions to Nathan but am not sure if he's added anything to it. I'll post my revision below too. Make sure when you remaster and you get the message to check /tmp/etc that you verify my revised /etc/profile is in there otherwise you won't be able to start as user grafpup.

Posted: Fri 11 May 2007, 18:23
by SimonW
Thanks, I will try out the revised remaster pretty soon.

Posted: Sat 12 May 2007, 22:17
by SimonW
Nathan, (and plinej I have tried your remaster script)

I am seeing some error messages in /tmp/bootsysinit.log like this:

/usr/sbin/savepuppyd: line 25: [ : Unary operator expected

I think they relate to use of the shell variable $PUPMODE in the script savepuppyd, which is now $GRAFMODE isn't it? This came up a few pages back in this thread and you fixed the error.

I'm testing the revised remaster script posted by plinej right now and will post my findings.

BTW I have a question about remastering - if I have a mahoosive HDD of data files mounted in a directory under /, as I plan to, and I remaster to an iso, will the whole contents of the data drive be included? I would hope the script or aufs is clever enough to omit that kind of thing?

Anyway, I'll edit this post later to report the remaster test.
EDIT: Here are the results.

The remastering process went well (hardware: VIA EPIA machine booted from CF, 1 Sata data hdd). I used plinej's updated script posted just above here. An iso was created.

The iso was transferred by WinSCP to my Athlon Windoze machine with CD-burner. The CD was written, and booted properly this time. Got the usual boot menu, so I booted with pfix=ram (I have got a savefile on this machine from before).

Grafpup came up, and could not successfully run X. This is what happens:
This script will run X windows for you....
/usr/X11R7/login ........ .XLOADED : No such file or directory
Starting X login manager, specs in /etc/X11/xorg.conf
slim then gives an error message about a Stale lockfile, removing it.
slim then segfaults.

The cycle repeats, but I managed to terminate it with Ctrl-Alt-backspace I think, and Grafpup then dropped to the Save to File/CD/Do Not Save dialog box.

My guess is that the setup on the VIA machine had/has been included in the Iso, and it doesn't work for the Athlon machine (which has different video h/w). There was a video=<something> parameter in the isolinux.cfg file .... the remaster script showed me that. Could that be the problem?
I do want to create remastered CDs that will boot on most machines, ie. are fairly universal. From that CD I can then make compact flash card to replace my boot media if and when I need to.

---------------
2nd Edit: another time, by selecting Xvesa after bootup, I managed to get logged in as root. Only took 2 tries, the first one (had correct username/pw as far as I know) exited back to the graphical login screen - I saw a "slim: Stale lockfile - removing" error message fly by.

There was a problem once I got logged in, the /home directory in which I had placed some subdirs, was gone. Just /home/grafpup remained. I thought that the remaster process would include all of /home? Could it be "still there", just concealed under another layer of the filesystem?
---------------

And one last question if I may. When booting from CF, I don't get the option to type in grafpup pfix=ram or any other options. Is this because the bootloader installed on CF is smaller/less capable that the one on the CD's ?

Thanks once again,
Simon.

Posted: Sun 13 May 2007, 19:19
by SimonW
Regarding the beta iso coming up on my VIA EPIA machine from a cold boot into what looks like 640x480 res, I found that Ctrl-Alt-Backspace caused it to cycle through resolutions. I eventually got 1024x768 and it took me 2 entries of username/pw to get logged in, but I got in. I also found (reported above) that if I log in with 640x480, then tell Grafpup to reboot, it comes up in 1024x768 the next time.

Might help!
Simon.

Posted: Mon 14 May 2007, 12:34
by Dougal
SimonW wrote: I found that Ctrl-Alt-Backspace caused it to cycle through resolutions.
Ctrl-Alt-Backspace?? That's supposed to kill X...
Ususally Ctrl-Alt-+ and Ctrl-Alt-- do that.