Bug#534887: live-initramfs: Loop mounting .iso for booting from multi-purpose USB stick?
Package: live-initramfs Severity: wishlist Hi, I've been trying to build a versatile USB stick, with the imntent that it be able to choose between various images at a grub prompt. Some .iso images (i.e. http://partedmagic.com/) are happy with this setup, becasue once booted (via grub4dos's ability to map a .iso and boot it) they look around for the image they came from and loop mount it, in much the same way as debian-live looks for its .squashfs debian-live does not appear to have this ability at present, although given that it can find the .squashfs I'd guess it's not going to be too hard to add, but I'm afraid my cursory glance over the code did not reveal the place where it should be added. Of course, it's possible to extract the .squashfs and put that on the stick: http://wiki.hands.com//howto/ultimate-usb-stick/#gettingdebian-livetorun but that seems like a bit of a kludge. I realise that there's already a usb-hdd target, but that involves wiping out the USB stick, which is tiresome, especially in these days of ever growing capacity. It seems to me that the ability to have a selection of .ISO's on a stick, and upgrade them as you see fit adds another dimension of conveinience. There is at least one gotcha though -- grub will often fail to map an image if it's fragmented, so you're liable to have to copy all the images off the stick, delete them and then write them back to make it happy. The --mem option to grub's map command is supposed to handle that case, by copying the image to ram, but I've not had a lot of luck with that. Note that when I say grub here I'm talking about grub4dos which is pretty much the same as grub2, but seems to deal with the vagaries of USB-ZIP rather better than grub2 at the moment. Cheers, Phil. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#534887: live-initramfs: Loop mounting .iso for booting from multi-purpose USB stick?
On Sun, Jun 28, 2009 at 11:27:30AM +0200, Michael Prokop wrote: > * Philip Hands [20090628 01:25]: > > > I've been trying to build a versatile USB stick, with the imntent that > > it be able to choose between various images at a grub prompt. Some > > .iso images (i.e. http://partedmagic.com/) are happy with this setup, > > becasue once booted (via grub4dos's ability to map a .iso and boot it) > > they look around for the image they came from and loop mount it, in much > > the same way as debian-live looks for its .squashfs > > > debian-live does not appear to have this ability at present, although > > given that it can find the .squashfs I'd guess it's not going to be > > too hard to add, but I'm afraid my cursory glance over the code did not > > reveal the place where it should be added. > > JFTR: > > http://git.grml.org/?p=live-initramfs-grml.git;a=blob;f=debian/patches/06_support_fromiso_isofrom.dpatch;hb=HEAD > http://git.grml.org/?p=live-initramfs-grml.git;a=blob;f=debian/patches/07_support_findiso.dpatch;hb=HEAD > > should basically do what you want. Yup, I've tried applying them to the live-initramfs from debian's git, and as long as I specify fromiso=/debian-live.iso (and call the image that, of course) it works. BTW would it not be a good idea to insert a / in front of the $FINDISO's in the script, so that people don't have to remember it on the kernel command line? > Do I understand it right that the partedmagic live system doesn't > require *any* additional bootoptions at all to boot the ISO directly > from USB (running losetup & CO on it's own)? Yes. Again you need to name the image as it expects (which in the case of PartedMagic 4.2 turns out to be "pmagic-4.1.iso", amusingly) > [...] > > There is at least one gotcha though -- grub will often fail to map an > > image if it's fragmented, so you're liable to have to copy all the images > > off the stick, delete them and then write them back to make it happy. > > The --mem option to grub's map command is supposed to handle that case, > > by copying the image to ram, but I've not had a lot of luck with that. > > Note that when I say grub here I'm talking about grub4dos which is pretty > > much the same as grub2, but seems to deal with the vagaries of USB-ZIP > > rather better than grub2 at the moment. > > You mention it in your blog article > http://wiki.hands.com//howto/ultimate-usb-stick/#gettingdebian-livetorun > already, but JFTR: grub2 with loopback option doesn't have the > fragmentation problem (though grub2 was/is kind of broken in current > Debian/unstable). > > What systems do you have that support USB-ZIP only? The one that prompted me to go to the effort was a recently purchased Jetway JNC91-330-LF 1.6GHz Dual Core ATOM Mainboard, which came with Pheonix AwardBIOS 6.00PG Copyright --2008 Oh, damn ... /me btters his head against the desk for a little while... Right, prompted by your question, and the fact that the system in question really ought to know how to boot USB-HDD, I had another rumage through the boot options. The menu for booting mentions USB-FDD USB-ZIP and USB-CD, but no USB-HDD. Of course, the thing that I'd failed to spot was the little arrow next to the "Hard Disk" option, indicating the presence of a sub-menu. If one selects that sub-menu, it reveals an option for the built-in HDD, and a "Bootable Add-in Cards" option -- which is what I was after all along, it seems. Ho hum -- I suppose I can make my usb-stick setup considerably less complicated now :-) Cheers, Phil. -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Presentation of iso downloads - simpler like Fedora?
0.4-amd64-lxde-desktop.iso.log 29-Jan-2012 13:28 208K [ ] debian-live-6.0.4-amd64-lxde-desktop.iso.packages 29-Jan-2012 13:27 21K [ ] debian-live-6.0.4-amd64-rescue.iso 29-Jan-2012 11:33 549M [TXT] debian-live-6.0.4-amd64-rescue.iso.list29-Jan-2012 11:33 18K [TXT] debian-live-6.0.4-amd64-rescue.iso.log 29-Jan-2012 11:33 236K [ ] debian-live-6.0.4-amd64-rescue.iso.packages29-Jan-2012 11:33 17K [ ] debian-live-6.0.4-amd64-standard.iso 29-Jan-2012 11:13 232M [TXT] debian-live-6.0.4-amd64-standard.iso.list 29-Jan-2012 11:13 18K [TXT] debian-live-6.0.4-amd64-standard.iso.log 29-Jan-2012 11:13 158K [ ] debian-live-6.0.4-amd64-standard.iso.packages 29-Jan-2012 11:12 5.8K [ ] debian-live-6.0.4-amd64-xfce-desktop.iso 29-Jan-2012 14:03 809M [TXT] debian-live-6.0.4-amd64-xfce-desktop.iso.list 29-Jan-2012 14:03 18K [TXT] debian-live-6.0.4-amd64-xfce-desktop.iso.log 29-Jan-2012 14:03 244K [ ] debian-live-6.0.4-amd64-xfce-desktop.iso.packages 29-Jan-2012 14:02 24K Woo! .iso images, we've won! Oh, wait, which one ... amd64-gnome-desktop.iso? shame there's no README to give a hint ... (there is a "standard" one, but that has no X so probably isn't what a newbie needs) Hmm, the ISO for the gnome variant is 1.1G -- that's not exactly useful for burning to a CD. How about XFCE? 809M -- still too big. So, after all that we've suckered people in with the cute front page, and then comprehensively wasted their time, particularly if they went to effort of downloading only to find that they've made a coaster by trying to put too big an image on their CD. I've heard the response that live.debian.net is actually supposed to be aimed at developers, so one shouldn't expect to find anything usable there for end users, which is fair enough, but in that case the front page should carry a prominent warning, and not have the cute icons. It would be really nice to have working live CDs, preferably linked to From the front page along with the install CDs, accessible in one or two clicks. I realise that one problem with that is the mechanical manner in which the ISOs produced by Debian Live just include the relevant tasks, and there's just too much stuff in that list to fit on a CD these days, which presumably means that someone needs to decide which packages to strip out to make them fit. Actually, in the case of the gnome CD, I see that it has the gnome package on it, which of course drags in a load of stuff, rather than just gnome-core and perhaps selected other packages. I'm not picking on gnome here BTW -- neither KDE nor XFCE fit either, so perhaps the problem is really that all the underlying X stuff is too big these days. Assuming that it's even possible to trim down the packages to fit on a CD, then perhaps a $DESKTOP-light or task-livecd-$DESKTOP package with a reduced set of dependencies from the default desktop package could be created, thus giving the Debian Live people a package to use for their CD images, and somewhere to report a bug when the resulting image creeps beyond the size of a CD. I can report this as a bug if that helps, but it seems to me that the debian-live folk need to have a chat with all the desktop packagers and come up with a solution between you (or declare it impossible, and put a warning on the live.debian.net front page that only DVD-sized images are available if you want to run a GUI) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpFESUPSgtpe.pgp Description: PGP signature
