I'm not done with this yet. I'm working on a more general patch with new features, which will be forthcoming shortly. I would ask that nothing major be done until that is ready.
The current version is certainly ready for testing, although Andreas already seems to have done so extensively. On Sat, 12 Oct 2013 20:03:53 +0200 Andreas Cadhalpun <andreas.cadhal...@googlemail.com> wrote: > The patch created by Ian Bruce and myself adds ISO loopback support > for the Debian installer using a new boot parameter, to be used as > follows: > > loopmount=[DEVICE:]ISO "loopback" is the name of a virtual network device; the proper term in this context is in fact "loopmount", hence the name of the boot parameter. > Here ISO specifies the path to the ISO, i.e. > /ISO/debian-7.1.0-amd64-CD-1.iso. Relative to the root directory of some block device, of course. > DEVICE is for the name or UUID of the device, on which the ISO is > located. Giving this is optional and if it is not given, all devices > are searched for the ISO. It specifies the filesystem label or UUID, as found in /dev/disk/by-label/ or /dev/disk/by-uuid/, or returned by /sbin/blkid. At least in my version of the patch, if it is not specified, then partitions and CD/DVD drives are searched, but not other devices. > If the boot parameter is not given (or no ISO could be found), > everything works essentially as before. As far as I know, if the "loopmount" parameter is not specified, then everything works EXACTLY as before (by design). > For the patch to work, the loop-module is needed in the initrd, so I > suggest to make it a dependency of cdrom-detect. I furthermore highly > recommend to make the ext2/ext3/ext4, ntfs and udf modules > dependencies of cdrom-detect, since these are the most common > filesystems and thus being able to loopmount from them would be good. It appears that the ext4 module would be sufficient to also mount ext2/ext3, whereas the reverse would not be true. https://ext4.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_is_the_difference_between_ext2.2C_ext3.2C_and_ext4.3F https://ext4.wiki.kernel.org/index.php/Frequently_Asked_Questions#Can_I_mount_existing_Ext3_as_Ext4.3F_And_vice_versa.3F_Similarly_from_Ext2_to_Ext4_and_its_reverse.3F https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Compatibility There might be some value in including NTFS, so that you could loop-mount from Windoze partitions. I don't know what usage UDF gets (besides DVDs) that would justify including it in the initrd. > (Fat is somewhat outdated.) VFAT is by no means outdated, since it is used on almost every USB flashdrive in existence. You might expect that it would eventually be replaced for this purpose by F2FS, but that certainly hasn't happened yet. Anyway, it's already in the initrd. > The patch makes it possible to boot using USB-HDD from any filesystems > with drivers in the initrd. Actually, from any supported block device with a supported filesystem. It appears that most standard PATA/SATA/SCSI/CDROM/USB drivers are already included in the initrd, so the only thing that would need to be added is "loop.ko" and a few filesystem drivers. > The patch also cleans up the somewhat messy workaround for bug > #608201. A proper fix would be for all ISO images to be treated the same, regardless of whether they were contained in a CD, a disk partition, or a loop-mounted file. I'm not sure why this shouldn't be possible, but it's not the issue we're mainly concerned with at the moment. > For ease of use, I propose to add a loopback.cfg similar to the the > attached one to the ISO in the folder /boot/grub/. This would allow to > easily mount the ISO using grub2. I can supply similar config files for Syslinux, allowing the use of the original boot menus with a loop-mounted ISO. > I tested loopmounting with the following ISOs. (They were modified > with the attached Apply_Patches.sh.) > > * debian-7.1.0-amd64-netinst.iso > * debian-7.1.0-i386-netinst.iso > * debian-7.1.0-amd64-CD-1.iso > * debian-7.1.0-amd64-CD-2.iso (+) > * debian-7.1.0-amd64-CD-3.iso (+) > * debian-7.1.0-amd64-DVD-1.iso > * debian-7.1.0-amd64-DVD-2.iso (+) > > (+): Not modified, just copied to the folder of the first ISO in the > set. As I have suggested previously, you don't actually have to modify the ISOs for testing; you can just patch an external copy of the initrd and boot with that. That way, the official MD5 and SHA256 hashes still verify. > This worked without problems. To make sure all other boot mechanisms > still work, I tested them for the patched debian-7.1.0-amd64-CD-1.iso: > > * Isohybrid: OK > * USB-HDD: OK Thanks for testing all that. > * CD: I can't open the CD drive with the button the on the drive. I > have to change to another TTY and use 'eject'. (This problem exists > also with the original ISO image, see #726137.) I think I also ran into this at some point. > Since the patch works well and does no harm, I ask you to include it > in git. I think this will be a highly useful feature, and may become the primary method of booting Debian. (Does anybody really bother burning install CDs anymore?) However, as I said above, I'm still working on some improvements, so it's not quite done yet. > Changes since the last patch: > * The script mountmedia uses 'mount -t auto', but this only tries to > mount as fat and nothing else, so I changed this to detect the > filesystem with blkid. Now firmware can be loaded from a harddrive/USB > with any of the filesystems, for which drivers are in the initrd. That's what "mount -t auto" is supposed to do. From the manual page: If no -t option is given, or if the auto type is specified, mount will try to guess the desired type. Mount uses the blkid library for guessing the filesystem type; if that does not turn up anything that looks familiar, mount will try to read the file /etc/filesystems, or, if that does not exist, /proc/filesystems. So I don't know why using /sbin/blkid directly would make any difference. Maybe there's some peculiarity about the Busybox version of "mount". > * Removed $FATFS from cdrom-detect and instead let the filesystem be > automatically detected using blkid. With this it is possible to use > USB-HDD for all filesystems, for which drivers are in the initrd. For the reasons given above, I'm not very confident about this. I think it's better to specify the relevant filesystem types directly. "mount -t vfat,ext4,iso9660" actually works; I suggest we just add ntfs or whatever seems desirable to that list. > * Removed iso-hybrid and usb-hdd templates, since it works well > without. I concur. That logic is better handled in another way. -- Ian Bruce -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
