> Actually you *can* use fdisk to manage partitions on DASDs ... > Example: to get rid of the implicitly created DASD partitions on > /dev/dasdx, use these commands: > > echo w | fdisk /dev/dasdx
Nice. THANK YOU. A quick check confirms that it works for both EXT2 and ISO-9660 filesystems. You have to create the filesystem first, of course. For example, 'mke2fs' will write zeros in the first 1K. (ISO FS starts at 32K, I believe.) But 'fdisk' safely keeps its PC partition table down to 512 bytes, so it does not clobber the FS. Do the 'fdisk' after the 'mke2fs' and it works like a charm. -- R; <>< Rick Troth Velocity Software http://www.velocitysoftware.com/ On Mon, Jan 10, 2011 at 08:25, Peter Oberparleiter <[email protected]> wrote: > On 04.01.2011 16:02, Richard Troth wrote: >> >> Mark is correct: one automagically created partition. Worse, there >> is no 'fdasd' or 'fdisk' management of that partition. > > Actually you *can* use fdisk to manage partitions on DASDs which are > formatted with a fixed block size (ECKD LDL or FBA), regardless of > whether DIAG access is used or not. > > Example: to get rid of the implicitly created DASD partitions on > /dev/dasdx, use these commands: > > echo w | fdisk /dev/dasdx > > This will write an MS-DOS type master boot record with an empty > partition table to dasdx. Note that some operations (mkfs.ext, pvcreate) > seem to overwrite the MBR so the fdisk step should be performed last. > > More background: When a DASD is set online, the Linux kernel attempts to > recognize the partition type by letting all supported partition type > handlers have a look at the disk contents. This process happens > sequentially and stops once a handler indicates that it has found a > valid partition. The DASD partition handler comes very late in the list, > so pretty much any partitioning scheme supported by the Linux kernel can > be used to circumvent implicit DASD partitioning. > >> WORSE STILL, >> you *must* put the filesystem into the "partition" (such as it is) if >> you are going to boot from this disk. A filesystem in /dev/dasdx will >> be clobbered by the first stage of the boot loader, while a filesystem >> in /dev/dasdx1 is protected by the extra 8K of padding. (12K total) >> >> I checked it again this morning. The bootstrap overwrites the root inode. > > This is a side effect of the zipl boot loader design, more precisely of > the size of the first stage IPL code that is written to block 0. It's > conceivable that this could be changed in the future. > >> God bless whoever in Boeblingen fixed this problem for FBA disks. You >> can use the pseudo-partition, or not. You can boot from them either >> way. > > This "problem" never existed for FBA disks - the first stage FBA IPL > code only spans a single FBA block. According to Martin Schwidefsky this > approach was chosen because there were no format or layout restrictions > for FBA disk so they decided to keep it similar to the Intel world. > > > Regards, > Peter Oberparleiter > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
