Background:
I wanted to boot puppy directly from ISO using grub(grub2). I tired of the grub4dos way
since it requires the iso to be contiguous. First I thought it was OK when I saw that grub
supports the loopback feature. This takes you as far as loading initrd.gz but when control
is passed the ISO loop is freed. The puppy stalls and fails to load basesfs. But for
example Ubuntu LiveCD's has a boot-parameter "iso-scan/filename" and thus can be booted.
I then set out to implement a boot-parameter pisoscan for Puppy Linux
Solution:
I extracted the init-script from the initrd.gz contained in ISO for further reevaluation.
I changed it in six places(listed here in order of appearance). A total of 34 lines not counting
comments and blank lines.
1. search_func(14 lines, starting at row: 464)
2. Handling of in-parameter pisoscan(2 lines, starting at row: 575)
3. Loading of basesfs(8 lines, starting at row: 1434)
4. Evaluation of COPYCONTENDER and COPY2RAM(1 line, starting at row: 1472)
5. Loading of Zdrv(3 lines, starting at row: 1521)
6. Unmounting of after loading if sfs-files, $UMOUNTME(6 lines, starting at row: 1582)
Of course point 5 will be repeated if more layers are added for example Adrv.
the changed areas are marked with
#--------------------------------ISO-SCAN-START-------------------------------------------------------------------
...
#--------------------------------ISO_SCAN_END---------------------------------------------------------------------
I have not tried to speed up or change the code to much. My objective was to achive the goal
with as little intrusion on the init-script structure as possible.
The script was developed on AlphaOS10 but the example files below is from precise-5.7.1.iso.
Other puppy's tried was slacko-5.6-PAE.iso and lina-1.0.iso. I included Fatdog64-621.iso in
the test suite but it employs the "Humongous" intitrd and can already be booted with grub directly.
Furthermore Fatdog's init-script doesn't use the same structure as the others which leads
me to believe it is not woof-based.
I have tested on both ntfs and vfat filesystems. Internal HD and USB.
With and without savefile. And tried on a simulated RAM-challenged machine.
It seems to work.
The grub config I used was
Code: Select all
menuentry "ISO SCAN Precise" {
set root=(hd0,msdos1)
loopback loop /boot/grub/PreciseWithIsoScan.iso
linux (loop)/vmlinuz pisoscan=/boot/grub/PreciseWithIsoScan.iso
initrd (loop)/initrd.gz
}
from grub manual:
(hdX,Y) is the partition Y on disk X, partition numbers starting at 1, disk numbers starting at 0
set root=(hdX,Y) sets the boot partition, where the kernel and GRUB modules are stored (boot need
not be a separate partition, and may simply be a directory under the "root" partition (/) )
Downloads:
init
Md5sum: 3f8804a84ef713b910797ecf596d4d71
PreciseWithIsoScan.iso
Md5sum: bc841d06ce097135c1dc1fd005072cdc
Questions:
a: I use existent mount point /mnt/data2. I cannot see it is used in init-script and I
believe it was reserved for future use. Am I right?
b: I use loop device loop10. Is there a reason this shouldn't be used?
c: Is the following unnescessary? Do you have to both umount and release loop device with losetup -d?
Code: Select all
losetup /dev/loop10 /mnt/data/$PISOSCAN
mount -r -t iso9660 -o noatime /dev/loop10 /mnt/data2
...
umount /mnt/data2
losetup -d /dev/loop10
d: Is there any case I haven't thought of where iso-scan would interfere with normal puppy operation?
Conclusion:
I have never used woof and don't know exactly how it is structured. But I have seen user-posts with patches for it.
It should be possible to add this and I propose that this be made standard in woof.
Request for comments...