I had no problem switching to 24 bit colours using xorgwizard in beta5. I chose the "probe" option. I don't know why 16 is the default, in the current Slacko beta we are defaulting to 24. Same kernel series, similar config.

As no one else has reported anything like my ram0 "hangover", and I don't think I'm the only one setting up a Full 5.3.91 directly from a Frugal 5.3.91, it looks like it is a hardware issue, at least in part.

Thanks for your time and thoughts,

David S

Not a hardware issue.
Same problem on my MSI netbook with full install from usb.
Reboot from Precise or any other OS ends with that
kernel panic.
Boot from power off works.
Did not have that problem with the previous (non pae)
version._________________
Inspiron 700m, Pent.M 1.6Ghz, 1Gb ram.
Msi Wind U100, N270 1.6>2.0Ghz, 1.5Gb ram.
Eeepc 8g 701, 900Mhz, 1Gb ram.
Full installs

Barry,
While testing my upgraded HSF modem support, I find that sometimes the HSF modem is discovered on first boot after installation or "pupdial erase", and other times not detected! I added trace logging to backend_modprobe to monitor its actions. I find that the trace log is identical (except for some of the ordering of unrelated events) whether the modem is detected or not. I suspect that the firmware package and extensive file changes made by the pinstall.hsfmodem script do not get made visible to other processes (i.e., /etc/init.d/hsfmodem) by the time they are needed.

I notice that the "backend_modprobe" script does not contain any 'sync' commands. I understand that command to force writing of file changes to the "device", where it becomes visible to all processes. My "rule of thumb" is to use 'sync' after writing a file that is intended to be used by other processes, on the assumption that the changes are visible only to the current process until the kernel decides to flush the buffers. Considering that several seconds appear to elapse before the initialization (init.d) script runs, it appears that the buffers do not get flushed even when the creating process (backend_modprobe's process) ends.

Because of the random nature of the detection/nondetection cases, it is difficult to verify absolutely that adding 'sync' results in success that could also happen by chance. But, since I added it, I have not seen a repeat of the detection failure.

My recommended fix is to add "sync" after the writing of the "lock1" and "protect1" files, and then after writing the "devpath" file. The latter would be effective for the files affected by a firmware package, which is where I suspect the HSF detection problem originates.

I attach a package containing only "backend_modprobe" with the 2 added 'sync' commands, in case anyone wants to try it. To test it, remove the files copied from the appropriate subdirectory in /lib/modules/all-firmware, from wherever they end up (usually /lib/firmware). Also remove /etc/modules/firmware.dep.inst.* (to cause reloading of the "firmware package"), then reboot.

Odd behaviour in a Full 5.3.91 made with the Universal Installer from a Frugal 5.3.91 using its home directory as the source of the installation files.
The Full to a freshly wiped partition.
The Full 5.3.91 install starts up and does all the right stuff and closes down as normal and without error messages.
The only new thing I've noticed is a change of display text size during booting and closing (text display starts as before but then goes coarser just before X opens), but other recent Pups do the same thing without the problem I get in this Full 5.3.91.

On re-booting the Full, after the first white text line, an orange-red text message appears almost immediately about checking its partition, and then with more white lines of text flowing down the screen, the computer freezes requiring a push-button restart.

When I check the dud Full 5.3.91 partition from another Pup or even from its OK 5.3.91 Frugal, I see in /mnt a ram0 directory listed. If I delete this ram0, the Full then starts up as normal. But on shutting down and attempting to reboot to this "fixed" Full, the same freeze occurs needing a reset to another Pup to get a good boot.

And the ram0 is back in the /mnt of the Full 5.3.91. Delete this and it will start again, but fail after a shut-down & reboot with the ram0 back again.

When I first found this problem fix (i.e. delete the ram0 directory), there were two ram directories in the Full's /mnt (ram0 and ram1), both of which I deleted and the Full seemed to re-start OK (until re-booted ).

I think 5.2.73 had the same freezing on re-boot problem but I overwrote that Full with this next version (5.3.91) so don't know if it also had this ram0 oddity.

Any advice or simple fix?

David S.
.

A partition filesystem check is performed at bootup if file /fsckme.flg exists.

This file is created at startup, then /etc/rc.d/rc.shutdown deletes it at shutdown -- except I think if it sees that the partition is due for a f.s. check.

I don't know why you f.s. check is failing. I will have to do a full hd installation to test it.

A hack you can do is edit rc.shutdown, make sure fsckme.flg always gets deleted._________________http://bkhome.org/news/

Having 'sync' in any module-loading code that is called by the kernel, can break things. Sometime ago I took out all syncs.

Besides, sync only flushes the files to the physical drive. Prior to flushing, the files are in RAM buffers and are accessable as per normal.

So, I suggest that the solution to your problem can be found in some other way.

I had a similar problem with Precise for the XO laptops (3.3.8-olpc kernel) failing to find the libertas wireless firmware in both XO-1 (usb8xxx) and XO-1.5 (libertas_sdio) when rc.update was running, ie in the 1st and 2nd boot and after an update.

Tried rerwin's patch with no results.
Adding sleep/sync/wait steps at various places in rc.sysinit was equally fruitless (maybe the initrd/init?)

What unexpectedly solved the problem was (looking for more info) to boot with "loglevel=7"!!!
I doubt is your loglevel 3 kernel patch that generates the problem. I would suspect a race issue alleviated by the (slower) loglevel 7 boot sequence.

However, given tat the same kernel does not give this issue, on the same hardware, in Fedora builds with loglevel 3 (or quite), I would think that there is still something in the boot sequence that allows for this (possible) race issue to manifest.
Rerwin's sketchy firmware issue might be due to something related._________________== Here is how to solve yourLinux problems fast ==Last edited by mavrothal on Mon 10 Sep 2012, 03:00; edited 1 time in total

I decided to start again so re-downloaded precise-5.3.91, this time as the single iso - although the delta into 5.2.73 gave the right md5 code for my previous travails.

The new Frugal 5.3.91 was made by mounting the iso and copying the files into the existing precise5391 directory on my frugals partition - deleting the previous files first.

Frugal-5.3.91 started up OK and I added my standard sfs files etc. Still all good

For the Full-from-Frugal test, I used GParted to first reformat the 3GB partition which had been ext2 to ext3. I then ran the Universal Installer to create a Full 5.3.91 in this partition using the /mnt/home/precise5391 directory as the files' source.

The Full started without complaint but I did check to see if there was a ram0 directory in /mnt. There wasn't, but there was a ram1 instead?? So I deleted this and re-booted. The Full-5.3.91 re-booted without problem and I could not find a ram0 or ram1 directory in /mnt. I re-booted a couple of more times and had no ram0 problems.

So I've loaded in my pets and symlinks, and my Full 5.3.91 is still running (and re-booting) without problem.

The only odd thing is when I install some home-made pets, their "Categories" entry gets changed so they end up elsewhere in the Menu. Just need to edit the .desktop files. Very recent Pups have done this too. These same home-made pets have not had this re-categorisation happen with earlier, more 'previous' Pups, so I suspect a woof-effect?

Anyway, the explanation about the f.s. partition checking being the cause of the ram0 problem looks "close to the money".

In future, I'll just need to occasionally re-format a Full partition for new Pups as wiping seems not quite the same thing?

This would be an excellent move at this time. Other issues have arisen with FULL in the intervening period, notably with the latest (5.3.5.x)Slacko series, reported on the Forum. Liaison with Mick might assist? Was there a Saluki FULL matter awaiting the maestro's attention? There are delta/upgrade problems for FULL, too. The gurus seem to think these things need scrutiny from The Top!

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum