Can't boot new lupu install

[lemmy999]

I decided to upgrade from RexBang 2.3 to 2.4 but on a different partition. Burn the ISO to CD and tried to boot. The CD will only boot to a desktop if I first hit F3 and put pfix=ram into the boot parameters.

I have then done a frugal install to sda8. All seems to go well until I attempt to exit. When asked if I want to create a save file I hit Yes and then the machine freezes. Only way to exit is by restarting the PC.

I am dualbooting with Ubuntu using Grub2. I modified my old custom entry from sda7 to sda8.

40_custom script

Code: Select all

set root=(hdo,8)
linux /puppy525/vmlinuz root=/dev/sda8 pmedia=atahd psubdir=puppy525

initrd /puppy525/initrd.gz

Now, when I boot the machine hangs at " searching for puppy files in computer disk drives" I have tried all sorts of fixes pfix=ram, pdev=sda8 but to no avail.

After some further work I think this is a savefile issue. I can get both the RexBang CD and a Fire Hydrant disk to boot , as long as i use pfix=ram as a boot option.

[sfeeley]

just a thought--on one of my older computers, building the initial save file takes a long long long time. And during that time it seems like the computer has frozen.

(That's on a slow computer, but even on a faster machine it takes a pretty long time, and the computer doesn't give any feedback while it is working)

So perhaps your computer actually was building the savefile, but you shut it off prematurely. The result perhaps is a half-built savefile that is corrupting your system at boot.


In my case, I've found it easier to create a savefile on a faster more reliable computer, and then copy it over to the target computer.

This is all a guess, but might explain the behavior you've seen.

[Kal]

I avoid grub 2, but look here for answers:

http://puppylinux.org/wikka/Grub2

Even I can see your code is incorrect, in your first line, that should be a zero not a little “o

[lemmy999]

@Kal

As i said in my original post I only changed hd0,7 to hd0,8 to account for the change in partition. The hdo in my post was a type on my part.

@sfeeley

As I am using pfix=ram the savefile issue should not matter.

[Béèm]

Always copy/paste instead of typing to avoid typo's and useless discussions.

If you install to sda8 in grub terms this is hd0,7 not hd0,8

[rhadon]

If you install to sda8 in grub terms this is hd0,7 not hd0,8

Sorry, but it's Grub2. AFAIK, Grub2 uses hd0,8 for sda8. But I never used Grub2, so I can't give advice.

Rolf

[lemmy999]

Always copy/paste instead of typing to avoid typo's and useless discussions.

Nice advice but I can't use the PC that is giving me all the issues and had to type the grub stanza into a spare laptop.

I'm using Grub2 and therefore AFAIK it should be hd0,8 not 7.

[rhadon]

I would boot from cd and check the partition with

Code: Select all

# fsck -y -f /dev/sda8

fsck --help for other options.

Then I would mount sda8 (maybe all partitions) and search (with Pfind) for *.2fs or *.3fs to find the corrupt save file and if there is one, delete it.

HTH
Rolf

[Béèm]

Ok then hd0,8 should be ok then. I don't use grub2 and thought they are all the same.

As for the statements, I use the simplest ones.
I would use

Code: Select all

kernel (hd0,8)/puppy525/vmlinuz
initrd (hd0,8)/puppy525/initrd.gz 

It may take a little longer to find the files, but I don't care.
Don't know if grub2 knows kernel.
If grub2 doesn't know kernel, change it to linux then.

[sfeeley]

I'm not at a computer that uses puppy, so please forgive if I'm wrong since I can't check.

But the poster wrote:

Now, when I boot the machine hangs at " searching for puppy files in computer disk drives"

but also said that this happens when he is trying to boot using a disk and pfix=ram

If the computer is running entirely from ram and a cd, why is it searching for puppy files?

I'm particularly curious since this is where he says the computer hangs.

Since this happened after a failed attempt to create a savefile (see original post), I still wonder if there is a corrupt savefile in there somewhere that is messing things up, despite the pfix=ram command. (I know this isn't supposed to happen, but then again he's not supposed to be having any of these difficulties)

Once in the distant past, when I had some difficulties where it seemed like failed installs were corrupting future attempts. Eventually I ran killdisk and wiped the entire drive. Don't know if that is an option in this case.

And, as I said I may be barking up the wrong tree, but something feel weird . . .