You are not logged in.
If you read the edit above . . . the task involves more than just making the isos. Some of the components might also need to be debugged . . .
That's part of my problem, no way I can de-bug that installer.
But the current live-iso of Devuan is using Refracta-installer which has the efi-grub as default, but also includes grub-pc with the installer knowing what to do if the user chooses a legacy BIOS install with grub installed to an MBR.
Couldn't it be as simple as using that iso for a base, updating, running usr-merge, changing sources.list to excalibur, upgrading, uninstalling dupe packages (is this what dist-upgrade is supposed to do? I did it by hand).
Then a simple snapshot. And once a week update and do another snapshot. Guarantee you I wouldn't hesitate to test a liveUSB if I was just a garden-variety user looking to help out if it's easy as downloading an iso and burning it to media and taking a test-drive, might get a lot more input that way.
ETA: Well obviously that won't solve the issue of other arches, but I can do amd_64 at least. Maybe other folks could do lives of other arches.
That's kind of what I thought, thank you Ralph for clarification.
A live system of current state-of-system for that week, is the best that I could do.
No live versions in that list. No live, no dice. What I have now is far more up-to-date than that.
@Ralph.Ronnquist . . . Didn't you move away from the Debian installer a while ago? Or perhaps I am misremembering.
For sure need to know this. You want a simple live-CD/DVD/USB build of current excalibur and i'll build you one every week until freeze and make it available online. For that kind of build/testing it should include a basic GUI interface, xfce will do although it's not optimum.
Okay, hot air, wow.
So exactly how can we help you find someone to build installer iso's? I'm happy to help if I can...
Seems a bit superfluous, it's like playing whack-a-mole at least until freeze since updates are pushed most every day, I have a working iso of it but it's full of bugs, and every time I fix one, 5 more pop up as soon as I update.
And I don't know who would have the patience to test installer iso's regularly with that gawdawful debian installer, especially when there are live-installers like Refracta that do in 10 minutes what the debian installer takes 2 hours to do...
Why is this conversation even happening when currently no one is building the installer isos! Seems like ya'll have lost sight of priorities . . .
I don't think there's anything I can personally do to help you find someone qualified and willing to assume that duty, if there was be assured I would do everything I could to help.
In the meantime it surely doesn't hurt to have a discourse about Devuan and it's components IMO.
Once you figured out which files are safe to delete, it's a small step automating this in a script. Which can then be packaged as a .deb for anyone to install as they see fit.
Just a thought wink
Or even just providing the script. I like the way you think. ![]()
It's not that i'm a zealot over systemd, what I am is an experimenter who set out a long time ago to do something about all the cruft that comes with most linux distributions, and just see what it really needed to run, and eliminate things that did not directly benefit the end-user (me). I care absolutely nothing about adoration or kudos or whatever, I enjoy the work and get a good amount of joy every single time I root out some hidden crap that doesn't belong.
It's a fact that smaller systems run faster and with less resource usage. In this day and age of ginormous amounts of storage space, ram and cpu power most people don't seem to care about the bloat though, and that's fine for them. But as for me, I have better uses for storage space.
Each little improvement may not seem like much, but added together over the years of learning what I could and could not get away with, I am able to make my own systems literally half the size or less.
It's just optimization, it's not a crusade. I'm not suggesting Devuan do this.
Devuan does not have the human resources to remove all of those useless barnacles though someone did manage to do it early on for Jessie.
Might be an interesting project for a rainy day. I already have quite a few "dummy" folders and files on my system from other stuff. I think best way to go about it, might be to start with a very minimal system, install it in conventional fashion to a USB stick (i.e. NOT a "liveUSB"), boot the stick, then start the "dummying" process to see what you can get away with before it breaks. A lot of stuff can probably just be outright deleted, and some programs just want to see that a folder or file exists with a certain name or verify that the package is installed according to apt.
I might just do it myself, if I do i'll report back.
1-21-2025 maintenance updates of the 5.03 ob-z's, new kernel 6.1.0-30-amd64 ( last week's new kernel didn't last long) + other updates and one addition. More info available, blog and wiki both up now.
Known issue with some Internet Service Providers and DNS, there are some workarounds for some folks posted in various threads, in some cases changing router settings may work.
Alternate solution is to choose a different mirror in your /etc/apt/sources.list file.
Do a forum search on this issue and you'll find several threads about it. I'm using a different mirror (gnlug) and it's working fine for me.
deb http://gnlug.org/pub/devuan/merged/ daedalus main contrib non-free non-free-firmware
deb http://gnlug.org/pub/devuan/merged/ daedalus-updates main
deb http://gnlug.org/pub/devuan/merged/ daedalus-security main I'm not into printing so much, but the wife is, so on her machine the first thing I install is usually system-config-printer and then specific drivers for our printer brand. It really makes configuring a breeze even for someone like me who generally doesn't use a printer.
Definitely stay within the repo unless you need a PPD that just isn't available.
^^^What dzz said.
Kinda confused here SpongeBOB, are you trying to make a liveUSB or are you trying to do a conventional install on a stick?
What live version?
Gparted: create new ms-dos partition table. Create fat32 main partition big enough to hold iso with some room to spare. Create 2nd partition in ext2 and name it "persistence. Then add boot flag to the first partition. done.
R2USB: use 01 or 02 first, I use 02 with the "findiso" option, finish that operation. It will want to install syslinux, let it do so. When done it will take you back to menu, then choose the option to create the persistence partition, run that, when it's done you are done, exit program.
You will be able to edit the boot entries and persistence.conf during the install or you can simply do it afterwards.
Maybe it is time for gparted to make the necessary adjustments.
Gparted definitely needs upgrading. It still won't properly recognize that I have two partitions on a liveUSB made with Mintstick and altered with gnome-disk-utility. The file manager (PCmanFM) easily recognizes the new data partition I have made and everything works normally and I am able to store data on the new partition.
As fsmithred said, it greatly depends on what you used to create the liveUSB.
I would use Refracta2usb or Mintstick to get best results. Mintstick won't get you persistence, Refracta2usb will.
There is also iso-master, but i've never tried it so have no idea if that would work for your scenario.
@Altoid, THANK YOU!! I'm sorry I don't have a good answer to your problem, but you just helped me solve one of mine that's been bugging me for a few weeks now with this portion of your post:
When I look at the installation media with gparted, it shows me a single ISO9660 file system taking up the whole 2.0Gb MicroSD card.
But when I look at it with the gnome-disk-utility, it shows me two partitions and free space.
This is the same problem i've had with Mintstick, it's super-fast and does a nice job in a hurry, but it also creates that ISO9660 fs that takes up the whole stick when in fact the iso is only 1.2 gigs, and i've been wanting a second partition just for data, not persistence, just data so when I rescue files from older PC's I have a place to store them easily.
Installed the gnome-disk-utility you mentioned, and it showed me the installed system was on it's own partition and the rest was literally empty space, just freakin empty space.
In it's menu if offered me the option of creating a new partition using that empty space, I did so and named it "DATA" and it worked perfectly and really fast, posting now from a liveUSB session using that very stick.
So again, big-time thank you and I hope you get your issue worked out!
Is this the proper section of the forum for this discussion? In Devuan Derivatives?
Human derived "celebrations" are useless, inconsequential and delusional and bind us to fantasies and the narratives de jour ( or try to).
And yet earlier in this very thread you said we all should have celebrated the solstice.
(We did so at my house ![]()
Well the first main difference is Vuu-do is not really a distro per se`, it's more of a personal project that I share on the internet. It's how I build systems for myself and family and friends. Crunchbang was a huge influence for me and I was sad to see it go, it was nice that other folks forked it and carried on, but they just weren't the same.
Second main difference is purely size, have a look at my projects, the difference is really stark in the older versions. I strip all translations out of Vuu-do, and I mean in a scorched-earth way most people can't even fathom taking the time to do, I even strip them out of .desktop files and places like the polkit-1 rules files, 10's of thousands of lines of code I removed by hand. Also everything in /usr/share/doc, docbase, bug, lintian, help, info, metainfo etc. etc. Extra icon packs get deleted, most of the large SVG's are deleted, extra themes, some video tutorials, more superfluous image files within programs like Libre-office. I retain basically only the man pages for help and take out a lot of the assistive stuff too. I go through almost every folder and file in the entire system.
It takes forever, but in the end the system is 30-50% smaller than it would normally be, and runs a lot faster with lighter resource usage.
The original versions back in 2017 were only 350 mb for the mini, and 560 for the max, goal was to keep them under 700 mb so they would fit on a CD. These days it's almost impossible to do that without removing a lot of the functionality. The 2018 max version even included all the firmware in the repo and every printer driver and firmware available for printing.
I really feel like my Openbox versions are some of the easiest to use of any Openbox versions made, i've done a lot of work to connect all the dots and make it feel and act like a dedicated DE like Mate or KDE.
Still my new versions are quite a bit smaller than most these days yet are very functional and nice looking (I think), and still very easy on resources and run fast even on old hardware, they are all built on my old 2012 Compaq laptop witha tiny dual-core APU at 1.00 ghz.
But a real distro includes all the docs and help files and translations, so that's why my stuff is just a project, an interesting take on what can be done about bloat that doesn't ever get used by most end-users.
EDIT: just saw your second post.
Microcrap employee dumps garbage code into the linux kernel.......just wondering who did it, perhaps somebody with the initials L.P. ?
I have despised pkexec since I first saw it, broke my heart to see gksu go bye-bye. You should be able to use it the same way gksu was used, just a simple "gksu (program name)" for things that need authentication, but oh hell no doesn't work like that. Piece of crap.
My current workaround: A script that adds all the pkexec bulls**t necessary to make authentication happen. Called it "gksu.sh" so now I just use that the same way I used to use gksu, i.e. "gksu.sh (program-name)". This is especially helpful for file-manager extensions that I wrote a long time ago that used gksu.
# Script to convert gksu to pkexec for extensions already written
# without adding a lot of code to the .desktop command line.
# Usage: "gksu.sh [program]"
#!/bin/bash
if [ -z $1 ]; then
echo -e "at least 1 argument required!\n" >> /dev/stderr
exit 1
fi
COMMAND=$1
shift #shift first arg
for ARG in "$@"
do
if [ -z "$ARGS" ]; then
ARGS="$ARG"
else
ARGS="$ARGS $ARG"
fi
done
ARGS=\'$ARGS\'
eval pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $COMMAND $ARGS
exit 0Nice! But don't you need to make a xorg.conf if you install the Nvidia drivers? Been years since I ran an Nvidia machine.
Another easy way to identify your chip is to install nvidia-detect then run that in terminal, it will also attempt to suggest what packages you might need to install for your chip.
Decided to give this a whirl today for the heck of it, some thoughts:
1. Worked fine, used mksq_opt="-comp lz4 -Xhc"
2. This was the only available option in mksquashfs for lz4, it does it's own thing and options available in the compressor are not all available when used in mksquashfs. I'm assuming the "Xhc" is it's way of using the lz4_hc variation that compresses more than just using lz4 does.
3. File size compressing 2.63 gig system: Zstd=859 mb Lz4=1.1 gb. So it's quite a bit larger, Zstd is already about 10% larger than Xz, Lz4 is about 40-45% larger than Xz, so it's a non-starter for my use as the file size is just too big.
4. Lz4 even at the high level I used, is MUCH faster compression, it took about half the time xz does, and a third of the time that zstd takes.
5. It's snappy as it can be in live-session use, but not sure there's much of a gain over zstd when all factors are considered, I still need to test an install with it to see if that's any faster, but the Refracta-installer on the zstd versions is so fast now it might be hard to tell any difference there either.
6. All in all zstd seems to be the best balance for everything but compression time where it's slow as molasses at high compression rates.
7. But if you are in a hurry to roll up an iso and don't care if it's larger, lz4 is the clear winner for speed even at it's highest compression level.