From: Gerd Knorr <kraxel@suse.de>
To: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com, Nick Logan <nick_logan@symantec.com>
Subject: Re: sfdisk -g support in DomU
Date: Wed, 16 Nov 2005 13:21:41 +0100 [thread overview]
Message-ID: <437B2455.9050200@suse.de> (raw)
In-Reply-To: <A95E2296287EAD4EB592B5DEEFCE0E9D32E9FD@liverpoolst.ad.cl.cam.ac.uk>
>> support for disk geometry. So, any application that uses
>> "sfdisk -g" to get the geometry of a partition, or disk, will
>> fail when run in DomU.
>>
>> Is this a deliberate omission?
IMHO the applications should be fixed to not depend on the disk
geometry. There is LBA addressing for disks since ages, all the CHS
addressing you still find are some more or less random, artificial
values picked to satisfy prehistoric software ;)
> Most people tend to import block devices as partitions rather than whole
> disks, so often there isn't a 'whole disk' device to interogate (though
> I guess a partition table for it could be faked out if anyone really
> cared). Importing partitions rather than whole disks makes resizing of
> indidual partitions easier.
I prefeare whole disks, works fine for me, nobody seems to care much
about the geometry these days:
localhost ~ # cat /proc/partitions
major minor #blocks name
202 0 4194304 xvda
202 1 3750000 xvda1
202 2 250000 xvda2
localhost ~ # parted /dev/xvda print
Disk geometry for /dev/xvda: 0kB - 4295MB
Disk label type: msdos
Number Start End Size Type File system Flags
1 1kB 3840MB 3840MB primary ext2
2 3840MB 4096MB 256MB primary linux-swap
Information: Don't forget to update /etc/fstab, if necessary.
localhost ~ # sfdisk -l /dev/xvda
Disk /dev/xvda: cannot get geometry
Disk /dev/xvda: 0 cylinders, 0 heads, 0 sectors/track
Units = mebibytes of 1048576 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End MiB #blocks Id System
/dev/xvda1 0+ 3662- 3663- 3750000 83 Linux
/dev/xvda2 3662+ 3906- 245- 250000 82 Linux swap / Solaris
/dev/xvda3 0 - 0 0 0 Empty
/dev/xvda4 0 - 0 0 0 Empty
localhost ~ #
The only issue I trapped into so far is that the yast2 installer
appearently doesn't like disks which have neither some geometry nor an
existing partition table ...
cheers,
Gerd
next prev parent reply other threads:[~2005-11-16 12:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-16 11:21 sfdisk -g support in DomU Ian Pratt
2005-11-16 12:21 ` Gerd Knorr [this message]
2005-11-17 10:00 ` Nick Logan
2005-11-16 21:22 ` Adam Heath
-- strict thread matches above, loose matches on Subject: below --
2005-11-16 14:46 Ian Pratt
2005-11-16 10:08 Nick Logan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=437B2455.9050200@suse.de \
--to=kraxel@suse.de \
--cc=m+Ian.Pratt@cl.cam.ac.uk \
--cc=nick_logan@symantec.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.