Busted my pup_save (fixed)

[PaulBx1]

Last night I wanted to save some stuff in /tmp, so I was going to copy the whole directory into a subdirectory of /root (since /tmp normally gets wiped clean at boot). However it was late, I was tired, and I think I MOVED /tmp over there.

At any rate, it fails the boot now. When it executes /etc/rc.d/rc.sysinit, it fails all accesses in /tmp with "File or directory not found", or equivalent.

I found an old pup_save and booted with that. Then I did an losetup of the broken one (it's encrypted), e2fsck'd it (it needed fixing), mounted it under root, and made sure I had a tmp directory there again, with the right permissions, owner, etc. I can copy files into it as well, so it is writeable...

Unfortunately, it still won't boot. The message it gives, just after "Making the filesystem usable...", is "/etc/rc.d/rc.sysinit: line 66: /tmp/bootsysinit.log: No such file or directory". Then like I said it has other problems with other files in /tmp, and it goes into an endless loop.

The latest backup I have is 15 days old, so if anyone can guess why it is failing it would save me some work.

[GuestToo]

you could try changing line 54 of rc.sysinit from this:

echo -n "Making the filesystem usable..."

to this:

echo -n "Making the filesystem usable..."
mkdir /tmp
chmod 1777 /tmp

i overlay /tmp with a tmpfs file system in rc.local, like this:

mount-FULL -t tmpfs -o size=900M tmpfs /tmp

so my /tmp is in ram

[GuestToo]

though actually, it might be better to add those lines after the file system has been remounted rw, for example, just after line 61 (Puppy 216):

mkdir /tmp
chmod 1777 /tmp
#v2.11 redirect all output to a log file...

i'm not at all sure if this will work ...

[PaulBx1]

Thanks G2, that did the trick. I don't think it was the mkdir (during boot I got the message it was already there), but the chmod. It had been set to 755 previously, not sure why it should make any difference, but it did.

I also confirmed the move of /tmp was the problem, by doing it on a copy of my earlier working pupsave.

I put the code as you said, after the remount.

Maybe this would be a good thing to have in there anyway, in case others make the same mistake (yeah, it's low probability, but it just makes things more idiot-proof ). I'd have a test for the existence of /tmp before the mkdir so we don't get extraneous error messages out.

It's weird, after a while I could no longer e2fsck that broken pupsave, even though I could still mount it, as it complained about a wasted superblock (this was after it had previously passed e2fsck). I tried other superblocks to no avail. However I was able to boot it after this fix of yours. Anyway after doing that I created a new pupsave with my convert-pupsave utility that was able to pass an e2fsck cleanly.

Life with computers!

[GuestToo]

glad it worked ... i wasn't at all sure it would

i was not sure if /tmp even existed at that point, which is why i suggested mkdir /tmp ... to avoid extra posts if chmod alone didn't work

i don't know why chmod 1777 would work if chmod 777 did not ... the 1 prevents a user from deleting another users files in /tmp ... for example, user nobody would not be permitted to delete a file belonging to /root

i just figured that if /tmp were there and had the right permissions, it really should work

mkdir -p /tmp

should suppress the error message if /tmp already exists