Bug#724931: Please include the patch in git
El 18/08/15 a las 19:28, Andreas Cadhalpun escribió: Hi adrian15, On 18.08.2015 10:47, adrian15 wrote: Can you please explain why you are using: get_fstype () function which it's based on blkid instead of just using the old method of relying in auto function from the kernel itself? The reason is simply that 'mount -tauto' didn't work, while explicitly specifying the type found with blkid works fine. Doing some archeology reveals the relevant error messages from syslog: With 'mount -tauto': kernel: [ 109.257009] UDF-fs: warning (device sda9): udf_fill_super: No partition found (1) kernel: [ 109.378443] FAT-fs (sda9): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! main-menu[550]: (process:4539): mount: mounting /dev/sda9 on /media failed: Invalid argument With blkid: [ 80.943104] EXT4-fs (sda9): mounted filesystem with ordered data mode. Opts: (null) These happened during check_missing_firmware, i.e. this comes from mountmedia. I think that convinced me not to use 'mount -t auto' in cdrom-detect. However, that was two years ago. Much could have changed in the meantime. Ok, I will try to reproduce it and see if it still happens. This is used in both cdrom-detect.patch and mountmedia.patch. Please, be aware, that I'm not telling you your approach is incorrect. It seems we are lacking the explanation or rationale on why you made that decision in order to evaluate that change in a fair manner. I'm curious: Why are you asking that now? I'm in debconf15 trying to push forward some improvements that I'm interested of as this one. Having around real people to speed things helps but don't raise your expectations too early. Best regards, Andreas adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#724931: Re: Bug#724931: Please include the patch in git
El 08/03/14 a las 18:11, Andreas Cadhalpun escribió: I fixed a few things in my previous patch (see attachments): * Fix typo in finish-install.d/10apt-cdrom-setup: cdrom/$j - cdrom$j * Always test for other CDs, except if it is a netinst CD. Otherwise one can't use CD-2 together with debian-testing-amd64-kde-CD-1.iso of type full_cd/single. (Maybe I didn't get how this is supposed to work?) * Mount further ISOs if at least four parts (seperated by -) of the name are the same. Example: a) debian-testing-amd64-CD-1.iso b) debian-testing-amd64-kde-CD-1.iso c) debian-testing-amd64-CD-2.iso d) debian-testing-amd64-CD-2-local-changes.iso e) debian-testing-i386-CD-2.iso a) and b) would load c) or d), but not e). * Fix crash, if the filesystem is not know (e.g. unpartitioned). Pease add the attached patches on top of current git, even if you don't want to apply the patch now and instead move it to another branch. Best regards, Andreas Can you please explain why you are using: get_fstype () function which it's based on blkid instead of just using the old method of relying in auto function from the kernel itself? This is used in both cdrom-detect.patch and mountmedia.patch. Please, be aware, that I'm not telling you your approach is incorrect. It seems we are lacking the explanation or rationale on why you made that decision in order to evaluate that change in a fair manner. Thank you very much! adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#724931: Please include the patch in git
Hi adrian15, On 18.08.2015 10:47, adrian15 wrote: Can you please explain why you are using: get_fstype () function which it's based on blkid instead of just using the old method of relying in auto function from the kernel itself? The reason is simply that 'mount -tauto' didn't work, while explicitly specifying the type found with blkid works fine. Doing some archeology reveals the relevant error messages from syslog: With 'mount -tauto': kernel: [ 109.257009] UDF-fs: warning (device sda9): udf_fill_super: No partition found (1) kernel: [ 109.378443] FAT-fs (sda9): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! main-menu[550]: (process:4539): mount: mounting /dev/sda9 on /media failed: Invalid argument With blkid: [ 80.943104] EXT4-fs (sda9): mounted filesystem with ordered data mode. Opts: (null) These happened during check_missing_firmware, i.e. this comes from mountmedia. I think that convinced me not to use 'mount -t auto' in cdrom-detect. However, that was two years ago. Much could have changed in the meantime. This is used in both cdrom-detect.patch and mountmedia.patch. Please, be aware, that I'm not telling you your approach is incorrect. It seems we are lacking the explanation or rationale on why you made that decision in order to evaluate that change in a fair manner. I'm curious: Why are you asking that now? Best regards, Andreas
Bug#724931: Please include the patch in git
Hi, On 08.03.2014 02:13, Cyril Brulebois wrote: Given the apt-cdrom regression we're hitting (#740673), I don't feel like shipping this amount of additional modifications in jessie alpha 1 images; Given that Bug #740673 is fixed and jessie alpha 1 is released, can you review and upload these patches now? Best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724931: Please include the patch in git
Andreas Cadhalpun andreas.cadhal...@googlemail.com (2014-03-24): Given that Bug #740673 is fixed and jessie alpha 1 is released, can you review and upload these patches now? Let me be very clear: being pushy isn't going to get your stuff reviewed sooner (probably the contrary, in fact). Annoyed, KiBi. signature.asc Description: Digital signature
Bug#724931: Please include the patch in git
Cyril Brulebois k...@debian.org (2014-03-08): Given the apt-cdrom regression we're hitting (#740673), I don't feel like shipping this amount of additional modifications in jessie alpha 1 images; on the other hand, not uploading what's in apt-setup's master currently would mean not using updated l10n material, which isn't too nice. I'm tempted to branch iso-loopback from current master, so that it's easily found afterwards, and to revert the ISO loopback bits for now. FWIW I've done that in apt-setup, which is awaiting another patch before an upload (~ in an hour). Mraw, KiBi. signature.asc Description: Digital signature
Bug#724931: Please include the patch in git
Hi,
On 08.03.2014 02:13, Cyril Brulebois wrote:
Given the apt-cdrom regression we're hitting (#740673), I don't feel
like shipping this amount of additional modifications in jessie alpha 1
images; on the other hand, not uploading what's in apt-setup's master
currently would mean not using updated l10n material, which isn't too
nice. I'm tempted to branch iso-loopback from current master, so that
it's easily found afterwards, and to revert the ISO loopback bits for
now.
I generally agree that it would be good to have an alpha 1 installer to
use for testing regressions of this patch, but on the other hand using
loopmount to install Debian *works*.
So you might want to reconsider applying this patch now, as it seems to
be currently the only way to install Debian jessie directly. ;)
Yesterday I made a new installation using the patched:
Debian GNU/Linux testing Jessie - Official Snapshot amd64 CD Binary-1
20140203-06:21
I'm only half-joking, it really works, otherwise I would have reported a
bug.
I fixed a few things in my previous patch (see attachments):
* Fix typo in finish-install.d/10apt-cdrom-setup: cdrom/$j - cdrom$j
* Always test for other CDs, except if it is a netinst CD.
Otherwise one can't use CD-2 together with
debian-testing-amd64-kde-CD-1.iso of type full_cd/single. (Maybe I
didn't get how this is supposed to work?)
* Mount further ISOs if at least four parts (seperated by -) of the
name are the same. Example:
a) debian-testing-amd64-CD-1.iso
b) debian-testing-amd64-kde-CD-1.iso
c) debian-testing-amd64-CD-2.iso
d) debian-testing-amd64-CD-2-local-changes.iso
e) debian-testing-i386-CD-2.iso
a) and b) would load c) or d), but not e).
* Fix crash, if the filesystem is not know (e.g. unpartitioned).
Pease add the attached patches on top of current git, even if you don't
want to apply the patch now and instead move it to another branch.
Best regards,
Andreas
diff -ruN apt-setup.orig/finish-install.d/10apt-cdrom-setup apt-setup/finish-install.d/10apt-cdrom-setup
--- apt-setup.orig/finish-install.d/10apt-cdrom-setup 2014-02-13 12:42:00.738178000 +0100
+++ apt-setup/finish-install.d/10apt-cdrom-setup 2014-02-13 15:49:18.868155368 +0100
@@ -10,10 +10,10 @@
if [ $loopdev ]; then
# Remove additional CD-Set mount points
j=1
- while [ -d /target/media/cdrom/$j ]; do
- logger -t finish-install unmount /target/media/cdrom/$j
- umount /target/media/cdrom/$j 2/dev/null || true
- rmdir /target/media/cdrom/$j
+ while [ -d /target/media/cdrom$j ]; do
+ logger -t finish-install unmount /target/media/cdrom$j
+ umount /target/media/cdrom$j 2/dev/null || true
+ rmdir /target/media/cdrom$j
j=$(($j + 1))
done
diff -ruN apt-setup.orig/generators/41cdset apt-setup/generators/41cdset
--- apt-setup.orig/generators/41cdset 2014-02-13 12:42:00.738178000 +0100
+++ apt-setup/generators/41cdset 2014-02-13 15:28:30.555167746 +0100
@@ -8,6 +8,20 @@
logger -t apt-setup $@
}
+split_string() {
+ # Save the old internal field separator.
+ OIFS=$IFS
+ # Change the internal field separator.
+ IFS=$2
+ arr=$1
+ # Convert the separator to newline.
+ for x in $arr; do
+ echo $x
+ done
+ # Restore the old internal field separator.
+ IFS=$OIFS
+}
+
# This code is copied from chroot-setup.sh, and is needed until after a d-i
# release whose initrds contain a sufficiently new version of di-utils.
if ! type chroot_cleanup_localmounts /dev/null 21; then
@@ -46,7 +60,7 @@
# bluray CDs have cd_type 'bluray'
cd_type=$(cat /cdrom/.disk/cd_type)
log The disk type is: $cd_type
-if [ $cd_type != full_cd ] [ $cd_type != dvd ]; then
+if [ $cd_type == not_complete ]; then
exit 0
fi
@@ -123,23 +137,32 @@
if [ $run_count -eq 0 ]; then
log Trying to find usable ISOs in the folder, where the boot ISO is...
loopdir=$(db_getval cdrom-detect/cdrom_device)
- ISOname=$(basename $loopdir)
- loopdir=$(dirname $loopdir)
- if [ $cd_type = dvd ]; then
-# DVD
-ISOstart=${ISOname%DVD-*}
-ISOs=$(ls ${loopdir}/ | grep ${ISOstart}DVD-[^1].*[.]iso$)
- elif [ $cd_type = blueray ]; then
-# BD
-ISOstart=${ISOname%BD-*}
-ISOs=$(ls ${loopdir}/ | grep ${ISOstart}BD-[^1].*[.]iso$)
- else
-# probably CD
-ISOstart=${ISOname%CD-*}
-ISOs=$(ls ${loopdir}/ | grep ${ISOstart}CD-[^1].*[.]iso$)
- fi
- for iso in $ISOs; do
-max_run=$(($max_run + 1))
+ ISOname=${loopdir##*/}
+ loopdir=${loopdir%/*}
+
+ ISOarray=$(split_string $ISOname -)
+ allISOs=$(ls ${loopdir}/ | grep .iso)
+ ISO=
+ for iso in $allISOs; do
+arr=$(split_string $iso -)
+count=0
+# Count common specifiers.
+for elem in $arr; do
+ if [ $elem == 1.iso ]; then
+ # Only look for supplementary ISOs, not ISOs like '*-CD-1.iso'.
+ count=-1
+ break
+ fi
+ for orig_elem in $ISOarray; do
+ if [ $elem == $orig_elem ]; then
+ count=$(($count + 1))
+ fi
+ done
+done
+if ([ $count -ge 4 ] [ $iso != $ISOname
Bug#724931: Please include the patch in git
Andreas Cadhalpun andreas.cadhal...@googlemail.com (2014-03-08): I generally agree that it would be good to have an alpha 1 installer to use for testing regressions of this patch, but on the other hand using loopmount to install Debian *works*. Sorry, but until it's been pushed to the masses, I can't blindly trust that. Many moving parts already, not going to add a critical one when we already have a (known) regression in apt-setup/apt-cdrom. Especially not a few days before a release. Mraw, KiBi. signature.asc Description: Digital signature
Bug#724931: Please include the patch in git
Hi, On 08.03.2014 19:04, Cyril Brulebois wrote: Andreas Cadhalpun andreas.cadhal...@googlemail.com (2014-03-08): I generally agree that it would be good to have an alpha 1 installer to use for testing regressions of this patch, but on the other hand using loopmount to install Debian *works*. Sorry, but until it's been pushed to the masses, I can't blindly trust that. Many moving parts already, not going to add a critical one when we already have a (known) regression in apt-setup/apt-cdrom. Especially not a few days before a release. I didn't really suggest applying the patch without further testing from someone other than me. I just wanted to express my amazement that loopmount works, while the usual way doesn't. I looked more closely and found that commenting out the following in 40cdrom fixes the problem: # Allow apt-cdrom to manage mounting/unmounting CDs in /target if [ $cd_mountable ]; then rm -f $ROOT/etc/apt/apt.conf.d/00NoMountCDROM $logoutput umount /target/media/cdrom* || true $logoutput umount /cdrom || true fi At least I managed to install Debian jessie in a Virtual Machine. So if there are no compelling reasons to have this (Note: I don't know, what this is supposed to do.), I would suggest removing this as a fix for Bug #740673. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724931: Please include the patch in git
Andreas Cadhalpun andreas.cadhal...@googlemail.com (2014-03-08): I looked more closely and found that commenting out the following in 40cdrom fixes the problem: # Allow apt-cdrom to manage mounting/unmounting CDs in /target if [ $cd_mountable ]; then rm -f $ROOT/etc/apt/apt.conf.d/00NoMountCDROM $logoutput umount /target/media/cdrom* || true $logoutput umount /cdrom || true fi At least I managed to install Debian jessie in a Virtual Machine. So if there are no compelling reasons to have this (Note: I don't know, what this is supposed to do.), I would suggest removing this as a fix for Bug #740673. Err, no. We had something that worked well enough for a while, it broke due to a change in apt-cdrom, which was confirmed to be unintentional. So let's fix that for now, and *maybe* rethink stuff after that. I'm not goint to drop random lines, especially not based on “I don't know what this is supposed to do”… Mraw, KiBi. signature.asc Description: Digital signature
Bug#724931: Please include the patch in git
Andreas Cadhalpun andreas.cadhal...@googlemail.com (2013-12-02): On Topic: It's always better, if more people look at a patch, so I'd be grateful for KiBi's thoughts on it, especially concerning the effects for kFreeBSD, since I could not test these, because I did not manage to unpack the initrd from the kFreeBSD ISO. The easiest way to get feedback concerning kFreeBSD is contacting debian-bsd@. I don't know really what you mean by invasive, but I assume you mean, that the installer could break, if apt-setup and cdrom-detect are not both updated at the same time. So let me clarify this a bit: The functionality to loopmount is not invasive at all, since the necessary code for this is only executed, if the boot parameter 'loopmount=' is given. What makes this patch more invasive is the fact that it cleans up the somewhat messy workaround for bug #608201. Up to now the situation was, that for every non-CD boot method (usb-hdd/isohybrid) a template was exported from cdrom-detect and imported in apt-setup to check there, whether cdset-detection should automatically (u)mount \cdrom. I moved the code to determine this to cdrom-detect and only exported the result (cdrom_mountable) to apt-setup, so that in the future one does not have to change apt-setup (changes are needed only for cdset support), if one adds a new boot method. Thus if not both patches (cdrom-detect and apt-setup) are applied at the same time, apt-setup will fail, because it looks for a template that does not exist. Given the apt-cdrom regression we're hitting (#740673), I don't feel like shipping this amount of additional modifications in jessie alpha 1 images; on the other hand, not uploading what's in apt-setup's master currently would mean not using updated l10n material, which isn't too nice. I'm tempted to branch iso-loopback from current master, so that it's easily found afterwards, and to revert the ISO loopback bits for now. Christian, can you please confirm that it makes sense on an l10n point of view? Mraw, KiBi. signature.asc Description: Digital signature
Bug#724931: Please include the patch in git
On 03.12.2013 00:46, Cyril Brulebois wrote: Andreas Cadhalpun andreas.cadhal...@googlemail.com (2013-12-02): this is now the second time that I did not get your mail. If you have any idea what could cause that, please let me know, because it is not really practical to always check bugs.debian.org. Gmail, spam folder? It's a royal pain anyway since it believes it knows better than users how many mails one should get… Strangely, these two mails did not end up in the spam folder (nor any other folder), they just seem to have vanishes somewhere on the way. But I get all(?) other mails from Christian (and everybody else). Sorry, will take a while for me to get to it, finalizing the move from ravel to dillon, and setting up a few things on my side to help me work on d-i. Thanks for bearing with me… That's no problem for me, since I'm personally using the patch already. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724931: Please include the patch in git
Hi, this is now the second time that I did not get your mail. If you have any idea what could cause that, please let me know, because it is not really practical to always check bugs.debian.org. On Topic: It's always better, if more people look at a patch, so I'd be grateful for KiBi's thoughts on it, especially concerning the effects for kFreeBSD, since I could not test these, because I did not manage to unpack the initrd from the kFreeBSD ISO. I don't know really what you mean by invasive, but I assume you mean, that the installer could break, if apt-setup and cdrom-detect are not both updated at the same time. So let me clarify this a bit: The functionality to loopmount is not invasive at all, since the necessary code for this is only executed, if the boot parameter 'loopmount=' is given. What makes this patch more invasive is the fact that it cleans up the somewhat messy workaround for bug #608201. Up to now the situation was, that for every non-CD boot method (usb-hdd/isohybrid) a template was exported from cdrom-detect and imported in apt-setup to check there, whether cdset-detection should automatically (u)mount \cdrom. I moved the code to determine this to cdrom-detect and only exported the result (cdrom_mountable) to apt-setup, so that in the future one does not have to change apt-setup (changes are needed only for cdset support), if one adds a new boot method. Thus if not both patches (cdrom-detect and apt-setup) are applied at the same time, apt-setup will fail, because it looks for a template that does not exist. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724931: Please include the patch in git
Andreas Cadhalpun andreas.cadhal...@googlemail.com (2013-12-02): this is now the second time that I did not get your mail. If you have any idea what could cause that, please let me know, because it is not really practical to always check bugs.debian.org. Gmail, spam folder? It's a royal pain anyway since it believes it knows better than users how many mails one should get… On Topic: It's always better, if more people look at a patch, so I'd be grateful for KiBi's thoughts on it, especially concerning the effects for kFreeBSD, since I could not test these, because I did not manage to unpack the initrd from the kFreeBSD ISO. I don't know really what you mean by invasive, but I assume you mean, that the installer could break, if apt-setup and cdrom-detect are not both updated at the same time. So let me clarify this a bit: The functionality to loopmount is not invasive at all, since the necessary code for this is only executed, if the boot parameter 'loopmount=' is given. What makes this patch more invasive is the fact that it cleans up the somewhat messy workaround for bug #608201. Up to now the situation was, that for every non-CD boot method (usb-hdd/isohybrid) a template was exported from cdrom-detect and imported in apt-setup to check there, whether cdset-detection should automatically (u)mount \cdrom. I moved the code to determine this to cdrom-detect and only exported the result (cdrom_mountable) to apt-setup, so that in the future one does not have to change apt-setup (changes are needed only for cdset support), if one adds a new boot method. Thus if not both patches (cdrom-detect and apt-setup) are applied at the same time, apt-setup will fail, because it looks for a template that does not exist. Sorry, will take a while for me to get to it, finalizing the move from ravel to dillon, and setting up a few things on my side to help me work on d-i. Thanks for bearing with me… Mraw, KiBi. signature.asc Description: Digital signature
Bug#724931: Please include the patch in git
Hi,
I have researched how to include the needed modules in the initrd.
If I understand it correctly, it would be possible to add the modules as
dependencies of cdrom-detect.
But that would not be feasible, because the kernel modules have the
version of the kernel in their name and therefore the dependencies would
have to be updated every time a new kernel is released.
Instead I think the best way is to change the config files for the
debian-installer [1] that determine what udebs are included in which
initrd. They reside in installer/build/pkg-lists.
For the modules needed for loopmount I attached a patch against the
debian-installer. In this patch I just added the loop-, ext4-, ntfs- and
udf-modules to all config files that include cdrom-detect. This comes
close to making them dependencies of cdrom-detect, but it is much
easier, since in these config files one can use the variable
${kernel:Version} and doesn't have to update that manually.
Please include that patch in the debian-installer and then release the
new versions of cdrom-detect, apt-setup, hw-detect and mountmedia.
Best regards,
Andreas
1: http://anonscm.debian.org/gitweb/?p=d-i/debian-installer.git;a=tree
diff -rup debian-installer.orig/installer/build/pkg-lists/cd_drivers/common debian-installer/installer/build/pkg-lists/cd_drivers/common
--- debian-installer.orig/installer/build/pkg-lists/cd_drivers/common 2013-11-29 23:57:37.780913000 +0100
+++ debian-installer/installer/build/pkg-lists/cd_drivers/common 2013-11-30 12:37:18.882104469 +0100
@@ -3,3 +3,11 @@ cdrom-retriever
disk-detect
cdrom-detect
file-preseed
+
+# This is for cdrom-detect to be able to loopmount an ISO.
+loop-modules-${kernel:Version}
+
+# This is to enable loopmount/usb-hdd from common non-fat file systems:
+ext4-modules-${kernel:Version}
+ntfs-modules-${kernel:Version}
+udf-modules-${kernel:Version}
diff -rup debian-installer.orig/installer/build/pkg-lists/cdrom/common debian-installer/installer/build/pkg-lists/cdrom/common
--- debian-installer.orig/installer/build/pkg-lists/cdrom/common 2013-11-29 23:57:37.780913000 +0100
+++ debian-installer/installer/build/pkg-lists/cdrom/common 2013-11-30 12:37:30.274111670 +0100
@@ -31,3 +31,11 @@ save-logs
mountmedia
libfribidi0-udeb
+
+# This is for cdrom-detect to be able to loopmount an ISO.
+loop-modules-${kernel:Version}
+
+# This is to enble loopmount/usb-hdd from common non-fat file systems:
+ext4-modules-${kernel:Version}
+ntfs-modules-${kernel:Version}
+udf-modules-${kernel:Version}
diff -rup debian-installer.orig/installer/build/pkg-lists/cdrom-apus/common debian-installer/installer/build/pkg-lists/cdrom-apus/common
--- debian-installer.orig/installer/build/pkg-lists/cdrom-apus/common 2013-11-29 23:57:37.780913000 +0100
+++ debian-installer/installer/build/pkg-lists/cdrom-apus/common 2013-11-30 12:37:40.694118260 +0100
@@ -24,3 +24,11 @@ save-logs
mountmedia
libfribidi0-udeb
+
+# This is for cdrom-detect to be able to loopmount an ISO.
+loop-modules-${kernel:Version}
+
+# This is to enable loopmount/usb-hdd from common non-fat file systems:
+ext4-modules-${kernel:Version}
+ntfs-modules-${kernel:Version}
+udf-modules-${kernel:Version}
Bug#724931: Please include the patch in git
clone 724931 -1
reassign -1 debian-installer
retitle -1 Please add needed modules for ISO loopmount to work in D-I
thanks
Quoting Andreas Cadhalpun (andreas.cadhal...@googlemail.com):
Hi,
I have researched how to include the needed modules in the initrd.
If I understand it correctly, it would be possible to add the
modules as dependencies of cdrom-detect.
But that would not be feasible, because the kernel modules have the
version of the kernel in their name and therefore the dependencies
would have to be updated every time a new kernel is released.
Instead I think the best way is to change the config files for the
debian-installer [1] that determine what udebs are included in which
initrd. They reside in installer/build/pkg-lists.
For the modules needed for loopmount I attached a patch against the
debian-installer. In this patch I just added the loop-, ext4-, ntfs-
and udf-modules to all config files that include cdrom-detect. This
comes close to making them dependencies of cdrom-detect, but it is
much easier, since in these config files one can use the variable
${kernel:Version} and doesn't have to update that manually.
Please include that patch in the debian-installer and then release
the new versions of cdrom-detect, apt-setup, hw-detect and
mountmedia.
Thanks, Andreas.
I therefore clone this bug report and assign it to debian-installer
itself, so that the needed actions are ataken on time there, too, if
we want this feature.
I was already suspecting that having Cyril Brulebois (CC'ed) look
specifically at all this is really needed as this feature is indeed
quite invasive. So, well, let's get his input.
I have the feeling that, given the time you invested in this, we
should have some cinfidence that your proposal both makes
senseand will not break D-I.but someone less optimistic and
confident than me might want to have a closer look...:-)
signature.asc
Description: Digital signature
Bug#724931: Please include the patch in git
Hi,
I just created patches against cdrom-detect-1.46, hw-detect-1.98 and
mountmedia-0.23. I hope that helps.
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 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.
Best regards,
Andreas
diff -rup cdrom-detect-1.46.orig/debian/cdrom-detect.postinst cdrom-detect-1.46/debian/cdrom-detect.postinst
--- cdrom-detect-1.46.orig/debian/cdrom-detect.postinst 2011-03-23 03:00:14.0 +0100
+++ cdrom-detect-1.46/debian/cdrom-detect.postinst 2013-11-24 09:44:59.678577887 +0100
@@ -1,4 +1,4 @@
-#! /bin/sh
+#!/bin/sh
set -e
. /usr/share/debconf/confmodule
@@ -14,26 +14,43 @@ fail() {
exit 1
}
+list_devices_by_id()
+{
+ local dir disk=$(echo $1 | sed 's/ /\\x20/g')
+ for dir in /dev/disk/by-label /dev/disk/by-uuid ; do
+ [ -e ${dir}/${disk} ] echo ${dir}/${disk} || true
+ done
+}
+
+get_fstype ()
+{
+ /sbin/blkid -s TYPE -o value $1 2/dev/null
+}
+
try_mount() {
local device=$1
local type=$2
+ local options=$3
+ local loopdev=$4
local ret=1
- if mount -t $type -o $OPTIONS $device /cdrom; then
- log CD-ROM mount succeeded: device=$device fstype=$type
+ if mount -o ${loopdev:+loop,}$options -t $type $device /cdrom; then
+ log CD-ROM ${loopdev:+loop-}mount succeeded: device=$loopdev${device#/loop} fstype=$type
if [ -e /cdrom/.disk/info ]; then
CDNAME=$(cat /cdrom/.disk/info)
log Detected CD '$CDNAME'
db_set cdrom-detect/cdrom_device $device
db_set cdrom-detect/cdrom_fs $type
+ db_set cdrom-detect/cdrom_options ${loopdev:+loop,}$options
+ db_set cdrom-detect/cdrom_loopdev $loopdev
ret=0
else
- log The CD in $device is not a Debian CD!
+ log The CD in $loopdev${device#/loop} is not a Debian CD!
umount /cdrom 2/dev/null || true
WRONG=1
fi
else
- log CD-ROM mount failed: device=$device fstype=$type
+ log CD-ROM ${loopdev:+loop-}mount failed: device=$loopdev${device#/loop} fstype=$type
fi
return $ret
@@ -61,25 +78,21 @@ OS=$(udpkg --print-os)
case $OS in
kfreebsd)
CDFS=cd9660
- FATFS=msdosfs
OPTIONS=ro,exec
;;
linux)
CDFS=iso9660
- FATFS=vfat
OPTIONS=ro,exec
;;
hurd)
CDFS=iso9660fs
- FATFS=fatfs
OPTIONS=ro
;;
*)
log Unknown OS '$OS', exiting
exit 0
-
esac
-
+
# Is a cdrom already mounted? If so, assume it's the right one.
mount | grep -q 'on /cdrom' set_suite_and_codename exit 0
if [ -e /cdrom/.disk/info ]; then
@@ -95,42 +108,101 @@ log Searching for Debian installation m
mkdir /cdrom 2/dev/null || true
+# Check whether the boot parameter 'loopmount=' is used
+for arg in $(cat /proc/cmdline); do
+ case $arg in
+ loopmount=*)
+ LOOPMOUNT=${arg#loopmount=}
+ LOOPFILE=${LOOPMOUNT#*:}
+ [ $LOOPFILE != $LOOPMOUNT ] LOOPDEV=${LOOPMOUNT%:*}
+ ;;
+ esac
+done
+
+if [ $LOOPMOUNT ]; then
+ # Create mount point for loop mount
+ mkdir /loop 2/dev/null || true
+fi
+
# Need to wait for the usb device scan to complete
if [ $OS = linux ]; then
- for count in 1 2 3 4 5 6 8 9 10; do
-devices=$(list-devices cd; list-devices maybe-usb-floppy)
-log Devices: '$devices'
-if [ -n $devices ]; then
- break 2
-else
- sleep 1
-fi
- done
+ for count in 1 2 3 4 5 6 8 9 10; do
+ devices=$(list-devices cd; list-devices maybe-usb-floppy)
+ log CD/maybe-usb-floppy devices: '$devices'
+ if [ $devices ]; then
+ break
+ else
+ sleep 1
+ fi
+ done
fi
+# This is for apt-cdrom-setup, that needs to know, whether or not it should try to automatically (u)mount the device.
+cd_mountable=true
+
while true; do
- WRONG=
+ WRONG=''
+
+ if [ $LOOPMOUNT ]; then
+ mounted=0
+ log Searching for Debian ISO: LOOPDEV='$LOOPDEV' LOOPFILE='$LOOPFILE'
+ loopfile=/loop/${LOOPFILE#/}
+ log Unmounting /loop just to be sure
+ umount /loop 2/dev/null || true
+
+ if [ $LOOPDEV ] ; then
+ dev_given=device_given
+ else
+ dev_given=
+ fi
+
+ # First look for the given device (if given) and then on USB devices, since the ISO is probably on them
+ for fs in $dev_given usb-partition cd partition; do
+ if [ $fs = device_given ]; then
+devices=$(list_devices_by_id $LOOPDEV)
+ else
+devices=$(list-devices $fs)
+ fi
+ log Trying loopmount ($fs) on '$devices' ...
+ for loopdev in $devices; do
+# Determine the filesystem of the device
+LOOPFS=$(get_fstype $loopdev)
+# Mount the device and try to mount the ISO specified by 'loopmount='
+log Try to mount device=$loopdev fstype=$LOOPFS
+if mount -o $OPTIONS -t $LOOPFS $loopdev /loop; then
+ log Try to loop mount file=$loopfile fstype=$CDFS
+ if [ -f $loopfile ] try_mount $loopfile $CDFS $OPTIONS $loopdev; then
+ mounted=1
+ cd_mountable=false
+ break 2
+ else
+ umount /loop
+ fi
+fi
+ done
+ done
+ if [
Bug#724931: Please include the patch in git
clone 724931 -1 -2 -3 reassign -1 cdrom-detect reassign -2 hw-detect reassign -3 mountmedia thanks Quoting Andreas Cadhalpun (andreas.cadhal...@googlemail.com): Hi, I just created patches against cdrom-detect-1.46, hw-detect-1.98 and mountmedia-0.23. I hope that helps. For the patch to work, the loop-module is needed in the initrd, so I suggest to make it a dependency of cdrom-detect. That (imho) won't work : if that module is not in D-I kernel then it should be added there. I furthermore highly recommend to make the 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. The same stands here, but I suspect all these modules are already in D-I kernel image packages. Needs to be carefully checked anyway. signature.asc Description: Digital signature
Bug#724931: Please include the patch in git
Hi, On 24.11.2013 12:50, Christian PERRIER wrote: That (imho) won't work : if that module is not in D-I kernel then it should be added there. Why do you think this wouldn't work? The same stands here, but I suspect all these modules are already in D-I kernel image packages. Needs to be carefully checked anyway. The udebs for these modules are on the D-I ISO (pool/main/l/linux), but not installed in the initrd (in initrd/lib/modules/3.*-amd64/kernel/fs/), where they are needed. What do you think is the best way to get these modules into the initrd? Best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724931: Please include the patch in git
Quoting Andreas Cadhalpun (andreas.cadhal...@googlemail.com): In general I think, that it would be good to include the patch now and add any additional improvements later. I just committed the changes to apt-setup. I will probably soon upload the package with them . PLEASE TEST AS SOON AS POSSIBLE. signature.asc Description: Digital signature
Bug#724931: Please include the patch in git
Hi, thanks for committing the patch to apt-setup [1]. These changes have to be accompanied by the appropriate changes in cdrom-detect (and vice versa), as otherwise the installer will not work anymore. Probably this should be ensured with a versioned dependency. The changes in hw-detect and mountmedia are necessary for loading non-free firmware from filesystems different from FAT. So please commit the changes to the other packages as well. Best regards, Andreas 1: http://anonscm.debian.org/gitweb/?p=d-i/apt-setup.git;a=commit;h=baf5e4aea1d15b0c8a04d9f8c2a186e76c26bb18 On 23.11.2013 22:31, Christian PERRIER wrote: Quoting Andreas Cadhalpun (andreas.cadhal...@googlemail.com): In general I think, that it would be good to include the patch now and add any additional improvements later. I just committed the changes to apt-setup. I will probably soon upload the package with them . PLEASE TEST AS SOON AS POSSIBLE. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724931: Please include the patch in git
Quoting Andreas Cadhalpun (andreas.cadhal...@googlemail.com): Hi, thanks for committing the patch to apt-setup [1]. These changes have to be accompanied by the appropriate changes in cdrom-detect (and vice versa), as otherwise the installer will not work anymore. Probably this should be ensured with a versioned dependency. The changes in hw-detect and mountmedia are necessary for loading non-free firmware from filesystems different from FAT. The problem is that, unless I'm mistaken, patches were not sent as patches against the relevant packages, but as patches against the ISO images. So, it makes it fairly hard, when a bit far from the context, to isolate what belongs to which package. The fact that many versions of patches were sent to bug reports doesn't make it easier, too..:-) So, could you isolate a patch that could apply cleanly to cdrom-detect package treeor point me to it? I think I managed to apply the right changes to apt-setup, but that probably need to be checked, too. TIA, signature.asc Description: Digital signature
Bug#724931: Please include the patch in git
Hi,
I don't know why, but I didn't receive your email. I just read it on
bugs.debian.org.
Using the patched ISOs I noticed an error in the patch: In 41cdset
$filename was incorrectly used instead of $ISOname. Therefore too many
ISOs were considered as part of the set. The corrected patch is
attached. I also removed the unused $ISOend variable.
Furthermore I noticed that there are more official ISOs than I had in
mind, when I wrote the cdset-patch:
If the first ISO is called debian-7.2.0-amd64-CD-1.iso, 41cdset looks
for other ISOs with names debian-7.2.0-amd64-CD-*[^1].*[.]iso and thus
finds e.g. debian-7.2.0-amd64-CD-2.iso. But there exists also the
debian-update-7.2.0-amd64-CD-1.iso, which would not be found. And if you
started with a debian-7.2.0-kfreebsd-amd64-CD-1.iso, 41cdset would not
find debian-7.2.0-amd64-CD-2.iso.
Possible ways to treat this problem:
* One could just adapt the script for these cases, but I think that
the detailed structure of the ISO names should not be hardcoded.
* Alternatively one could just check every *.iso, but this has the
disadvantage, that if you have many other ISOs in the same folder, you
would have to click through many messages in the installer, stating that
this or that ISO is no Debian ISO.
* I think the best way would be to mention in the documentation what
ISOs 41cdset looks for. Any ISO could easily be renamed to match the
assumptions.
I have also tried to apply the patch to the kfreebsd ISO to check,
whether it works there as well, but I have been unable to extract the
initrd. It seems not to be packed as gzipped cpio archive.
I haven't heard from Ian since his last mail on 13th October and I have
no clue what he has in mind as a more general solution. Perhaps he has
been busy otherwise.
In general I think, that it would be good to include the patch now and
add any additional improvements later.
Best regards,
Andreas
diff -rupN apt-cdrom-setup.orig/usr/bin/load-install-cd apt-cdrom-setup/usr/bin/load-install-cd
--- apt-cdrom-setup.orig/usr/bin/load-install-cd 2011-03-23 03:00:10.0 +0100
+++ apt-cdrom-setup/usr/bin/load-install-cd 2013-10-11 21:36:49.735038936 +0200
@@ -10,6 +10,13 @@ ROOT=$1
logoutput=log-output -t load-install-cd
+# Why isn't this function, or something like it,
+# in /usr/share/debconf/confmodule ?
+db_getval()
+{
+ db_get $1 echo $RET || true
+}
+
check_id() {
cd_ids=$(LC_ALL=C $logoutput --pass-stdout chroot $ROOT \
apt-cdrom ident | grep ^Identifying | cut -d -f2)
@@ -29,18 +36,9 @@ while ! check_id; do
db_go || exit 10
done
-fs=iso9660
-if db_get cdrom-detect/cdrom_fs [ $RET ]; then
- fs=$RET
-fi
-OS=$(udpkg --print-os)
-case $OS in
- hurd)
- OPTIONS=ro
- ;;
- *)
- OPTIONS=ro,exec
- ;;
-esac
+fs=$(db_getval cdrom-detect/cdrom_fs)
+[ $fs ] || fs=iso9660
+OPTIONS=$(db_getval cdrom-detect/cdrom_options)
+[ $OPTIONS ] || OPTIONS=ro,exec
db_get cdrom-detect/cdrom_device
$logoutput mount -t $fs -o $OPTIONS $RET /cdrom
diff -rupN apt-cdrom-setup.orig/usr/lib/apt-setup/generators/40cdrom apt-cdrom-setup/usr/lib/apt-setup/generators/40cdrom
--- apt-cdrom-setup.orig/usr/lib/apt-setup/generators/40cdrom 2013-05-12 12:49:10.0 +0200
+++ apt-cdrom-setup/usr/lib/apt-setup/generators/40cdrom 2013-10-11 00:19:52.494473022 +0200
@@ -10,7 +10,9 @@ if ! type chroot_cleanup_localmounts /d
# Variant of chroot_cleanup that only cleans up chroot_setup's mounts.
chroot_cleanup_localmounts () {
rm -f /target/usr/sbin/policy-rc.d
- mv /target/sbin/start-stop-daemon.REAL /target/sbin/start-stop-daemon
+ if [ -f /target/sbin/start-stop-daemon.REAL ]; then
+ mv /target/sbin/start-stop-daemon.REAL /target/sbin/start-stop-daemon
+ fi
if [ -x /target/sbin/initctl.REAL ]; then
mv /target/sbin/initctl.REAL /target/sbin/initctl
fi
@@ -40,32 +42,23 @@ if [ ! -s /cdrom/.disk/info ]; then
exit 0
fi
-cd_mountable=1
-db_get cdrom-detect/hybrid || true
-if [ $RET = true ] || [ -d /hd-media ]; then
- cd_mountable=
-else
- db_get cdrom-detect/usb-hdd || true
- if [ $RET = true ]; then
- cd_mountable=
- fi
-fi
+# Why isn't this function, or something like it,
+# in /usr/share/debconf/confmodule ?
+db_getval()
+{
+ db_get $1 echo $RET || true
+}
+
+# See whether the device is mountable
+cd_mountable=true
+cd_mountable=$(db_getval cdrom-detect/cdrom_mountable)
remount_cd() {
- if [ $ROOT ] [ $cd_mountable ]; then
- fs=iso9660
- if db_get cdrom-detect/cdrom_fs [ $RET ]; then
- fs=$RET
- fi
- OS=$(udpkg --print-os)
- case $OS in
- hurd)
-OPTIONS=ro
-;;
- *)
-OPTIONS=ro,exec
-;;
- esac
+ if [ $ROOT ] [ $cd_mountable = true ]; then
+ fs=$(db_getval cdrom-detect/cdrom_fs)
+ [ $fs ] || fs=iso9660
+ OPTIONS=$(db_getval cdrom-detect/cdrom_options)
+ [ $OPTIONS ] || OPTIONS=ro,exec
db_get cdrom-detect/cdrom_device
$logoutput mount -t $fs -o $OPTIONS $RET /cdrom || true
fi
@@ -106,7 +99,7 @@ if [ $ROOT ]; then
chroot=chroot
# Allow
Bug#724931: Please include the patch in git
Quoting Andreas Cadhalpun (andreas.cadhal...@googlemail.com): I haven't heard from Ian since his last mail on 13th October and I have no clue what he has in mind as a more general solution. Perhaps he has been busy otherwise. In general I think, that it would be good to include the patch now and add any additional improvements later. I re-added this to my TODO list. I'm just leaving a few more days as an opportunity for Ian to react... signature.asc Description: Digital signature
Bug#724931: Please include the patch in git
Quoting Andreas Cadhalpun (andreas.cadhal...@googlemail.com): Control: affects -1 + hw-detect mountmedia Hi, the patch for this bug affects the following packages: * apt-setup * cdrom-detect * hw-detect (check-missing-firmware) * mountmedia Since among the maintainers of all these packages is Christian Perrier, I'm sending this to you. A short summary: 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: ../... Ian later asked for more time as he's working on more general fixes. So, should I wait or shouldn't I? signature.asc Description: Digital signature
Bug#724931: Please include the patch in git
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
Bug#724931: Please include the patch in git
On Sun, 2013-10-13 at 01:21 -0700, ian_br...@fastmail.net wrote: On Sat, 12 Oct 2013 20:03:53 +0200 Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: [...] 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. [...] The ext2 and ext3 modules are also being removed from Debian kernel packages, starting with Linux 3.11. Ben. -- Ben Hutchings Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth signature.asc Description: This is a digitally signed message part
Bug#724931: Please include the patch in git
Hi, On 13.10.2013 10:21, ian_br...@fastmail.net wrote: 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. I'm curious, what features do you want to add? 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. Yes, loopback is the lo network interface, but for some reason I don't understand, GRUB uses the term loopback for booting from an ISO: https://www.gnu.org/software/grub/manual/grub.html#Loopback-booting This is why I constantly get confused between loopback and (the more descriptive) loopmount. 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). In my latest patch, some changes are effective, even if loopmount is not used, e.g.: * I cleared up the workaround for bug #608201, so that in the future it should not be necessary to change apt-cdrom-setup, if one adds a new booting method. * Since I included more filesystem drivers in the initrd, I changed the code so that USB-HDD also works from filesystems other than FAT. * I also exported the boot options from cdrom-detect and imported them in several places, instead of determining the again. This should not have any effect, if loopmount is not used, but if it is, the 'loop' option is used. If in the future some changes are made with the boot options in cdrom-detect, they will be respected by apt-cdrom-setup. It appears that the ext4 module would be sufficient to also mount ext2/ext3, whereas the reverse would not be true. I just tested loopmounting from an ext2 filesystem, while only the ext4 filesystem driver was in the initrd: It worked, blkid identified it as ext4 and mounting as such only gave an info message: kernel: [ 13.170123] EXT4-fs (sdb1): mounted filesystem without journal. Opts: (null) And according to Ben there will be no ext2/ext3 modules in the kernel starting with 3.11. So just add the ext4 module. I don't know what usage UDF gets (besides DVDs) that would justify including it in the initrd. I have to admit, that I didn't know more than that a month ago. (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. FAT32 is no modern filesystem, since it doesn't support files larger than 4 GB, e.g. the debian-7.1.0-amd64-DVD-2.iso with 4.7 GB. The reason for it to be still widespread is, that it is supported by (nearly?) all operating systems. While F2FS might be modern and optimized for flash drives, it is only supported in Linux and thus cannot replace FAT32. UDF on the other hand is used for DVDs and most operating systems can read (and even write to) it. Furthermore it supports large files and thus is the most probable replacement for FAT32. For further explanation see: http://duncanlock.net/blog/2013/05/13/using-udf-as-an-improved-filesystem-for-usb-flash-drives/ Already, some USB sticks sold are formatted with UDF. So I recommend to add UDF support now, although it will probably not be relevant for the broad audience until several years have passed by. 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. In fact, with my patch, they are treated practically the same, with the one exception of CD set support, which is only available for actual disks in a drive and loopmounted ISOs. It is probably possible to extend this support to isohybrid and USB-HDD, but it is assumed, that one does not want to use multiple USB sticks to install Debian. 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. That would be great. 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. The problem is, that I also have to modify the apt-cdrom-setup.udeb, that is not in the initrd, but gets loaded afterwards from /pool/main/a/apt-setup. * 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
Bug#724931: Please include the patch in git
Control: affects -1 + hw-detect mountmedia
Hi,
the patch for this bug affects the following packages:
* apt-setup
* cdrom-detect
* hw-detect (check-missing-firmware)
* mountmedia
Since among the maintainers of all these packages is Christian Perrier,
I'm sending this to you.
A short summary:
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
Here ISO specifies the path to the ISO, i.e.
/ISO/debian-7.1.0-amd64-CD-1.iso.
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.
If the boot parameter is not given (or no ISO could be found),
everything works essentially as before.
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.
(Fat is somewhat outdated.)
The patch makes it possible to boot using USB-HDD from any filesystems
with drivers in the initrd.
The patch also cleans up the somewhat messy workaround for bug #608201.
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 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.
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
* 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.)
Since the patch works well and does no harm, I ask you to include it in git.
Changes since the last patch:
* finish.d/10apt-cdrom-setup: Remove the whole 'deb file:' line. With
the last patch, an empty line remained.
* The script mountmedia uses 'mount -tauto', 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.
* 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.
* Removed iso-hybrid and usb-hdd templates, since it works well without.
Best regards,
Andreas
Apply-Patches.sh
Description: application/shellscript
diff -rupN apt-cdrom-setup.orig/usr/bin/load-install-cd apt-cdrom-setup/usr/bin/load-install-cd
--- apt-cdrom-setup.orig/usr/bin/load-install-cd 2011-03-23 03:00:10.0 +0100
+++ apt-cdrom-setup/usr/bin/load-install-cd 2013-10-11 21:36:49.735038936 +0200
@@ -10,6 +10,13 @@ ROOT=$1
logoutput=log-output -t load-install-cd
+# Why isn't this function, or something like it,
+# in /usr/share/debconf/confmodule ?
+db_getval()
+{
+ db_get $1 echo $RET || true
+}
+
check_id() {
cd_ids=$(LC_ALL=C $logoutput --pass-stdout chroot $ROOT \
apt-cdrom ident | grep ^Identifying | cut -d -f2)
@@ -29,18 +36,9 @@ while ! check_id; do
db_go || exit 10
done
-fs=iso9660
-if db_get cdrom-detect/cdrom_fs [ $RET ]; then
- fs=$RET
-fi
-OS=$(udpkg --print-os)
-case $OS in
- hurd)
- OPTIONS=ro
- ;;
- *)
- OPTIONS=ro,exec
- ;;
-esac
+fs=$(db_getval cdrom-detect/cdrom_fs)
+[ $fs ] || fs=iso9660
+OPTIONS=$(db_getval cdrom-detect/cdrom_options)
+[ $OPTIONS ] || OPTIONS=ro,exec
db_get cdrom-detect/cdrom_device
$logoutput mount -t $fs -o $OPTIONS $RET /cdrom
diff -rupN apt-cdrom-setup.orig/usr/lib/apt-setup/generators/40cdrom apt-cdrom-setup/usr/lib/apt-setup/generators/40cdrom
--- apt-cdrom-setup.orig/usr/lib/apt-setup/generators/40cdrom 2013-05-12 12:49:10.0 +0200
+++ apt-cdrom-setup/usr/lib/apt-setup/generators/40cdrom 2013-10-11 00:19:52.494473022 +0200
@@ -10,7 +10,9 @@ if ! type chroot_cleanup_localmounts /d
# Variant of chroot_cleanup that only cleans up chroot_setup's mounts.
chroot_cleanup_localmounts () {
rm -f /target/usr/sbin/policy-rc.d
- mv /target/sbin/start-stop-daemon.REAL /target/sbin/start-stop-daemon
+ if [ -f /target/sbin/start-stop-daemon.REAL ]; then
+ mv /target/sbin/start-stop-daemon.REAL /target/sbin/start-stop-daemon
+ fi
if [ -x
