blkid does not detect the USB flash memory stick.
 

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?

Maybe the USB stick was already inserted when you saw this message: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.

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?

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?

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: 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 and everything will be as at the beginning, I hope. What could possibly go wrong with this scheme?

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).

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.

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.

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?

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.

That's right.
But see this code snippet in GRUB source code (file /grub-2.00/grub-core/boot/i386/pc/boot.S):So you just have a buggy BIOS, but you are not alone ;)

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.

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