READ-ONLY Archive
https://oldforum.puppylinux.com/
sed can do several commands, one after the other, so shouldn't need to pipe into it twice. I think this should work (though haven't tried it):jd7654 wrote:
Change to /usr/local/bin/apt2sfs line 352:Code: Select all
export SFS=$(for i in "$INSTALL"; do echo $(echo $i | sed 's| |_|g' | sed 's|=||g'); done)
Code: Select all
export SFS=$(for i in "$INSTALL"; do echo $(echo $i | sed 's| |_|g; s|=||g'); done)
Then Fred clued me in reading his msg awhile back what Peebee did, so am trying to learn. This all is just great stuff. Also, I saw Toni posted in "HOW TO" section an easy way to rename all my frugal install's "live" folders, thus keeping better track and also ending any boot confusion by making myself stick to "psubdir=", something I already do for all pups.
Yes, thanks for reporting.peebee wrote:Synaptic error when trying to apply an installation request:E: Could not open lock file /var/cache/apt/archives/lock - open (2: No such file or directory)
E: Could not open file descriptor -1
E: Unable to lock the download directory
Had the same problem ....but just deleted /var/cache/apt/archives some xxx.bin(s) .peebee wrote:
Synaptic error when trying to apply an installation request:
Quote:
E: Could not open lock file /var/cache/apt/archives/lock - open (2: No such file or directory)
E: Could not open file descriptor -1
E: Unable to lock the download directory
Even better. I just tacked that on to the end of the line to show the minimum change to workaround apt2sfs failure.wiak wrote:Code: Select all
export SFS=$(for i in "$INSTALL"; do echo $(echo $i | sed 's| |_|g; s|=||g'); done)
No need to apologize. Finding bugs is part of the development process.fredx181 wrote:@dancytron
Sure you did !I think I found the save2flash issue.
...
...
I fixed the problem by removing debdogmountscripts dependency in version 0.0.3
So now installing debdoginstallscripts will not install porteusbootscripts
Also added ~/Startup/initchanges.sh in the 0.0.3 version (will help empty tmpfs after running save2flash)
But in fact porteusbootscripts doesn't need to be installed, because these (essential) scripts are already in the build by default.
But version 0.0.3 has the logrotate option, if you want that:Also added new version 0.0.4 to the repo that has the exact same files as included in the build.Code: Select all
apt-get install porteusbootscripts=0.0.3
Thanks for finding out and sorry for the inconvenience.
/snip/
What I changed is under lined and bold.# export final variables defined through GUI or CLI (with or without custom config)
export BASE_INSTALL="$BASE_INSTALL"
export BASE_DOG_APPS_INSTALL="$BASE_DOG_APPS_INSTALL"
export BASE_APPS_INSTALL="$BASE_APPS_INSTALL"
export DESK_APPS_INSTALL="$DESK_APPS_INSTALL"
export EXTRA_DOG_APPS_INSTALL="$EXTRA_DOG_APPS_INSTALL"
export FIRMWARE="$FIRMWARE"
export REM_AUTO_INST="$REM_AUTO_INST"
export FORCE32="$FORCE32"
It's just what you'd prefer. Because the scripts for porteus-boot are already included in the build by default, there's no need to install porteusbootscripts package.By logrotate option, you mean when you log off it asks if you want to get rid of all the old logs? So, to get full Debian Dog functionality, including the logrotate, I should include porteusbootscripts in the mklive script? Do you really mean I should install version 0.0.3 and not the newest one?
Yes, that's right! When using GUI there's no problem (exported earlier in script) but with CLI it was, fixed now.I believe the line with firmware is missing at line 280 of the script.
I changed it to
Quote:
# export final variables defined through GUI or CLI (with or without custom config)
export BASE_INSTALL="$BASE_INSTALL"
export BASE_DOG_APPS_INSTALL="$BASE_DOG_APPS_INSTALL"
export BASE_APPS_INSTALL="$BASE_APPS_INSTALL"
export DESK_APPS_INSTALL="$DESK_APPS_INSTALL"
export EXTRA_DOG_APPS_INSTALL="$EXTRA_DOG_APPS_INSTALL"
export FIRMWARE="$FIRMWARE"
export REM_AUTO_INST="$REM_AUTO_INST"
export FORCE32="$FORCE32"
A workaround would be to edit /etc/mke2fs.conf to how it used to be in "older" systems.mikeslr wrote:Hi All,
I'm not sure if this falls under the heading "Buying into problems before they materialize" or "Reading the Writing on the Wall and Preparing to meet an unavoidable problem".
Short version: As far as I can tell, grub4dos is no longer maintained. The last version on the Puppy Linux Forum was created in 2014. Although it has support for Linux Ext4, it is unable to boot operating systems from drives formatted as 64 bit Linux Ext4.
See the following problems which have recently surfaced trying to boot Puppies:
http://murga-linux.com/puppy/viewtopic. ... 862#964862
http://www.murga-linux.com/puppy/viewtopic.php?t=111371. See, in particular, jd7654's analysis of what works, and what doesn't. http://murga-linux.com/puppy/viewtopic. ... 267#965267
mikesLr
mikeslr wrote:Hi All,
I'm not sure if this falls under the heading "Buying into problems before they materialize" or "Reading the Writing on the Wall and Preparing to meet an unavoidable problem".
Short version: As far as I can tell, grub4dos is no longer maintained. The last version on the Puppy Linux Forum was created in 2014. Although it has support for Linux Ext4, it is unable to boot operating systems from drives formatted as 64 bit Linux Ext4.
See the following problems which have recently surfaced trying to boot Puppies:
http://murga-linux.com/puppy/viewtopic. ... 862#964862
http://www.murga-linux.com/puppy/viewtopic.php?t=111371. See, in particular, jd7654's analysis of what works, and what doesn't. http://murga-linux.com/puppy/viewtopic. ... 267#965267
mikesLr
Fyi, I have mutliple hard drives (from IDE to SATA I,II & III, internal and external), and all of them, save for one, is governed by grub4dos (the other one had grub2). Here's the thing: all those other drives? They are all formatted, inside pups, 64-bit ext4, and grub4dos is then next installed. fredx181 wrote:A workaround would be to edit /etc/mke2fs.conf to how it used to be in "older" systems.mikeslr wrote:Hi All,
I'm not sure if this falls under the heading "Buying into problems before they materialize" or "Reading the Writing on the Wall and Preparing to meet an unavoidable problem".
Short version: As far as I can tell, grub4dos is no longer maintained. The last version on the Puppy Linux Forum was created in 2014. Although it has support for Linux Ext4, it is unable to boot operating systems from drives formatted as 64 bit Linux Ext4.
See the following problems which have recently surfaced trying to boot Puppies:
http://murga-linux.com/puppy/viewtopic. ... 862#964862
http://www.murga-linux.com/puppy/viewtopic.php?t=111371. See, in particular, jd7654's analysis of what works, and what doesn't. http://murga-linux.com/puppy/viewtopic. ... 267#965267
mikesLr
The Stretch-Live build (also Stretchdog and Trinitydog-Stretch) has that workaround included, btw.
See for how to modify mke2fs.conf : http://murga-linux.com/puppy/viewtopic. ... 397#959397
Fred
To avoid confusion:belham2 wrote:mikeslr wrote:Hi All,
I'm not sure if this falls under the heading "Buying into problems before they materialize" or "Reading the Writing on the Wall and Preparing to meet an unavoidable problem".
Short version: As far as I can tell, grub4dos is no longer maintained. The last version on the Puppy Linux Forum was created in 2014. Although it has support for Linux Ext4, it is unable to boot operating systems from drives formatted as 64 bit Linux Ext4.
See the following problems which have recently surfaced trying to boot Puppies:
http://murga-linux.com/puppy/viewtopic. ... 862#964862
http://www.murga-linux.com/puppy/viewtopic.php?t=111371. See, in particular, jd7654's analysis of what works, and what doesn't. http://murga-linux.com/puppy/viewtopic. ... 267#965267
mikesLr
Hi Mike,
Uhhh, what?
Grub4dos even handles my drive that is specifically targetted to rpm distros. On that one, I am booting manjaro, openSUSE, antergos, pclinuxOS and Fedora......all S.O.B. distros that are finicky & picky as heck since some require require separate boot/home partitions to function well.
I am not sure what is being propagated out there, but it is complete nonsense that grub4dos "...is unable to boot operating systems from drives formatted as 64 bit Linux Ext4." Yeah, it currently is nt mantained, but it handles everything today with aplomb. It just is not automatic...a person has to pay a bit of attention.
HTH
Made new version of package apt2sfs with that change from jd7654, install:jd7654 wrote:Side note:
While playing around with Dog package tool AptToSfs to create sfs modules to load, ran into failures of that app when using older or newer forced version packages such as:
firefox-esr=24.8.0esr-1~deb8u2 mpv=0.23.0-2+b2
I found that if you remove the "=" sign from the working directory name, then the AptToSfs completed successsfully with those forced version packages.
Change to /usr/local/bin/apt2sfs line 352:
Code:
export SFS=$(for i in "$INSTALL"; do echo $(echo $i | sed 's| |_|g' | sed 's|=||g'); done)
Code: Select all
apt-get update
apt-get install apt2sfs # installs version 1.1.2Code: Select all
DESK_APPS_INSTALL="xfce4 xfce4-goodies slim"Code: Select all
startxfce4I don't know if ext3 has the same issue (64bit filesystem flag being set when created using newer systems)? Personally I prefer ext3 as for instance that can be rw from a freebsd boot, whereas ext4 is ro. I have used freebsd to create and restore backups using mksquashfs/unsquashfs and that works well with ext3. My understanding is that access is however ext2 like i.e. no journalling, but for a simple operation such as unsquashfs to restore the content of a ext3 partition from a backup using freebsd that's not really a issue anyway (if there was a power cut midway then likely you'd redo from afresh afterwards).fredx181 wrote:To avoid confusion:
It's not that grub4dos doesn't work anymore booting newer systems (e.g. Stretch), it's when formatting a drive by using a newer system
For info again: The Dogs and StretchLive won't have the problem because the workaround is included. (modified mke2fs.conf)