Hi Fred,
Sometimes, in the heat of the day, we say the wrong things, but we never escalate!
Peace in the valley!
And yes, both mount-wizard-orig and peasyglue work fine now. I have a feeling, under dash the whole system is running snappier. Great discovery Fred, will be a game changer.
Thank you for your work.
DebianDog - Jessie (21 June 2017)
I wouldn't get rid of the Debian Live boot methods.fredx181 wrote:Hi backi
So you are suggesting to have only one boot choice, porteus-boot ?As rufwoof mentioned :
" Personally I found the different boot choices 1, 2 or 3 to be confusing at first, and settled on what seemed the more familiar (1 porteus style). 2 I've never used. 3 I have, but partition saving isn't as good IMO as savefolder save (boot 1)."
Do much agree.
I see it as an important idea.
Maybe a lot of newbies feel rejected to use this amazing Tool, by an overkill of boot options they don`t quite understand (like myself ).
This would make DD appear more easier and beginner friendly.
It is not so much a technical enhancement ,but more a psychological one .
The more complex methods could be given to a later point.
Don't know yet, then the whole idea of DebianDog being 'puppyfied' but still 'pure' Debian (Live) will be gone. (when live-boot-3 isn't one of the choices)
Fred
It is more a "marketing" thing. Something like:
Then in the sample boot methods txt file, simply put the Porteus method first instead of last, with a little intro saying: "For beginners, especially those familiar with Puppy Linux, we recommend the Porteus boot method.""For beginners, especially those familiar with Puppy Linux, we recommend the Porteus boot method. You can also boot using 2 different methods from Debian Live. [link to Debian Live methods on a different page].
[Explanaton Porteus method]"
Still temporarily 'here' (oh my goodness...). Just wanted to mention that I also mainly use Openbox (with pcmanfm) though I do like having Rox filemanager available too. I don't think we need to use JWM just because Puppy does - openbox options Fred provides seems to me to be more flexible (I like how in openbox you can drag a file onto a minimised taskbar icon and it opens up - not sure if JWM can do that.
Fred is pretty good at creating a JWM addon anyway.
But, yes, I totally agree - main problem with original DebianDog series is that too many options were provided - great for those of us who have used Linux for a long time but must be offputtingly complex for newer Linux users and less technical users. All these extra options don't need to be taken away - just put into the background of separate thread for alternate possibilities I feel.
EDIT: It seems to me that the 'remaster' approach to building/customising/creating 'new' distributions is more accessible to most people than complex (semi)automatic build systems such as woof. One reason may simply be psychological in that we all tend to be a bit lazy having to learn how a build system works before we can tailor it to our own needs. A remastering process, on the other hand, can involve us immediately - then the task becomes simply selecting what we want along with modifying existing functionality in what is already there and adding new functionality in the form of utilities and custom apps - more user friendly than a build system for most I think. Build systems also tend to be somewhat inflexible in the sense that they have been designed a particular way and tend to produce a relatively fixed template in terms of distribution structure (which can be both a good thing and a bad thing I suppose).
EDIT2: I think original woof was partly created so that BarryK could pass on a recreatable project, such that he could 'retire', especially since primarily adopting Debian/Ubuntu/Slackware repositories. Main problem with that concept, for me, is that package management should also have moved towards those of Debian/Ubuntu (and Slackware when required) rather that using Debian/Ubuntu repositories via modified petget package manager - hence DebianDog alternative approach being preferred by me at least: like a Puppy in some ways but full dpkg/apt capability - had it not been for woof philosophy/design, I feel official Puppy developments could have moved forward better with full dpkg/apt capability - however, just my opinion.
William
I'm really going back to my break now (!) unless I come up with anything that I feel might be particularly useful somewhere or to address any issues to do with my own creations such as weX.
Fred is pretty good at creating a JWM addon anyway.
But, yes, I totally agree - main problem with original DebianDog series is that too many options were provided - great for those of us who have used Linux for a long time but must be offputtingly complex for newer Linux users and less technical users. All these extra options don't need to be taken away - just put into the background of separate thread for alternate possibilities I feel.
EDIT: It seems to me that the 'remaster' approach to building/customising/creating 'new' distributions is more accessible to most people than complex (semi)automatic build systems such as woof. One reason may simply be psychological in that we all tend to be a bit lazy having to learn how a build system works before we can tailor it to our own needs. A remastering process, on the other hand, can involve us immediately - then the task becomes simply selecting what we want along with modifying existing functionality in what is already there and adding new functionality in the form of utilities and custom apps - more user friendly than a build system for most I think. Build systems also tend to be somewhat inflexible in the sense that they have been designed a particular way and tend to produce a relatively fixed template in terms of distribution structure (which can be both a good thing and a bad thing I suppose).
EDIT2: I think original woof was partly created so that BarryK could pass on a recreatable project, such that he could 'retire', especially since primarily adopting Debian/Ubuntu/Slackware repositories. Main problem with that concept, for me, is that package management should also have moved towards those of Debian/Ubuntu (and Slackware when required) rather that using Debian/Ubuntu repositories via modified petget package manager - hence DebianDog alternative approach being preferred by me at least: like a Puppy in some ways but full dpkg/apt capability - had it not been for woof philosophy/design, I feel official Puppy developments could have moved forward better with full dpkg/apt capability - however, just my opinion.
William
I'm really going back to my break now (!) unless I come up with anything that I feel might be particularly useful somewhere or to address any issues to do with my own creations such as weX.
github mcewanw
Hi dancytron!.... hi mcewanw !
You said:
"I wouldn't get rid of the Debian Live boot methods.
It is more a "marketing" thing. Something like:"
Quote:
"For beginners, especially those familiar with Puppy Linux, we recommend the Porteus boot method. You can also boot using 2 different methods from Debian Live. [link to Debian Live methods on a different page].
[Explanaton Porteus method]"
Then in the sample boot methods txt file, simply put the Porteus method first instead of last, with a little intro saying: "For beginners, especially those familiar with Puppy Linux, we recommend the Porteus boot method."
mcewanw said :
" But, yes, I totally agree - main problem with original DebianDog series is that too many options were provided - great for those of us who have used Linux for a long time but must be off puttingly complex for newer Linux users and less technical users. All these extra options don't need to be taken away - just put into the background of separate thread for alternate possibilities I feel."
Exactly you guys .....you took the words right out of my mouth .
You said:
"I wouldn't get rid of the Debian Live boot methods.
It is more a "marketing" thing. Something like:"
Quote:
"For beginners, especially those familiar with Puppy Linux, we recommend the Porteus boot method. You can also boot using 2 different methods from Debian Live. [link to Debian Live methods on a different page].
[Explanaton Porteus method]"
Then in the sample boot methods txt file, simply put the Porteus method first instead of last, with a little intro saying: "For beginners, especially those familiar with Puppy Linux, we recommend the Porteus boot method."
mcewanw said :
" But, yes, I totally agree - main problem with original DebianDog series is that too many options were provided - great for those of us who have used Linux for a long time but must be off puttingly complex for newer Linux users and less technical users. All these extra options don't need to be taken away - just put into the background of separate thread for alternate possibilities I feel."
Exactly you guys .....you took the words right out of my mouth .
mcewanw wrote :
"Main problem with that concept, for me, is that package management should also have moved towards those of Debian/Ubuntu (and Slackware when required) rather that using Debian/Ubuntu repositories via modified petget package manager.
- hence DebianDog alternative approach being preferred by me at least: like a Puppy in some ways but full dpkg/apt capability - had it not been for woof philosophy/design, I feel official Puppy developments could have moved forward better with full dpkg/apt capability - however, just my opinion."
This and some more things ,like going frugal instead of full install (easy restoring of backed up savefile ,using applications via sfs or squashfs instead of installing , " Saving on demand" ,... this and more makes D-D so avantgarde and results in a far more stable-robust system ...a very import step in Puppies development (and also Debian or Ubuntu )
....stepping outside any Puppy Fundamentalism .
Who could ask for more .
With all this fine-tuning which is done lately.....Deb-Dog becomes more and more some kind of Maserati in Linux World riding on a fast lane.
Show me one Distro-Project more versatile......
I think .. it is hard to beat .....
" So the Winner is.........."
Cheers
"Main problem with that concept, for me, is that package management should also have moved towards those of Debian/Ubuntu (and Slackware when required) rather that using Debian/Ubuntu repositories via modified petget package manager.
- hence DebianDog alternative approach being preferred by me at least: like a Puppy in some ways but full dpkg/apt capability - had it not been for woof philosophy/design, I feel official Puppy developments could have moved forward better with full dpkg/apt capability - however, just my opinion."
This and some more things ,like going frugal instead of full install (easy restoring of backed up savefile ,using applications via sfs or squashfs instead of installing , " Saving on demand" ,... this and more makes D-D so avantgarde and results in a far more stable-robust system ...a very import step in Puppies development (and also Debian or Ubuntu )
....stepping outside any Puppy Fundamentalism .
Who could ask for more .
With all this fine-tuning which is done lately.....Deb-Dog becomes more and more some kind of Maserati in Linux World riding on a fast lane.
Show me one Distro-Project more versatile......
I think .. it is hard to beat .....
" So the Winner is.........."
Cheers
Hi anikin and everyone
It appears that "switchsh" is not as reliable as I thought is was.
For example: the mount command doesn't work via switchsh:
This is why mount-wizard didn't work via switchsh.
Also when running pburn, browsing for ISO, the partitions that were not already mounted, will not mount when clicking on it (in the left side panel) (they should be mounted and opened when you do that).
This gtkdialog sh > dash combination 'trick' via switchsh was a nice try, but just doesn't work for all applications.
(it's beginning to be an unhealthy obsession for me, so I have to give up)
So.. I see no other way then setting it up the same again as in previous DD versions:
-- symlink sh > bash by using dpkg-reconfigure:
-- install standard gtkdialog again:
Sorry for some misleading info in earlier posts from me.
Fred
OK!!Sometimes, in the heat of the day, we say the wrong things, but we never escalate!
Peace in the valley!
Well, don't want to spoil the party, but..And yes, both mount-wizard-orig and peasyglue work fine now. I have a feeling, under dash the whole system is running snappier. Great discovery Fred, will be a game changer.
It appears that "switchsh" is not as reliable as I thought is was.
For example: the mount command doesn't work via switchsh:
Code: Select all
switchsh mkdir /media/sda3 # this works ok
switchsh mount /dev/sda3 /media/sda3 # this does nothing, no error message either Also when running pburn, browsing for ISO, the partitions that were not already mounted, will not mount when clicking on it (in the left side panel) (they should be mounted and opened when you do that).
This gtkdialog sh > dash combination 'trick' via switchsh was a nice try, but just doesn't work for all applications.
(it's beginning to be an unhealthy obsession for me, so I have to give up)
So.. I see no other way then setting it up the same again as in previous DD versions:
-- symlink sh > bash by using dpkg-reconfigure:
Code: Select all
dpkg-reconfigure dash # choose 'No'Code: Select all
apt-get install gtkdialog=0.8.3-1Fred
Re; too many boot options
Re; too many boot options
We could also ditch live-boot-2, once it was official Debian, but not anymore for a long time (now live-boot-3/4) and I bet that almost nobody uses live-boot-2.
Fred
Yes, I like that."I wouldn't get rid of the Debian Live boot methods.
It is more a "marketing" thing. Something like:"
Quote:
"For beginners, especially those familiar with Puppy Linux, we recommend the Porteus boot method. You can also boot using 2 different methods from Debian Live. [link to Debian Live methods on a different page].
[Explanaton Porteus method]"
Then in the sample boot methods txt file, simply put the Porteus method first instead of last, with a little intro saying: "For beginners, especially those familiar with Puppy Linux, we recommend the Porteus boot method."
We could also ditch live-boot-2, once it was official Debian, but not anymore for a long time (now live-boot-3/4) and I bet that almost nobody uses live-boot-2.
Fred
Boot 2 was Squeeze, outdated. Boot 1 supports save file or save folder, Boot 3 supports save file or save partition.
Perhaps merge the two initrd's for boot 1 and 3 into a single initrd, a common vmlinuz and some additional code within linuxrc to redirect to one or the other blocks of code (boot 1 or boot 3) according to which boot parameters were specified.
As a core system, Openbox/xfce (lxde) definitely has the edge IMO over rox/jwm, more easy to configure.
Have a single sfs with massive firmware/drivers ... as a get you going. Another large sfs with common programs. Keeps the core lean (save folder content light).
I'd guess perhaps 150MB core, and 300MB for each of the main applications sfs and firmware, where the firmware one could be dropped once the system was configured (needed contents migrated over to the core savefile).
Simple single choices for new users to understand (single files). High probability it will work - graphical desktop/net connected. And a choice to load a bulk standard set of programs that all work well with each other (main 'programs' sfs sourced by Debian), or DIY build one for themselves (apt2sfs libreoffice audacity pcmanfm ...etc (i.e. modular)). If users save their stuff (docs etc) outside on a separate partition, then the savefolder content is predominately just configuration changes/values, keeping the core lean.
Perhaps merge the two initrd's for boot 1 and 3 into a single initrd, a common vmlinuz and some additional code within linuxrc to redirect to one or the other blocks of code (boot 1 or boot 3) according to which boot parameters were specified.
As a core system, Openbox/xfce (lxde) definitely has the edge IMO over rox/jwm, more easy to configure.
Have a single sfs with massive firmware/drivers ... as a get you going. Another large sfs with common programs. Keeps the core lean (save folder content light).
I'd guess perhaps 150MB core, and 300MB for each of the main applications sfs and firmware, where the firmware one could be dropped once the system was configured (needed contents migrated over to the core savefile).
Simple single choices for new users to understand (single files). High probability it will work - graphical desktop/net connected. And a choice to load a bulk standard set of programs that all work well with each other (main 'programs' sfs sourced by Debian), or DIY build one for themselves (apt2sfs libreoffice audacity pcmanfm ...etc (i.e. modular)). If users save their stuff (docs etc) outside on a separate partition, then the savefolder content is predominately just configuration changes/values, keeping the core lean.
Hi Fred et al,
1) Debian boot method
The official one, it implies the current version of live-boot, whatever that might be - 3,4, etc., Anyone can look it up in Debian packages https://packages.debian.org/search?sear ... =live-boot to make sure which one.
2) DD Porteus boot method.
As the name suggests, this one is based on Porteus and has been created specifically for DD.
As you know, there's no such thing as boot methods in Debian - there are only live-boot versions.
At least, you brought us very close - as never before to adopting dash. As they say, there's no such thing as failure - there are variable degrees of success. Your effort has been a success.Fred wrote:Well, don't want to spoil the party, but..
It appears that "switchsh" is not as reliable as I thought is was
Yes, and maybe to make it absolutely clear and simple for newcomers, by boot methods we mean only 2 options:Fred wrote:We could also ditch live-boot-2, once it was official Debian, but not anymore for a long time (now live-boot-3/4) and I bet that almost nobody uses live-boot-2
1) Debian boot method
The official one, it implies the current version of live-boot, whatever that might be - 3,4, etc., Anyone can look it up in Debian packages https://packages.debian.org/search?sear ... =live-boot to make sure which one.
2) DD Porteus boot method.
As the name suggests, this one is based on Porteus and has been created specifically for DD.
As you know, there's no such thing as boot methods in Debian - there are only live-boot versions.
Hi rufwoof !
Tested your new Remaster concept from your :
https://drive.google.com/file/d/0B4MbXu ... sp=sharing
This is pretty cool for beginners .Fast and simple ........I like it .
One have the choice of making changes easily permanent (part of your core-system -Just one click- Remaster just an empty Changes-folder left behind )..... or flexible- just one click- save ( saves to Changes-folder ) .
No hassle... bulletproof for everyone .
So keep on rocking ruf .
Tested your new Remaster concept from your :
https://drive.google.com/file/d/0B4MbXu ... sp=sharing
This is pretty cool for beginners .Fast and simple ........I like it .
One have the choice of making changes easily permanent (part of your core-system -Just one click- Remaster just an empty Changes-folder left behind )..... or flexible- just one click- save ( saves to Changes-folder ) .
No hassle... bulletproof for everyone .
So keep on rocking ruf
.Using Fred's recent beta ISO ...
Compressed boot1 initrd weighs in at around 10MB, boot3 15MB. Creating two folders boot1 and boot3 with their respective initrd content and a small / level script, reformed and xz compressed comes in at 25MB (I had hoped to see some overlap reduction in size compared to the simple sum of both ... but clearly not).
As gzip compressed 34MB
Rounding ...
33MB non compressed boot1
151MB non compressed boot3
185MB non compressed combined
The template root level init script content I used was (clearly non-working)
Compressed boot1 initrd weighs in at around 10MB, boot3 15MB. Creating two folders boot1 and boot3 with their respective initrd content and a small / level script, reformed and xz compressed comes in at 25MB (I had hoped to see some overlap reduction in size compared to the simple sum of both ... but clearly not).
As gzip compressed 34MB
Rounding ...
33MB non compressed boot1
151MB non compressed boot3
185MB non compressed combined
The template root level init script content I used was (clearly non-working)
Code: Select all
#!/boot3/bin/sh
export PATH=/boot3/sbin:/boot3/usr/sbin:/boot3/bin:boot3/usr/bin
for x in $(cat /proc/cmdline); do
case $x in
bootmethod=*)
BOOTMETHOD=${x#bootmethod=}
;;
esac
done
chroot ./$BOOTMETHOD init "$@"Thanks all, it's a pleasure for me to see this thread reviving, specially rufwoof's ideas and the great progression he makes in scripting.
Hard to keep up, though!
My goal is still to create a new DebianDog openbox_xfce 2nd edition, with the bugs fixed of course (I'll leave Jwm version up to Toni) and update the DD-github pages with new/modified information and links to new (or improved) project(s).
Previously this was Toni's project and he was always been "sort of a leader" (well... at least a guard, to make sure things didn't go wrong, e.g. finding unexpected possible bugs, in any way realistic about things).
Now it's much more like a community project which I like very much (although have to get used to it and there's a risk of chaos).
I'll try in the next days to index for myself every idea/suggestion from the previous pages and get back later about it .
Fred
Hard to keep up, though!
My goal is still to create a new DebianDog openbox_xfce 2nd edition, with the bugs fixed of course (I'll leave Jwm version up to Toni) and update the DD-github pages with new/modified information and links to new (or improved) project(s).
Previously this was Toni's project and he was always been "sort of a leader" (well... at least a guard, to make sure things didn't go wrong, e.g. finding unexpected possible bugs, in any way realistic about things).
Now it's much more like a community project which I like very much (although have to get used to it and there's a risk of chaos).
I'll try in the next days to index for myself every idea/suggestion from the previous pages and get back later about it .
Fred
Another suggestion Fred ... grab a copy of the debian live cd, copy the live folder to hdd, extract the content of filesystem.squashfs to / and create a empty filesystem.squashfs. Also copy the boot folder across from the live cd and have sym links from /initrd and /vmlinuz into the /boot folder contents.
If you don't mind a less snappy system ... that works as a full install within a layered filesystem so you can load sfs's, run read only sessions that with the addition of a single script (save2flash) can save to disk (merging is slower as there's more to find/compare during merging). A major benefit is that kernel updates are possible, such that in time when Debian move on to the next version/different kernel, updates occur 'automatically'.
Add in apt2sfs type scripts and you can keep the core system 'pure Debian' layered with additional non-debian (dogradio for instance) as sfs's.
It is, as I said, the slowest to boot/save however. But once up and running for a while with much already cached, general performance tends to compare. And with time and as more move to SSD's the difference is speeds will tend to narrow.
If you don't mind a less snappy system ... that works as a full install within a layered filesystem so you can load sfs's, run read only sessions that with the addition of a single script (save2flash) can save to disk (merging is slower as there's more to find/compare during merging). A major benefit is that kernel updates are possible, such that in time when Debian move on to the next version/different kernel, updates occur 'automatically'.
Add in apt2sfs type scripts and you can keep the core system 'pure Debian' layered with additional non-debian (dogradio for instance) as sfs's.
It is, as I said, the slowest to boot/save however. But once up and running for a while with much already cached, general performance tends to compare. And with time and as more move to SSD's the difference is speeds will tend to narrow.
You want to drive me crazy?rufwoof wrote:Another suggestion Fred ... grab a copy of the debian live cd, copy the live folder to hdd, extract the content of filesystem.squashfs to / and create a empty filesystem.squashfs. Also copy the boot folder across from the live cd and have sym links from /initrd and /vmlinuz into the /boot folder contents.
If you don't mind a less snappy system ... that works as a full install within a layered filesystem so you can load sfs's, run read only sessions that with the addition of a single script (save2flash) can save to disk (merging is slower as there's more to find/compare during merging). A major benefit is that kernel updates are possible, such that in time when Debian move on to the next version/different kernel, updates occur 'automatically'.
Add in apt2sfs type scripts and you can keep the core system 'pure Debian' layered with additional non-debian (dogradio for instance) as sfs's.
It is, as I said, the slowest to boot/save however. But once up and running for a while with much already cached, general performance tends to compare. And with time and as more move to SSD's the difference is speeds will tend to narrow.
Fred
Hi rufwoof,
Can you check if the attached remaster script is alright for you? (I modified a little)
I added check for if porteus-boot is in use or not at the beginning, and at the end changed wmreboot to reboot (see fredx181 comments)
I like to add it as Menu entry with name something like "Quick-Remaster" but that's up to you how to name it.
Later I will check with you the changes required for it in linuxrc.
Maybe it's good at some point in the script to check if filesystem.module exists, if not, do something like: "echo filesystem.squashfs > filesystem.module", just a thought.
Fred
Can you check if the attached remaster script is alright for you? (I modified a little)
I added check for if porteus-boot is in use or not at the beginning, and at the end changed wmreboot to reboot (see fredx181 comments)
I like to add it as Menu entry with name something like "Quick-Remaster" but that's up to you how to name it.
Later I will check with you the changes required for it in linuxrc.
Maybe it's good at some point in the script to check if filesystem.module exists, if not, do something like: "echo filesystem.squashfs > filesystem.module", just a thought.
Fred
- Attachments
-
- quick-remaster.gz
- Quick-Remaster (fake .gz)
- (4.95 KiB) Downloaded 268 times
A neat feature of boot 3 is everything is self contained, the same initrd whether you're booting a full install or a frugal install. My LXDE 64 install for instance is installed to the first partition, along with grub4dos menu.lst and also has the Debian boot loader (grub) in /boot ... and that same partition is set to be the persistence (save folder) partition.
With everything in /live/filesystem.squashfs more usually, but I can fully extract that to / and then boot via grub (chained from menu.lst) and it acts as a full install (all changes immediately written to disk, kernel can be updated via apt-get upgrade ...etc.). Then afterwards I can reboot persistence (frugal), run a remaster and all of / (save folder) is moved back into filesystem.squashfs (except menu.lst bootloader ...etc files).
In short you can flip between being a 'full install' to/from being a frugal install using /live/filesystem.squashfs - with / as being the 'save folder'. And that caters for the kernel being upgraded/updated. In contrast, with boot 1, you have to lock (pin) the kernel/initrd.
The only downside is that, unlike boot 1, it doesn't support save to folder, only save to file or save to partition (where the partition can be the same one as where the filesystem and menu.lst are).
Point being ... you can target how involved (potentially driving you mad at one end, to very low effort at the other end) you might want to make DebianDog. At the lightest effort end could be just a couple of scripts, save2flash and single click remaster, applied to a boot 3 setup (as supplied by Debian), perhaps with the core desktop being Openbox/LXDE (as supplied by Debian). At the other end you might target DD as being three different boot styles, two different desktop setups (Openbox and Rox/Jwm) ... or as complicated as you like.
With everything in /live/filesystem.squashfs more usually, but I can fully extract that to / and then boot via grub (chained from menu.lst) and it acts as a full install (all changes immediately written to disk, kernel can be updated via apt-get upgrade ...etc.). Then afterwards I can reboot persistence (frugal), run a remaster and all of / (save folder) is moved back into filesystem.squashfs (except menu.lst bootloader ...etc files).
In short you can flip between being a 'full install' to/from being a frugal install using /live/filesystem.squashfs - with / as being the 'save folder'. And that caters for the kernel being upgraded/updated. In contrast, with boot 1, you have to lock (pin) the kernel/initrd.
The only downside is that, unlike boot 1, it doesn't support save to folder, only save to file or save to partition (where the partition can be the same one as where the filesystem and menu.lst are).
Point being ... you can target how involved (potentially driving you mad at one end, to very low effort at the other end) you might want to make DebianDog. At the lightest effort end could be just a couple of scripts, save2flash and single click remaster, applied to a boot 3 setup (as supplied by Debian), perhaps with the core desktop being Openbox/LXDE (as supplied by Debian). At the other end you might target DD as being three different boot styles, two different desktop setups (Openbox and Rox/Jwm) ... or as complicated as you like.
Looks good to me Fred. reboot is a good choice, I edited my wmreboot and commented out the saving choices and splash to equal effect. The Porteus check ... you know better than me anyway, so I'd say its good to go.fredx181 wrote:Can you check if the attached remaster script is alright for you?
My boot 3 remaster is similar in many ways, but it does its own clearing out of the save 'folder' (which is a partition in boot 3 case, and that in my case is shared alongside /live folder and menu.lst .....etc, so its a selective 'clean'). If it were in its own dedicated partition then it could all be wiped. One issue with that however is that depending upon the amount of changes, removing files can lead to a system lockup and having to hard shutdown (hold power button for 5 seconds). The Porteus version is cleaner in that respect (left to initrd to do the cleaning at the next reboot). With boot 3 and accepting kernel/initrd updates from Debian means that cleaning can't be coded into the initrd ... unless you pin that kernel/version.
Code: Select all
#!/bin/bash
BOOT=`cat /proc/cmdline | grep persistence-read-only`
if [ -z "${BOOT}" ]; then
exit 1
fi
/usr/local/bin/flush2disk # Store latest changes
RetCode=$?
if [ $RetCode -eq 3 ]; then
echo
read -p "Continue with remaster (y/n) " -n 1 -r
if [[ $REPLY =~ ^[Yy]$ ]]
then
echo
echo Remastering without current session changes
else
echo
echo Cancelling remaster
sleep 5
exit 3
fi
fi
echo
sync
LABEL=`cat /proc/cmdline | awk 'BEGIN{FS="persistence-label="} {print $2}' | awk 'BEGIN{FS=" "} {print $1}'`
BASE=`mount -l | grep "\[$LABEL\]" | grep -m 1 /lib/live/mount/persistence | awk 'BEGIN{FS=" "} {print $3}'`
if [ -z "${BASE}" ]; then
echo cannot identify installation type - exiting
sleep 4
exit
fi
cd $BASE/live
mkdir remaster
cd remaster
mkdir -p tmp1 tmpa
# read filesystem.module to determine which of the two toggles to use
CURRENT=`cat ${BASE}/live/filesystem.module | grep filesystem | grep squashfs`
mount -o loop ${BASE}/live/$CURRENT tmp1/
mount -t aufs -o br:$BASE:tmp1 none tmpa/
CURRENT=`echo $CURRENT | sed s/.squashfs//`
if [ ! -z `echo $CURRENT | grep 01` ]; then
if [ -f $BASE/live/filesystem.squashfs ]; then
rm $BASE/live/filesystem.squashfs
fi
mksquashfs2 tmpa $BASE/live/filesystem.squashfs -comp lzo -Xcompression-level 1 -e tce live Documents boot lost+found persistence.conf vmlinuz initrd.img grldr menu.lst sdb_mbr.bak debian-usb
sed -i "s/filesystem01.squashfs/filesystem.squashfs/" $BASE/live/filesystem.module
else
if [ -f ${BASE}/live/filesystem01.squashfs ]; then
rm $BASE/live/filesystem01.squashfs
fi
mksquashfs2 tmpa $BASE/live/filesystem01.squashfs -comp lzo -Xcompression-level 1 -e tce live Documents boot lost+found persistence.conf vmlinuz initrd.img grldr menu.lst sdb_mbr.bak debian-usb
sed -i "s/filesystem.squashfs/filesystem01.squashfs/" $BASE/live/filesystem.module
fi
sync
umount -f tmpa tmp1
rmdir tmpa tmp1
cd ..
rmdir remaster
cd $BASE
rm -rf root etc .wh* .gtk* lib usr var .Trash* bin dev lib32 lib64 live-build opt media mnt proc home run sbin srv sys tmp
sync
exit 2Code: Select all
#!/bin/bash
read -p "Flush changes recorded in memory to disk : Are you sure? (y/n) " -n 1 -r
if [[ $REPLY =~ ^[Yy]$ ]]
then
echo
sudo flush2disk.sh
exit 0
else
exit 3 # can be called by remaster so we include a error # here for that
fi
echosystemD unit/service
For boot 3 this is a cleaner way to clean out the persistence files after a remaster ... add a systemD service
Create a executable script to do the persistence (save) cleaning, but only if /tmp/cleanpersistence file exists ... mine looks like :
/usr/local/bin/persistence
Create a systemD service to link that into systemD
/lib/systemd/system/persistence.service
... and enable it
systemctl enable persistence.service
you can check its status is enabled by scanning through
systemctl list-unit-files
that shows all files, or just look for the single file by name
root@debian:/home/user# systemctl list-unit-files persistence.service
UNIT FILE STATE
persistence.service enabled
1 unit files listed.
root@debian:/home/user#
so now all remaster.sh script has to do is create a /tmp/cleanpersistence flag file
touch /tmp/cleanpersistence
... and when the system reboots, halts, shutsdown the persistence.service will fire up /usr/local/bin/persistence ... which cleans out the persistence (save) files/folders
Not sure, but if you edit the /usr/local/bin/persistence script you may have to (???) deactivate and reactivate the persistence.service so that it re-sym-links in that new code
systemctl disable persistence.service
systemctl enable persistence.service
I haven't thoroughly tested it yet - but working well so far for me Leaving deletion of live running files right to the end of shutdown/halt/reboot (i.e. in single user mode rc.0 or rc.6) is less inclined to cause a system lock-up as was the case if the remaster script deleted those files whilst still in multi-user mode.
UPDATE : No luck. For very large updates that still can result in shutdown locking up (needing a hard shutdown).
out the persistence files after a remaster ... add a systemD service Create a executable script to do the persistence (save) cleaning, but only if /tmp/cleanpersistence file exists ... mine looks like :
/usr/local/bin/persistence
Code: Select all
#!/bin/bash
if [ -f /tmp/cleanpersistence ]; then
LABEL=`cat /proc/cmdline | awk 'BEGIN{FS="persistence-label="} {print $2}' | awk 'BEGIN{FS=" "} {print $1}'`
BASE=`mount -l | grep "\[$LABEL\]" | grep -m 1 /lib/live/mount/persistence | awk 'BEGIN{FS=" "} {print $3}'`
if [ -z "${BASE}" ]; then
exit
fi
cd $BASE
rm -rf root etc .wh* .gtk* lib usr var .Trash* bin dev lib32 lib64 live-build opt media mnt proc home run sbin srv sys tmp
fi/lib/systemd/system/persistence.service
Code: Select all
[Unit]
Description=persistence clean if requested
DefaultDependencies=no
Before=shutdown.target reboot.target halt.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/persistence
[Install]
WantedBy=halt.target reboot.target shutdown.targetsystemctl enable persistence.service
you can check its status is enabled by scanning through
systemctl list-unit-files
that shows all files, or just look for the single file by name
root@debian:/home/user# systemctl list-unit-files persistence.service
UNIT FILE STATE
persistence.service enabled
1 unit files listed.
root@debian:/home/user#
so now all remaster.sh script has to do is create a /tmp/cleanpersistence flag file
touch /tmp/cleanpersistence
... and when the system reboots, halts, shutsdown the persistence.service will fire up /usr/local/bin/persistence ... which cleans out the persistence (save) files/folders
Not sure, but if you edit the /usr/local/bin/persistence script you may have to (???) deactivate and reactivate the persistence.service so that it re-sym-links in that new code
systemctl disable persistence.service
systemctl enable persistence.service
I haven't thoroughly tested it yet - but working well so far for me
Leaving deletion of live running files right to the end of shutdown/halt/reboot (i.e. in single user mode rc.0 or rc.6) is less inclined to cause a system lock-up as was the case if the remaster script deleted those files whilst still in multi-user mode.UPDATE : No luck. For very large updates that still can result in shutdown locking up (needing a hard shutdown).
Re: systemD unit/service
Hi Everyone,
rufwoof,
Is there a hidden meaning in your remastering concept?
I'm thinking at the top of my mind and can't get the gist of it. Please, don't get me wrong, but remastering is a very basic thing. It boils down to the following:
1) You remaster to preserve the changes to the system without *any* save/persistence options.
2) Or, alternatively, you preserve the changes via save/persistence options.
It's that simple, a binary choice: either remaster, or use persistence/save, but don't mix them together. I remaster a lot and use Toni's remastering script, that he created a long time ago at my request (see the attachment). It is extremely simple, but works flawlessly not only on DD but any Debian/Ubuntu live. Fred has a GUI remastering tool, that also works nicely.
rufwoof wrote:For boot 3 this is a cleaner way to clean
rufwoof,
Is there a hidden meaning in your remastering concept?
I'm thinking at the top of my mind and can't get the gist of it. Please, don't get me wrong, but remastering is a very basic thing. It boils down to the following:
1) You remaster to preserve the changes to the system without *any* save/persistence options.
2) Or, alternatively, you preserve the changes via save/persistence options.
It's that simple, a binary choice: either remaster, or use persistence/save, but don't mix them together. I remaster a lot and use Toni's remastering script, that he created a long time ago at my request (see the attachment). It is extremely simple, but works flawlessly not only on DD but any Debian/Ubuntu live. Fred has a GUI remastering tool, that also works nicely.
- Attachments
-
- remasterdog.sh.gz
- fake gz
- (2.75 KiB) Downloaded 246 times