search for: hdn

Hi All, I sent the patch to allow blktap to be able to booted as system bolume for PV-on-HVM. However, there was a problem that hdN and xvdN were not able to be specified at the same time. I made the patch to correct it as follows. - Whether hdN is defined first is checked. - If hdN is defined, xvdN is not replaced with hdN. Signed-off-by: Takanori Kasai <kasai.takanori@jp.fujitsu.com> Best Regards, -- Takanori Kasai...

Hi All, I sent the patch to make blktap work with PV-on-HVM. I corrected the part that had been pointed out in the Xen community. ・All xvdN disk is looked like hdN. ・All tap disks are checked.(tap:aio, tap:sync, tap:vmdk, etc.) We cannot use blktap for the volume of the system with PV-on-HVM and are embarrassed. Could you apply this patch? Or, please give the comment to me. Signed-off-by: Takanori Kasai <kasai.takanori@jp.fujitsu.com> Best Regards,...

...000 Apr 21 15:02:14 aurora kernel: attempt to access beyond end of device Apr 21 15:02:14 aurora kernel: 09:03: rw=2, want=623969628, limit=10240000 Apr 21 15:07:35 aurora kernel: VFS: dquota write failed on dev 09:06 Apr 21 15:07:35 aurora last message repeated 32 times Here is my configuration: hdn@aurora:~$ uname -a Linux aurora 2.4.18 #1 SMP Sun Apr 21 17:20:25 NOVST 2002 i686 unknown hdn@aurora:~$ mount /dev/md/3 on / type ext3 (rw,errors=remount-ro,usrquota,grpquota) proc on /proc type proc (rw) /dev/hda2 on /boot type ext2 (rw,noexec,nosuid,nodev) /dev/md/5 on /var type ext3 (rw,nosuid,...

...tification of a new message works fine. However, when I set up voicemail.conf to have an attachment of the file sent to email I get an error message like this on the console: [Feb 17 13:33:37] WARNING[17296]: app_voicemail.c:1633 base_encode: Failed to open file: /var/spool/asterisk/voicemail/hdn/101/tmp/KtqxHG.WAV: No such file or directory The directory exists and is owned by asterisk.asterisk. The context and extension are valid, and as I said all other aspects of voicemail are working. I even get a msg####.WAV file attached to my notification message, but it is zero bytes. Sox i...

...) @@ -467,7 +467,7 @@ and resolve_fstab_device spec md_map os_type = debug_matching "Hurd"; let typ = PCRE.sub 1 and disk = int_of_string (PCRE.sub 2) - and part = int_of_string (PCRE.sub 3) in + and part = PCRE.sub 3 in (* Hurd disk devices are like /dev/hdNsM, where hdN is the * N-th disk and M is the M-th partition on that disk. @@ -504,7 +504,7 @@ and resolve_xdev typ disk part default = let i = drive_index disk in if i >= 0 && i < Array.length devices then ( let dev = Array.get devices i in - let dev = dev ^ string...

...if (check_hostname_unix (g, fs) == -1) @@ -1635,6 +1642,22 @@ resolve_fstab_device (guestfs_h *g, const char *spec, Hash_table *md_map) if (r == -1) return NULL; } + else if (match3 (g, spec, re_hurd_dev, &type, &disk, &part)) { + /* Hurd disk devices are like /dev/hdNsM, where hdN is the + * N-th disk and M is the M-th partition on that disk. + * Turn the disk number into a letter-based identifier, so + * we can resolve it easily. + */ + int disk_i = guestfs___parse_unsigned_int (g, disk); + char disk_as_letter[2] = { 0 }; + disk_as_lett...

...Cumm wrote:- >TC64 still has ISOLINUX. The basics are to use chain.c32 to boot >USB-B:p3 but syntax depends. Ideally, it's a modern enough Syslinux >version that you can use the "guid" or "label" options to auto-detect >its location rather than "chain.c32 hdN M". Hopefully your FS >label/GUID is unique sdb3 Boot Primary ext4 [New486Xfce] 7593.79 New486Xfce <- Label per cfdisk Useing existing working ISOLINUX entry as template: Since I will assume that the order of mounting / accessing files is: 1: KERNEL /boot/S3P...

AIM: from <isolinux> on USBstikA, boot Debian7 installation on USBstikB. EXISTING STATE: USBstikA is TinyCore64bit booter, with:- /boot/isolinux/* 61312 Oct 26 2016 menu.c32 24576 Oct 26 2016 isolinux.bin 2069 Nov 22 01:24 isolinux.cfg ... USBstikB-partition3: Currently boots a 32bit installation, via GRUB using the entry:----- menuentry 'Debian GNU/Linux, with Linux

...ems to be the same question. TC64 still has ISOLINUX. The basics are to use chain.c32 to boot USB-B:p3 but syntax depends. Ideally, it's a modern enough Syslinux version that you can use the "guid" or "label" options to auto-detect its location rather than "chain.c32 hdN M". Hopefully your FS label/GUID is unique -- -Gene

...Ctrl-U -> kill entire command line input. * The "samples" directory contains a (barely at all tested) chain loading example, chain.c32, which may be used to chainload local floppy disks and hard disks. Use with "chain fdN" or "chain hdN [partition]"; N = 0 for the first drive of each type. Begin3 Title: syslinux Version: 2.08 Entered-date: 2003-12-12 Description: SYSLINUX is a collection of boot loaders for the Linux operating system which operates off MS-DOS floppies,...

...t;>TC64 still has ISOLINUX. The basics are to use chain.c32 to boot >>USB-B:p3 but syntax depends. Ideally, it's a modern enough Syslinux >>version that you can use the "guid" or "label" options to auto-detect >>its location rather than "chain.c32 hdN M". Hopefully your FS >>label/GUID is unique > > sdb3 Boot Primary ext4 [New486Xfce] 7593.79 > New486Xfce <- Label per cfdisk > Useing existing working ISOLINUX entry as template: > > Since I will assume that the order of mounting / accessi...

...access: 3 status: 1 number: 0 open: 1 allocation: 0 device: 58:01 # /sbin/pvscan pvscan -- reading all physical volumes (this may take a while...) pvscan -- ACTIVE PV "/dev/hdm" of VG "foo1" [76.31 GB / 0 free] pvscan -- ACTIVE PV "/dev/hdn" of VG "foo3" [76.31 GB / 0 free] pvscan -- ACTIVE PV "/dev/hdk" of VG "foo3" [74.50 GB / 0 free] pvscan -- ACTIVE PV "/dev/hdl" of VG "foo2" [74.50 GB / 0 free] pvscan -- ACTIVE PV "/dev/hdi" of VG "foo1" [76.31 GB /...

Before, in my "Hard Problem" email I was trying to communicate a design issue were trying to solve with Xen. This is what we need to do: 1) Deploy 24 Windows XP VMs in parallel. 2) Boot them from a shared Windows XP C: drive. 3) Since this is a read-only shared image we obviously can''t have multiple VM''s writing to it. 4) All writes to the boot image for logging,

Before, in my "Hard Problem" email I was trying to communicate a design issue were trying to solve with Xen. This is what we need to do: 1) Deploy 24 Windows XP VMs in parallel. 2) Boot them from a shared Windows XP C: drive. 3) Since this is a read-only shared image we obviously can''t have multiple VM''s writing to it. 4) All writes to the boot image for logging,

...Mountable.of_device dev + ) + else default + ) + + else if PCRE.matches re_hurd_dev spec then ( + debug_matching "Hurd"; + let typ = PCRE.sub 1 + and disk = int_of_string (PCRE.sub 2) + and part = int_of_string (PCRE.sub 3) in + + (* Hurd disk devices are like /dev/hdNsM, where hdN is the + * N-th disk and M is the M-th partition on that disk. + * Turn the disk number into a letter-based identifier, so + * we can resolve it easily. + *) + let disk = sprintf "%c" (Char.chr (disk + Char.code 'a')) in + + resolve_xdev typ disk...

...t + ) + + else if Str.string_match re_hurd_dev spec 0 then ( + debug_matching "Hurd"; + let typ = Str.matched_group 1 spec + and disk = int_of_string (Str.matched_group 2 spec) + and part = int_of_string (Str.matched_group 3 spec) in + + (* Hurd disk devices are like /dev/hdNsM, where hdN is the + * N-th disk and M is the M-th partition on that disk. + * Turn the disk number into a letter-based identifier, so + * we can resolve it easily. + *) + let disk = sprintf "%c" (Char.chr (disk + Char.code 'a')) in + + resolve_xdev typ disk...

v9 was here: https://www.redhat.com/archives/libguestfs/2017-July/msg00139.html This depends on these three series (the first two being single minor patches): https://www.redhat.com/archives/libguestfs/2017-July/msg00207.html https://www.redhat.com/archives/libguestfs/2017-July/msg00209.html https://www.redhat.com/archives/libguestfs/2017-July/msg00215.html There is no substantive change. I

This depends on the patch series "[PATCH 00/27] Reimplement many daemon APIs in OCaml." (https://www.redhat.com/archives/libguestfs/2017-July/msg00098.html) v8 was posted here: https://www.redhat.com/archives/libguestfs/2017-June/msg00274.html v9: - I split up the mega-patch into a more reviewable series of smaller, incremental patches. There are some other changes vs v8, but

This fixes almost everything. Note that it adds an extra commit which fixes the whole utf8/iconv business. It's probably better to list what isn't fixed: (1) I didn't leave the osinfo code around because I'm still haven't looked too closely at virt-builder-repository. Can't we just fetch this code from the git history when we need it? (2) I didn't change the way

v10: https://www.redhat.com/archives/libguestfs/2017-July/msg00245.html No actual change here, but I rebased and retested. Also this series now does not depend on any other patch series since everything else needed is upstream. Rich.