search

puppylinux-woof-CE / woof-CE

woof - the Puppy builder
GNU General Public License v2.0
389 stars 278 forks source link

Version update issue - DISTRO_SPECS in savefile not updated? #911

Closed peabee closed 7 years ago

peabee commented 7 years ago

@Marv has reported a possible issue with version updates at: http://www.murga-linux.com/puppy/viewtopic.php?p=934490

One thing I've noted the past few updates and may have pinned down is that even though my savefile has been sucessfully updated, on the next boot or boots it still shows as not updated and goes through another update. On inspection of the save file (running another pup), I see that the DISTRO_SPECS directly under initrd isn't being updated though everything else is. Copying the correct DISTRO_SPECS to there from /etc fixes the issue til the next update. My guess is that it is a 'rationalized' initrd update script problem.

mavrothal commented 7 years ago

Booting from a CD with a savefolder in the HD, I do not see that. DISTO_SPECS, both in /etc and /initrd, update fine. No issue on next boot either

wdlkmpx commented 7 years ago

I edited a few lines in rc.update:

http://pastebin.com/raw/e29cRMdR

I haven't tested it.. I never upgrade. so i'll leave it to those who do..

peabee commented 7 years ago

@Marv has clarified that: it is a savefile, formatted EXT2, just 256Mb

wdlkmpx commented 7 years ago

I usually use a 256mb savefile to test puppies. So i edited the DISTRO_SPECS in the save file (both DISTRO_SPECS), changing 7.0.0a1 to 7.0.0a0

Booting with dpup stretch there is a prompt upgrade. I upgrade. Reboot. And nothing happens. So i can't reproduce the bug..

peabee commented 7 years ago

I will check using Slacko-6.9.6.4 and LxPupSc-16.12.1

@Marv says:

Pristine boot of 16.12.1 (last one in the .1 series. Set time zone and hardware clock only. Reboot creating a 256Mb EXT2 savefile. Reboot once more with 16.12.1 files just to check. All ok.

Substitute all current 16.12.2 files into that boot directory and reboot. Asks to update savefile, does so and runs fine. A quick look shows all relevant updates have been done.

Reboot again. Asks to update savefile again. Exactly as I saw earlier.

Boot into another pup and mount and examine the savefile in question.

In that savefile the DISTRO_SPECS in /initrd/ is the 16.12.1 one. Copying the 16.12.2 one over that stops the repeated ask for update.

While running the pup in question using the savefile, the 16.12.1 DISTRO_SPECS is in /initrd/pup_01/initrd/

It's real and consistent, does exactly the same thing every time. Can't see any way it's hardware or timing.

wdlkmpx commented 7 years ago

he's probably using pupmode 13 (usbflash).. i'll test it tomorrow.. probably.

meanwhile this should fix multisession cd/dvd (pupmode 77) https://github.com/puppylinux-woof-CE/woof-CE/commit/8bb32c756f43acbcc1b493943c34a656760ad2be or at least make most things work. i successfully saved session several times

wdlkmpx commented 7 years ago

indeed the problem happened in pupmode 13: pmedia=usbflash pmedia=ataflash

commit https://github.com/puppylinux-woof-CE/woof-CE/commit/06df07cae11cfb5b7721233fa274eba05ef42ed6 fixes this.

actually the situation was pretty bad. pup_ro1 was mounted read-only so no further updates were possible.

peabee commented 7 years ago

Tried the new init in a ydrv - but got a kernel panic on boot.....

/sbin/init in ydrv

wdlkmpx commented 7 years ago

initrd-progs/0initrd/init goes in the initrd.gz file. edit initrd.gz (replace init, make sure it's executable)

/sbin/init is actually woof-code/rootfs-skeleton/sbin/initNEW ... these are 2 completely different files.

i use edit-initramfs to extract and repackage initrd.gz. first click = extract (i edit stuff), second click = repackage. assuming mime associations (*.initrd.gz) are working.

or edit-initramfs -x <initrd.gz/xz> - extract (edit files) edit-initramfs -c <initrd.gz/xz> - repackage

peabee commented 7 years ago

OOPS! - sorry - lesson learnt!! Easiest to do a new build - new interim delta to LxPupSc-16.12.2 uploaded for @Marv to test

peabee commented 7 years ago

Both my tests and also @Marv confirms that this is now fixed - many thanks - will close.

wdlkmpx commented 7 years ago

by the way i deleted the local noarch-official. but peebee, p.l.e.a.s.e add this line to the online noarch-official

firmware_linux_module_brcm_pi3-7.45.41.26|firmware_linux_module_brcm_pi3|7.45.41.26||BuildingBlock|428K||firmware_linux_module_brcm_pi3-7.45.41.26.pet||Pi3 wifi firmware from github.com/RPi-Distro/firmware-nonfree||||
peabee commented 7 years ago

Done

BUT

noarch ..... pi3 specific ..... doesn't sound right to me?