Jump to content











Photo
- - - - -

SVBus Virtual SCSI Host Adapter for GRUB4DOS

svbus virtual scsi host adapter grub4dos

  • Please log in to reply
111 replies to this topic

#76 Blackcrack

Blackcrack

    Frequent Member

  • Advanced user
  • 410 posts
  •  
    Germany

Posted 20 July 2019 - 06:23 AM

Misty, a lil/couple question/s

it is possible to make a program, who can put g4d in CDRom(folder) as iso and/or "install"
to USB-Stick with a emty "isos" folder, where it is possible to put different iso's in this folder
where make it possible to read in the ./isos folder and list this iso's in a bootmenu
and starts via svbus-host-adapter as live-cd ..
like linux.iso's or WinNT.iso and PE's in this single folder.

if there a folder with iso's as example ./boot-menu-isos/* take this folder and create a bootable iso from it..
i think on a Administration-tool DVD/blueray/USB-Stick with different iso's for a DVD or blueray or something
on a USB-Stick do i think on minisd's (with 64-128 or more Gig)
where be supported by USB-Stick
https://images-na.ss...mTL._SY355_.jpg
or
https://i.ebayimg.co...GfOx/s-l225.jpg

where it is really easy possible to have a huge usb.. therewith also the possible to have many iso's
on it where it is possible to "catch" and boot so creating a Application who make :

[ ]add/install G4D to the usb-stick and make it possible to boot to the Menu
[ ]create a bootmenu via array out from the ./isos by booting (menu-generating/creating by starting of G4D)
[ ]start the iso via svbus-vsha via selecting and starting the readed Iso-Filename (press enter)

as single exe..
is that interesting for you ?

best regards
Blacky

#77 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 20 July 2019 - 10:08 AM

@Blackcrack
I'm not sure if I have understood correctly.

If you are asking me if I am able to create an application/executable to complete the tasks in your post then the answer is most definitely no. Please do not be fooled by my Developer status - I'm no programmer.

The scope of your suggestions is huge. Let's take the autocreation of a grub4dos bootmenu from a range of .iso files copied to the proposed ./isos folder - which grub4dos settings are required? Different .iso files will likely require different grub4dos settings. Even using RTM windows builds, Windows NT5 and Windows NT6 are significantly different and require a completely different approach if trying to install Windows from a Grub4dos mapped .iso using SVBus. Generating a boot menu on the fly based on .iso files that are likely to have random names is a recipe for disaster.

Your post also mentioned linux.iso's - this has no relevance to SVBus.

Sorry if I have misunderstood any of your points.

One last comment - I prefer manual approaches to creating multiboot systems (including multiboot USB drives) as this helps me to understand the steps involved and helps to develop my skills and knowledge.

Regards,

Misty

#78 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15042 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 July 2019 - 10:17 AM

...."install"
to USB-Stick with a emty "isos" folder, where it is possible to put different iso's in this folder
where make it possible to read in the ./isos folder and list this iso's in a bootmenu
and starts via svbus-host-adapter as live-cd ..
like linux.iso's or WinNT.iso and PE's in this single folder..

You just described Easy2boot:

http://www.easy2boot.com/

by our friend Steve6375

 

SVBUS is a (Windows NT) virtual disk driver (with a particular capability to "hook" grub4dos mapped images), it is NOT a "host adapter" and it will ONLY work on Windows NT family OS's and PE's.

 

:duff:

Wonko



#79 Blackcrack

Blackcrack

    Frequent Member

  • Advanced user
  • 410 posts
  •  
    Germany

Posted 20 July 2019 - 11:26 AM

misty, on 20 Jul 2019 - 12:08 PM, said:
Your post also mentioned linux.iso's - this has no relevance to SVBus.

ah okey, was only a idea burb belch *s* ;)


Wonko, it supports not to read out the name of the iso's via array and
not a folder where you can place easy a couples of iso's where should be able to boot..

but well.. was only a burb belch..

best regards
Blacky

edit: uppss not burb.. a belch, have confused the words, sorry..



#80 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15042 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 July 2019 - 02:05 PM

ah okey, was only a idea burb *s* ;)


Wonko, it supports not to read out the name of the iso's via array and
not a folder where you can place easy a couples of iso's where should be able to boot..

but well.. was only a burb..

best regards
Blacky

You keep using that word

https://www.thefreedictionary.com/burb

 

 

 

burb   (bûrb)
n. Informal
A suburb.
[Short for suburb.]

839.png

 

 

:duff:

Wonko



#81 Blackcrack

Blackcrack

    Frequent Member

  • Advanced user
  • 410 posts
  •  
    Germany

Posted 20 July 2019 - 04:33 PM

thy for hint Wonko, have confused the words ..

 

it's easily to hot today ..



#82 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15042 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 July 2019 - 05:07 PM

thy for hint Wonko, have confused the words ..

 

it's easily to hot today ..

Yep, still not hot enough to cause an eruption : :eek: 

https://www.dictiona...om/browse/belch

 

Seriously, I don't think :dubbio: you can use "belch" the way you used (I mean without putting a hand before your mouth ;)), you probably meant more like burst or outburst? :unsure:

 

https://www.dreamsti...d-image28514472

 

:duff:

Wonko



#83 steve6375

steve6375

    Platinum Member

  • Developer
  • 7071 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 25 July 2019 - 07:19 AM

hiccup or brain fart?



#84 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15042 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 25 July 2019 - 09:37 AM

hiccup or brain fart?

No, hiccup or brain fart have a negative meaning,  what BlackCrack was trying to say is - I believe - that he had a sudden inspiration/intuition and spoke/wrote about it on the spur of the moment, without analyzing it/thinking about it much.

 

:duff:

Wonko



#85 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 737 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 06 September 2019 - 10:07 AM

Time to resurrect this topic.....Anyway, I gave up on trying to get SVBus working a few months ago due to lack of time. But I came back and noticed misty's instructions @ http://reboot.pro/to...e-3#entry211762.

 

I've noticed that many of you seem to be using SVBus in a RAMboot scenario. But that is not my interest in SVBus. I use a full disk encryption program called BestCrypt Volume Encryption. Long story short, it insists on having its' MBR on one of my internal drives, even if I use the option to move its' loader to an external source. I like being in control of what is in my drives' MBRs, I have 3 internals in total. BCVE can work in UEFI mode as well, but I am using MBR and legacy boot on all 3 disks.

 

So I came up with an idea, install Windows 10 boot files to either a flash drive (current working idea) or into a partition inside a VHD/raw IMG, then encrypt my partitions (minus the bootable media where BCVE loader is located, of course). End result is that BCVE installs its' MBR into either the flash drive or virtual disk file. I can also use RMPrepUSB's disk to file function to convert the flash drive into a raw IMG. I currently have an IMG of the flash drive, as well as a VHD that was converted from IMG with CloneDisk.

 

But now I have to find a way to load said file at boot, and I think SVBus might be the ticket.....just a bit of trouble getting the process down.

 

The setup:

1. A 4GB NTFS partition on internal HDD, marked active/bootable, and contains GRUB4DOS's files and menu.lst, also contains the IMG/VHD of the flash drive in the root

2. G4D installed into the MBR of internal HDD, it contained no boot code before, just a partition table and disk signature

3. 2nd partition on this HDD is where SVBus's test C drive is installed along with its' driver, which I integrated into my WIM with misty's instructions (could not get the driver to be shown as loaded in Device Management when using that same WIM to install into VMware/VirtualBox)

4. A 1GB partition on a flash drive, which contains stock W10 boot files created with bcdboot, and BCVE's MBR

 

I have confirmed that SVBus is loaded properly in Device Manager when using the alternative signed driver provided on pg1 of this thread, Test Mode is not on and integrity checks are not disabled in the BCD. So now I just need to get G4D to load the MBR of either of the images (they are identical besides the added VHD footer in the VHD), pass it off to SVBus, which should hopefully load it as a virtual hard disk that Windows can see and identify as its' boot partition. And then, hopefully, BCVE is happy and doesnt either try to replace one of my internal drive's MBRs, or nag that the MBR has been changed. These images are exact copies of the flash drives, so BCVE shouldn't be able to know that it has been moved.

 

Contents of menu.lst:

timeout 5
title Reboot
reboot
 
title Poweroff
halt
 
title SVBus With BestCrypt
find --set-root /SVBusBoot.img
map /SVBusBoot.img (hd0)
map --hook
rootnoverify (hd0,0)
chainloader hd0,SVBusBoot.img
 
I'm pretty sure I got something wrong, upon trying to load the 3rd entry G4D contains that the exact path of the file must be specified. But I only need to load the MBR of either image, SVBus takes over, then authenticate.
 
I've been working on this all night and made no progress on creating a menu.lst that works to accomplish this, so time to sleep, I'll try again later.


#86 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15042 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 September 2019 - 12:10 PM

This is not syntatically correct (besides making little sense generally):

chainloader hd0,SVBusBoot.img

 

should be:

chainloader (hd0)+1

 

Breakout:

 

find --set-root /SVBusBoot.img <- find image files SVBusBoot.img in the root directory of *any* device and establish current root to it
map /SVBusBoot.img (hd0) <- map the (relative to the current root path) image to device hd0 (first hard disk)
map --hook <- hook, i.e. make it "definitive" the new mapping above, from now on device hd0 is SVBusBoot.img (to be more exact the whole contents of /SVBusBoot.img are now accessible as device hd0)
rootnoverify (hd0,0) <- establish root (without any verification) to the first volume of (hd0): this makes nothing useful

 

chainloader (hd0)+1 <- continue booting the first sector of (hd0), i.e. its MBR, i.e. the MBR of the SVBusBoot.img image (mapped to hd0)

 

As always it is strongly NOT suggested to pre-make a menu.lst entry, this should be done only after having tried succesfully the intended sequence of commands on the command line.

 

The last two lines:

 

rootnoverify (hd0,0)

chainloader (hd0)+1

 

Should actually be:

rootnoverify (hd0)

chainloader +1

 

And most probably a single line:

chainloader (hd0)+1

would do as well.

 

:duff:

Wonko



#87 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 737 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 07 September 2019 - 06:22 AM

Current menu.lst:

 

timeout 5
 
title SVBus With BestCrypt
find --set-root /SVBusBoot.img
map /SVBusBoot.img (hd0)
map --hook
rootnoverify (hd0)
chainloader (hd0)+1
 
title Reboot
reboot
 
title Poweroff
halt
 
I did each line one at a time in command line. There are no errors, but G4D does give a messing about probing CHS and sectors. I think it has found the img successfully, when I do:
 
find --set-root /SVBusBoot.img
 
It says it is on hd0,0. So It sounds like I am trying to map my img to an internal drive that already is hd0. After putting in the last line nothing happens, just a blinking cursor.
 
Since I have 3 internal drives, I tried using hd3 instead, so G4D wont map the img to one of my drives. But same results. I am aware that G4D sets the drive it boots from as hd0.
 
Edit: I have also opened my flash drive and img in Tiny Hexer, to confirm that they do indeed have a MBR, partition table, and disk signature. All 3 are present, and the MBR/sector 0 is identical. There is only 1 1024MB NTFS partition in the disk. But, since I am using encryption, I cannot directly chainload the bootmgr in this volume, instead I need to chainload the img's MBR. Not sure why G4D won't do it. Or, at the very least, give an informational message.


#88 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15042 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 September 2019 - 08:05 AM

The blinking cursor is typically the result of either:

1) bad code in the MBR or in the PBR

2) bad offset to the PBR

3) bad geometry of the device (IF CHS access is used)[1]

4) mismatched geomety in the PBR [1]

 

But in the case of your particular setup it may well be due to other reasons, no idea on how actually the BestCrypt code in the MBR works.

 

If I were you, since you had a USB stick that is working, I would try making an image of the stick "as is" and use that as "SVBusBoot.img".

 

Or anyway make a test with a "big enough" image, i.e. one larger than 1024*255*63*512=8422686720 bytes, and see what happens.

 

If the large image works then the issue is connected with CHS (items #3 or #4 in the above list).

 

:duff:

Wonko

 

[1] most BIOSes will assume a given geometry as a function of the size of the (virtual) device, very small devices will likely be mapped with 16/63 geometries or in some cases even "smaller" ones.



#89 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 737 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 07 September 2019 - 08:12 AM

@Wonko: Did you read my 2 prior posts? I already did make an img of my flash drive with RMPrepUSB. Are you saying that i will need to use an unnecessarily large img to get this to work?



#90 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15042 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 September 2019 - 08:42 AM

@Wonko: Did you read my 2 prior posts? I already did make an img of my flash drive with RMPrepUSB. Are you saying that i will need to use an unnecessarily large img to get this to work?

Yes, for testing only purposes.

 

An image that exceeds the upper limit of the CHS addressing will be accessed by the BIOS as having a 255/63 HS geometry (which is the default geometry since XP and  that most probably was used when your USB stick has been formatted and the Bestcrypt MBR installed to) and LBA access will be used.

 

If that is the issue, then we will later find a way to reduce the size of the image.

 

:duff:

Wonko



#91 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 737 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 07 September 2019 - 08:46 AM

@Wonko: My flash drive is a 8GB PNY (old, very slow, runs at 2.0 speeds, but suitable for testing). I have extended its' 1024MB partition to span the rest of the drive. RMPrepUSB is imaging it now, I will report boot results shortly.



#92 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 737 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 07 September 2019 - 09:10 AM

Success!

 

By resizing the partition from 1024MB to 8GB, it loaded the BCVE MBR, I was able to enter password, W10 boots. And Disk Management even shows the img as a real physical disk approx 8GB in size, and marked as the System (boot) partition. BCVE also doesn't complain about a tampered MBR, and doesn't replace G4D on the internal HDD to which the SVBus C drive is installed. And the flash drive was not plugged in during boot. So it appears that SVBus is working, it's nice to know that it will be useful for my purpose.

 

Screenshot:

 

w6432qx.jpg

 

But I had to edit the commands a bit in G4D, this is what worked:

 

timeout 5
 
title SVBus With BestCrypt
find --set-root /SVBusBoot.img
map /SVBusBoot.img (hd3)
map --hook
chainloader (hd3)+1
 
title Reboot
reboot
 
title Poweroff
halt
 
I had also tried substituting hd3 with hd0 but I got the same results as posted above, no errors, no boot, just a message about CHS and sectors.
 
So now, we know it is something to do with the CHS/size.


#93 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 737 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 07 September 2019 - 09:20 AM

Q1f4NKC.jpg

 

RVJDNQz.jpg

 

eXPG3wq.jpg



#94 steve6375

steve6375

    Platinum Member

  • Developer
  • 7071 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 07 September 2019 - 09:23 AM

maybe try the smaller .img and use

 

map --heads=255 --sectors-per-track=63 /SVBusBoot.img (hd3)

 

??

 

You did make the smaller images using  start=0 and length=P1 ?



#95 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 737 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 07 September 2019 - 09:38 AM

@steve6375: In RMPrepUSB I used start=0 and length=PALL. It looks like P1 and PALL are essentially the same, since the flash drive has just 1 1024MB primary partition (I resized it back to its' original size and am making another image now).



#96 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 737 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 07 September 2019 - 10:04 AM

Bad news, and just when I thought I had a breakthrough:

 

I resized the flash drive partition back down from 8GB to 1024MB, then created an img of the drive with RMPrepUSB

 

My menu.lst:

 

timeout 5
 
title SVBus With BestCrypt
find --set-root /SVBusBoot.img
map --heads=255 --sectors-per-track=63 /SVBusBoot.img (hd3)
map --hook
chainloader (hd3)+1
 
title Reboot
reboot
 
title Poweroff
halt
 
This works to boot up Windows from G4D with BCVE, but I get this in Disk Management:
 
sxOQHby.jpg
 
The boot partition is shown as raw, not NTFS. If I bypass G4D and boot from the flash drive, it reads as a 1GB partition on a 8GB flash drive, and it is shown as NTFS.
 
So basically, what I have now is a bootable floppy that disappears after Windows boots, but otherwise works. I believe the SVBus driver is responsible for this behavior. I'm guessing there is probably not a menu.lst tweak I can make that will resolve this issue.


#97 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15042 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 September 2019 - 01:11 PM

From what I can see in the disk manager screenshot you posted the issue is not SVBUS, but rather BestCrypt.

 

I mean the SVBUS:

1) mounted the device just fine
2) passed it to the mount manager (that gave it the S: drive letter) just fine

3) the disk manager sees it just fine (Healthy, System, Active)

 

but if the volume is encrypted (and for some reasons Bestcrypt doesn't hook it and decrypts it automatically) the result is RAW.

 

Maybe (no idea if this is actually possible) Bestcrypt has a manual command to forcefully "hook" and decrypt a volume?

 

Or maybe (just like BIOS) it expects a different CHS geometry for smaller volumes?

 

Right now, with the "--heads=255 --sectors-per-track=63" you are "forcing" grub4dos to mount the image with that geometry, and SVBUS should hook it with that geometry (or maybe geometry is not relevant for it :unsure:) but that doesn't mean that another program expects the "right" geometry for the actual image size.

 

Is the PBR BPB actually encrypted by Bestcrypt?

 

:duff:

Wonko 



#98 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 737 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 07 September 2019 - 08:18 PM

@Wonko: As stated, W10 boots fine if i only use the flash drive. It appears as NTFS and as the volume where boot files are stored. Drive letter assignment isnt automatic, I added it manually. But, SVBus doesnt kick in when I'm using the flash drive, it doesnt need to (no img/vhd involved, and G4D is bypassed). And since it is not seen as raw, BestCrypt apparently has no issue with a 1GB boot partition either (even though the FD is much bigger).

 

The 1GB image, on the other hand, is not representative of the entire FD, since the image only covers the FD up to the end of 1st partition, with the rest excluded. But up to that point they are byte for byte identical. So if there is an issue with geometry/size then why does the issue manifest with my img's chosen size, but not with the FD?

 

And to answer your question, BestCrypt never encrypted the FD, it only detected it as the boot file location and installed its' MBR to it. I stated as much in a previous post that the FD was not encrypted, either I'm not being clear enough, or someone isnt reading. Anyway, this should have either overwrote Windows native boot code (installed to FD with bootsect), or moved it outside the MBR and beyond the 1st partition (so it can be loaded by BCVE MBR loader later, if that is possible), which means it isnt in my img (probably doesnt matter).

 

I guess there is only one way to find out if BestCrypt is responsible: reinstall from my custom wim with SVBus integrated, but dont install BestCrypt. Make a 1GB image of the FD and boot it with SVBus and G4D. If it boots but shows as raw then SVBus is the issue. Will take a few more hours to test since I'm busy ATM with other things.



#99 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15042 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 08 September 2019 - 08:46 AM

The (possible) issue with geometry, at least at BIOS level is (would be ) not linked to the size of the volume but to the size of the device (the whole thing).

 

I.e. if you make an image of the whole USB stick when there is only the 1 GB volume in it (but the image remains some 8 GB in size) it should behave the same as when you had a larger 8 GB volume (and image).

 

What is "strange" is that once the thingie has booted the CHS geometry should be irrelevant, as *anything* in NT should be accessed via LBA.

 

It is possible that for some reasons CHS address and LBA don't match? :unsure:

 

I doubt it, but if the volume PBR is not encrypted, post a copy of the PBR (only first sector is needed) and of the MBR.

 

Anyway if the issue is with the geometry, instead of forcing grub4dos to use the 255/63 one, the solution would be to correct the geometry to what the *whatever* is appropriate (16/63 will be too little, maybe 128/63? :dubbio:)

 

What is the exact message about CHS that you get in grub4dos (without using the heads/sectors parameters)?

 

  :duff:

Wonko



#100 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 737 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 08 September 2019 - 09:35 PM

@Wonko: I finished my test without BC, it seems (by process of elimination) that BC may be the cause of the partition showing as raw. Steps:

 

1. Create a 1st partition on HDD, install custom SVBus-integrated WIM to that

2. create a 2nd partition on HDD, marked as active, to hold G4D files and an img

3. Zero out a small portion of the flash drive with dd, create MBR partition table, and a single primary/active NTFS partition, install boot files with bcdboot, and MBR with bootsect

 

Gparted was used to create all partitions. Windows boots from flash drive. Then:

 

1. Create img of flash drive up to end of this partition

2. Boot this img with G4D using the following menu.lst:

 

title SVBus Without BestCrypt
find --set-root /SVBusBoot.img
map --heads=255 --sectors-per-track=63 /SVBusBoot.img (hd3)
map --hook
chainloader (hd3,0)/bootmgr
 
I also tried:
 
title SVBus Without BestCrypt
find --set-root /SVBusBoot.img
map /SVBusBoot.img (hd3)
map --hook
chainloader (hd3,0)/bootmgr
 
It booted with or without heads/sectors being specified, and no need to boot the MBR because of encryption not being present. I guess this works because I am only chainloading bootmgr instead of the MBR. But why? However, I did verify the presence of an MBR and tried to boot it with:
 
chainloader (hd3)+1
 
But G4D (or the BIOS, not sure) complained that something wasnt bootable.
 
Anyway, on both tries Disk Management in Windows 10 showed the disk as 1GB, marked as active, as the system (boot) volume, and with an NTFS filesystem.
 
I cannot try to answer your other questions without testing BC again, so that is next.






Also tagged with one or more of these keywords: svbus, virtual scsi host adapter, grub4dos

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users