blkid does not detect the USB flash memory stick.

stf92 · 04-24-2015, 05:08 PM

Slackware 14.1

I ran pkgtool to make a booteable stick, but this program said "No new memory stick found". Then I ran blkid and it did not listed it. I then ran 'fdisk -l' and it reported the stick all right. but it said (I am not able to copy and paste the output) "This doesn't seem like a partition table", under /dev/sdb1.

Then I booted Windows 7 and the explorer (file manager) found no trouble with it. The last thing I did with the stick was to run WinSetupFromUSB-1.4.exe with a Windows ISO image. But I did not do one thing: try to write it with dd, which is what i'll now do. Any idea why pkgtool does not see it?

Didier Spaier · 04-24-2015, 05:38 PM

Maybe the USB stick was already inserted when you saw this message:

Code:

Please insert a USB flash memory stick and then press ENTER to create a boot stick.

If that is the case try again but then, don't insert the USB stick until you see this message.

Explanation: the program (actually /var/log/setup/setup.80.makebootdisk) compares the list of USB devices before and after it outputs this message. If all the USB devices it finds after were already there before, it says "No new memory stick found". This is to avoid that you mistakenly erase the content of your installation USB stick in case you use one, as the same program is used during installation or in an already installed system.

If following my advice doesn't work, please:

insert the USB stick
then provide the output of
Code:
```
lsblk -o name,size,model,fstype
```

I ask you to do that because lsblk finds its data in /sys/block, as does setup.80.makebootdisk.

stf92 · 04-24-2015, 06:24 PM

I did what you said, i.e, run pkgtool with no stick plugged in and it recognized it. But when booting from the resulting stick, the keyboard does not respond. Anyways, the purpose of running pkgtool>Make booteable stick is to be able to boot the machine with no MBR on the hard disk. I want to write the MBR with a program that will tell me the state of the CPU when the BIOS transfers control to 00007C0, where a copy of the MBR itself has been previously copied by the BIOS.

Of course, after that program runs I must be able to restore the MBR. To do that, I must be able to boot from some media, namely the stick, the only other external memory storage device I have. But if the code in the stick wants to mount a /dev/sdaN device, then I am in trouble.

In a machine with optical drives, I can boot with the slackware intall disc and I do not need to even have a hard disk. Can this behavior be replicated by the code written into the stick by pkgtool?

Didier Spaier · 04-24-2015, 10:43 PM

Quote:

Originally Posted by stf92

In a machine with optical drives, I can boot with the slackware intall disc and I do not need to even have a hard disk. Can this behavior be replicated by the code written into the stick by pkgtool?

No, because /var/log/setup/setup.80.makebootdisk just does what it it says: make a boot disk.

But you can instead use dd to put the installer itself on an USB stick and it will work exactly as on an optical media.

But how are you going then to restore the MBR? Of course you could use dd (shipped in the installer), but where will be the backup that you will need to copy to the hard disk?

I mean, there's no issue to write the boot code on 446 bytes, tools like fdisk or cfdisk can do that, but where are you going to store either the whole 512 bytes or your partition table, assuming that you want to restore this partition table as else the endeavor you describe is pointless?

stf92 · 04-25-2015, 09:31 AM

I see. I can't mount the stick and copy the MBR as a file onto it. I could use a second stick for the MBR backup but I only have one. So, I will copy an image of the MBR to one of the last stick sectors, after having copied the slack image to the stick, in this way:

Code:

 dd if=/dev/sda of=dev/sdb seek=SEEK bs=512 count=1

For instance, if the iso image is 1000000 512-byte sectors, I can put SEEK= 1000000. Then, after having overwritten the MBR with my program, when I want to have my computer back, I boot with the stick and run

Code:

 dd if=/dev/sdb of=/dev/sda skip=SEEK bs=512 count=1

and everything will be as at the beginning, I hope. What could possibly go wrong with this scheme?

perbh · 04-25-2015, 04:08 PM

why would you want to do that? the MBR is the _first_ 512 bytes of every disk ... if the disks are of different sizes you want 448 bytes rather than 512 (because the latter will also copy the partition layout)
I can't see the purpose of using the seek option! (unless you use the value zero).

Didier Spaier · 04-25-2015, 05:26 PM

Another way would be to unpack the initrd, write a copy of the MBR as /MBR in its tree, repack it, then use dd to put it back.

But frankly all that is worthless as an USB stick is not that costly, at least in Paris.

gnashley · 04-26-2015, 03:24 AM

Not 448 bytes -it's 446 bytes which the bootcode occupies. 446=bootcode, next 64 bytes partition table, last two bytes are 'magic' which signal the end of the MBR.

stf92 · 04-26-2015, 02:50 PM

For what is worth, when the BIOS transfers control to the boot loader (jmp 000007c0), DX is DX=0x0800, which is wierd. This is an HP notebook booting from the hard disk. I would expect DL=0x80, not DL=0x00, which has always signaled the first floppy drive in a PC compatible.

Didier Spaier · 04-26-2015, 03:52 PM

Quote:

Originally Posted by stf92

For what is worth, when the BIOS transfers control to the boot loader (jmp 000007c0), DX is DX=0x0800, which is wierd. This is an HP notebook booting from the hard disk. I would expect DL=0x80, not DL=0x00, which has always signaled the first floppy drive in a PC compatible.

That depends on the BIOS boot order setting. Is it set to try to boot off a floppy disk first, that's what we would expect

Furthermore that is the default boot order IIRC; try the first floppy drive, then if that fails try the first hard disk.

Anyway this issue has nothing to do with the topic of this thread, or do I miss something?

stf92 · 04-26-2015, 04:19 PM

Well, post #1 had to do with the first step in finding the contents of the DL register, namely, to be able to boot from the flash memory stick, once I had destroyed the MBR. After that was solved, I did not want to créate a new thread for what was basically the same problem.

As to the value in DL, it is, as far as I know, an indicator of the media from which the BIOS booted, and is not directly related with boot order.

Didier Spaier · 04-26-2015, 04:39 PM

Quote:

Originally Posted by stf92

As to the value in DL, it is, as far as I know, an indicator of the media from which the BIOS booted, and is not directly related with boot order.

That's right.
But see this code snippet in GRUB source code (file /grub-2.00/grub-core/boot/i386/pc/boot.S):

Code:

/* general setup */
    cli        /* we're not safe here! */

        /*
         * This is a workaround for buggy BIOSes which don't pass boot
         * drive correctly. If GRUB is installed into a HDD, check if
         * DL is masked correctly. If not, assume that the BIOS passed
         * a bogus value and set DL to 0x80, since this is the only
         * possible boot drive. If GRUB is installed into a floppy,
         * this does nothing (only jump).
         */
    . = _start + GRUB_BOOT_MACHINE_DRIVE_CHECK
boot_drive_check:
        jmp     3f    /* grub-setup may overwrite this jump */
        testb   $0x80, dl
        jz      2f
3:
    /* Ignore dl different from 0-0x0f and 0x80-0x8f.  */
    testb   $0x70, %dl
    jz      1f
2:    
        movb    $0x80, %dl
1:
    /*
     * ljmp to the next instruction because some bogus BIOSes
     * jump to 07C0:0000 instead of 0000:7C00.
     */
    ljmp    $0, $real_start

So you just have a buggy BIOS, but you are not alone

stf92 · 04-26-2015, 07:14 PM

Yes. The code written by Lilo in my case after some manipulaiton with DH and DL ends up with DL=80 when callint int 13h. The object of all this is to have a Little fun following the boot loader code.

perbh · 04-26-2015, 08:21 PM

Quote:

Originally Posted by gnashley

Not 448 bytes -it's 446 bytes which the bootcode occupies. 446=bootcode, next 64 bytes partition table, last two bytes are 'magic' which signal the end of the MBR.

oooops - I stand corrected! 446+64+2 ... momentary brain-freeze