Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Interest in a lower compression iso optimized for USB booting?
#1
Due to the goal of maximizing compatibility and including as many useful applications into the constraints of a 700MB CD size I am using zx compression on the ISO.  The trade-off here is that time to boot from the live image can be impacted.  It isn't that noticeable on more powerful hardware, but on light weight netbooks or virtual machines it can slow the process of booting down.  This does not affect boot time once DSL is installed on a hard drive.

I've noticed that a lot of people are installing DSL 2024 on pen drives and using them to boot their netbooks or running DSL in a virtual machine.  It would not be very difficult to provide an ISO that is optimized for these boot methods.  With an identical build but switching from zx compression to lz4 compression I've halved the boot time in Qemu.  The drawback is that the ISO is larger, 1084M vs. 632M for the zx version -- not really critical for most people who are interested in running DSL in a virtual machine or booting from USB.

So, is there interest?  Could I get people to report the difference in boot time?
Reply
#2
I'd be happy to experiment if you do this. I have a candidate machine sitting there on the back of the other sofa doing nothing .. a Toshiba NB520. I don't trust the hard disk controller as I had a disk die in a very strange manner, so USB boot is the only option without a "sacrificial" HDD to do further tests with.

It's a dual-core Atom @ 1.66GHz with (I think) 2GB RAM. Same CPU as my Acer Aspire One, which although in use it wouldn't hurt to test with as well. Only a reboot needed .. which I typically do once in a blue moon. That definitely has 2GB RAM.
Reply
#3
I'll volunteer to do it as well--just need clear communication about when it's "up" or if you want text only, etc. I've got a couple even older machines I can drag-out too.

This brings-up another issue, specifically, the stuff inside the squashfs files that's gzipped -- like the initrd.

I started looking the other day and started taking screens in Vbox, but I haven't figured-out anticap's scripts enough to remaster (I'm new here and build-iso itself is 4k lines, etc) outside of the tool yet.

Soooo, the initrd about 25MB, gzipped inside the squash is 10+ MB. Applying xz to that gets it to ~7.5MB etc. Kernel config looks like it's built to boot from xz as well. Compressing the initrd with xz seems to boot (Slackware uses it) _if_ the --check=crc32 is used at compression, FWIW.

If you
grep -iE "(initrd|xz|initramfs)" ./config-5.10.188-antic.1-486-smp
and
grep CONFIG_RD_

all that stuff is the same as the Slackware config that boots xz-compressed initrds, FWIW.

I just don't know enough yet--now many md5 checks are in the installer where, etc, or how to remaster ($MAKE_ISO seems command-line arg in the script so not even xorriso cmd, etc). I looked at some mx scripts too but it's all unclear. Perhaps you have build customizations further divorced from antix as well, etc.
Reply
#4
I'll just add there are a couple of machines with a single-core Atom - Toshiba NB250 and NB305 - and I'd be tempted to test it on the ancient Time  laptop  pavement slab from around the turn of the century, if I can find the power supply.
Reply
#5
I have done very little to the initrd. All that remains in there is antiX proper other than some distro identification stuff. It is also worth noting that for the DSL builds I'm not using any of the native antiX remastering tools, but rather working more old school in a chroot environment and then compressing it all up and rebuilding the iso with mksquashfs and mkisofs. The initial reason for doing it this way was that some of the dependencies for the antiX remastering tools were removed from the project because they were too big.

As for testing, I would like the tests to be timed from the point of selecting boot option to the time that the icons appear on the desktop. It would be very helpful to have an A<=>B test of the regular zx Alpha2 release and the lz4 version specifically made for USB booting -- both versions booting from the USB port on the same computer.

Give me a little bit of time and I'll put it up. Thanks guys!
Reply
#6
Okay, here is the test iso:
https://damnsmalllinux.org/download/dsl-...esting.iso
https://damnsmalllinux.org/download/dsl-...so.md5.txt
Reply
#7
32-bit single core celeron 2.2GHz 1GB, apples-to-apples USB boot:
3:04 alpha2
2:03 lz4

Can try other machines (both directions) tomorrow if useful.
Reply
#8
Thank you for reporting! Yes, I would be very curious to see other results.
Reply
#9
Hi Y'all!

First a quick comment on my crazy setup right now. Running Windows, VMware workstation and the DSL testing on that playing music from youtube. Running DSL testing on Qemu from which I'm typing this listening to the music. Have updated DSL and it just uses about 150-250 MB of RAM. All that at the same time on a laptop.

Thanks for posting this testing cut John! I have tried it in a lot of settings on both Vmware Workstation and Qemu on windows. It works without problems with 512 MB of RAM both on VMw. and Qemu. It boots in like 40-60 seks on VMw and even faster on Qemu on my laptop. I finally was able to make an install that is like a 10" screen on VMw. It really is an outstretched 1280x800 resolution of the testing cut. Sound works but on Qemu I can't make it work. It seems that the terminal on the top of the menu stops working if you make an update. All of this on hypervisors though.

The laptop that I have is really an anti Linux computer. After a lot of hacking in the BIOS it finally booted up the test cut on an usb drive but just to the screen where you choose boot options. After that just a bunch of error messages and I have to turn it off otherwise it boots a bitlocker reset. So unfortunately I have too use the VMware Workstation to run DSL with sound. I like to have some background music when I "work".

I use MX Linux, cousin to antiX I believe. MX gave a lot of resistance when I installed it. It just showed up like a tiny square on the screen. Then I checked the settings and almost every possible resolution was found there. I chose 1920x1080 and in a second it extended all over the screen. So that works well on VMw but so far I have to be content with a 10" screen for DSL but the things I use works including the sound. So I use MX when I "work" and DSL when I want to have some fun. So thanks again John for posting this test cut of DSL. Later on I think that DSL will work as it should even on this Linux hating laptop of mine.

Thanks for resurrecting DSL John,
meo

Incredible!

When I came back to the install of DSL testing on the VMware Workstation it had "grown". Can hardly believe it. Now it's like an 11.5". It just has a 3/4 of an inch black border on the sides. Computers, at times, seem to have different personalities just like humans. I just don't understand!!!

// meo
Reply
#10
Thanks giving it a try Meo! Say, do you mind posting a like for like boot time for Alpha2 vs. this lower compression version?
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)