(old)Puppy Linux Discussion Forum

Ah, boot from grub. Ok. Back in a few minutes.

Here you go, Mick.

Concerning your "EDIT": I only put a diskette in the diskette drive when I
get nostalgic about FREEDos, never in Linux. It would be strange, wouldn't
it, if the Puppy detected an 1T eSATA drive as a 1.44K diskette drive. A
"snake eating its tail" kind of thing. Just a thought.

In any case, I edited the first post of this thread to make clear to those
users who may experience a similar problem that there are a couple of
valid work-arounds for this bug.

BFN.

musher0

Bingo!

Found the source of the bug... initrd is not recognising that you have an ext3 filesystem! Now to find out why . Hmm,.. there is a cutdown "probepart" in the initrd, I guess thats as good as any place to start.

Here's something radical to try. Remove the slacko-5.6.1.sfs (yes, the main one), leave the initrd and vmlinuz there, and boot. It will say something like "can't find slacko-5.6.1.sfs .. dropping out to initial ramdisk console".
You'll be dumped to "#". Type "/sbin/probepart_init" (no quotes). Tell me if sda2 has a filesystem according to the output, plus other partitions results as well. Sorry, there is no way to save these results, just snap or write 'em down.

----------------------------------
[a little later ]

While you in are the ramdisk shell environment run this also; And why not try on other partitions?

IF THAT FAILS.. try this one.

Hi, Mick.

Another requested report.

For some partitions, the last field of the probepart_init reading is unsure.
That part of my report is a transcript from blurry or overexposed pictures.
I hope it's not too important. I can send the pics in a separate archive, or
redo the tests with a steadier hand if you need them.

As you will see, the low-level Linux recognizes the file types for all the
partitions.

Thanks again. BFN.

musher0

Ok, my last post was crap (rdsh ? .. still crap), you can get all that from running pup anyway (pfix=ram of course).

Take a look in /initrd/tmp, zip up all those logs and post them, should cover everything and if/why there is a breakdown in the initrd.

TIA

01micko wrote:Ok, my last post was crap (rdsh ? .. still crap), you can get all that from running pup anyway (pfix=ram of course).

Take a look in /initrd/tmp, zip up all those logs and post them, should cover everything and if/why there is a breakdown in the initrd.

TIA

Here you are!

Hello, all.

Here's a reprint from a message sent a few minutes ago:
~~~~~~~~~~~~~~~

Hello again, Mick.

I tried Godt's patch: no joy. However replacing the busybox blkid in
/sbin with the attached solves the problem, in CLI [mode] as least.

I did check BK's code with set -xe earlier and his exit script has no
errors. It's the Imperial Poodle who wrote the busybox applet for
blkid who should be chastised. (I hope you're not said Poodle!)

For the record: (will save you some typing)
* rename the link blkid in /sbin to blkid-NO
* unpack the attached in /sbin
* make a link from blkid-2.23 to blkid.
Done.

The attached blkid utility is a ready-made binary from archlinux, upx'd.
Version number -- of the utils-linux series it's from -- is 2.23. You may
wish to compile your own from the latest utils-linux-2.24 for your next
re-mastering / woofing of slacko.

Problem solved, as far as I'm concerned. TWYL.

Have a great day! (Which it is, isn't?)

musher0

~~~~~~~~~~~~

Voilà ! BFN.

musher0

(Was initially in the first post. Brought here in an effort to re-organize
things.)
~~~~~~~~~~~~
Edit Nov. 24, 2013
~~~~~~~~~~~~

Hello all!

I'm awaiting 01micko's diagnosis of my latest test and will edit this intro
further when it comes in.

But I think it is safe to say that:
* this problem is more likely to exist if you launch your Puppy through
__ grub4dos or similar, from a folder you have nested it in.

* the cause (has been validated) is incorrect recognition of an
__ external eSATA drive by Puppy's busybox blkid utility. If the
__ busybox utility is replaced with the full one, the problem goes away.
(Edit, Nov. 27, 2013)

* Edit, Nov. 25, 2013. On the subject of the language or locale being a
__ factor in this bug: a recent report from someone using a dual EN/PL
__ keyboard setting has come in, suggesting that locale has no effect.

* At the time of this writing, there are four known solutions at the newbie
__ level if you experience this bug:

0) (Point zero)
Before booting the new Puppy, if you don't already have a special folder
for this new Puppy, create one on your disk, with the name of said new
Puppy. Write this name down, and also the name of the partition (/mnt/
sda2, for example). You'll be working half-blind and under stress for the
next few minutes, so this note will be helpful if your memory gets short.

1) Create a pupsave file beforehand in said folder, as per instructions
listed here:
http://murga-linux.com/puppy/viewtopic. ... ost#737783
The new Puppy will pick it up correctly at 1st boot. Do some minimal
configuration changes. Exit and reboot with the same pupsave file to
validate. If things are ok, you're done. Congratulations!

If things are not ok... read on.

2) Burn the Puppy ISO to CD, and boot from this CD. Type Code:
puppy pfix=ram


at the initial prompt. Once inside Puppy, edit your configurations minimally
and reboot. Folllow the prompts to create a pupsave file. When asked
about the place where to put it, type in the name of the folder you jotted
down earlier. Once done, remove your CD, and reboot through the
grub interface to validate.

If the desktop looks fine and things are ok, you're done. Again,
congratulations!

If things are not ok... read on.

3) Boot your Puppy from the grub interface or the CD, it does not matter.
Do some minimal configuration changes. But instead of exiting directly,
open a console, type Code:
shutdownconfig


and follow the prompts. Once the process is finished, close the console.
Check in the Puppy-derivative folder to see if you now have a pupsave
file. You should.

Now exit normally. You will be asked the same questions again. Give the
appropriate answers and/or choices (same as before) until you come to
the end of the process. This time, though, the process will have saved
your configurations in the pupsave file and then kick you out! Reboot
with same pupsave file to validate. If things are ok, you're done.
Congratulations!

If things are still not ok... read on.

4) Boot your new Puppy through the grub interface. Use the replacement
solution mentioned below at
http://murga-linux.com/puppy/viewtopic. ... ost#739203.
(This a manual copy process. Double-check yourself. You will be replacing
the existing rc.shutdownconfig in folder /etc with one from an older derivative of Puppy.)
Ask to exit and follow the prompts. This is a non-recommended solution,
but if it works... hush -- and use it.

If things are still not ok... try another breed of Puppy?

I guess that's it for now.

Have a pleasant day or evening!

musher0

Edits: Nov. 26, 2013; Nov. 30, 2013.
~~~~~~~~~~~~
Hello, everyone.

The work-arounds described above may still be needed for earlier Puppies,
but I believe that I have finally found a system solution. Please read
http://murga-linux.com/puppy/viewtopic. ... ost#739666.
Hopefully, the developers will incorporate it in the coming Puppies.

Enjoy!

musher0

(Re-edited Nov. 30, 2013 in an effort to re-organize the subject.)
~~~~~~~~~~~~
Bug is still present in slacko-5.6.3_alpha. Sorry for the false joy, folks!
Please use one of the work-arounds above if you have this bug, or the
attached script. It will create a 384 Mb pupsave for a number of Puppies,
not only for slacko Puppies.

As usual, once unpacked, make the script executable before running.

Later, should you need to enlarge that file, go in a console, type and hit < Return >. Then, reboot with the same Puppy. Upon reboot, the
Puppy will add 384M (in human-understandable numbers) to your already
existing pupsave file. You may repeat this simple process every time your
pupsave file gets nearly full.

BFN.

musher0

~~~~~~~~~~~~~~
Edit, Nov. 30, 2013.
I leave this attachment here for historical purposes, but please use the
new, more precise one, located below at
http://murga-linux.com/puppy/viewtopic. ... ost#740648
Thanks.

echo "Let's begin."
echo
mount /dev/sda1 /mnt/sda1 >/dev/null 2>&1
cd /mnt/sda1
echo "Here are the names of some common Puppies:"
echo

WOW ! /dev/null for trouble shooting. Very informative. Thanks. Common in Puppyland .

Karl Godt wrote:

...
echo "Here are the names of some common Puppies:"
...

WOW ! /dev/null for trouble shooting. Very informative. Thanks. Common in Puppyland .

...and here is the full list: Puppy Derivatives

Thank you, gentlemen. Your feedback is appreciated.

@Karl:
Check for (open) sda1 partition is now done at the start in an if...else
structure.

@L18N
"some" changed to "recent".

• Your URL points to a thread on derivatives -- also of Puppy clubs. It's
  useful, but this script would need a full list of the "pupsave" file names,
  if it exists, not of the actual Puppies.
  
  It might be very long, so no other edit is envisioned on this sub-subject; I
  leave it to the user, to be careful.

Again, thank you both for your input.

Best regards.

musher0
~~~~~~~~~~~~~~
Edit, Nov. 30, 2013.
To the user: I've left this attachment for historical purposes, but please use the new, more precise one, located below. Thanks.

@L18N
This additional edit presents the list of recent pupsave filenames with
some checking within a case...esac structure. Thanks for the unlikely
"inspiration" !

BFN.

musher0
~~~~~~~~~~
To the user:
Attachment left here for historical purposes. Please use version 4 below. Thanks.

musher0 wrote:...Thanks for the unlikely
"inspiration" !

Maybe another inspiration:

running your script it wrote:ls: cannot access /mnt/sda1: No such file or directory
Please mount partition /mnt/sda1 and restart the script.
If you are on a diskless station, burn your Puppy on
DVD and use it in multi-session mode; this script is of
no use to you.
#

Really, of no use for me but hopefully for others.

L18L wrote:

musher0 wrote:...Thanks for the unlikely
"inspiration" !

Maybe another inspiration:

running your script it wrote:ls: cannot access /mnt/sda1: No such file or directory
Please mount partition /mnt/sda1 and restart the script.
If you are on a diskless station, burn your Puppy on
DVD and use it in multi-session mode; this script is of
no use to you.
#

Really, of no use for me but hopefully for others.

Hi, L18L.

I realize this script will be useful for only a few users.

A clarification if I may: are you running on a diskless machine or is your
sda1 partition simply not mounted?

What is telling you?

Thanks in advance.

musher0
~~~~~~~~
Edit: ok, got it. Will use blkid in combination with ls for finer detection.

Hello, all.

Another edit. This version provides additionnal checks: for ntfs drive and diskless computer.
Any constructive comments will be welcome.

Best regards.

musher0

There is the missing..

Still /dev/null ..

No rox /mnt/"$DRV" .. to check for progress at least at the end ..

If I get error messages a clear will erase them ..

Nicely written and readable, but content is less than the eye .

And almost forgotten to mention that error checks are missing .

Karl Godt wrote:There is the

Code: Select all

mkdir -p /mnt/"$DRV"

missing..

Still /dev/null ..

No rox /mnt/"$DRV" .. to check for progress at least at the end ..

If I get error messages a clear will erase them ..

Nicely written and readable, but content is less than the eye .

Hi, Karl.

The above are now incorporated. Thanks.

As to your suggestions in the following post, the error check for the
"create" function is a good idea. The other ones seem to be more
trouble than they're worth, though.

I double-checked and the >/dev/null 2>&1 actually prevents an error,
given the context. Also, in the sequence (line 91). the "else" statement is the error catcher. There is no need to
specifically error-catch the error-catcher, I think; the logic of the if-else-fi
structure does it.

Paranoia can be a virtuous sickness, you know.

So here is version 5.

BFN.

musher0