Re: Adding partition(s) to a Debian install pendrive
Le 19/08/2016 à 11:43, Thomas Schmitt a écrit : Pascal Hambourg wrote: Any _decent_ BIOS should ignore the partition table. It is none of its business. Yep. But there seems to be the tendency to install MBR code which extents the BIOS by looking at the partition table and hop onto the x86 code at the start of the partition marked by the "Boot" flag. So there was a risk that some well meant default mechanism decided to replace the ISOLINUX x86 code by such chain loader code. As I previously wrote, such ill behaviour from a partition editor falls obviously in the "badly broken" category. A Debian isohybrid MBR together with invalid GPT and a valid APM (Apple Partition Map) is quite far from looking sane. These features are fishing for boot firmware, not for the applause of partition editors. That's why they are so much borderline. A partition editor could come to the idea to make the GPT valid by patching in its standard Protective MBR template. It could come to the idea to correct the insane size value or the other fields of the APM Block0, which are actually x86 instructions to let the CPU hop on the ISOLINUX El Torito boot image. You have a point, I didn't consider possible issues with the multiple invalid partition tables in the ISO hybrid image. I observed once that parted destroyed a hybrid MBR partition table I had created with gdisk (in order to boot Windows from BIOS on a GPT disk), and replaced it with a standard protective MBR. Well, with fdisk "n" it seems to be ok, currently. Yes, fdisk is definitely the tool of choice for this task. Parted just tries to be too clever.
Re: Adding partition(s) to a Debian install pendrive
Hi, Pascal Hambourg wrote: > Any _decent_ BIOS should ignore the partition table. It is none of its > business. Yep. But there seems to be the tendency to install MBR code which extents the BIOS by looking at the partition table and hop onto the x86 code at the start of the partition marked by the "Boot" flag. So there was a risk that some well meant default mechanism decided to replace the ISOLINUX x86 code by such chain loader code. > So unless the partitioning tool is badly broken Their disciples accuse each other of that sin. A Debian isohybrid MBR together with invalid GPT and a valid APM (Apple Partition Map) is quite far from looking sane. These features are fishing for boot firmware, not for the applause of partition editors. That's why they are so much borderline. A partition editor could come to the idea to make the GPT valid by patching in its standard Protective MBR template. It could come to the idea to correct the insane size value or the other fields of the APM Block0, which are actually x86 instructions to let the CPU hop on the ISOLINUX El Torito boot image. Well, with fdisk "n" it seems to be ok, currently. Have a nice day :) Thomas
Re: Adding partition(s) to a Debian install pendrive
Le 18/08/2016 à 21:45, Thomas Schmitt a écrit : Pascal Hambourg wrote: i wrote: Let's hope the USB stick still boots via BIOS and EFI ... It boots via any decent BIOS. That would be the more likely candidate for failure, because the BIOS hops on the x86 code in the MBR of which the partition table got manipulated by fdisk. Any _decent_ BIOS should ignore the partition table. It is none of its business. So unless the partitioning tool is badly broken and messed with the boot program in the MBR, the BIOS boot should be unaffected.
RESOLVED: Re: Adding partition(s) to a Debian install pendrive
Thanks to all who replied (or read my original post), the problem is resolved. I followed the instructions in Thomas Schmitt's first reply, and things just worked. I need to try to puzzle out what I did differently the first time--I do know one difference, I was trying to make a logical instead of a primary partition, maybe that had something to do with it. And, I guess it is possible in all the attempts I made, maybe in some of them I hadn't umounted the drive before partioning (I'm about 95% sure I did, but ??. At this point in time, I probably won't file a bug against that document, but I'll think it over (sleep on it) and might suggest adding explicit instructions (like Thomas'). Also, I learned some other useful things, like lsblk. Thanks again! Randy Kramer On Thursday, August 18, 2016 03:45:06 PM Thomas Schmitt wrote: > Pascal Hambourg wrote:
Re: Adding partition(s) to a Debian install pendrive
Hi, Pascal Hambourg wrote: > Fdisk [...] calls the system call to tell the > kernel to re-read the partition table Ah yes. That's plausible. With my previous Linux i would have had to unplug and re-plug the stick. But Debian 8 noticed the new partition without that: $ ls -l /dev/sdc* brw-rw 1 root thomas 8, 32 Aug 18 20:44 /dev/sdc brw-rw 1 root disk 8, 33 Aug 18 20:44 /dev/sdc1 brw-rw 1 root disk 8, 34 Aug 18 20:44 /dev/sdc2 brw-rw 1 root disk 8, 35 Aug 18 20:44 /dev/sdc3 systemd magic ? i wrote: > > Let's hope the USB stick still boots via BIOS and EFI ... > It boots via any decent BIOS. That would be the more likely candidate for failure, because the BIOS hops on the x86 code in the MBR of which the partition table got manipulated by fdisk. > I haven't tested EFI boot with it, but I don't > see why it would not work as the new partition is "regular". As long as we have only one partition of type 0xef and not overlapping partitions of non-zero type, EFI should be happy. From MBR it takes only the partition table entry to find its FAT filesystem with the boot programs. Now it has to be tested whether or how easily the installer can make use the files in partition 3. > > > https://www.debian.org/releases/jessie/amd64/ch04s03.html.en This looks pre-isohybrid, i.e. two generations behind of debian-cd for i386 and amd64. I understand arm64 is suitable for CD and USB stick, too. Some other arches make no difference between CD and disk at all. Have a nice day :) Thomas
Re: Adding partition(s) to a Debian install pendrive
On Thu 18 Aug 2016 at 20:57:33 +0200, Thomas Schmitt wrote: > $ /sbin/fdisk /dev/sdc > ... > Command (m for help): n > Select (default p): p > Partition number (3,4, default 3): 3 > First sector (505856-3915775, default 505856): > Last sector, +sectors or +size{K,M,G,T,P} (505856-3915775, default > 3915775): > > Created a new partition 3 of type 'Linux' and of size 1.6 GiB. > Command (m for help): w > The partition table has been altered. > Calling ioctl() to re-read partition table. > Re-reading the partition table failed.: Permission denied I get exactly this. > (I wonder by what method fdisk tries to read the table and fails) I ignore things I do not understand. > In any case it has worked: As it did for me. > $ /sbin/fdisk -l /dev/sdc > ... > Device Boot Start End Sectors Size Id Type > /dev/sdc1 * 0 505855 505856 247M 0 Empty > /dev/sdc2 39004731 832 416K ef EFI (FAT-12/16/32) > /dev/sdc3 505856 3915775 3409920 1.6G 83 Linux > > Let's hope the USB stick still boots via BIOS and EFI ... It does. > Next one would mkfs.fat a filesystem onto /dev/sdc2 and copy files to it. Indeed.
Re: Adding partition(s) to a Debian install pendrive
Le 18/08/2016 à 20:57, Thomas Schmitt a écrit : $ /sbin/fdisk /dev/sdc ... Command (m for help): n Select (default p): p Partition number (3,4, default 3): 3 First sector (505856-3915775, default 505856): Last sector, +sectors or +size{K,M,G,T,P} (505856-3915775, default 3915775): Created a new partition 3 of type 'Linux' and of size 1.6 GiB. Command (m for help): w The partition table has been altered. Calling ioctl() to re-read partition table. Re-reading the partition table failed.: Permission denied (I wonder by what method fdisk tries to read the table and fails) Fdisk does not tries to read the table, it calls the system call to tell the kernel to re-read the partition table to update its view of the partitions on the device. I guess this is a privileged operation. Note also that this old system call fails if any partition of the device is in use (mounted filesystem, active swap, active RAID member, part of an active LVM...). Parted, partprobe and other tools based on libparted use a newer system call which does not have this flaw. Let's hope the USB stick still boots via BIOS and EFI ... It boots via any decent BIOS. I haven't tested EFI boot with it, but I don't see why it would not work as the new partition is "regular".
Re: Adding partition(s) to a Debian install pendrive
Hi, rhkra...@gmail.com wrote: > I'll characterize those as, generally, partition the USB stick, then add the > installer image (and, iiuc, you have to use a different install image than > the DVD-1 .iso.) and a different procedure. The installer ISOs are supposed to be put on the base device of the USB stick (e.g. /dev/sdc, not /dev/sdc1). There they establish an MBR partition table which has two partitions: $ /sbin/fdisk -lu debian-8.4.0-amd64-netinst.iso ... Device Boot StartEnd Sectors Size Id Type debian-8.4.0-amd64-netinst.iso1 *0 505855 505856 247M 0 Empty debian-8.4.0-amd64-netinst.iso2 3900 4731 832 416K ef EFI (FAT This is not a very neat one, as Pascal Hambourg wrote meanwhile. (My program makes it, but it is not to blame because it only follows the ishoybrid+GRUB layout developed by Matthew Garrett for Fedora.) Also there is a GPT head block, which is normally not considered valid because not properly announced by MBR. Nevertheless some partition editors actively hate it. The type "Empty" is part of the trick, because EFI ignores it but Linux is willing to mount it (yielding the overall ISO). I tried on Debian 8: # get rw-permission to /dev/sdc $ dd if=debian-8.4.0-amd64-netinst.iso of=/dev/sdc bs=1M $ /sbin/fdisk -l /dev/sdc ... /dev/sdc1 *0 505855 505856 247M 0 Empty /dev/sdc23900 4731 832 416K ef EFI (FAT-12/16/32) $ /sbin/fdisk /dev/sdc ... Command (m for help): n Select (default p): p Partition number (3,4, default 3): 3 First sector (505856-3915775, default 505856): Last sector, +sectors or +size{K,M,G,T,P} (505856-3915775, default 3915775): Created a new partition 3 of type 'Linux' and of size 1.6 GiB. Command (m for help): w The partition table has been altered. Calling ioctl() to re-read partition table. Re-reading the partition table failed.: Permission denied (I wonder by what method fdisk tries to read the table and fails) In any case it has worked: $ /sbin/fdisk -l /dev/sdc ... Device Boot Start End Sectors Size Id Type /dev/sdc1 * 0 505855 505856 247M 0 Empty /dev/sdc2 39004731 832 416K ef EFI (FAT-12/16/32) /dev/sdc3 505856 3915775 3409920 1.6G 83 Linux Let's hope the USB stick still boots via BIOS and EFI ... Next one would mkfs.fat a filesystem onto /dev/sdc2 and copy files to it. Have a nice day :) Thomas