similar to: mkdiskimage: perl error and lack of checks

utils/mkdiskimage.in: New option -S to sync zeroizing after each cylinder and to issue pacifier messages. --- utils/mkdiskimage_patched_03.in 2014-01-30 20:54:27.000000000 +0100 +++ utils/mkdiskimage.in 2014-01-30 20:59:19.000000000 +0100 @@ -139,6 +139,7 @@ if ( $file eq '' || $c < 1 || $h < 1 || print STDERR " -4 use partition entry 4 (standard for

Hi, i too played with mkdiskimage in order to get more Linux examples. When i applied it to a real 2 GB stick with write speed 4 MB/s i had enough time to add some pacifier code to the big zeroizer loop. (-s does not prevent zeroizing on block device. Probably because truncate() fails.) My pacifier is combined with what Perl advised me when i tried "fsync(OUTPUT);". Of course this

Hi, me: > > [mkdiskimage] -s does not prevent zeroizing on block device. Probably > > because truncate() fails. hpa: > Yes, we should probably fix that. The tool was originally designed for > images, not for hardware devices, and it doesn't make much sense to zero > the whole hardware device like that. Maybe for privacy reasons ? But indeed: -s should skip zeroizing,

Hi, Gene Cumm wrote: > > There's 0 need to build MBRs for EFI Ady wrote: > At least gptmbr.bin might come to mind It's source code looks like a BIOS MBR program which shall search the "active" partition in GPT rather than in the MBR partition table. See comments about "EBIOS" detection and "CHS" addresses in

Hi, this is the diff which i consider a halfways reasonable solution for the following problems with mkdiskimage: 1. Ignoring option -s if the target file is not suitable for truncate(). 2. Miscalculation of truncate() size by a factor of 512. 3. The storage capacity of device files can only be measured for Linux block devices. 4. Long time of silent work when slow devices (e.g. USB

On Wed, Sep 23, 2015 at 9:29 PM, Paul D. DeRocco via Syslinux <syslinux at zytor.com> wrote: > I've got an embedded x86 system built with Yocto, which boots from a USB > flash drive. It uses a loop mount to give access to an ext3 root file > system contained within a FAT16 file, which means it has persistent > storage. What I want is something that boots from the flash drive,

utils/mkdiskimage.in: With option -s: Avoid zeroizing the partition even if truncate() failed. --- utils/mkdiskimage_patched_01.in 2014-01-30 20:43:02.000000000 +0100 +++ utils/mkdiskimage.in 2014-01-30 20:45:09.000000000 +0100 @@ -217,8 +217,11 @@ print OUTPUT "\x55\xaa"; $totalsize = $c*$h*$s; $tracks = $c*$h; -# If -s is given, try to simply use truncate... -unless

--- utils/mkdiskimage.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/utils/mkdiskimage.in b/utils/mkdiskimage.in index 533193a..a95a077 100644 --- a/utils/mkdiskimage.in +++ b/utils/mkdiskimage.in @@ -218,7 +218,7 @@ $totalsize = $c*$h*$s; $tracks = $c*$h; # If -s is given, try to simply use truncate... -unless ($opt{'s'} && truncate(OUTPUT,

On 07/11/2014 12:33 AM, Thomas Schmitt wrote: > Technical side note: > It turned out that the lseek(2) function of NetBSD does not work > with SEEK_END as expected from the manual. libburn had to resort > to a binary search with try-and-error to determine device sizes. > I did not check perl's sysseek() whether it suffers from the > lseek(2) shortcomming, but i would expect

Windows uses several sectors in the _partition_ for booting. Windows only uses sector 0 of the Disk (the MBR), and does not use any other sectors. Other boot managers and copy protection software (the stuff that comes with TurboTax this year uses track 0, evil...) For FAT16 filesystems, only the first sector is used. For FAT32, there are 32 sectors that are reserved by the FS, and I've come

> There's 0 need to build MBRs for > EFI At least gptmbr.bin might come to mind (after all, GPT is part of the UEFI specs). Isohybrid with UEFI options perhaps too? > and I'm looking at why utils/ depends on mbr/ isohybrid(.pl) and mkdiskimage come to mind here? I'm not saying for certain these are the reasons for such dependencies, but they might (and perhaps

hello everybody, apologies if I'm missing something here Just tried to build 6.04-pre1 test version with: make bios installer and found some problems all (seemingly) related to inaccurate paths in various Makefiles. I enclose a complete patch at the end of this email, which details the problems I found and how they got fixed for me. As an example, this is the first error I got:

Let's try to get this thing released. Dag: will you do your RPM buildathon on this drop? Changes in 3.74: * New UI directive, which allows a more natural way to specify a menu system (or not.) With the UI directive specifying the menu system, the DEFAULT directive can be used to select the default entry inside the menus. * kbdmap.c32: new module

Hi, FYI syslinux upstream has a bugfix. Both in the 6.xx branch and the 4.xx branch. ----- Forwarded message from syslinux-bot for Martin Str|mberg <ams at ludd.ltu.se> ----- Date: Sat, 15 Apr 2017 10:27:08 -0700 From: syslinux-bot for Martin Str|mberg <ams at ludd.ltu.se> To: Syslinux commits mailing list <syslinux-commits at zytor.com> Cc: ams at ludd.ltu.se Subject:

It is good to see this ----- Forwarded message from syslinux-bot for Martin Str|mberg <ams at ludd.ltu.se> ----- Date: Sat, 25 Mar 2017 05:54:09 -0700 From: syslinux-bot for Martin Str|mberg <ams at ludd.ltu.se> To: Syslinux commits mailing list <syslinux-commits at zytor.com> Cc: ams at ludd.ltu.se Subject: [syslinux:master] mbr/isohdpfx.S: correct pointer for heads/sectors

3.75 is a bug fix release for 3.74. Changes in 3.75: * PXELINUX: fix the "keeppxe" option, which was broken in 3.74. * MEMDISK: correct the extraction of geometry information from the MBR of a hard disk image, again broken in 3.74. * extlinux(1) man page from Brian Pellin. * Simple menu: MENU SAVE is now controllable on a menu-by-menu

On Sun, Jun 23, 2013 at 11:09 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Sun, Jun 23, 2013 at 11:06 PM, Gene Cumm <gene.cumm at gmail.com> wrote: >> core and the simple menu do not interpret the IPAPPEND/SYSAPPEND >> directives in the same way. Which is the proper way? Either way, >> this should be clarified in the documentation. > > To be clear:

2015-10-08 12:58 UTC+02:00, Gene Cumm <gene.cumm at gmail.com>: > On Mon, Oct 5, 2015 at 2:15 PM, celelibi--- via Syslinux > <syslinux at zytor.com> wrote: >> From: Sylvain Gault <sylvain.gault at gmail.com> >> >> These patches basically remove unused linker scripts and port a change >> that was >> made to an unused script. >> >>

For the MBR: I usually don't touch the Microsoft MBR and chainload Linux from the Microsoft bootloader. However while trying to get my btrfs setup to work, I backed up the Microsoft MBR (dd if=/dev/sda bs=440 count=1 of=MBRbackup.bin) and I installed the syslinux MBR. I tried several ways: - with the script provided by Arch: syslinux-install_update -i -a -m - manual method with mbr.bin (first

2015-10-15 12:53 UTC+02:00, Gene Cumm <gene.cumm at gmail.com>: > On Mon, Oct 5, 2015 at 2:15 PM, celelibi--- via Syslinux > <syslinux at zytor.com> wrote: >> From: Sylvain Gault <sylvain.gault at gmail.com> >> >> Some linker scripts were splitted into i386 and x86_64 versions in >> commit d8eede3f2a360163235fad222a0190cd7c5bef38 but older scripts