Hi, David Christensen wrote: > > there are valid reasons for putting the rescue operating > > system and the images on one large capacity device
rlhar...@oplink.net wrote: > 1. Would not that require the drive to be partitioned into an > "installation" partition and a "debianlive" partion? Yes. The partition for the disk based operating system has to be added. If you start with one of the isohybrid ISOs (e.g. debian-8.2.0-amd64-netinst.iso) then put it on the stick as described in https://www.debian.org/CD/faq/#write-usb After that your stick is a partitioned "hard disk". $ /sbin/fdisk -lu /dev/sdc Disk /dev/sdc: 1.9 GiB, 2004877312 bytes, 3915776 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x7714c637 Device Boot Start End Sectors Size Id Type /dev/sdc1 * 0 505855 505856 247M 0 Empty /dev/sdc2 3984 4815 832 416K ef EFI (FAT-12/16/32) Now you need a partition editor which is willing to tolerate - the fact that partition 2 lies inside partition 1 (/sbin/fdisk -l labels partition 1 as "Empty") - the fact that there are both, a MBR partition table and a GUID Partition Table (GPT). By this editor you add partition number 3 and maybe number 4. I will use MBR partition editor fdisk, but first zapp the GPT header block in order to remove the ambiguity of partitioning. The main header is at 512-block 1 (directly after MBR): $ dd if=/dev/zero of=/dev/sdc bs=512 seek=1 count=1 conv=notrunc The backup header is in the last 512-block of the ISO. It will become part of the new partition and there is supposed to be regarded as meaningless garbage. Next would be a session with fdisk: $ /sbin/fdisk /dev/sdc with input n p 3 w A total of 6 inputs, two of them empty lines. I did this as normal user (after chmod g+w /dev/sdc). So i have now to unplug the device and plug in again to force loading of the partition table by the running Linux kernel. Now i have /dev/sdc1, /dev/sdc2, dev/sdc3 $ /sbin/fdisk -l /dev/sdc ... Device Boot Start End Sectors Size Id Type /dev/sdc1 * 0 505855 505856 247M 0 Empty /dev/sdc2 3984 4815 832 416K ef EFI (FAT-12/16/32) /dev/sdc3 505856 3915775 3409920 1.6G 83 Linux Let's try whether it still boots: $ qemu-system-x86_64 -enable-kvm -m 512 -hda /dev/sdc ... Debian GNU/Linux installer boot menu ... $ qemu-system-x86_64 -enable-kvm -m 512 -cdrom /dev/sdc ... Debian GNU/Linux installer boot menu ... So now the stick is usable as Debian installation medium with additional data vault. The adventure begins when you populate that vault with a disk based operating system. ----- One could decide to let GPT survive. But other than MBR partitioning, GPT is clearly specified to not have overlapping partitions. I have a proposal pending to omit GPT from Debian ISOs and to append the EFI boot partition _after_ the ISO partition. Although this would waste the room of a duplicate EFI boot image, it would make above use case more straightforward. (Start fdisk and make partition. Basta.) The price of 416 KiB can hardly be unaffordable. > 2. And would it not be necessary that both partitions be bootable? I understand that the "bootable" flag is a hint towards bootloaders which partition to use by default or where to look for a partition boot loader. Neither ISOLINUX nor GRUB2 seem to care much about this. > 3. Or is the "installation" partition ruined when the boot loader is > installed? It will be interesting to see what debian-installer does to its own boot equipment when installing the boot loader of the hard disk based system. We have two boot loaders and their configurations: ISOLINUX used for BIOS machines, GRUB2 used for EFI machines. Only experiments will give insight. Make a (sparse) installation, reboot, and look what choices you get offered by the boot menu. Have a nice day :) Thomas
